Re: [Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls
Hey, I agree that removing the attack surface is a good idea. Some thoughts and material for discussion on this...: You make no distinction between the INPUT and OUTPUT chains and suggest that both should be changed to "NEW, ESTABLISHED". I understand your argument for the OUTPUT chain but I would argue that that NEW would not be desirable for the INPUT chain as it would open up the firewall to the outside. However ESTABLISHED may be sufficent for the INPUT chain in order to allow stateful egress connections. My second thought is what core network protocols might be affected by this change. The network protocols that I see used in Tails are ARP, DHCP and TCP. (I also saw an outgoing ICMP packet after shortly after the DHCP discover. But this may be an artifact from the virtualisation software). I did do some tests using the following testing procedure - setup sniffer - boot the live system (allow for root login) - kill network connection - edit /etc/ferm/ferm.conf to included the iptables tweak: INPUT: [...] mod state state (ESTABLISHED) ACCEPT; OUTPUT: [...] mod state state (NEW ESTABLISHED) ACCEPT; - set the iptables rules to DROP everything - use network manager to reestablish connection (works) Evaluating the results for the protocols required by Tails: - ARP should not be (and is not) affected by the changes you propose as it is handled by lower level netfilter code - DHCP still works. Which is strange, isn't? I configured the firewall to drop everything so DHCP should not work. To debug a little I inserted some code into /etc/NetworkManager/dispatcher.d/00-firewall.sh to see what the state if ifconfig and iptables is right before bringing up the firewall: Result: The IP adress is already is configured (DHCP was renewed) and the iptables configuration is still set to DROP. So I am not sure how the DHCP packets could get through. Maybe I have a flaw in my debugging procedure or this is another issue. - TCP still works and Tor succeeds in establishing a connection. While this seems fine at first I think we should investigate the following potential impact that might surface in some circumstances: Reading through the iptables man page it states that: RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error. While Tails does not use UDP which might need ICMP as a helper protocol (e.g. for closed ports) 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. Currently I have no router to set up a small MTU path and test this. But I guess that with the above firewall config the ICMP packet would not be allowed and thus the Linux kernel would not get the information that it has to decrease the packets sizes (e.g. during an upload or large POST). So here is some more speculation what would happen is this case: In such a case the impact and behavior of not receiving the ICMP DU/FN then depends on the following Linux kernel sysctls: - /proc/sys/net/ipv4/ip_no_pmtu_disc (path mtu discovery) - /proc/sys/net/ipv4/tcp_mtu_probing (mtu probing) The Tails configuration for path mtu discovery and TCP mtu probing are as follows: 0 (Path MTU discovery is On), 0 (MTU probing is Off) I did some test with a 2.6 kernel using these settings some years ago and the result was the with the settings above the Linux Kernel would not be able to deal with a situation where it sends large packets (e.g. 1400 bytes) via a router with a small MTU (e.g. 900 bytes). The router would refuse to relay packets and send ICMP DU/FN that would not reach the Tails client. Because of the sysclt settings the Linux kernel would try to sent TCP retransmissions 5 times with increasing delta delays and then give up on the connection (-> people would not be able to upload large data in this circumstances) 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. Another solution would be to explicitly allow this specific type of ICMP packet from the outside. 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...). Cheers! Olli According to Jacob Appelbaum on Wed, Dec 03 2014: > Hi, > > After talking with a new friend about netfilter and the kerne
Re: [Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls
Hi, I retried the test but deleted the lease files from the directory you mentioned before reconnecting. I now see a complete DHCP DORA (Discovery, Offer, Request, Ack) on the wire. So nothing gets blocked. I would also expect that just doing a renewal (request, ack) should be blocked as the Ack is a response to the request. Doing some research I found that one possible explaination is that the dhclient uses raw sockets which get the packet even if netfiler rules are in place [1], [2]. This seems to be true: lsof -f | grep dhclient: dhclient 7946 root5u pack 34603 0t0 ALL type=SOCK_PACKET dhclient 7946 root6u IPv4 34605 0t0 UDP *:bootpc dhclient 7946 root 20u IPv4 34571 0t0 UDP *:45935 dhclient 7946 root 21u IPv6 34577 0t0 UDP *:44461 One would need to dig deeper into the dhclient code in order to check if this RAW socket is really necessary and if there are e.g. compile time options that would allow to just use UDP sockets (note also that dhclient does both it opens udp:68 and a raw socket) that would be filterable by the firewall. In general it might be better for security to have a derooted DHCP client that does not need CAP_NET_RAW and also has less attack surface then dhclient (C code + shell scripts). Maybe use a small replacement client that does only support bare minimum needed to get an IP4/6 and not the whole spec (instead of trying to fix dhclient)? Anyways, some efforts for dhclient are made here [3]. Regards, Olli [1] https://lists.isc.org/pipermail/dhcp-users/2012-August/015863.html [2] http://bit.ly/11YRHcE [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=308833 According to Michael Rogers on Thu, Dec 04 2014: > On 04/12/14 01:06, Oliver-Tobias Ripka wrote: > > - DHCP still works. Which is strange, isn't? I configured the > > firewall to drop everything so DHCP should not work. > > > > To debug a little I inserted some code into > > /etc/NetworkManager/dispatcher.d/00-firewall.sh to see what the > > state if ifconfig and iptables is right before bringing up the > > firewall: > > > > Result: The IP adress is already is configured (DHCP was renewed) > > and the iptables configuration is still set to DROP. So I am not > > sure how the DHCP packets could get through. Maybe I have a flaw in > > my debugging procedure or this is another issue. > > Is it possible that the DHCP client still has a valid lease that was > granted before the firewall rules were changed? Perhaps deleting any > leases in /var/lib/dhcp and bringing the interface up again will > change the result? > > Cheers, > Michael > ___ > Tails-dev mailing list > Tails-dev@boum.org > https://mailman.boum.org/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. -- Jabber contact o...@jabber.ccc.de PGP public key https://bockcay.de/otr.asc Off the record 32EA EEA8 955A 9FD7 6F61 94EB 4D7C 2A0E 9A2A 4D58 PGP fingerprint 6D63 8AA9 8B88 1266 DE0D 49EC 2490 01D2 9ADB 137B Textsecure 05CB 0C48 C87E FC47 2B13 7AD4 1D6E 0CE0 BB64 069A fingerprint 8BD7 227B 047F E38D 87D7 DE66 signature.asc Description: Digital signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls
According to anonym on Thu, Dec 04 2014: > FWIW I experienced no issues during my tests with *only* ESTABLISHED in > both the INPUT and OUTPUT chains so neither NEW nor RELATED seems > essential for the basic usage I tested. And of course the above > "exploits" didn't work due to the absence of NEW. You're right it work with ESTABLISHED only. This is due to whitelisted rule for the debian-tor user that may send any kind of packet. We might consider harden this rule to prevent leaks of other protocols by the debian-tor user; basically restrict it to only allow TCP SYN packets. The rest would be handled by the stateful rule. Cheers, Olli ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls
Thinking some more about this I think that there might not only be the TCP PATH MTU issue, but also my list of protocols used by Tails was incomplete. While it does not run by default I think I2P is supported within Tails and it seems to have also UDP firewall requirements [1] that need to be tested. Regards, Olli [1] https://geti2p.net/en/faq#ports ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls
According to Jacob Appelbaum on Thu, Dec 04 2014: > On 12/4/14, Oliver-Tobias Ripka wrote: > > According to anonym on Thu, Dec 04 2014: > > > >> FWIW I experienced no issues during my tests with *only* ESTABLISHED in > >> both the INPUT and OUTPUT chains so neither NEW nor RELATED seems > >> essential for the basic usage I tested. And of course the above > >> "exploits" didn't work due to the absence of NEW. > > > > You're right it work with ESTABLISHED only. This is due to whitelisted > > rule for the debian-tor user that may send any kind of packet. > > That is what I'd expect, yes. We should also tighten that user down as > well. What do you think for the first iteration? For the first iteration it is probably good to implement the changes suggested by you and tweaked by anonym: that is to narrow the stateful rules down to ESTABLISHED. At the same time we should be able to change the debian-tor rule to allow only NEW TCP packets, disallowing all other protocols. 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. Cheers, Olli ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls
According to anonym on Thu, Dec 11 2014: > So, in addition to "proto tcp", how does "--syn" compare to "state NEW"? > Actually, what is it we are trying to defend against here? Is there any > conceivable attack vector based on sending non-syn packets for > non-ESTABLISHED (i.e. NEW) TCP streams? Ok... aside from the defence-in-depth and the "it is a good idea to harden everyhting argument" ... One constructed theoratical scenario we would defend against is a bug in a specific Tor client or specific Kernel version that does not follow the TCP protocol and sends e.g. a SYN/ACK before a SYN. This would allow provide an attacker against Tor users to have an easier time to deanonymize users of this buggy stack because of this version anomaly that is visible on the network. Implementing the NEW state would prohibit such leaks. Cheers, Olli ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
