| Message ID | 20220427065233.2075-7-w@1wt.eu (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | insufficient TCP source port randomness | expand |
From: Willy Tarreau > Sent: 27 April 2022 07:53 > > Moshe Kol, Amit Klein, and Yossi Gilad reported being able to accurately > identify a client by forcing it to emit only 40 times more connections > than there are entries in the table_perturb[] table. The previous two > improvements consisting in resalting the secret every 10s and adding > randomness to each port selection only slightly improved the situation, > and the current value of 2^8 was too small as it's not very difficult > to make a client emit 10k connections in less than 10 seconds. > > Thus we're increasing the perturb table from 2^8 to 2^16 so that the the > same precision now requires 2.6M connections, which is more difficult in > this time frame and harder to hide as a background activity. The impact > is that the table now uses 256 kB instead of 1 kB, which could mostly > affect devices making frequent outgoing connections. However such > components usually target a small set of destinations (load balancers, > database clients, perf assessment tools), and in practice only a few > entries will be visited, like before. Increasing the table size has a bigger impact on anyone trying to get the kernel to run in a limited memory footprint. All these large tables (often hash tables) soon add up. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Wed, Apr 27, 2022 at 08:07:29AM +0000, David Laight wrote: > From: Willy Tarreau > > Sent: 27 April 2022 07:53 > > > > Moshe Kol, Amit Klein, and Yossi Gilad reported being able to accurately > > identify a client by forcing it to emit only 40 times more connections > > than there are entries in the table_perturb[] table. The previous two > > improvements consisting in resalting the secret every 10s and adding > > randomness to each port selection only slightly improved the situation, > > and the current value of 2^8 was too small as it's not very difficult > > to make a client emit 10k connections in less than 10 seconds. > > > > Thus we're increasing the perturb table from 2^8 to 2^16 so that the the > > same precision now requires 2.6M connections, which is more difficult in > > this time frame and harder to hide as a background activity. The impact > > is that the table now uses 256 kB instead of 1 kB, which could mostly > > affect devices making frequent outgoing connections. However such > > components usually target a small set of destinations (load balancers, > > database clients, perf assessment tools), and in practice only a few > > entries will be visited, like before. > > Increasing the table size has a bigger impact on anyone trying > to get the kernel to run in a limited memory footprint. > > All these large tables (often hash tables) soon add up. We know, and the initial approach that required a significantly larger table and an extra table per namespace was a no-go. All these are part of the reasons for the effort it took to refine the solution in order to avoid such unacceptable costs. The way it was made here makes it easy to patch the value for small systems if needed and leaves the door open for a configurable setting in the future if that was estimated necessary for certain environments. Willy
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c index d746e5656baf..f30c50aaf8e2 100644 --- a/net/ipv4/inet_hashtables.c +++ b/net/ipv4/inet_hashtables.c @@ -726,11 +726,12 @@ EXPORT_SYMBOL_GPL(inet_unhash); * Note that we use 32bit integers (vs RFC 'short integers') * because 2^16 is not a multiple of num_ephemeral and this * property might be used by clever attacker. - * RFC claims using TABLE_LENGTH=10 buckets gives an improvement, - * we use 256 instead to really give more isolation and - * privacy, this only consumes 1 KB of kernel memory. + * RFC claims using TABLE_LENGTH=10 buckets gives an improvement, though + * attacks were since demonstrated, thus we use 65536 instead to really + * give more isolation and privacy, at the expense of 256kB of kernel + * memory. */ -#define INET_TABLE_PERTURB_SHIFT 8 +#define INET_TABLE_PERTURB_SHIFT 16 #define INET_TABLE_PERTURB_SIZE (1 << INET_TABLE_PERTURB_SHIFT) static u32 *table_perturb;