Fork the source
Fork github.com/oyst12rsas/taransvar. Review it, record your configuration and keep your own changes auditable.
TARASEC FOR BUSINESS
Don’t wait for cooperative cybersecurity to be proven. Help prove it.
Keep the security controls you already trust. Add TaraSec in a controlled way, test it with infrastructure you control, measure what happens and help determine whether cooperative security can reduce cybercrime pressure across networks.
STEP 1 — BASIC SECURITY
Start with ordinary security hygiene.
TaraSec is not a replacement for basic security. Patch systems, reduce exposed services, use strong authentication, separate administrative access from public services, keep backups and logs, and restrict management traffic to the sources that need it.
The public Taransvar repository contains the current experimental firewall, routing, SSH and reporting work. Use the current source as the technical reference rather than relying on old copied instructions.
Security engineering always carries implementation risk. TaraSec is experimental, but that does not make it uniquely risky. Firewalls, VPNs, Zero Trust gateways, cloud controls and other security systems also change traffic and trust boundaries. The meaningful comparison is measured risk and benefit, with staged deployment, observability and rollback.
STEP 2 — ELEVATED SECURITY
Fork it. Establish your own router. Self-host the systems you test.
A business should be able to reproduce and inspect the TaraSec environment independently instead of trusting a black box operated by somebody else.
Establish your own TaraSec router
Use a Linux router or gateway you control. It can begin as a dedicated test router and later take on more responsibility if the evidence justifies it.
Self-host test VMs
Create VMs for servers, targets, honeypots and clients. Generate known-good and known-bad traffic and verify exactly what is reported and how other participants respond.
Join the TaraSec test network
Approved test systems can participate through the project’s NetBird environment while your organisation keeps control of its own hosts, routing policy and security boundaries.
Measure instead of assuming
Record attacks, false positives, false negatives, latency, failures, contradictory evidence, recovery and administrative impact. Negative results are useful evidence too.
Scale on evidence
Expand only when the results justify it. Keep rollback available, just as you would for any other change to production security infrastructure.
SSH & ADMINISTRATIVE ACCESS
Use a TaraSec router as a guarded login point for your servers.
One elevated-security deployment is to make a dedicated TaraSec-controlled router or login gateway the administrative entry point for SSH access to other servers. Public SSH attempts can terminate at a controlled gateway or honeypot boundary, while real administrative SSH is restricted to an alternate port, trusted sources, VPN paths or other explicit policy.
The gateway can log connection attempts and security observations and contribute those observations to TaraSec, while the protected servers are less directly exposed. It remains additional security context rather than a substitute for SSH keys, MFA, host hardening or normal access control.
The current Taransvar firewall work already includes configurable SSH source restrictions, SSH port handling and recovery protection, making this a natural area for reproducible business testing.
SECURITY RISKS — CHALLENGE THEM
A cooperative security network creates new attack surfaces. Find them before attackers do.
TaraSec should be judged against realistic failure modes, not against an imaginary risk-free alternative. The project explicitly invites businesses, students, red teams, researchers and security engineers to challenge the implementation and the underlying model.
Compromised participant
A trusted router, gateway or reporting node could be taken over and begin sending false information or manipulating traffic. Test containment, revocation, trust reduction and how quickly other participants can stop relying on it.
False or malicious reports
A participant could intentionally or accidentally report legitimate traffic as malicious. Test provenance, corroboration, conflicting evidence, dispute handling and whether false attribution can be reversed quickly.
Incorrect traffic tagging
Software bugs or bad correlation could associate threat information with the wrong unit or flow. Measure false positives, scope of impact and whether downstream systems can distinguish confidence levels rather than treating every signal as absolute.
Routing and forwarding mistakes
A TaraSec router could black-hole legitimate traffic, leak traffic onto the wrong path, create loops or fail open/closed at the wrong time. Test route withdrawal, failure behaviour, rollback and recovery after partial network failure.
VPN and test-network trust
NetBird or another overlay creates additional trust relationships. Test what a compromised peer can reach, whether segmentation is adequate, and whether joining the test network exposes services that were previously unreachable.
Login gateway compromise
A router used as an SSH login point becomes security-critical. If compromised, it could expose credentials, sessions or protected servers. Test key handling, MFA, privilege separation, logging, isolation and whether the gateway can be bypassed safely during recovery.
Denial of service through cooperation
Attackers may try to abuse reporting, tagging or assistance mechanisms to make participants block legitimate users or waste resources. Test rate limits, amplification potential, resource exhaustion and safe degradation under load.
Privacy and metadata leakage
Even without names or customer identities, traffic metadata and persistent technical identifiers can become sensitive. Test what participants can infer, what must remain local and whether the minimum necessary information is actually being shared.
Supply-chain and update risk
Forks, packages, dependencies, deployment scripts and automated updates can all be compromised. Test signatures, reproducible deployment, code review, dependency control and whether an organisation can pin and independently verify what it runs.
Unsafe defaults or configuration drift
A secure design can still fail through a bad default, stale firewall rule or inconsistent configuration between nodes. Test fresh installs, upgrades, rollback, repeated deployment and whether the system detects configuration drift.
Recovery and reputation failure
A unit that was compromised may later be clean, and a unit may also have been wrongly classified in the first place. Test whether evidence can lower confidence, clear status and propagate corrections before a temporary mistake becomes a lasting penalty.
Central-service or governance failure
Any shared database, coordination service or governance function can become a target or source of systemic error. Test degraded operation, loss of connectivity, malicious administration, conflicting authorities and whether participants retain meaningful local control.
Challenge TaraSec. Try to compromise a participant. Try to create a false report. Try to make legitimate traffic disappear. Try to abuse recovery. Try to learn more metadata than you should. Try to make one compromised component damage the whole network. A credible result is valuable whether it strengthens TaraSec or demonstrates that part of the model must be redesigned.
Responsible findings should include enough detail to reproduce the problem, the expected impact, affected components and a proposed test for the fix. The goal is not to defend the current design at all costs; it is to discover whether cooperative cybersecurity can be made safer and more effective than the fragmented model it is intended to improve.
JOIN TO HELP PROVE IT
The evidence cannot be produced by TaraSec alone.
Why join before the model is proven?
Because a cooperative security model can only be tested properly when independent networks participate. Businesses can help determine whether accountable sharing of security observations actually reduces unwanted traffic, improves attribution and moves useful intervention closer to the source.
Start with infrastructure you control: a router, a few self-hosted VMs and controlled traffic. Preserve normal protections. If TaraSec performs worse, document it. If it performs better, publish the measurements. Either result moves the project forward.
The point is not blind adoption. Join to prove TaraSec right, prove it wrong, or show exactly what has to change.
FROM PARTICIPATION TO MARKET PRESSURE
Enough participating customers can change what ISPs and hosting providers are expected to deliver.
Ask ISPs to act closer to the source
If customers can demonstrate useful reports and lower unwanted traffic, they have a concrete basis for asking access providers to identify and act on malicious activity within the originating network rather than leaving every destination to defend itself independently.
Ask hosting providers to cooperate
Hosting and cloud providers see enormous volumes of attacks and abuse. Participation can turn those observations into accountable input for the networks that know the technical source.
Create pressure through demand
A single organisation has limited leverage. A growing set of customers asking for compatible reporting, attribution and response creates commercial and operational pressure for providers to support cooperative security.
Reduce total cybercrime pressure
The hypothesis is larger than protecting one company. If useful intervention happens closer to compromised sources, the same malicious traffic should not need to be detected, processed and blocked independently by thousands of destinations.
That is the business invitation: improve your own security, help test the cooperative model, and use the evidence to demand better security behaviour from the networks and providers you already pay.
PARTICIPATE
Bring a router, a VM environment, a security team — or simply a willingness to test.
Businesses, ISPs, hosting providers, universities and public organisations are welcome to test the current implementation, challenge the architecture and contribute measurements.
Øystein Torsås
+47 99647892
oystein@taransvar.no
TaraSec is an initiative of Taransvar, Norwegian organisation no. 992 132 027.