Re: conntrack: TCP CLOSE and TIME_WAIT are not counted towards per-zone limit, and can overflow global table

[Florian Westphal <fw@strlen.de>]

Eugene Crosser <crosser@average.org> wrote:
> we are running a virtualization platform, and assign different conntrack
> zones, with per-zone limits, to different users. The goal is to prevent
> situation when one user exhaust the whole conntrack table on the host,
> e.g. if the user is under some DDoS scenario.
> 
> We noticed that under some flooding scenarios, the number of entries in
> the zone assigned to the user goes way above the per-zone limit, and
> reaches the global host limit. In our test, almost all of those entries
> were in "CLOSE" state.
> 
> It looks like this function in net/filter/nf_conncount.c:71
> 
> static inline bool already_closed(const struct nf_conn *conn)
> {
> 	if (nf_ct_protonum(conn) == IPPROTO_TCP)
> 		return conn->proto.tcp.state == TCP_CONNTRACK_TIME_WAIT ||
> 		       conn->proto.tcp.state == TCP_CONNTRACK_CLOSE;
> 	else
> 		return false;
> }
> 
> is used to explicitly exclude such entries from counting.
> 
> As I understand, this creates a situation when an attacker can inflict a
> DoS situation on the host, by opening _and immediately closing_ a large
> number of TCP connections. That is to say, per-zone limits, as currently
> implemented, _do not_ allow to prevent overflow of the host-wide
> conntrack table.
> 
> What was the reason to exclude such entries from counting?

I'd wager only intent was to limit *active* connections, not conntrack
entries.

This code originates from a time when zones did not exist, hence
conntrack upperlimit was sufficient, no partitioning needed.

> Should this exception be removed, and _all_ entries in the zone counted
> towards the limit?

I suppose so.