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

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] [day] [month] [year] [list]

Date: Wed, 20 Sep 2023 23:47:37 +0200
From: Florian Westphal <fw@...len.de>
To: Eugene Crosser <crosser@...rage.org>
Cc: netdev@...r.kernel.org, Florian Westphal <fw@...len.de>,
	Yi-Hung Wei <yihung.wei@...il.com>,
	Martin Bene <martin.bene@...medias.com>
Subject: Re: conntrack: TCP CLOSE and TIME_WAIT are not counted towards
 per-zone limit, and can overflow global table

Eugene Crosser <crosser@...rage.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.