Hi all, I'm impressed by Tor and its contribution to freedom of speech and started to run some tor relays. The first one is https://atlas.torproject.org/#details/DBE3CE33BA8BF1CB98091EE2A72690DF8218C2... and I have applied tight iptables to that as below. Can somebody advise what should be add/remove to make it more efficient to tor network? =========iptables-rules.sh========== # Flushing all rules iptables -F iptables -X # Setting default filter policy iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP #ipv4 udp drop all iptables -A INPUT -p udp -j DROP iptables -A OUTPUT -p udp -j DROP #ipv6 udp drop all ip6tables -A INPUT -p udp -j DROP ip6tables -A OUTPUT -p udp -j DROP # Allow unlimited traffic on loopback iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT ip6tables -A INPUT -i lo -j ACCEPT ip6tables -A OUTPUT -o lo -j ACCEPT # Allow incoming SSH iptables -A INPUT -p tcp --dport xxx -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport xxx -m state --state ESTABLISHED -j ACCEPT # Allow incoming 443 iptables -A INPUT -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT # Allow outgoing 443 iptables -A OUTPUT -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT # Allow incoming 9050 iptables -A INPUT -p tcp --dport 9050 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 9050 -m state --state ESTABLISHED -j ACCEPT # Allow outgoing 9050 iptables -A OUTPUT -p tcp --dport 9050 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --sport 9050 -m state --state ESTABLISHED -j ACCEPT # Allow incoming 9051 iptables -A INPUT -p tcp --dport 9051 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 9051 -m state --state ESTABLISHED -j ACCEPT # Allow outgoing 9051 iptables -A OUTPUT -p tcp --dport 9051 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --sport 9051 -m state --state ESTABLISHED -j ACCEPT # Allow incoming 9001 iptables -A INPUT -p tcp --dport 9001 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 9001 -m state --state ESTABLISHED -j ACCEPT # Allow outgoing 9001 iptables -A OUTPUT -p tcp --dport 9001 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --sport 9001 -m state --state ESTABLISHED -j ACCEPT Thanks Simon
On 05/22/2014 02:23 AM, Contra Band wrote:
I'm impressed by Tor and its contribution to freedom of speech and started to run some tor relays.
Cool! Welcome on board. :-) At least on that box you seem to be running with ORPort set to 443, and no DirPort. So, the only port you need to open for incoming TCP connections is 443 (besides SSH). The problem with selective filters for outgoing traffic is that Tor needs to be able to connect to all other Tor relays, some of which use non-standard ports. -- Moritz Bartl https://www.torservers.net/
On 5/21/2014 7:38 PM, Moritz Bartl wrote:
The problem with selective filters for outgoing traffic is that Tor needs to be able to connect to all other Tor relays, some of which use non-standard ports.
One could add a rule to the OUTPUT chain that allows all traffic from the tor user (or uid). This allows one to maintain non-tor related outbound rules without interfering with tor itself. On a hypothetical system where the uid under which tor runs is 501 an iptables rule like this should work: iptables -I OUTPUT -p tcp -m owner --uid-owner 501 -j ACCEPT One resource for ideas on how to harden a system is the NSA. I for one have referenced these two docs on more than one occasion (clearnet links) and they can be adopted conceptually into many other distros: http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731.pdf http://www.nsa.gov/ia/_files/os/redhat/NSA_RHEL_5_GUIDE_v4.2.pdf -- Morgan Smith | IntersafeIT Phone/Fax: +1 (888) 623-7444 morgan@intersafeit.com www.intersafeit.com | intersafewhe4eoy.onion Twitter: @IntersafeIT | GnuPG ID: 9CDD26C7
Am 2014-05-22 02:23, schrieb Contra Band:
# Allow incoming 9050 iptables -A INPUT -p tcp --dport 9050 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 9050 -m state --state ESTABLISHED -j ACCEPT
# Allow outgoing 9050 iptables -A OUTPUT -p tcp --dport 9050 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --sport 9050 -m state --state ESTABLISHED -j ACCEPT
# Allow incoming 9051 iptables -A INPUT -p tcp --dport 9051 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 9051 -m state --state ESTABLISHED -j ACCEPT
# Allow outgoing 9051 iptables -A OUTPUT -p tcp --dport 9051 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --sport 9051 -m state --state ESTABLISHED -j ACCEPT
Do you actually need remote access to ports 9050 (Socks proxy) and 9051 (control port)? By default, Tor opens these ports on the loopback interface only. Paul
Nice thread. in my case (tor exit node): Output only security connections; ExitPolicy accept *:22 ExitPolicy accept *:443 ExitPolicy accept *:465 ExitPolicy accept *:995 ExitPolicy accept *:993 ExitPolicy reject *:* Block all output like http and smtp in my netfilter (Gnu Linux); -A OUTPUT -p tcp -m tcp --dport 80 -j DROP -A OUTPUT -p tcp -m tcp --dport 110 -j DROP etc .. I had problems with portscan originated in my output. Even without ExitPolicy accept EX: Dear Sir/Madam, We have detected abuse from the IP address MYIPADDRESS, which according to a whois lookup is on your network. We would appreciate if you would investigate your logs and take action as appropriate. Log lines are given below, but please ask if you require any further information. (If you are not the correct person to contact about this please accept our apologies - your e-mail address was extracted from the whois record by an automated process.) Regards, Critical Path, Inc. Note: Local timezone is +0000 (GMT) Jan 15 16:03:00 65.20.0.47 pop3: Failed password from MYIPADDRESS Jan 15 17:40:07 65.20.0.47 pop3: Failed password from MYIPADDRESS Jan 15 17:40:09 65.20.0.47 pop3: Failed password from MYIPADDRESS Jan 15 17:40:09 65.20.0.47 pop3: Failed password from MYIPADDRESS Jan 15 17:40:11 65.20.0.47 pop3: Failed password from MYIPADDRESS Jan 15 17:40:14 65.20.0.47 pop3: Failed password from MYIPADDRESS Jan 15 17:40:17 65.20.0.47 pop3: Failed password from MYIPADDRESS Jan 15 17:40:18 65.20.0.47 pop3: Failed password from MYIPADDRESS ****************************** ------------------------- END ------------------------------------ to keep me in a comfort zone, I installed OSSEC. OSSEC is an Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response. example of my latest incidents: OSSEC HIDS Notification. 2014 May 23 11:45:44 Received From: darkstar->/var/log/messages Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system." Portion of the log(s): May 23 12:45:44 darkstar kernel: tor: page allocation failure. order:0, mode:0x20 --END OF NOTIFICATION 'm Slowly creating rules (regular expressions) to OSSEC for the Tor messageand treating facilities. On Thu, May 22, 2014 at 2:31 PM, Paul Staroch <paulchen@rueckgr.at> wrote:
Am 2014-05-22 02:23, schrieb Contra Band:
# Allow incoming 9050 iptables -A INPUT -p tcp --dport 9050 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 9050 -m state --state ESTABLISHED -j ACCEPT
# Allow outgoing 9050 iptables -A OUTPUT -p tcp --dport 9050 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --sport 9050 -m state --state ESTABLISHED -j ACCEPT
# Allow incoming 9051 iptables -A INPUT -p tcp --dport 9051 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 9051 -m state --state ESTABLISHED -j ACCEPT
# Allow outgoing 9051 iptables -A OUTPUT -p tcp --dport 9051 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --sport 9051 -m state --state ESTABLISHED -j ACCEPT
Do you actually need remote access to ports 9050 (Socks proxy) and 9051 (control port)? By default, Tor opens these ports on the loopback interface only.
Paul
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Noilson Caio Teixeira de Araújo https://ncaio.wordpress <http://ncaio.ithub.com.br>.com<http://ncaio.ithub.com.br> https://br.linkedin.com/in/ncaio <http://br.linkedin.com/in/ncaio> https://twitter.com/noilsoncaio
On Fri, May 23, 2014 at 06:16:56PM -0300, Noilson Caio wrote:
Block all output like http and smtp in my netfilter (Gnu Linux);
-A OUTPUT -p tcp -m tcp --dport 80 -j DROP -A OUTPUT -p tcp -m tcp --dport 110 -j DROP etc ..
Relays need to allow connections to all outgoing ports. If you do lines like the above, your Tor relay will be unable to reach other Tor relays that chose port 80 or port 110 for their ORPort or their DirPort. (People choose those ports because some users are behind firewalls that only allow connections to those ports.) https://www.torproject.org/docs/faq#OutboundPorts --Roger
Thanks guys, Your experience is really helpful. After some thoughts now I'm allowing only incoming tcp ports 443 and ssh outgoing tcp port 443 I haven't enabled the Dirport. Heard all tor relays are dir mirrors by default. Later I will read the nsa, Linux hardening guide. It looks good. Thanks for sharing.
On 2014-05-24 01:25:36 (-0700), Contra Band wrote:
Your experience is really helpful. After some thoughts now I'm allowing only
incoming tcp ports 443 and ssh
outgoing tcp port 443
Please enable at least outgoing port 9001 as well. Most relays listen on that port, with 443 in second place. With those ports allowed you'll be able to reach 80% of the network. This is a quick tally of the number of relays by orport: $ awk '/^r / {print $8}' ~/tmp/2014-05-24-07-00-00-consensus |sort -n |uniq -c |sort -rn |head 2613 9001 1251 443 49 8080 35 9090 34 80 27 9002 25 8443 25 22 23 8001 22 110 -- David Serrano GnuPG id: 280A01F9
On Sat, 24 May 2014 10:51:52 +0200 David Serrano <tor@dserrano5.es> wrote:
With those ports allowed you'll be able to reach 80% of the network.
So you're okay with the thought that their relay will be 20% broken, and 20% of all circuits people try to establish through it, will fail? As Roger said, *all* outgoing ports need to be enabled. -- With respect, Roman
That is a great piece of advice David. I have enabled the tcp outgoing 9001 and seeing a lot of new connections established to relays with 9001 ORPort. Thanks a lot. Keep it up guys... On Saturday, May 24, 2014 8:51 AM, David Serrano <tor@dserrano5.es> wrote: On 2014-05-24 01:25:36 (-0700), Contra Band wrote:
Your experience is really helpful. After some thoughts now I'm allowing only
incoming tcp ports 443 and ssh
outgoing tcp port 443
Please enable at least outgoing port 9001 as well. Most relays listen on that port, with 443 in second place. With those ports allowed you'll be able to reach 80% of the network. This is a quick tally of the number of relays by orport: $ awk '/^r / {print $8}' ~/tmp/2014-05-24-07-00-00-consensus |sort -n |uniq -c |sort -rn |head 2613 9001 1251 443 49 8080 35 9090 34 80 27 9002 25 8443 25 22 23 8001 22 110 -- David Serrano GnuPG id: 280A01F9 _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Thanks
Thanks guys, Your experience is really helpful. After some thoughts now I'm allowing only incoming tcp ports 443 and ssh outgoing tcp port 443 I haven't enabled the Dirport. Heard all tor relays are dir mirrors by default. Later I will read the nsa, Linux hardening guide. It looks good. Thanks for sharing.
Thanks guys, Your experience is really helpful. After some thoughts now I'm allowing only incoming tcp ports 443 and ssh outgoing tcp port 443 I haven't enabled the Dirport. Heard all tor relays are dir mirrors by default. Later I will read the nsa, Linux hardening guide. It looks good. Thanks for sharing.
If you do lines like the above, your Tor relay will be unable to reach other Tor relays that chose port 80 or port 110 for their ORPort or their DirPort. (People choose those ports because some users are behind firewalls that only allow connections to those ports.)
indeed. By personal choice, I have found it more convenient to exclude this traffic leaving my relay. I'll make scrips that create rules with these output ports only for Tor relays. Thanks a lot mr. Roger. On Fri, May 23, 2014 at 7:30 PM, Roger Dingledine <arma@mit.edu> wrote:
On Fri, May 23, 2014 at 06:16:56PM -0300, Noilson Caio wrote:
Block all output like http and smtp in my netfilter (Gnu Linux);
-A OUTPUT -p tcp -m tcp --dport 80 -j DROP -A OUTPUT -p tcp -m tcp --dport 110 -j DROP etc ..
Relays need to allow connections to all outgoing ports.
If you do lines like the above, your Tor relay will be unable to reach other Tor relays that chose port 80 or port 110 for their ORPort or their DirPort. (People choose those ports because some users are behind firewalls that only allow connections to those ports.)
https://www.torproject.org/docs/faq#OutboundPorts
--Roger
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Noilson Caio Teixeira de Araújo https://ncaio.wordpress <http://ncaio.ithub.com.br>.com<http://ncaio.ithub.com.br> https://br.linkedin.com/in/ncaio <http://br.linkedin.com/in/ncaio> https://twitter.com/noilsoncaio
On Fri, May 23, 2014 at 06:30:08PM -0400, Roger Dingledine wrote:
Relays need to allow connections to all outgoing ports.
If you do lines like the above, your Tor relay will be unable to reach other Tor relays that chose port 80 or port 110 for their ORPort or their DirPort. (People choose those ports because some users are behind firewalls that only allow connections to those ports.)
If anybody is looking for a good project to get used to Stem or txtorcon and to help out the Tor network, here's a great one: build pairwise circuits between all relays, to see which of them can reach each other and which can't, with the goal of understanding how far from a clique our network topology actually is, and then helping with an awareness campaign to correct it if it's a problem. I've written up more details and ideas here: https://trac.torproject.org/projects/tor/ticket/12131 --Roger
participants (8)
-
Contra Band -
David Serrano -
Morgan Smith -
Moritz Bartl -
Noilson Caio -
Paul Staroch -
Roger Dingledine -
Roman Mamedov