Hi,
intrigeri wrote (05 Mar 2015 21:14:50 GMT) :
> intrigeri wrote (18 Jan 2015 21:45:15 GMT) :
>> I see this thread has been quiet for a bit more than a month.
>> Maybe it's time for someone to sum up whatever consensus was reached,
>> and whatever disagreement may still be remaining?
>> Jake, maybe?
> Ping?
OK, OK, here we go :)
Thank you all for your contribution!
I have compiled everything that everybody seemed to agree in this
thread, into a Git branch (feature/various-firewall-hardening).
I'll build it and run our automated test suite on it.
There's one question below, mainly for Oliver-Tobias, but anyone else
is free to have a look.
Anyone who participated in this thread, please consider checking my
summary below. This is _not_ my area of expertise, and it may very
well be that I got something wrong from your discussion, which is why
I was asking for someone else to sum it up a year ago.
Thanks in advance!
Note that all patches pasted below are entirely untested.
Regarding the firewall rules, I think the agreement that was reached
is:
--- a/config/chroot_local-includes/etc/ferm/ferm.conf
+++ b/config/chroot_local-includes/etc/ferm/ferm.conf
@@ -15,7 +15,7 @@ domain ip {
policy DROP;
# Established incoming connections are accepted.
- mod state state (RELATED ESTABLISHED) ACCEPT;
+ mod state state (ESTABLISHED) ACCEPT;
# Traffic on the loopback interface is accepted.
interface lo ACCEPT;
@@ -25,7 +25,7 @@ domain ip {
policy DROP;
# Established outgoing connections are accepted.
- mod state state (RELATED ESTABLISHED) ACCEPT;
+ mod state state (ESTABLISHED) ACCEPT;
# White-list access to local resources
outerface lo {
So far, so good. Except one problem was raised about this change, i.e.
the potential for breaking stuff if a link along the way has a small
MTU. On this we have two messages from Oliver-Tobias:
Oliver-Tobias Ripka wrote (04 Dec 2014 01:06:11 GMT):
> there are some cases where TCP also depends on
> ICMP. What comes to mind is PATH MTU discovery. As TCP always has the DF
> bit set it, packets might get rejected by routers on the path that only
> allow for a small MTU. This results in an ICMP destination
> unreachable/fragmentation needed(DU/FN) message that has the "next hop mtu"
> value set.
> [...]
> The bottom line is that we should test if this theory above actually
> results in problems when sending large packets in these circumstances.
> Possible solutions would be to tweak the sysctls to allow the Kernel to
> determine an efficient MTU via black hole router detection and MTU
> probing.
If I understand correctly this means settig net.ipv4.tcp_mtu_probing=1.
Right?
I've tested this 9 months ago and at least it didn't break our
automated tests (
https://labs.riseup.net/code/issues/9268#note-10).
> Another solution would be to explicitly allow this specific
> type of ICMP packet from the outside.
I'll go with the 1st solution for now, since if I got it right what
you meant, I have put time into understanding it meanwhile, and have
an implementation ready and tested. As opposed to this 2nd option,
which has no code yet, let alone tested code :)
> Maybe this may also be considered not to be an issue because small MTUs
> are not so common (mostly only if you are somewhere behind a Tunnel,
> VPN, 6in4,4in6...).
Oliver-Tobias Ripka wrote (09 Dec 2014 22:40:32 GMT):
> For the potential PATH MTU problem I saw Tor using fixed sizes segments
> that are quite small (about 500bytes). Thus PATH MTU should not be a
> problem besides extreme cases of network misconfiguration.
> Actually it might be a good idea to block these messages because if the
> network stack reacted to these ICMP messages it might allow a remote
> attacker to artificially lower the MTU of the segments sent. This may
> potentially make it easier to deanonymize a Tor user, I guess. Not sure
> if Tor can protect against this kind of attack as this may happen on
> the Kernel layer.
> You asked how to test it. Well I currently don't have a real router
> which I can configure to provide such a low MTU. But using software
> tools it is possible to simulate this: 1. route Tails through a Linux box
> with low MTU on the WAN interface. (Linux should send ICMP DF) 2. route
> Tails through Linux box with iptables rule dropping large packets and
> scapy script sniffing an sending ICMP DF for each large packet.
Note that we had a discussion about MTU earlier, that suggested that
current Tails might not be supporting low MTU already:
https://labs.riseup.net/code/issues/9268.
So my take on this is that we should not bother too much about low
MTU, that seem uncommon and possibly already broken; and still, enable
MTU probing (Packetization Layer Path MTU Discovery, RFC 4821) as done
in our bugfix/9268-deal-with-smaller-MTU branch, in case it may help.
IMO this should not block the proposed firewall hardening.
Another point that was raised was:
Jacob Appelbaum wrote (03 Dec 2014 17:22:30 GMT):
> If we look at on the latest Tails, we'll see
> /proc/sys/net/netfilter/nf_conntrack_helper is set to 1. I propose
> that we set it to 0. We do not want help tracking connections, we do
> not want those extra protocol parsers in the kernel doing this kind of
> heavy lifting.
... that I think we should try (via our automated test suite).
To end with, this other unrelated firewall hardening proposal was left
unchallenged and is probably good (we have good test coverage in this
area so our automated test suite should tell us relatively quickly if
it breaks anything):
Oliver-Tobias Ripka wrote (09 Dec 2014 22:40:32 GMT):
> At the same time we should be able to change the debian-tor rule to
> allow only NEW TCP packets, disallowing all other protocols.
... that is something like:
--- a/config/chroot_local-includes/etc/ferm/ferm.conf
+++ b/config/chroot_local-includes/etc/ferm/ferm.conf
@@ -141,7 +141,9 @@ domain ip {
}
# Tor is allowed to do anything it wants to.
- mod owner uid-owner debian-tor ACCEPT;
+ mod owner uid-owner debian-tor {
+ proto tcp syn mod state state (NEW) ACCEPT;
+ }
# i2p is allowed to do anything it wants to on the internet.
outerface ! lo mod owner uid-owner i2psvc {
Thoughts?
Cheers,
--
intrigeri
