Basic installation
Install the components for the node’s role, set its identity and access policy, and confirm that the reported status matches actual listeners, routes and firewall rules. Keep a working way back in.
SAFETY & LIMITATIONS
Is it safe?
TaraSec aims to provide a practical starting template: install the basic protection and monitoring components, verify that they work, then harden your own servers to the level your environment requires. Choose your own tools and path for professional operations.
1 · SECURITY AGENT
Monitor the setup. Ask before making a change.
A node-side agent checks specific security settings and reports short findings under a pseudonym chosen in its configuration. When it finds a supported problem, it can propose a narrowly defined repair with the command, conditions, expected effect and rollback shown to the operator.
An authorized operator signs in to the approval page with a Google account and enters a fresh Google Authenticator code for each approval. Approvals expire. The node rechecks its conditions before executing the approved action. An unapproved proposal cannot be executed by this workflow.
Current scope: the agent performs limited configuration checks and can propose disabling an obsolete, already failed gateway service on a non-gateway node. It does not yet provide comprehensive AI analysis or certify that a server is secure. Set up operator two-factor authentication →
2 · CORE NETWORK PROTECTION
Share attack evidence. Apply local policy.
When a participating network detects suspicious traffic, TaraSec can report the observation toward the originating network so it can identify and respond to the responsible technical unit. Participating systems can carry threat context with later traffic. A receiving node can drop traffic when a received tag exceeds its configured severity threshold.
For protected SSH, the kernel policy can reject connections from units whose recorded severity exceeds the configured SSH threshold. On configured demo nodes, a separate honeypot can listen on port 22 while the real SSH service runs on its configured port behind firewall and SSH authentication. These protections depend on correct routing, tagging, kernel deployment and effective firewall rules; a tag alone is not a universal SSH block.
Source code and installation material are available in TaraSec Core. The effectiveness of each control still depends on how it is deployed and verified. We welcome independent review, reproducible tests and improvements to the baseline.
YOUR DEPLOYMENT PATH
Start with a working baseline. Harden it as far as you choose.
The goal is a repeatable installation with the basic node services, traffic policy, monitoring and recovery checks ready to configure and verify. TaraSec should be a useful template for someone bringing up a server, not a claim that every host is already hardened. Check the installed role, SSH access, IPv4 and IPv6 firewall behavior, forwarding, updates and rollback before relying on it.
Stronger operation
Add the authentication, monitoring, alerting, backups, recovery drills, change review and independent testing that your deployment needs. Document who responds when a check fails.
Your choice of tools
You control your servers. Use TaraSec’s defaults where they fit and combine them with your preferred Linux, network, identity and security tools. Apply stricter policy where the risks justify it.
Some capabilities on this page are still limited or planned. The sections below say what is currently checked and what requires further implementation and validation.
WHAT IS AVAILABLE NOW
Existing mechanisms and the configuration they need.
These components exist in the current TaraSec code or live operator service. A component is useful only after it is configured for the node’s role and checked on the running machine. Keep actual credentials in private configuration, never on this page or in a public report.
Traffic and SSH policy
The node software can report rejected traffic, apply received threat context and enforce configured thresholds. The SSH honeypot and real administrative SSH port are separate where deployed. Configure the node role, SSH port, firewall and tagging policy; then verify IPv4 and IPv6 rules, listener state and forwarding on that node. Kernel protection depends on the modules actually being installed and active.
Server checks and recovery
The installed server worker checks selected SSH, firewall and service evidence and reports an assessment. An operator can approve its currently supported fixed repair. Optional bounded SSH containment requires an explicit local policy and a fresh independent recovery-console heartbeat; its rule has an automatic rollback timer. This is not unrestricted AI command execution.
Operator approval
The live approval page uses an authorized Google account and a separate time-based authenticator code for each approval. TaraSec must configure the Google Web client ID and website origin, operator allowlist and private authenticator secret. The client ID identifies the web app; the authenticator secret must remain private. Additional authentication methods are not enabled by values in the node policy file.
Node identity and test access
Each reporting node keeps its own random bearer token locally; TaraSec registers only its hash. A token alone cannot approve an operator action. Remote app testers need an individual WireGuard configuration and QR code unless they are already connected through a TaraSec hotspot or node. Treat the WireGuard QR code as a credential and do not publish it.
Where configuration lives: node role, SSH and nickname settings such as IS_GATEWAY, SSH_PORT and AGENT_PUBLIC_NICKNAME belong in the node configuration. AI_AGENT_MODE, console heartbeat and SSH action permissions belong in the separate server-manager policy. The node bearer token, operator authenticator secret and tester WireGuard QR are credentials; their values stay private. See the node and operator setup guide for current setting names and limits.
Still to finish: deployment automation, broader operating-system monitoring, independent security review, stronger operator authentication choices and a connected AI model need implementation or validation before they can be described as standard protection on every node.
3 · GLOBAL AI SUPERVISION
An opt-in research direction.
We are exploring AI that could compare security signals across participating networks and, if an operator enables it, help review activity and configuration on that operator’s servers. It should report evidence and suggest actions for human review rather than silently change a server’s policy.
Development status: this wider, opt-in supervision is a proposed research direction, not a service that continuously monitors every TaraSec server today. The current local agent above has a much smaller set of checks. Decisions about what data leaves a server, who can see it and what an AI is allowed to recommend require design and testing with participants. Read about the AI architecture →
WEAK SPOTS & OPEN QUESTIONS
Does TaraSec add risk, or reduce it?
Both are possible. Extra protection has to outweigh the new software, network links, credentials and decisions it introduces. We intend to measure that, not assume it.
New attack surface
The kernel module, node agent, web approval service and reporting paths need hardening and independent review. An operator account, authenticator secret or node token that is stolen could undermine an approval workflow.
Wrong or manipulated signals
A false report, forged or misread tag, compromised participant or mistaken attribution can block legitimate traffic. Provenance, corroboration, thresholds, appeals and correction must work in practice.
Configuration drift and outages
A firewall rule in the wrong order, a missing IPv6 rule, a lost persistent rule after reboot or a broken partner link can leave protection weaker than the dashboard suggests. Monitoring needs independent reachability and recovery tests.
Privacy and AI limits
Network observations can reveal sensitive activity. Opt-in AI must minimize what is shared, restrict access and retention, and distinguish a useful suggestion from an unreliable conclusion.
Our intention is clear: provide a more secure network while exposing the assumptions for public scrutiny. Join the security challenge, explore suggested student and research projects, read the source and technical documentation, or contact us with a weakness you have found.
OPERATOR TWO-FACTOR AUTHENTICATION
Set up Google Authenticator for approvals.
The administrator first configures your exact Google email address and a unique authenticator setup key in the website server’s private configuration. Ask for the key through a trusted channel. If the page says “Authenticator setup required,” approvals are disabled until this step is complete.
- On your phone, open Google Authenticator and tap +, then Enter a setup key.
- Choose a name such as TaraSec approvals, enter the setup key, and select Time based. Save the entry.
- Return to Gatekeeper agent approvals, sign in with the same authorized Google account, review a proposal, then enter the six-digit Authenticator code when approving it. Each approval needs a fresh code.
The setup key stays in the private server configuration and your authenticator. Never paste it into the approval page, a public issue, or a chat. The approval page accepts only the changing six-digit code. If you lose access to the authenticator, ask the administrator to rotate the key and enroll again.
This code is for approving agent repairs; it does not change SSH authentication. Securing your Google account with its own two-step verification is also recommended.