Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iptables + networking lockdown recommendations #15

Open
grugq opened this issue Nov 28, 2013 · 3 comments
Open

iptables + networking lockdown recommendations #15

grugq opened this issue Nov 28, 2013 · 3 comments

Comments

@grugq
Copy link
Owner

grugq commented Nov 28, 2013

Need to check that the iptables script (and other settings) are consistent with the recommendations outlined here:

https://lists.torproject.org/pipermail/tor-talk/2012-October/026226.html

@ad90df8e708e8fa8153e56a059
Copy link
Contributor

Comparing the current iptables ruleset to the one suggested above, the following rules are missing:

(I added inline comments to some of them to explain their purpose, and changed the DNS port to 9053 where applicable.)

  • 2 filter INPUT lines (for logging bad incoming connection attempts)
*filter
-A INPUT -p tcp -m tcp -m state --state NEW -j LOG --log-prefix "input(tcp) " -m limit --limit 1/minute
-A INPUT ! -p tcp -j LOG --log-prefix "input(all) " -m limit --limit 1/minute
  • 2 nat OUTPUT lines (to allow egress to TransPort & DNSPort)
*nat
-A OUTPUT ! -o lo -p tcp  -m tcp -j REDIRECT --to-ports 9040
-A OUTPUT -p udp --dport 53 -m state --state NEW -j REDIRECT --to-ports 9053
  • 6 filter OUTPUT lines (for general egress filtering)
*filter
-A OUTPUT -j ACCEPT -p icmp -m comment --comment "icmp outgoing on all interfaces accepted."
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -m comment --comment "Established outgoing connections are accepted."
-A OUTPUT -d 127.0.0.0/255.0.0.0 -j ACCEPT -m comment --comment "Outbound internal network connections are accepted."
-A OUTPUT -p tcp -m tcp --dport 9040 -j ACCEPT -m comment --comment "Outbound to TransPort accepted."
-A OUTPUT -p udp -m udp --dport 9053 -j ACCEPT -m comment --comment "Outbound to DNSPort accepted."
-A OUTPUT -j REJECT --reject-with icmp-port-unreachable -m comment --comment "Drop all other connections."

The link also suggests the following kernel tweaks that are not implemented:

(However, since one of the suggestions was to set ipv4_forward = 0, which would for sure will break routing, I don't know if all of these should necessarily be implemented as they may not have been thought all the way through.)

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts   # ignore broadcast
##echo 0 > /proc/sys/net/ipv4/ip_forward   # this suggestion breaks routing...
echo 1 > /proc/sys/net/ipv4/tcp_syncookies   # enable tcp syn cookie protection
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses   # ignore buggus icmp responses
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all   # ignore all icmp
echo "512" >/proc/sys/net/ipv4/tcp_max_syn_backlog   # Reduce number of possible SYN Floods
for i in /proc/sys/net/ipv4/conf/*/proxy_arp; do echo 0 > $i; done   # Disable proxy_arp.

# ip spoofing protection
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do 
    echo 1 > $f
done

# Don't accept or send ICMP redirects.
for i in /proc/sys/net/ipv4/conf/*/accept_redirects; do echo 0 > $i; done
for i in /proc/sys/net/ipv4/conf/*/send_redirects; do echo 0 > $i; done   

# Disable Source Routed Packets
for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
    echo 0 > $f
done 

# Log martians
for f in /proc/sys/net/ipv4/conf/*/log_martians; do
    echo 1 > $f
done

tl;dnr: I think the egress filtering and (some?) of the kernel tweaks would be useful additions, everything else is duplicative or not really of much help in this use case IMO.

I'll try to test all of these possible changes out individually to see if they break things and put together a pull request.

@grugq
Copy link
Owner Author

grugq commented Mar 20, 2016

Seems like not so important stuff. Some basic network lockdown shit.

Disabling packet routing is actually a good thing, and something I thought I had done already. The Tor daemon does the packet forwarding itself (receives on one interface, sends on the other)... if the device supports routing then there is the potential for the device to fail open. It should fail closed (without Tor handling the packets, there should be no way for any data to access the Internet).

@ad90df8e708e8fa8153e56a059
Copy link
Contributor

Yeah wow, didn't realize that, just assumed ipv4_forward was needed for redirecting to the TransPort, but I guess that's already bound to the private network.

I think the Whonix gateway uses its own firewall binary, but it looks like https://forums.whonix.org/t/torifying-a-linux-container-with-whonix-gateway-firewall-rules/243 has a list of iptables rules that its based off of. Looks like another good base to work from.

But other than some basic OUTPUT filtering, I don't think there's much that wouldn't be adequately handled by what is already in place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants