Opened 4 years ago

Last modified 3 months ago

#13703 accepted enhancement

Adding doc/HARDENING

Reported by: mmcc Owned by: Jaruga
Priority: Medium Milestone: Tor: unspecified
Component: Community Version: Tor: unspecified
Severity: Normal Keywords: hardening, security, opsec, docs, lorax, tor-relay, tor-doc
Cc: sysfu Actual Points:
Parent ID: Points:
Reviewer: isis Sponsor:

Description

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.

Child Tickets

Change History (37)

comment:1 Changed 4 years ago by nickm

Keywords: 026-deferrable lorax added
Milestone: Tor: 0.2.6.x-final

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.

comment:2 Changed 4 years ago by mmcc

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.

comment:3 Changed 4 years ago by 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."

comment:4 Changed 4 years ago by nickm

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

comment:5 Changed 4 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.???

comment:6 Changed 4 years ago by nickm

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

comment:7 Changed 4 years ago by mmcc

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.

comment:8 Changed 4 years ago by cypherpunks-duplicate

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.

comment:9 Changed 3 years ago by sysfu

Cc: sysfu added

comment:10 Changed 3 years ago by mmcc

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

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

comment:11 Changed 3 years ago by mmcc

Here's the current version:

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

I'd love to hear what people think.

comment:12 Changed 3 years ago by nickm

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

comment:13 Changed 3 years ago by toralf

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)

Last edited 3 years ago by toralf (previous) (diff)

comment:14 Changed 3 years ago by toralf

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)

comment:15 Changed 3 years ago by mirimir

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.

comment:16 Changed 3 years ago by toralf

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

comment:17 Changed 3 years ago by starlight

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.

comment:18 Changed 3 years ago by nickm

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

comment:19 Changed 3 years ago by nickm

Status: newassigned

comment:20 Changed 3 years ago by nickm

Keywords: 027-triaged-1-out added

Marking triaged-out items from first round of 0.2.7 triage.

comment:21 Changed 3 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.???

Make all non-needs_review, non-needs_revision, 027-triaged-1-out items belong to 0.2.???

comment:22 Changed 3 years ago by mmcc

I agree with the sentiment from the mailing list discussion that doc/HARDENING probably belongs on the wiki. At most, a link could be put somewhere in doc/. I wrote it mostly for new relay operators, who are unlikely to look in doc/ to begin with, and putting a guide like this in the codebase implies a degree of authority that I don't have.

If anyone disagrees, let me know. I'm happy to see this document wherever it'll be used most.

comment:23 Changed 3 years ago by mmcc

Also, the current version of doc/HARDENING still lives on Gist:

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

comment:24 Changed 19 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:25 Changed 18 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:26 Changed 13 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:27 Changed 13 months ago by nickm

Keywords: 027-triaged-in added

comment:28 Changed 13 months ago by nickm

Keywords: 027-triaged-in removed

comment:29 Changed 13 months ago by nickm

Keywords: 027-triaged-1-out removed

comment:30 Changed 13 months ago by nickm

Keywords: 026-deferrable removed

comment:31 Changed 13 months ago by nickm

Status: assignednew

Change the status of all assigned/accepted Tor tickets with owner="" to "new".

comment:32 Changed 12 months ago by nickm

Milestone: Tor: unspecifiedTor: 0.3.2.x-final
Severity: Normal
Status: newneeds_review

IMO we should take this, merge it, pull out anything that looks wrong, mark it as a working draft, and let people submit patches to it.

comment:33 Changed 12 months ago by nickm

Keywords: tor-relay tor-doc added

comment:34 Changed 12 months ago by nickm

Keywords: review-group-18 added

comment:35 Changed 12 months ago by isis

Milestone: Tor: 0.3.2.x-finalTor: unspecified
Reviewer: isis
Status: needs_reviewnew

It seems like that gist that mmcc linked to above has disappeared (https://gist.github.com/plsql/49e642d5bce835df2946). The account for that github user has also either disappeared or been renamed. Setting to "new" and moving out of 0.3.2.x-final because there's no patch/document to review.

comment:36 Changed 12 months ago by isis

Keywords: review-group-18 removed

comment:37 Changed 3 months ago by Jaruga

Component: Core Tor/TorCommunity
Owner: set to Jaruga
Status: newaccepted

This is long overdue but seems like a good idea - I can create a hardening doc for the wiki and forward it on for possible inclusion elsewhere.

Note: See TracTickets for help on using tickets.