Bug 192888 - ipfw NAT vulnerable to simple DOS attacks
Summary: ipfw NAT vulnerable to simple DOS attacks
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 9.2-RELEASE
Hardware: Any Any
: --- Affects Many People
Assignee: Lutz Donnerhacke
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-21 13:57 UTC by napTu
Modified: 2021-05-04 16:24 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description napTu 2014-08-21 13:57:22 UTC
ipfw NAT vulnerable to DOS attacks by sending ip packets to external ip address and any port.
In this situation CPU usage goes to 100%.

NAT should find a matched internal address, and, if not, skip the packet to external ip.

This process (with failed search) take a many time and resources.
Comment 1 Tom Jones freebsd_committer 2020-09-19 16:35:58 UTC
Could you add some more detail or steps to reproduce? If this issue still exists in FreeBSD I would be very interested in fixing this. If I don't have any response in the next few months I will close this issue.
Comment 2 Lutz Donnerhacke freebsd_committer 2020-09-20 11:26:08 UTC
It seems that the problems still exists:
(Articles in German)
https://lutz.donnerhacke.de/Blog/Performance-Probleme-mit-NAT
https://lutz.donnerhacke.de/Blog/Wenn-der-Traceroute-Kreise-tanzt

It's a variant of the LAND attack https://en.wikipedia.org/wiki/LAND.

My solution is to use ipfw (which is used to activate NAT) to drop incoming packets sourced from the public NAT IP. So simple antispoofing.
Comment 3 Lutz Donnerhacke freebsd_committer 2021-05-02 20:09:01 UTC
All versions up to current are affected.
Comment 4 Lutz Donnerhacke freebsd_committer 2021-05-04 16:24:29 UTC
I went through the source code and can drill the problem down to an full scan of an unsorted linked list in a given hash bucket. This eats CPU cycles for breakfast.

A workaround is to increase the hash table size in sys/netinet/libalias/alias_local.h:
#define LINK_TABLE_OUT_SIZE        4001

A short term solution is to make the hard coded parameters tunable.

But the real solution is to find a data structure which allows sub linear access methods to the flow data. Possibly using a non blocking algorithm for access and modification.