[Bug 192888] ipfw NAT vulnerable to simple DOS attacks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888 --- Comment #8 from Lutz Donnerhacke --- May you please test your problem against 14-CURRENT? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 192888] ipfw NAT vulnerable to simple DOS attacks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888 --- Comment #7 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=d261e57deacb0d00d9e827447f235df83dda3e3a commit d261e57deacb0d00d9e827447f235df83dda3e3a Author: Lutz Donnerhacke AuthorDate: 2021-05-28 20:36:59 + Commit: Lutz Donnerhacke CommitDate: 2021-06-19 20:12:28 + libalias: Switch to efficient data structure for incoming traffic Current data structure is using a hash of unordered lists. Those unordered lists are quite efficient, because the least recently inserted entries are most likely to be used again. In order to avoid long search times in other cases, the lists are hashed into many buckets. Unfortunatly a search for a miss needs an exhaustive inspection and a careful definition of the hash. Splay trees offer a similar feature: Almost O(1) for access of the least recently used entries, and amortized O(ln(n)) for almost all other cases. Get rid of the hash. Now the data structure should able to quickly react to external packets without eating CPU cycles for breakfast, preventing a DoS. PR: 192888 Discussed with: Dimitry Luhtionov MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D30536 sys/netinet/libalias/alias_db.c| 75 +- sys/netinet/libalias/alias_local.h | 6 +-- 2 files changed, 36 insertions(+), 45 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 255775] panic with ipfw turned on at boot time
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255775 --- Comment #20 from Michael Meiszl --- About the load sequence: I was also suprised to see when I have checked it with "rcorder ..." But it does not seem to be important. I've tried to change the order to insure that gif0 is created and up before ipfw is loaded, it made no difference to the crashes. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 255775] panic with ipfw turned on at boot time
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255775 --- Comment #19 from Michael Meiszl --- Created attachment 225933 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=225933=edit ruleset mam -- You are receiving this mail because: You are the assignee for the bug.
[Bug 255775] panic with ipfw turned on at boot time
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255775 --- Comment #18 from Michael Meiszl --- (In reply to Mark Johnston from comment #17) No big problem, the rules are straightforward. See attached rulesfile. (I needed to blur out some IPs, they are not good for the public) Originally I had Table(1/2/3) filled by failtoban, but I converted them to static rules in the hope that the bug was inside the table management (did not work, sniff) Anyway, its a very restrictive setting. 80% of the world is locked out. For V6 only certain ports to certain hosts are offered to the outside (there is no V4 restriction on ports because that is handled by a different machine). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 255775] panic with ipfw turned on at boot time
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255775 --- Comment #17 from Mark Johnston --- (In reply to Michael Meiszl from comment #16) I don't have a good place to upload vmcores, sorry. Google drive is used sometimes. Reading through again, I'm not sure that a vmcore will be very useful. I suspect your comment 2 is a good clue. I don't quite follow though: the firewall rules reference gif0, and the rules are loaded before gif0 is created? I would have assumed that this would not be permitted. It may be more useful to share the exact ruleset you're using. -- You are receiving this mail because: You are the assignee for the bug.
