Hello All,
Just a quick question. I am doing scrub on my upstream OpenBSD server.
Will this work as a temporary workaround for this security flaw (below)
in FreeBSD?
Regards
Mark
-Forwarded Message-
From: FreeBSD Security Advisories [EMAIL PROTECTED]
To: FreeBSD Security Advisories
On Wed, Mar 03, 2004 at 11:40:03AM +0200, Mark Bojara wrote:
Just a quick question. I am doing scrub on my upstream OpenBSD server.
Will this work as a temporary workaround for this security flaw (below)
in FreeBSD?
No, scrub does IP reassembly (assembling IP fragments into complete IP
On Tue, Mar 02, 2004 at 09:27:48AM -0800, Getchell, Adam wrote:
I'm under the impression pf keeps the state table across reboots, but
Googling for it just gives Darren Reed's response:
http://monkey.org/openbsd/archive/misc/0201/msg01135.html
Does it?
No, the state table is not stored in a
It might be worth adding that the traffic exploiting that problem is not
invalid in any sense. TCP segments can arrive out-of-order in legitimate
usage, too. For instance, individual TCP packets of one connection can
take different paths to your peer, so a higher fragment may very well
arrive
What is the difference between the 2 block'ing rules below
... table garbage { 127/8, 10/8, 172.16/12, 192.168/16, 255.255.255.255/32 }
... block in log quick on $exIF from no-route to any
... block in log quick on $exIF from garbage to any
i.e. what does no-route expand to.
The manual entry
On Wed, Mar 03, 2004 at 09:24:41PM +1100, Damian McGuckin wrote:
What is the difference between the 2 block'ing rules below
... table garbage { 127/8, 10/8, 172.16/12, 192.168/16, 255.255.255.255/32 }
... block in log quick on $exIF from no-route to any
... block in log quick on $exIF
On Tue, Mar 02, 2004 at 09:27:48AM -0800, Getchell, Adam wrote:
I'm under the impression pf keeps the state table across reboots, but
It does not.
