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...
According to Jacob Appelbaum on Thu, Dec 04 2014:
On 12/4/14, Oliver-Tobias Ripka o...@bockcay.de 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
] 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
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.
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
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