ICMP analyser incorrectly handles ICMP connections

Description

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
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
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

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 one connection and between timestamps 898088768.759437 and 898088797.366861 as another connection.

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

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

Activity

Show:
Seth Hall
June 15, 2016, 6:00 AM

This is a known behavior. Bro is creating fake "connections" for ICMP traffic. What you are likely looking for is an icmp.log (which doesn't exist yet) which would have a have a different logging unit than "connection".

Assignee

Unassigned

Reporter

Oman Security Officer

Labels

External issue ID

None

Components

Affects versions

Priority

Normal
Configure