[tor-bugs] #28084 [Core Tor]: Proposed "Best Practices" for running Tor public network services

[Tor Bug Tracker & Wiki]

#28084: Proposed "Best Practices" for running Tor public network services
-------------------------+--------------------------
 Reporter:  gman999      |          Owner:  (none)
     Type:  enhancement  |         Status:  new
 Priority:  Medium       |      Component:  Core Tor
  Version:               |       Severity:  Normal
 Keywords:               |  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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28084>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online