Adding doc/HARDENING

The two text files currently in the doc directory are doc/HACKING and doc/TUNING. The latter is the only one that deals with relay operation, and its subject is oddly specific: increasing the maximum number of file descriptors. If we're going to put critical documentation in the codebase, I think it would also be worthwhile to have a basic hardening guide. It could include suggestions like:

• allowing only public key non-root SSH login
• using a firewall
• keeping your system up-to-date
• not running any other programs (especially networked ones)
• considering hardened or security-focused OS choices

Nick suggested that most of the actual information be contained in referenced links, which I agree with. There's no good reason to duplicate effort when there are, for example, so many good SSH hardening guides.

Let me know what you think, or if you have any contributions. If this is generally considered a good idea, I can start writing a draft.

Trac:
Username: mmcc

changed milestone to %Tor: unspecified

added component::community docs hardening lorax milestone::Tor: unspecified opsec owner::Jaruga priority::medium reporter::mmcc reviewer::isis security severity::normal status::accepted tor-doc tor-relay type::enhancement version::tor unspecified labels

I endorse the idea of a doc/HARDENING... but IMO it should link to an existing "How to harden your favorite server OS" guide or guides, and should include extra information only to the extent that it's tor-specific.

Trac:
Keywords: docs deleted, docs 026-deferrable lorax added
Milestone: N/A to Tor: 0.2.6.x-final

Agreed. Basic OpenSSH hardening is common to all OSs, as far as I know, so that could be an OS-independent section. Firewall and update concerns would definitely have to be OS-specific, though.

Trac:
Username: mmcc

It would probably be a good idea to add a disclaimer saying something like:

"These changes are not magic, and can have the opposite of the intended effect if done incorrectly. Please try to understand what you are doing before you dive in."

Trac:
Username: mmcc

(I'll take a good document if somebody writes one, but I'm not planning to write one myself.)

Trac:
Milestone: Tor: 0.2.6.x-final to Tor: 0.2.???

(This could go into 0.2.6 if somebody does it in time.)

I'm planning on writing this as soon as I have the time. I'm in-semester at the moment, so that may be a few days, but I should be able to have a simple version soon. Anyone interested in contributing should let me know.

Trac:
Username: mmcc

Some more advanced points to add for servers:

IPMI and BMC/RMC awareness. Make sure you don't expose any management interface on server IP or dedicated IP. Check from inside the providers network and from outside. Nmap -sSV -p1-65535

Configure mail system with TLS for outgoing mail only and with local (providers) smtp relay, if available

Use simple log monitoring tool to alert in case of strange happenings.

Before bringing the server online, install and configure tripwire.

If possible, use a trusted hardware firewall to lock down traffic to exactly what is needed to operate. Have the firewall log any outgoing UDP traffic from the server, and if such traffic is observed and non-explainable, consider the hardware compromised.

Use availability monitoring and latency monitoring (smokeping) to be in the picture what happens with the server.

Trac:
Username: cypherpunks-duplicate

Trac:
Username: sysfu
Cc: N/A to sysfu

For those not aware, I sent this out a while back:

https://www.mail-archive.com/tor-relays@lists.torproject.org/msg04998.html

Trac:
Username: mmcc

Here's the current version:

https://gist.github.com/plsql/49e642d5bce835df2946

I'd love to hear what people think.

Trac:
Username: mmcc

I've sent an email to the tor-relays mailing list, asking for feedback.

I 'd like to see hardened Gentoo as an OS choice listened here too.

wrt "not running any other programs (especially networked ones) " - here might be a good argument to seconded that : http://www.zwiebeltoralf.de/torserver/cep2/index.html

• and comments to that page are highly appreciated

(and I must admit, that currently I removed the WCG from BOINC's project list instead of kicking off BOINC from the server entirely)

A 'd like to see hardened Gentoo as an OS choice listened here too.

wrt "not running any other programs (especially networked ones) " - here might be a good argument to seconded that : http://www.zwiebeltoralf.de/torserver/cep2/index.html

• and comments to that page are highly appreciated

(and I must admit, that currently I removed the WCG from BOINC's project list instead of kicking off BOINC from the server entirely)

Would restricting outgoing connections to the tor uid be useful? But maybe it's overkill.

It would be good to mention Tor-ramdisk as an alternative (good or bad) to disk encryption.

FDE for hosted machines can be a pain. There are online guides for setting up dropbear for remotely unlocking LUKS volumes, with LVM for encrypted swap. I could point to tested instructions, or if necessary, provide some.

Trac:
Username: mirimir

And furthermore entropy packages like timer_entropyd, haveged, rngd and so on are worth to be considered.

Here's an idea for the advanced/intense subset of hardening. Unrealistic to expect everyone to do this but it ought to be listed as an option to remind those who are able and inclined. This type of hardening might especially be applied to servers running hidden services.

When a tor relay will run on dedicated hardware in a colocation facility (or perhaps even in one's basement), one should

a) apply strong passwords to both admin and user BIOS access b) apply strong passwords to the IPMI/BMC c) minimize IPMI/BMC features, especially disabling HTTP, HTTPS, telnet, etc management in favor of SSH and IPMI protocol d) enable chassis intrusion detection, configure an alarm if possible possibly have the system wipe memory and power down immediately e) if possible, disable chassis-external USB ports in the BIOS f) alternately, disconnect mainboard-to-chassis USB cables perhaps cut USB port leads where USB connectors mounted on mainboard g) severely restrict USB hotplug devices via 'udev' rules h) set /proc/sys/kernel/modules_disabled after reboots complete (make sure all required modules are loaded first) i) likewise, disable any other transports such as Firewire

The essential idea here is hardening against a variety of physical proximity attacks. I'm sure more possibilities exist here, but this is what came off the top of my head.

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.2.7.x-final