| |
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [FW-1] Virtual defragmentation error:
This happens to relate to a class of semi-theoretical attacks that I've
been researching lately.
TCP/IP includes a mechanism for splitting up "segments" (TCP/UDP/etc layer
"packets") into "fragment" IP-level packets (to improve odds of successful
delivery), and reassembling them at the destination. Typically, fragments
include only IP-level headers, and so security decisions about
allowing/blocking fragments based on port/session info cannot be properly
made without reassembling the fragments. However, since the fragments
themselves should be forwarded (if allowed) and not the reassembled segment,
there is a sense in which this midstream reassembly is "virtual".
Look at the info we have about the particular fragment that triggered the
error:
proto 17 -- This is a UDP segment. Note that this means that there is
no connection, so the origin may be freely spoofed.
id 13887 -- The id field is an IP header field whose value should be
the same for all fragments of the same segment. Anybody who wants to do
reassembly needs to collect together fragments whose (source, destination,
id) all match, and this probably requires some kind of memory structure that
might be called a "table". One of the attacks that is part of the class
I've been looking at involves deliberately sending fragments with random
ids, in order to fill up such a table. (Odds are good, too, that there are
protocol stacks out there whose code for searching this table is O(n) (or
perhaps even worse) because in non-pathological cases the performance of
this code is rarely critical.)
len 1500 -- This is a typical fragment size (slightly less than the
TCP/IP MTU) for Ethernet traffic. This at least suggests that the
originator is simply throwing large segments at the network, and letting
normal TCP/IP stack code fragment them, rather than crafting pathological
fragments.
offset 31080 -- The segment that this fragment is part of is apparently
at least 32K in size. While there are various ways to implement this
(generally, trying to improve performance by (pre) allocating lots of buffer
space), each (source, destination, id) entry in the table needs space to
hold/reassemble the fragments, up to the full 64K that is the maximum
segment size. (While a security device *that is not, itself, the traffic
destination* only needs to look at the TCP/UDP/whatever header, it needs to
hold the rest of the fragments until a decision can be made.)
I think what you're actually seeing is a bandwidth-exhaustion
(distributed?) denial-of-service attack. The attacking code allocates a big
buffer, 32-64K, (possibly spoofing the source address), and hands it off to
UDP for delivery. The source machine's IP layer code slices it up into
1500-byte fragments and fires them at the destination, chewing up lots of
bandwidth in the process. In the distributed case, various compromised
machines around the net are all doing that, and the incoming traffic swamps
the destination's connection to the outside world.
I don't think that the fragmentation table overflow is intended by the
sender; if it was, they could probably create that kind of effect by
crafting pathological fragments, using much less bandwidth at the source....
Dave Gillett
> -----Original Message-----
> From: Mailing list for discussion of Firewall-1
> [mailto:[email protected]]On
> Behalf Of Anuska
> Aragón Fernández
> Sent: Friday, June 07, 2002 3:20 AM
> To: [email protected]
> Subject: [FW-1] Virual defragmentation error:
>
>
> I'm having a lot of this messages.
> Can someon explain why is this happening and how can I solve it?
> I'm using NG FP2 in RedHat Linux 7.2
>
> kernel: FW-1: Virtual defragmentation error: frag_table is
> full (..xxx.xxx -> yyy.yyy.yyy.yyy proto 17 id 13887
> len 1500 offset 31080) - 10458 fragments dropped during the
> last 60 seconds
>
>
> Thanks.
>
> --
> A n u s k a A r a g ó n
> Servicio Informático e-mail: [email protected]
> Universidad de La Rioja Tf.: +34 941 299233
> Av. de La Paz 93, 26004 Logroño Fax: +34 941 299180
>
> =================================================
> To set vacation, Out Of Office, or away messages,
> send an email to [email protected]
> in the BODY of the email add:
> set fw-1-mailinglist nomail
> =================================================
> To unsubscribe from this mailing list,
> please see the instructions at
> http://www.checkpoint.com/services/mailing.html
> =================================================
> If you have any questions on how to change your
> subscription options, email
> [email protected]
> =================================================
>
=================================================
To set vacation, Out Of Office, or away messages,
send an email to [email protected]
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
[email protected]
=================================================
|
|
