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

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

[Eugene Crosser]

[-- Attachment #1.1: Type: text/plain, Size: 1380 bytes --]

Hello,

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?
Should this exception be removed, and _all_ entries in the zone counted
towards the limit?

Thanks

Eugene

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Florian Westphal]

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.