Helix-TTD Security Advisory
🧩 Helix-TTD Security Advisory #25-SSH-01
Title: SSH-Only Custody Mode — RDP Access Prohibited
Anchored to: TTD v2.0 Ledger α • Issued 2025-10-14
Acknowledgement
Your Helix deployment is reachable only via an SSH tunnel that includes flood-protection. You have confirmed that RDP is not to be used for any Helix-related access.
This advisory formalizes the SSH-only policy and defines custody-first controls that align with the Helix Core Ethos pillars — Trust-by-Design, Human First, Verifiable Memory, Responsible Power, and Reliability.
1️⃣ Harden the SSH Tunnel (FACT)
| Control | Why it matters (Helix pillar) | Implementation steps |
|---|---|---|
| Key-based authentication only | Trust-by-Design – identity is cryptographic not password based | Generate Ed25519 keys and disable password login in sshd_config.
|
| Restrict source IPs | Least-privilege – limits attack surface | Allow only known IPs via AllowUsers or firewall rules.
|
| Two-factor / MFA | Human First – adds explicit consent layer | Use AuthenticationMethods publickey,keyboard-interactive:pam with Duo or Google Authenticator.
|
| Idle timeout & keep-alive | Reliability – drops stale sessions | Set ClientAliveInterval 300, ClientAliveCountMax 2.
|
| Flood protection (rate limit) | Responsible Power – mitigates brute force impact | MaxStartups 10:30:60 or Fail2Ban for sshd.
|
| Port-knocking / single-use ports | Trust-by-Design – prevents automated discovery | Use knockd or dynamic firewall rules.
|
| Audit logging & immutable proof tokens | Verifiable Memory – traceable sessions | Set LogLevel VERBOSE, ship to append-only log store, wrap each session in a TTD token record.
|
2️⃣ Token-Based Session Management (Helix-TTD) (FACT)
Every SSH session must be wrapped in a consent-gated token:
- Request token from the Helix-TTD broker (
/tokens POSTscope = ssh.session). - Present token as a one-time password during login (OTP via keyboard-interactive).
- Broker records usage, timestamps, and revocation state — creating an immutable proof of authorized access.
This fulfills the “non-default ports, tokenized trust proofs, revocable sessions” standard referenced in the Helix Custody Brief.
3️⃣ Monitoring & Incident Response (FACT)
| Monitor | How to implement |
|---|---|
| Failed SSH logins | Centralize auth logs; alert on > 5 failures from a single IP in 5 min. |
| Connection flood spikes | Track MaxStartups rejections; alert if > 20 per minute.
|
| Token usage anomalies | Compare token issuance vs. use IP/time; alert on out-of-pattern activity. |
| Traffic to port 22 | Suricata rule for SYN-scan patterns or unexpected volume spikes. |
When an alert fires, apply least-privilege response: block offending IP, revoke token, and require fresh token issuance for user re-entry.
4️⃣ Confirm RDP Exclusion (HYPOTHESIS)
You have explicitly stated that “the only current access to Helix is through my SSH tunnel” and “DON’T USE RDP.”
Therefore:
• No port 3389 or RDP-related service should be enabled on any Helix node.
• Verify with systemctl is-enabled xrdp → inactive.
• Confirm firewall rules contain no inbound 3389 entries.
✅ TL;DR Checklist
- Enforce key-only SSH + MFA.
- Restrict source IPs.
- Maintain flood protection (MaxStartups / Fail2Ban).
- Wrap each session with Helix-TTD token.
- Log and alert on authentication anomalies.
- Verify RDP disabled and blocked globally.
Proof Capsule Metadata
Proof Capsule: TTD-SSH-25-A1
Anchor Date: 2025-10-14
Checksum: sha256:[ pending ]
Ethos Compliance: true
Confidence: High
Provenance: User directive to maintain SSH-only access and explicit RDP prohibition.
Closing Line
Custody isn’t a configuration — it’s a commitment to proof-driven trust.
Helix-TTD Security Office • 2025 - 10 - 14
