Dumping traffic on Juniper IDP

One of the things that is crucial of an IDS/IPS is the ability to get more information about an attack than just the alerts. An alert won’t, by itself, serve well as evidence in the court. It won’t tell you what really happened either. At the point when a truly critical alert is fired, you will wan’t to look at the detals. Who did it? What did he do? Can we prove it?

The IDS/IPS from Juniper Networks, a.k.a. IDP, has Tcpdump available on the sensors, but also a self-developed script that does log rotating of Tcpdump captures in a nice way. This makes the IDP an ideal platform for dumping real time network traffic in “ring buffer mode”. Which essentially mean that we can, in an automated fashion, store packet captures for a specified time back in history.

The script, called dumpLoop, uses Tcpdump for packet capture and can be configured in numerous ways, depending on how long back in time you’d want captures for etc. Here what executing dumpLoop looks like, configured to capture on interface eth2, saving 5 files, each being a hundred megabytes.

[root@defaulthost admin]# dumpLoop -i eth2 -k 5 -s 100000000
Starting loop.
Checking capture filesize...
File nofile.cap does not exist.
...size check complete.
Rotating tcpdump...
New filename:200705111455_eth2.cap
Starting new... (tcpdump -n -i eth2 -s 0 -w 200705111455_eth2.cap )...
tcpdump: WARNING: eth2: no IPv4 address assigned
tcpdump: listening on eth2
Reset PID...
New PID is 7706.
...rotation complete.
...check complete.
Checking log count...
Keeping 200705111455_eth2.cap
...end log count check.
Break to exit.
Checking capture filesize...

This configuration allows us to have 500 megs of traffic captures, which is basically a few hours on a moderately busy link. The files are stored in the current working directory and is named in a good way that describes when the capture started and on what interface. A log file of the process shown above is also written to disk as seen below

[root@defaulthost admin]# ls -lh
total 1.3M
-rw------- 1 root root 1.3M May 11 14:56 200705111455_eth2.cap
-rw------- 1 root root 392 May 11 14:56 dumpLoop_200705111455.log

Replaying the contents of the capture is as easy as letting tcpdump read the file, using the f-flag.

[root@defaulthost admin]# tcpdump -r 200705111455_eth2.cap
14:55:39.286474 802.1Q vlan#100 P0 X.X.X.9.rtsp > X.X.X.63.1514: . 14981:16441(1460) ack 1 win 64785 (DF) [tos 0x70]
14:55:39.286479 802.1Q vlan#4093 P0 X.X.X.63.1514 > X.X.X.9.rtsp: . ack 16441 win 65535 (DF)
14:55:39.286486 802.1Q vlan#100 P0 X.X.X.9.rtsp > X.X.X.63.1514: . 16441:17901(1460) ack 1 win 64785 (DF) [tos 0x70]
14:55:39.286491 802.1Q vlan#100 P0 X.X.X.9.rtsp > X.X.X.63.1514: P 17901:18028(127) ack 1 win 64785 (DF) [tos 0x70]
14:55:39.288620 802.1Q vlan#4093 P0 X.X.X.63.1514 > X.X.X.9.rtsp: . ack 18028 win 65535 (DF)
14:55:39.389889 802.1Q vlan#4093 P0 X.X.X.57.2412 > X.X.X.58.1863: . ack 320 win 64508 (DF)

If other tools suits the analysis better, such as Wireshark, Tshark or Argus, the captured files could of course be copied to another system.