Any security tips on running a TOR relay?
Hi, I've got a spare server for two (freebsd) and I'd like to start running TOR relays on them. Is there any security concerns I need to deal with, or is the ports compile + updates good enough to keep my systems decently secure. I actively monitor the machines, but as you know, the game is prevention, not reaction to security incedents :) Thanks, AB49K
I'd say the normal server hardening precautions apply. Off the top of my head: - keep software/packages up to date - only use public-key authentication for ssh / disable password-based auth - optionally change the ssh port (it just avoids the worst of the port scanning / brute force attempts) - limit the number of services running on your relays (ideally only run Tor and supporting services (i.e., maybe dns) - firewall off (deny) everything except DirPort/ORPort/ssh
I'm assuming this doesn't apply to exit relays? Or is there a way to block incoming while allowing outgoing? On Aug 4, 2016 12:27 PM, "Green Dream" <greendream848@gmail.com> wrote:
- firewall off (deny) everything except DirPort/ORPort/ssh
Tristan: yep, I was assuming a non-exit. Although sure, you can block incoming traffic without affecting outbound traffic with a stateful firewall like iptables.
Just finished setting up UFW on my exit node. Outgoing traffic is allowed, incoming traffic is blocked except for SSH, OrPort, and DirPort. According to arm, Tor is still getting traffic, but I'm seeing a lot of blocked incoming connections on random high-numbered ports. Did I do something wrong? Tor should only be using OrPort and DirPort, so I'm not sure where all this other traffic is coming from. On Thu, Aug 4, 2016 at 12:52 PM, Green Dream <greendream848@gmail.com> wrote:
Tristan: yep, I was assuming a non-exit. Although sure, you can block incoming traffic without affecting outbound traffic with a stateful firewall like iptables.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Finding information, passing it along. ～SuperSluether
That's my setup as well. My UFW looks like: To Action From -- ------ ---- 80/tcp ALLOW Anywhere 443/tcp ALLOW Anywhere xxx/tcp ALLOW Anywhere I have my DirPort set to 80 and ORPort on 443. The last line is my ssh port (I didn't want to broadcast it). I also see the same type of blocked incoming packets. It's never been a problem. I think it's just the nature of the stateful firewall. Once connections are closed and no longer in the state table, additional packets are getting denied. That's my lazy/gut explanation, I don't have more time to think about it at the moment, but I don't think it's anything to worry about.
I didn't look at all of them, but I've been tracing some of the IPs that have been blocked. Each one I've traced goes back to *.in-addr.arp. Even more interesting is that some of these connections get blocked, even though they're incoming on port 443, which allows traffic from anywhere! Any ideas what in-addr.arp is, and why the firewall would block it even on allowed ports? I remember seeing this somewhere in the Unbound config, but the IP isn't the same, and I didn't set up any of the "local zones" in there. On Thu, Aug 4, 2016 at 6:00 PM, Green Dream <greendream848@gmail.com> wrote:
That's my setup as well. My UFW looks like:
To Action From -- ------ ---- 80/tcp ALLOW Anywhere 443/tcp ALLOW Anywhere xxx/tcp ALLOW Anywhere
I have my DirPort set to 80 and ORPort on 443. The last line is my ssh port (I didn't want to broadcast it).
I also see the same type of blocked incoming packets. It's never been a problem. I think it's just the nature of the stateful firewall. Once connections are closed and no longer in the state table, additional packets are getting denied. That's my lazy/gut explanation, I don't have more time to think about it at the moment, but I don't think it's anything to worry about.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Finding information, passing it along. ～SuperSluether
Hey Tristan,
Any ideas what in-addr.arp is
Yes, this is the standard format for reverse DNS lookups for IPv4 addresses. I'm not sure what command(s) you were using, but in-addr.arpa is an expected result (or intermediate step) of doing something like "host 8.8.4.4" on Linux. The IP octets are reversed and appended to the domain suffix in-addr.arpa (ex: 4.4.8.8.in-addr.arpa for 8.8.4.4) to create a hostname. Then to continue the same example, the host tool finds a PTR record for that hostname (ex: google-public-dns-b.google.com). You can read more about this here: https://en.wikipedia.org/wiki/Reverse_DNS_lookup https://tools.ietf.org/html/rfc2317 So... those in-addr.arpa references don't really tell you anything. It's just a distraction. My hunch is that the IP addresses in your log are going to be a random selection of IPv4 addresses from Tor clients and relays.
why the firewall would block it even on allowed ports?
I was trying to explain earlier but did a poor job. I don't have a specific explanation for Tor, but it's common to see the same behavior with denied packets to port 80 and 443 on a web server, even when there is a UFW (iptables) allow rule. It has to do with the state of the connection. There's an explanation for web servers and port 80 blocks here: https://ubuntuforums.org/showthread.php?t=2138691 (see the 2nd post) I am making an assumption that we're seeing the same behavior on the Tor ports. It would be good if someone with a better understanding of the protocols could confirm or deny the theory. I'm not 100% certain.
P.S. Tristan, here's the explanation from that mailing list... just in case people can't access the link or it goes away: "Yes, it has everything to do with those flag bits. For TCP connections, Linux tends to use a "half-duplex" close sequence where either side of the session can initiate connection termination via a single 2 way FIN-ACK handshake (which puts the connection into the CLOSE_WAIT state), instead of a full 4 way FIN-ACK handshake. When one also includes routers and such, it is not uncommon, indeed common, that one side might think the connection has been terminated, while the other side thinks it has still open or not fully terminated. Your log file is, most probably, showing entries for cases where your computer thinks the tcp had been closed and it has forgotten about it, but the client is trying to close the session. In the case where you got a RST bit, it can be because the client gave up trying the FIN method and now is just trying to reset the connection. By observation only, rather than authoritative reference, it seems that Apple computers tend to use FIN and FIN-ACK more, and MS windows computers tend to use RST more. Conclusion: Everything is fine."
Green, Thanks for the info. I used iptables once when setting up a VPN, but I just followed instructions. It's obviously way more intricate than UFW lets on. Also thanks to Mike for the really good blog post about operational security. It was really informative. On Aug 4, 2016 8:49 PM, "Green Dream" <greendream848@gmail.com> wrote:
P.S. Tristan, here's the explanation from that mailing list... just in case people can't access the link or it goes away:
"Yes, it has everything to do with those flag bits. For TCP connections, Linux tends to use a "half-duplex" close sequence where either side of the session can initiate connection termination via a single 2 way FIN-ACK handshake (which puts the connection into the CLOSE_WAIT state), instead of a full 4 way FIN-ACK handshake. When one also includes routers and such, it is not uncommon, indeed common, that one side might think the connection has been terminated, while the other side thinks it has still open or not fully terminated. Your log file is, most probably, showing entries for cases where your computer thinks the tcp had been closed and it has forgotten about it, but the client is trying to close the session. In the case where you got a RST bit, it can be because the client gave up trying the FIN method and now is just trying to reset the connection. By observation only, rather than authoritative reference, it seems that Apple computers tend to use FIN and FIN-ACK more, and MS windows computers tend to use RST more.
Conclusion: Everything is fine."
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Thu, 4 Aug 2016 20:20:45 -0500 Tristan <supersluether@gmail.com> wrote:
Any ideas what in-addr.arp is, and why the firewall would block it even on allowed ports? I remember seeing this somewhere in the Unbound config, but the IP isn't the same, and I didn't set up any of the "local zones" in there.
https://tools.ietf.org/html/rfc1033 Regards, -- Yawning Angel
Andrew wrote:
I've got a spare server for two (freebsd) and I'd like to start running TOR relays on them.
Is there any security concerns I need to deal with, or is the ports compile + updates good enough to keep my systems decently secure.
I actively monitor the machines, but as you know, the game is prevention, not reaction to security incedents :)
Here's a guide I wrote: https://www.sccs.swarthmore.edu/users/16/mmcconv1/tor-hardening.html Thanks especially for contributing relays that use a less common OS, by the way! Best, Mike
participants (5)
-
Andrew -
Green Dream -
Michael McConville -
Tristan -
Yawning Angel