Hi,
[cleaning my INBOX]
tl;dr: all the proposed changes were applied in Tails 2.4. Thanks!
intrigeri (Thu, 11 Feb 2016):
> 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?
>> 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.
FTR these changes went in Tails 2.4.
> 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).
This went into Tails 2.4 to.
> Another point that was raised was:
>> 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).
This was applied in Tails 2.4 too.
> 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?
Ditto, applied in 2.4.
Cheers,
--
intrigeri
