Advanced Tor Bridge Security Hardening Guide 2026

A secure bridge server starts with the minimal set of installed software. Use a minimal OS installation: Debian minimal or Ubuntu Server minimal. Remove unnecessary packages after installation (deborphan, apt autoremove). Disable and remove services not needed: www-data web server if not running WebTunnel, mail server (postfix is often auto-installed), print services, display managers. The attack surface is proportional to the number of running services and installed packages. Audit installed services: systemctl list-units --type=service --state=running. Target list for a bridge-only server: sshd, tor, obfs4proxy (or WebTunnel server), fail2ban, unattended-upgrades, cron. Nothing else should be running.

SSH is the primary administration interface and a major attack surface. /etc/ssh/sshd_config hardening: PermitRootLogin prohibit-password (disable root password login, allow key-only), PasswordAuthentication no (key-only authentication), Port 2222 (or another non-standard port to reduce log noise from automated scanners), AllowUsers yourusername (whitelist only your admin account), MaxAuthTries 3 (reduce brute force window), ClientAliveInterval 300 and ClientAliveCountMax 2 (disconnect idle sessions). SSH key configuration: generate ed25519 keys (stronger than RSA), store private key on your management machine only, protect private key with passphrase. Consider Yubikey or hardware token for SSH authentication for high-security deployments.

UFW (Uncomplicated Firewall) provides straightforward firewall management. Bridge server rules: ufw default deny incoming, ufw default allow outgoing, ufw allow SSH_PORT/tcp (your chosen SSH port), ufw allow ORPORT/tcp (Tor ORPort, 443 if using), ufw allow TRANSPORT_PORT/tcp (obfs4 or WebTunnel port), ufw enable. If running WebTunnel: ufw allow 443/tcp for the web server. Rate limiting SSH: ufw limit SSH_PORT/tcp (enables connection rate limiting to slow brute force). Additional iptables rules for DDoS mitigation: limit new connections per IP per minute, drop malformed packets, and enable SYN cookies. Log dropped connections for monitoring but rotate logs to prevent disk fill.

AppArmor provides mandatory access control (MAC) that limits what the Tor process can access even if compromised. Debian and Ubuntu include a Tor AppArmor profile by default. Enable AppArmor: aa-status to verify active profiles, and check if the usr.bin.tor profile is enforced. If not: aa-enforce /etc/apparmor.d/usr.bin.tor. The Tor AppArmor profile restricts Tor to only the filesystem paths it needs (its data directory, the torrc, the control socket) and prevents writing to arbitrary locations. For obfs4proxy: create or apply a custom AppArmor profile restricting obfs4proxy to its binary path and the Tor data directory. AppArmor combined with running Tor as a dedicated low-privilege user (the tor user, created by the Tor package) provides defense in depth.

Fail2ban: configure to ban IPs making repeated failed SSH connections (standard setup) and optionally to ban IPs that repeatedly probe non-bridge ports (SSH scanners). Custom fail2ban filter for Tor protocol violations: if you log Tor connection rejections, fail2ban can ban IPs that make malformed Tor handshakes repeatedly. OSSEC or Wazuh: agent-based IDS that monitors file integrity (detects unauthorized changes to configuration files), log analysis (detects authentication failures, unexpected processes), and real-time alerts. Rootkit detection: rkhunter or chkrootkit scan for known rootkit indicators. Run weekly and after any suspicious activity. Aide (Advanced Intrusion Detection Environment): file integrity monitoring that detects changes to system binaries and configuration. Configure baseline, then run regular checks. Alert if Tor binary or torrc is modified unexpectedly.