ADDED SECURITY
Basic security measures
TaraSec adds layers of protection around administrative access, attack detection and response.
- SSH moved away from port 22. Administrative SSH uses a separate configured port.
- Honeypots on port 22 and 1,000 additional ports. Decoy services detect attempts to access ports that have no legitimate login purpose.
- Authorized SSH sources only. Administrative SSH accepts connections only from explicitly allowed source addresses or networks, including during a temporary MFA opening.
- Certified partner routers for login. The intended policy accepts administrative SSH only through registered partner routers with active certification meeting the node owner’s minimum level.
- SSH key authentication. Real administrative access requires an authorized key.
- SSH closed; MFA to open it for five minutes. The intended access flow requires an authorized Google login and multi-factor authentication before a temporary opening.
- Tagging on the first miss; blocking across TaraSec units. A detected honeypot hit or rejected attack attempt is reported so the responsible unit can be tagged and participating units can block its traffic.
- AI agent monitoring. The server agent checks security settings and attack activity and reports findings; connected AI analysis extends this monitoring.
- Reports and alarms in the signed-in app. The intended app flow gives the authorized manager threat reports and alerts for linked units.
These are added security measures. Their effect depends on which components are installed, enabled and working on each unit.
COLLECTIVE SECURITY
Security grows through participation
TaraSec is built on collective security. Imagine a neighbourhood where an intrusion at one house makes dogs across the neighbourhood bark: others receive a warning and can respond. Participating networks report rejected attack traffic and share warnings so other participants can take protective action.
Local deployments protect participating networks and provide a starting point for wider cooperation. As more gateways, organisations and internet providers join, warnings can reach more receivers and more networks can act at the source. Adoption by major telecom operators would extend that protection to far more users. Helping the concept spread is part of building its protection, alongside securing each participating system.
Better routers protect more than their owners
Poorly secured Wi-Fi, routers and connected devices can be compromised and used to attack people elsewhere on the internet. Improving their security benefits both the owner and others exposed to traffic from those devices.
TaraSec aims to give telecom operators an incentive to supply better-secured routers and participate in cooperative detection and response. Customers can ask their provider which protections it implements, how it handles attack reports and whether it participates in this cooperation.
Know the security policies at the other end
The proposed partner-certification model would make another participating provider’s security policies and verified certification level visible: for example, router access controls, updates, reporting and response practices. This gives receiving networks an additional basis for applying their own access and traffic-handling policies.
Policy declarations should be distinguished from verified controls, with the verification date, validity and restrictions shown. The authenticated distribution and enforcement of that information is still a next implementation step, as described below. A certified provider does not guarantee every device behind it is clean; traffic detection and protective controls remain necessary.
DEPLOYMENT
The agent should suggest your next step to harden login
Start with the protection actually running on your unit. The agent should identify the next missing login control, explain why it matters and propose a concrete change with a way to recover access.
- Check current access. Verify the SSH listener, authorized keys, password and root-login policy, firewall rules and an independent recovery console.
- Recommend the next improvement. For example, test key login before disabling passwords; then restrict administrative SSH and enable the five-minute MFA opening when its recovery path is ready.
- Review and apply. Show the proposed change, its effect and rollback to the authorized manager. Use the operator approval workflow for supported changes.
- Verify and continue. Test legitimate login, rejected access and automatic closure. Report the result to the signed-in app, then suggest the next remaining improvement.
Your node, your decision
The node belongs to its owner, not TaraSec. AI can recommend and implement improvements within the owner’s authorization and local policy without waiting for TaraSec team approval. If team review has not been verified, the recommendation should be labeled: “Recommended by AI; not yet reviewed or authorized by the TaraSec team.” This identifies its status; it does not prevent the owner from using it.
Verified fixes can be contributed to the shared routines for review. An owner’s local change is not automatically a TaraSec-endorsed default.
Every new node helps improve the routines
When someone deploys a TaraSec node, the AI should suggest hardening steps suited to that node. Each step within the agreed deployment scope is also an opportunity to test the installation, access controls, alerts and recovery routines on a real deployment.
Routine bug fixes, tests, documentation changes and compatible hardening improvements should be implemented and verified without repeated authorization. If a check fails, the agent should record the expected and observed result, help diagnose the fault and propose a fix. Verify the correction on that node and use the findings to improve the shared routines and documentation for the next operator. Share only the diagnostic details the operator authorizes, with credentials and personal data removed.
Deployment goal: a specific next action based on the unit’s observed state, with unverified controls clearly identified. The current agent’s limited checks and supported actions are described below.
What is working, and what still needs verification?
The core supports rejected-traffic reporting, tagging and blocking under the receiving unit’s configured policy. Administrative SSH and honeypots must be configured separately, including the decoy port range and key authentication. A first detection can start the response; network-wide enforcement depends on report delivery, attribution and active protection on the participating units.
The current server agent performs defined security checks and reports assessments. Its installer does not connect an AI model. The operator approval page already requires an authorized Google account and a fresh authenticator code.
The five-minute MFA SSH opening and app alarms need deployment verification. Google login and MFA for approving agent changes do not by themselves enable temporary SSH access. These access and notification flows should be described as active on a unit only after they have been tested there.
Certified partner access is a next implementation step. Local partner addresses already reach the kernel, and the DB provides a partner-restriction feed. Certification levels and their defined requirements, validity, revocations and versioned partner information still need distribution and enforcement for administrative SSH. Registration alone does not establish a certification level.
The DB should supply authenticated partner information; each node should enforce its owner’s minimum certification level from a validated local snapshot. Updates must remove suspended, revoked or expired eligibility promptly. Missing or stale certification must not create a new login permission. Certification identifies the registered router’s assurances; access checks must also verify the connection’s association with that router. Source restrictions, SSH keys and MFA remain required.
Node and operator setup guide · Server agent · Reported node status
CONTINUING HARDENING
Reduce the remaining risks, step by step
When the basic controls are working and verified, TaraSec provides several layers against unauthorized SSH access, with detection and coordinated response. The next priorities strengthen the software, reporting and recovery behind those controls.
| Area | How to reduce the remaining risk |
|---|---|
| Kernel and privileged services | Review packet parsing, test malformed traffic, limit resource use and fix defects. Isolate honeypots from administrative services. |
| Reliable cooperative blocking | Authenticate reports, verify the responsible unit, expire blocks and test release. Limit the influence of any one participant. |
| DB and management services | Separate credentials and use minimal permissions. Enforce local safeguards so a central fault cannot grant unrestricted control over nodes. |
| AI-assisted administration | Base actions on observed evidence, validate changes, preserve recovery access and verify results. Use each deployment to improve shared routines. |
| Administrator access | Combine certified partner access at the owner’s minimum level, authorized sources, SSH keys and temporary MFA openings. Strengthen account authentication with passkeys or security keys and support prompt credential revocation. |
| Availability and recovery | Rate-limit honeypots and reports, monitor actual protection and test reboot, IPv6, automatic SSH closure and recovery. Specify whether expiry blocks new connections or also ends existing sessions. |
Make these repeatable deployment checks. Each new node provides evidence that protection works and an opportunity to repair routines that fail. These are hardening priorities, not a claim that every mitigation is already implemented.
Check the protection on the running unit
Verify the real SSH port, allowed source addresses and key policy, honeypot listeners, IPv4 and IPv6 firewall rules, first-hit reporting, tagging and blocking. Test that temporary SSH access closes again and that the authorized app receives the alert. Keep an independent recovery path.
Incorrect reports can block legitimate traffic. Missing modules, broken reporting or stale status can leave protection incomplete. TaraSec’s own software also needs independent review.