iptables + networking lockdown recommendations about portalofpi

[ad90df8e708e8fa8153e56a059]

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]

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]

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.