Oman Security Officer created BIT-1488:
------------------------------------------
Summary: ICMP analyser incorrectly handles ICMP connections
Key: BIT-1488
URL: https://bro-tracker.atlassian.net/browse/BIT-1488
Project: Bro Issue Tracker
Issue Type: New Feature
Components: Bro
Affects Versions: 2.4
Environment: Security Onion 12.4 (Linux 3.13.0-63-generic
#104~precise1-Ubuntu SMP x86_64 GNU/Linux) installed On VMware Workstation
(10.0.3 build-1895310) running on Windows 8.1 Enterprise
Reporter: Oman Security Officer
Attachments: results.txt, test_icmp.bro
I have been testing BRO scripts on DARPA 1998 dataset (Week 3 - Wednesday)
TCPDUMP
[https://www.ll.mit.edu/ideval/data/1998/training/week3/wednesday/tcpdump.gz].
This file contains a lot of ICMP packets. I was testing ICMP events in BRO to
understand their role.
* event *icmp_echo_request*(c: connection, icmp: icmp_conn, id: count, seq:
count, payload: string)
* event *icmp_echo_reply*(c: connection, icmp: icmp_conn, id: count, seq:
count, payload: string)
It seems that, the ICMP analyser does not handle the ICMP connections in the
right way. I have noticed that, when I use those 2 events the "*c: connection*"
variable does not return the right results.
For example, the mentioned DARPA file contains the following ICMP traces
between hosts 202.72.1.77 and 172.16.112.50. the exchanged packet are
summarized in the following table:
No. Time Source Destination Protocol Length Info
{color:#f6c342}28076 898088609.998513 202.72.1.77 172.16.112.50
ICMP 60 Echo (ping) request id=0xf305 seq=0/0 ttl=63
28077 898088610.000822 172.16.112.50 202.72.1.77 ICMP 60
Echo (ping) reply id=0xf305 seq=0/0 ttl=254
28150 898088612.998292 202.72.1.77 172.16.112.50 ICMP 60
Echo (ping) request id=0xf305 seq=256/1 ttl=63
28151 898088612.998641 172.16.112.50 202.72.1.77 ICMP 60
Echo (ping) reply id=0xf305 seq=256/1 ttl=254
28669 898088644.998259 202.72.1.77 172.16.112.50 ICMP 60
Echo (ping) request id=0xf405 seq=0/0 ttl=63
28670 898088644.998652 172.16.112.50 202.72.1.77 ICMP 60
Echo (ping) reply id=0xf405 seq=0/0 ttl=254
28682 898088647.998159 202.72.1.77 172.16.112.50 ICMP 60
Echo (ping) request id=0xf405 seq=256/1 ttl=63
28683 898088647.998566 172.16.112.50 202.72.1.77 ICMP 60
Echo (ping) reply id=0xf405 seq=256/1 ttl=254{color}
{color:#f79232}30478 898088768.759437 202.72.1.77 172.16.112.50
ICMP 60 Echo (ping) request id=0xf176 seq=0/0 ttl=63
30479 898088768.760917 172.16.112.50 202.72.1.77 ICMP 60
Echo (ping) reply id=0xf176 seq=0/0 ttl=254
31016 898088797.366418 202.72.1.77 172.16.112.50 ICMP 60
Echo (ping) request id=0xf276 seq=0/0 ttl=63
31017 898088797.366861 172.16.112.50 202.72.1.77 ICMP 60
Echo (ping) reply id=0xf276 seq=0/0 ttl=254{color}
It can be seen that, there are 6 ICMP connections by exchanging 12 packets (6
Echo Requests and 6 Echo Replays). Whereas, Bro will handle them as 2
connections only making the final results inaccurate.
I have found that, BRO will treat all requests and replays between timestamps
898088609.998513 and 898088647.998566 as *{color:#f6c342}one connection{color}*
and between timestamps 898088768.759437 and 898088797.366861 as
*{color:#f79232}another connection{color}*.
The results of calling events *icmp_echo_request* and *icmp_echo_reply* on that
file between the named hosts (202.72.1.77 and 172.16.112.50) can bee found in
the attached file (results.txt) as well as the script file (test_icmp.bro).
The following commands were called to obtain the results
> wget -c
> https://www.ll.mit.edu/ideval/data/1998/training/week3/wednesday/tcpdump.gz
> gzip -d < tcpdump.gz > week3_Wednesday.tcpdump
> bro -r week3_Wednesday.tcpdump test_icmp.bro > results.txt
--
This message was sent by Atlassian JIRA
(v7.0.0-OD-07-011#70107)
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
