Mikael Olsson wrote
>
> Ouch, that sucks. I really had higher hopes
> for checkpoint than that.
as far as there are only hopes, that doesn't hurt.
but don't rely on any fw vendor for your own security.
reread their licence to see onceagain that they are not
responsible of any security holes.... they only provide a tool,
and a imperfect one (perfect things have not yet been invented, but will
shortly be!).
> > > 1. FW-1 by default drops any fragmented packet that has
> > > a data length of 8 or 16 bytes.
>
> Hmmm let's see now. What happens if I send a 1500 byte (1480
> byte payload) packet that needs to go through a path with
> an MTU of 1492? Hmmm.. I get a one 1472 byte payload and
> then one 8 byte payload.
> Ouch.
8 and 16 bytes in the payload are definitely ok, so if FW1 rejects them,
it is a bug. The only condition on fragments payload size is that
the data length of all fragments but the last must be a multiple of 8 bytes
(a positive one, so zero is not ok).
so a packet fragmented into 8190 frags with 8 bytes each except the last
which contains
3 bytes, no IP options, is legitimate and is produced as an example in
[Stevens, TCP/IP illustrated].
> ...
> instead imagine what happens if you have to pass
> through a VPN or two with different header sizes. It
> gets more complex, but the same thing happens.
even if this would be complex, developpers may not make assumptions
on what is happening in experience, but must follow the standard whenever
possible.
I can see no benefit in rejecting 8/16 bytes fragments. why not reject
24bytes frags?
was the filter developped on August 16th?
regards,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
