Hi all,
Mikkel Refsgaard Bech wrote:
> Hi,
>
> This patch provides a new target called LOWTW, which gives the ability
> to change the timeout in the TIME-WAIT state on connections in the
> conntrack table. It always accept packets.
>
> This is useful when you have a _lot_ of short-lived connections
> through your firewall (eg. web traffic), because each conntrack have a
> timeout of 2 minutes (default, hard-coded) the conntrack table could
> be filled with entries in the TIME-WAIT state.
>
> The patch is simple, it just sets the timeout (specified with the
> "--lowtw-set n", where n is the timeout in seconds) on the conntrack
> when the conntrack enters the TIME-WAIT state.
>
> E.g. to avoid the conntrack table to filled with entries from web
> traffic from your LAN do: iptables -A FORWARD -p tcp -source
> 192.168.0.0/24 --dport 80 -j LOWTW --lowtw-set 10
>
> The patch was tested against 2.4.18.
>
> Any comments, bug-reports or questions are welcome.
It looks like nobody is interested in this feature, but I really think
this point is important.
One of the major problem introduced by using stateful inspection in a
firewall seems to be that it introduces some denial of services
vulnerability. Indeed, storing the states of all the valid connection
takes some space in memory and memory is well known to be a limited
ressource.
According to this, minimizing the number of connections held in this
table should be as small as possible.
The problem of the time out of a connection from the stateful firewall
point of view is that the last ACK packet expect no answer from
the receiver... except if this ACK message get lost somewhere AFTER
the firewall.
Final packet:
FIN+ACK
Client -----------> Firewall Server
FIN+ACK
Client Firewall -----------> Server
ACK
Client Firewall <----------- Server
Packet is lost:
ACK
Client X--------- Firewall Server
Time-out:
ACK
Client Firewall <----------- Server
?
If the connection is removed from the table when the firewall see
the FIN+ACK packet, them it will not be abble to handle the resent
of the FIN+ACK. But, in another hand, if you keep the connection
too long, you are very much exposed to DOS attacks.
In the current Netfilter, you are waiting 120 secs
(see TCP_CONNTRACK_TIME_WAIT).
But this patch seems to reduce this waiting time... or at least
that's my feeling.
Regards
--
Emmanuel
And I'm right. I'm always right, but in this case
I'm just a bit more right than I usually am.
-- Linus Torvalds
