TCP syn flooding protection

Fri Apr 23 04:19:30 EDT 2021

On Fri, 23 Apr 2021 15:45:54 +0900, JeongHwan Kim said:

> I'm testing packet flooding test with old kernel version 2.6.30.

[/usr/src/linux-next] git show v2.6.30 | grep Date
Date:   Tue Jun 9 20:05:37 2009 -0700
[/usr/src/linux-next] git diff --shortstat v2.6.30..HEAD
 82911 files changed, 25695096 insertions(+), 6275216 deletions(-)

You're almost 26 million lines and 12 years out of date.  Why are you using
such an old version?  As GregKH will say, complain to the people who are
forcing you to use such an outdated kernel version.

(Another indication of how much code change has happened is that 82,911
files were changed - but there are currently only 72,245 files in the source tree)

> My board experienced process starvation when injecting ICMP flood with hping3 tool.
> I modified softirq invocation routine to launch ksoftirqd instead of executing do_softirq
> and I limitted the speed of ethernet phy to accept below 10Mbps.

What CPU are you running this on? Anything resembling modern hardware should be
able to handle *much* higher data rates. Of course, if you're stuck with decade-old
hardware, it's harder.  But even a Sun3/50 with a 16Mhz 68020 processor back in
1986 was able to deal with 10Mbps traffic.

Also, note that the critical point is the packets per second, not the bitrate
of the PHY.  On server-class hardware, it's trivial to get 10 gigabit/sec
traffic when using MTU=9000, harder at MTU=1500, and *very* difficult to handle
10Gbit/s of 64-byte minimum size packets (even *generating* that many packets
that fast requires some cleverness).

> It seems that the board can process flooding ICMP packets of 10Mbps,
> but the board cannot process against TCP/UDP packet flooding,
> the speed of processes become slow down.

Well, it *should* self-protect against TCP packet flooding by simply not
sending ACK packets with sequence numbers until those sequence numbers have
actually been dealt with.

However, UDP doesn't have any such built-in protections.

> How can I protect the TCP/UDP flooding in my environment.

It's not TCP/UDP flooding that's your problem.  Packet flooding *in general* is
a problem.  The only reason you think ICMP is working is because the per-packet
overhead for handling an ICMP flood packet is much lower - UDP and TCP have to
do more processing, especially if the packet is going to a port number that's
actually in use. TCP packets to non-open ports are cheap to send an RST packet
back, and UDP packets to non-open ports are equally cheap (but send an ICMP
PORT UNREACHABLE instead), but if a TCP or UDP packet is going to an open
port, there's a lot more processing that has to be done even if the packet is
going to be discarded.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20210423/4b3c3b19/attachment.sig>