Date: Fri, 20 Jun 2025 17:11:44 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 287229] IP reassembly issue in FreeBSD 14.1 Message-ID: <bug-287229-7501-Nmt3Vz6uhi@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-287229-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-287229-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D287229 --- Comment #31 from Gleb Smirnoff <glebius@FreeBSD.org> --- On Fri Jun 20 10:03:19 2025 UTC, lucas.aubard@irisa.fr wrote: > We are currently working on Network Intrusion Detection Systems (NIDS) ev= asion > with overlapping IP fragments or TCP segments. > Some NIDSes (Suricata, Snort) propose configuring their IP and TCP reasse= mblies > based on the supervised host OSes as an evasion countermeasure to > overlapping-based attacks. In that context, we test OSes (and other stack= s) to > obtain and describe their reassembly policies so NIDSes can implement and > propose them. > From a NIDS perspective, OS reassembly consistency is thus quite importan= t. Security wise, the coin has two sides. If an attacker can predict what exa= ct fragments would be freed once a system runs out of reassembly queue limits, then they can instrument attacks that would target specific connections. In FreeBSD we salt the hash with a random seed: V_ipq_hashseed =3D arc4random(); This makes distribution of fragment reassemble queue across the hash slots = not predictable by the attacker. For your experiments, you can disable that. = But for the general use of the system, we consider that not a bug, but a featur= e. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-287229-7501-Nmt3Vz6uhi>