linux-kernel - Re: [BUG] SNAT sometimes allows packets to pass through unchanged

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4993B132.80908@trash.net>
Date:	Thu, 12 Feb 2009 06:18:42 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	netdev@...r.kernel.org,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] SNAT sometimes allows packets to pass through unchanged

Alan Stern wrote:
> I'm seeing some strange behavior on my firewall, which is running 
> Fedora 8's version of 2.6.26.  Every so often a packet with a private 
> source address is sent out the public interface unchanged, when it 
> should be dropped.
> 
> This happens when internal hosts are slow to close their end of a TCP 
> connection.  For example:
> 
> 	Internal host A (using a private address) initiates a TCP
> 	connection to an external server B.
> 
> 	Data is sent back and forth.
> 
> 	External host B sends a FIN and host A responds with ACK.
> 
> 	Several minutes later (after the tracking for this connection
> 	has expired), host A sends a FIN to host B.  This packet
> 	goes through the firewall unchanged and is sent out the
> 	public interface with the private source address intact.
> 
> Now I would expect that such packets would be dropped, because they 
> don't belong to an existing connection and they can't be the start of a 
> new connection.  The fact that this doesn't happen indicates there is a 
> bug in the netfilter code somewhere.

If the connection has already timed out (from conntracks perspective),
it has lost its state. Unless connection pickup is enabled, the packet 
will be marked as INVALID because it doesn't belong to a connection.
You can control dropping of these packets yourself by adding the
appropriate "-m state --state INVALID" rules. That said, there were
some bugs in the past few releases that caused some bad interaction
between TCP and TCP conntrack (not sure anymore which one of both was
to blame). Its possible that this is the root cause for this, so
you might want to consider a kernel update.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/