Opened 2 years ago

Last modified 2 years ago

#28084 new enhancement

Proposed "Best Practices" for running Tor public network services

Reported by: gman999 Owned by:
Priority: Medium Milestone:
Component: Core Tor Version:
Severity: Normal Keywords:
Cc: phoul Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Proposed Best Practices for Tor Public Services
including directory authorities and bandwidth scanners

In an effort to work towards standardized and current "best practices" for Tor public network infrastructure, this document servers as a starting point. Configuring and maintaining high-uptime internet public services is not a skill anyone is born with, but comes from experience and instruction. Input and updates are vital.

  • Single-Purpose Servers

The most important rule for all Tor public services is that the servers should be configured and maintained for a single-purpose. These are critical servers for the network and millions of users, and extraneous functions can not only deprecate the operation, but provides a large footprint of possible vulnerabilities.

  • Bare Metal over Virtualized

When there's a choice between a "bare metal" versus a virtual solution such as VPS or a cloud instance, opt for the former. Actual server hardware provides lower-level access to the system than any virtualized system. Virtualized systems are sharing various resources, such as processors, entropy sources and so on.

  • Multiple IPs

Multiple IPs are useful to separate remote access via SSHD(8) from the publicly listening services.

  • Operating System and Application Options

Stable versions of both the operating system and applications should be chosen over snapshot or current branches, as the former should require less attention and provide more stability. Tor public network services are not playgrounds to tinker with new software versions. The best operating system to use is the one the administrator is most comfortable with.

  • Full-Disk Encryption (FDE)

FDE is an important aspect of security in the event an adversary takes physical control of the server. For a remote server, some type of console access may be required for FDE password.

  • System Partitioning

Separate partition for the relevant service, in some cases this would be the
${TOR_DATA_DIR}. There are two benefits. First, distinct mount(8) options can be enforced to enhance security such as removing the ability to execute binaries (-o noexec). Second, in the event that the partition reaches full capacity, the server should remain accessible as it's separate from the main operating system's partitions. A minimum partition size should be pre-determined.

directory authority:
bandwidth scanner:
bridge directory authority: current partition utilization is 228Mb

  • Time Synchronization

Reasonably accurate time is critical. All operating systems contain some sort of time-syncing daemon, such as NTPD. Accurate time should not be scheduled with tools like rdate, which perform periodic hard resets of time. Accurate time allows for easier correlation in troubleshooting any issues between remote servers. Setting time to UTC makes this task simpler between systems on different time zones.

  • SSHD(8) and SSH(1)

SSHD should be configured with strong security knobs including the most current asymmetric encryption (ED25519 currently), public/private keypair authentication, with a password-secured private key. SSHD keypairs should periodically be replaced. Consider using tested two-factor authentication, such as YubiKey. By default, ssh(1) should notify you if host keys change. Turn off any non-essential sshd(8) knobs, such as "AllowAgentForwarding" and "X11Forwarding".

  • SSHD(8) Host Keys

The SSHD(8) host keys are another critical authenticity measure. A list of host keys should be maintained, and in the event host key's change, other relevant parties should be notified immediately. Print out a hard copy of any relevant servers' host keys.

  • .Onion SSHD

Running a separate tor instance with SSHD as a hidden or .onion service provides a quiet entryway into the server more difficult to locate for most adversaries.

  • Ports/Packages over Source

Third-party packages/ports should be installed from the operating systems' packages/ports system which eases future upgrades. Installing from source means upgrades may leave residual files, and is more difficult to script.

  • Minimize Ports/Packages

Post-install packages/ports should be kept to a bare minimum. In most cases, the base operating system utilities should be preferred over third-party packages.

  • torrc Configuration

The specific torrc file should be provided, and configuration changes, if necessary, need to be communicated clearly. Only the minimum options should be included in the torrc.

  • User Configuration

Separate users should be employed when possible to provide least-privilege. A regular, non-privileged user with sudo-type access should be the main remote management login. Any local scripts run via cron(8) should be run as separate, non-privileged users without a login shell (eg, /sbin/nologin). The root user's crontab(1) should not be used for Tor-related server functions if possible.

  • Data Backups

Regular backups are vital, particularly for the ${TOR_DATA_DIR} which includes the server's fingerprint and keys. Backups should be stored remotely in a secure location.

  • Backup Hardware

A cold, offline hardware backup server is strongly recommended. While the backup server might not have all the current data, it should be fully capable of quickly syncing once connected.

  • DNS

DNS can be a tool to mitigate certain security problems. PTR records should be set to assist in determining the authenticity of a remote server. In the case that SSL/TLS is used, CAA records should also be configured. DNSSec should be employed for better verification of DNS queries. Servers might consider running a local DNS caching server if lookups are a required part of the system's requirements

  • IPv6

IPv6 should be configured for the server. IPv6 is slowly being integrated into the Tor infrastructure, and maintaining functional IPv6 means developers can test code without server administrators playing catch-up.

  • daily(8)

Daily operating system reports should be configured whether part of the base system, scripted or added as a third-party package. A regular check on system operation and health, including RAID disk status and packet throughput is important for maintaining server uptime.

  • Remote Monitoring

Remote monitoring is vital for knowing when services are unavailable. Systems which require a listening agent, such as Nagios, should not be used, as they increase possible vulnerability footprints. There are lighter monitoring systems, such as Sysmon (xxxxx) which don't require any local configuration on the monitored device. With Sysmon, for instance, particular IP/port combinations can be checked at set intervals for responsiveness, with an alert delivered by email.

  • Know Your Upstream Provider(s)

Relations with provider and upstream is critical, most obviously in instances where cold backup hardware needs to be swapped out with failing current hardware. Additionally, in the event of dealing with hardware seizure, DDOS attacks, etc. coordination with provider can be the critical ingredient.

  • Backup Administrators and Mentoring

In most cases a single administrator is responsible for each network service. Carefully selected secondary administrators should be mentored in an effort to extend knowledge of building and maintaining high-uptime Tor services. Such person should be considered well-trusted, and it's also an opportunity to diversify Tor's administrators to more women and other less-represented groups.

Child Tickets

Change History (1)

comment:1 Changed 2 years ago by phoul

Cc: phoul added
Note: See TracTickets for help on using tickets.