[Bro] Fragmentation and TCP overlapping Issues

[Veronica Estrada]

Hello,
Sorry for sending again these questions to the list but I haven't received
any answer to my old post in bro list. Besides, I want to add more details.
We try to understand the behavior of BRO regarding fragmentation and other
related issues. I am validating results with another IDS (Snort) and results
are surprisingly different, but to  understand the differences we need
answers to the questions in e-mail below. For example, check question 7: in
our traces, there is a file that contains corrupted headers and  several
packets. Snort output is different whether we use the original file or a
truncated version:

Original file (contains corrupted headers):

DISCARD: 87.9%

TCP: 11.751%

OTHER: 1379

Total fragments: 36

TCP Overlaps: 1494

ALERTS: 1836

Processed packets: 3,771,244 (discard: 3311766)

Same file but truncated since the point where wireshark  triggers "corrupted
header" and cannot read anymore

DISCARD: 0 %

TCP: 94%

OTHER: 22819

Total fragments: 1072 (fragments reassembled 522)

TCP Overlaps: 34580

ALERTS: 116877

Processed packets: 3,795,710

Original file 4Gb, Truncated file 3.9 Gb

BRO output is identical for both files. Moreover, I cannot check how many
discard packets or how BRO deals with the corrupted header packets.
Regarding question 1 below, I am using libpcap 1.0.0.
Thank you in advance,

Veronica Estrada

On Thu, Nov 25, 2010 at 12:25 AM, Veronica Estrada <
estrada.veronica at gmail.com> wrote:

>
> Hello everyone,
>
> First of all, tomorrow is thanksgiving and I would like to thank all of you
> for all the feedback I've always received to my posts.
>
> I continue with my research on anomalies, now focus on evasion techniques,
> and I need to ask you some help to understand how BRO deals with
> fragmentation and TCP overlapping issues.  For reference, I am using Bro
> 1.5.1 in offline analysis.
>
>
> 1. Although I am loading "frag", I am not receiving any event related with
> fragmentation.
>
> What could be wrong? libpcap library? my BRO version?
>
>
> 2. What are the possible events triggered by weird analyzer related with
> tcp overlapping? (because I am not getting any of them although I think I
> should see them on my trace)
>
>
> 3. TCP overlapping problems may generate "partial_ftp_request",
> "partial_RPC_request" or other partial events? and also confuse BRO on how
> the connection should be flagged? For example a connection with flag "S0",
> no reply seen could be related with TCP overlapping problems?
>
>
> 4. How does BRO perform TCP reassembly? I mean, is the traffic on ALL ports
> reassembled? Is there any way to apply a default policy for doing TCP
> reassembly? Like Policy First or Last or Unix…
>
>
> 5. There is an "active mapping" function to improve TCP reassembly. Can we
> define the host profile database without this active function?
>
>
> 6. Can we configure the size of the reassembly buffer? I read in historical
> msg (from 2006) there wasn't such config and BRO presented a vulnerability
> against an adversary trying to exhaust memory, is this a current
> possibility?
>
>
> 7. By doing offline analysis, I understood that BRO will analyze all the
> packets without loss even if the CPU is running at 100%. Still, I need
> information about dropping packets for other reasons. For example, if BRO
> encounters TCP overlapping, Does it drop all the packets? Choose some of
> them? Are these actions log somewhere? The same with fragmentations issues.
> Where can I check the portion of fragments that where reassembled? how many
> frames discarded, etc?
>
>
> 8. I am not seeing any difference in bro logs when I analyze 2 pcap files.
> One file contains some malformed packet at the end and wireshark says "the
> packet is bigger than 65535", the other pcap file is the same file but
> truncated using editcap to avoid this "malformed packet" (if I check the hex
> using hd, the part truncated represents 850MB ). All the logs of BRO when
> input is one file or the other are identical. Is this the expected result?
>
>
> Veronica Estrada
>
> Nakao Lab. Network System Research Group
>
> University of Tokyo
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20101205/a42d95c6/attachment.html