Mikael Olsson wrote:
>
> Stateful inspection firewalls worth their name ought to be able
> to protect you from this if the guy that coded the fragment
> (pseudo)reassembly routines had half a brain. I would certainly
> hope that FW-1 is included in this category.
NOT!
To quote a recent post from Lance Spitzner <[EMAIL PROTECTED]>:
>
> There has been a great deal of 'controversy' concerning
> how FW-1 handles IP fragmentation. I'm not a big fan of
> speculation, so I decided to test it myself. Below are
> the results (tested on FW-1, ver 4.1 on Solaris x86 2.7)
> Some understanding of IP Fragmentation is expected. Keep
> in mind that the data legnth of Frag IP packets is increased
> in increments of 8 bytes (Stevens).
>
> 1. FW-1 by default drops any fragmented packet that has
> a data length of 8 or 16 bytes. At a minimum, the fragmented
> IP packet must have a minimum data legnth of 24 bytes. This
> means 'nmap -f' scans are dropped by default by FW-1. The
> log entry will be rule 0 with info "reason: TCP packet too short".
>
> 2. Fragmented packets accepted by FW-1 rulebase (minimum 24 bytes)
> are forwarded in the fragmented state. Frags in, frags out.
So re-assembly is not performed. FW-1 either drops sub-minimum fragments
of forwards the fragments along in their original state.
Some interesting things to try:
Combine with FW-1 default of rebuilding the state table with ACK's
Fragment the transport header as well
Try fragments that are not a factor of 8x
Hummmm.....
Chris
--
**************************************
[EMAIL PROTECTED]
* Mastering Cisco Routers
http://www.amazon.com/exec/obidos/ASIN/078212643X/
* Mastering Network Security
http://www.amazon.com/exec/obidos/ASIN/0782123430/
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
