Small bug in TCP_Rewriter

Zeek
1

Hi,

This may already be fixed but I believe there is a bug in the TCP rewriter. I'm using
bro 0.9a10.5.

File TCP_Rewriter.cc, Line 710:

       ASSERT(next_packet->AppendData(data, left));
If the ASSERT preprocessor conditional isn't enabled, the statement isn't included in the
translation unit and using -A for re-writing doesn't include any payload (only headers) :frowning:

perhaps ..

         if(!next_packet->AppendData(data, left))
         { ASSERT(0); }

Plz. let me know if this isn't the appropriate forum for submitting bugs.

cheers,
.martin

2

Hey Martin :slight_smile:

Hi,

This may already be fixed but I believe there is a bug in the TCP
rewriter. I'm using
bro 0.9a10.5.

File TCP_Rewriter.cc, Line 710:

       ASSERT(next_packet->AppendData(data, left));

If the ASSERT preprocessor conditional isn't enabled, the statement
isn't included in the
translation unit and using -A for re-writing doesn't include any
payload (only headers) :frowning:

Uh-oh. Smells rotten to me!

Plz. let me know if this isn't the appropriate forum for submitting bugs.

Oh definitely. Keep 'em coming...

Cheers,
Christian.

3

Yes, thanks! This is a bug. And the fix looks right, too.

Ruoming

4

Sirs,

What is the best form to analyse the BRO received packets?
I need to calculate how many false positives bro detected in a determinated
period.

I didn't have success in reports, I continue receiving empty reports, then I
need to analyse the logs or using other way to detect what event is a false
positive and why is not.

Please, can you help me?

Thanks
Angelita

5

Martin,

I pretend to see what alerts bro detects. These information are not enough
to analyse if each alert is an attempt or false positive. I need alert
information.

Do you understand now?

tks
Angelita

6

Hi Jason,

I need to understand more the alert, the definition of each column.

In your example, could you explain me what each column means?

Sep 18 06:51:41 0.153497 131.243.2.87 131.243.2.13 http 2077 80 tcp 66 239 RSTO X %14
Sep 18 06:51:41 0.162454 131.243.2.87 131.243.2.13 http 2087 80 tcp 70 604 RSTO X %14
Sep 18 06:51:42 0.153911 131.243.2.87 131.243.2.13 http 2100 80 tcp 80 604 RSTO X %14
Sep 18 06:51:42 0.165501 131.243.2.87 131.243.2.13 http 2115 80 tcp 80 604 RSTO X %14

Date/time: Sep 18 06:51:42
Duration of de connection: 0.153497
Origin IP: 131.243.2.87
Victim IP: 131.243.2.13
Victim Protocol: http
???: 2077
Victim Port: 80
Transport Protocol: tcp
???: 66
???: 239 *** (is this the alert SID0?)
???: RSTO
???: X
???: %14

Does the bro use SID to identify the alert description?

Thanks
Angelita

7

Hi there,

Hi Jason,

I need to understand more the alert, the definition of each column.

In your example, could you explain me what each column means?

Sep 18 06:51:41 0.153497 131.243.2.87 131.243.2.13 http 2077 80 tcp 66 239 RSTO X %14
Sep 18 06:51:41 0.162454 131.243.2.87 131.243.2.13 http 2087 80 tcp 70 604 RSTO X %14
Sep 18 06:51:42 0.153911 131.243.2.87 131.243.2.13 http 2100 80 tcp 80 604 RSTO X %14
Sep 18 06:51:42 0.165501 131.243.2.87 131.243.2.13 http 2115 80 tcp 80 604 RSTO X %14

Date/time: Sep 18 06:51:42
Duration of de connection: 0.153497
Origin IP: 131.243.2.87
Victim IP: 131.243.2.13
Victim Protocol: http
???: 2077

Source port.

Victim Port: 80
Transport Protocol: tcp
???: 66

Bytes sent by originator.

???: 239 *** (is this the alert SID0?)

Bytes sent by responder.

???: RSTO

Connection state:
http://www.bro-ids.org/Bro-reference-manual/Connection-summaries.html

???: X

Connection flags, see same URL.

???: %14

That's additional data as reported by the analyzer, in this case, the
HTTP analyzer. You can use these for correlation (a "primary key" of
sorts).

http://www.bro-ids.org/Bro-reference-manual/http-variables.html

Cheers,
Christian.

8

Angelita,

http://www.bro-ids.org/Bro-reference-manual/Connection-summaries.html

Explains how the fields are structured, but its a little out of date.
I'll fill in the missing parts and see that the manual gets updated.

Given a line like this from the conn.log:

1122055977.662564 0.105927 10.1.1.1 10.2.2.2 http 55985 80 tcp 735 12946 SF L %71

Unix Date/time: 1122055977.662564
Duration of the connection: 0.105927
Originator IP: 10.1.1.1
Responder IP: 10.2.2.2
Protocol: http
Originator port: 55985
Responder port: 80
Transport Protocol: tcp
Originator bytes sent: 735
Responder bytes sent: 12946
Flags: SF (Normal connection saw both SYN and FIN packets)
Additional Flags: L (connection was initiated locally)
Tag: %71

Now I can take my tag, and look in the http.log to
find out more about that connection (i'm running the
http analyzer):

http.log looks like this (example):
1121793380.980924 %71 start 10.1.1.1 > 10.2.2.2
1121793380.985317 %71 GET /foo/bar/baz.html (200 "OK" [145])

Having said all this, the alarm.log is very different, its
a 'tagged' format that is fairly self descriptive. This is
an example from the alarm.log file:

t=1000057981.940712 no=AddressScan na=NOTICE_ALARM_ALWAYS sa=10.1.1.1 sp=2222/tcp da=10.2.2.2 dp=3333/tcp msg=10.1.1.1\ has\ scanned\ 2000\ hosts\ (3333/tcp
) tag=@42

t: time
no: notice
na: notice action
sa: source address
sp: source port
dp: destination port
msg: message (in this case a host has scanned 20 hosts)
tag: identifier to match this to lines in notice.log and conn.log:

Now you can take the tag and look in the conn.log to find the connection (with grep):

1000057956.062082 ? 10.1.1.1 10.2.2.2 other 2222 3333 tcp ? ? S0 X @142
(we can see that it didn't connect and no bytes were transfered)

Also there is a good section in the manual about alarms:
http://www.bro-ids.org/Bro-user-manual/Analysis-of-Incidents-and-Alarms.html#Analysis-of-Incidents-and-Alarms

That should help explain the sort ids.

Hope this helps.
Cheers,
jason

Angelita de Cássia Corrêa wrote:

9

Hi,
  I am trying to use the anonymization features of bro but it seems
that I can't enable it since no packets are written to output or log files.
Is there any documentation about these features? Any example policy scripts?

Thanks in advance,
Antonatos Spiros