Related to yesterdays post entitled IDS and IPS systems and their effectiveness on reppelling penetration tests, Network World recently conducted a review of the prevention-ratio from of IPS:s whom are a part of UTM-products.

We tested intrusion-prevention systems in two scenarios: protecting clients (such as Web browser) and protecting servers (such as Web and e-mail servers) separately. The percentages shown are scores from our tests using Mu Security’s Mu-4000 Security Analyzer appliance to launch the attack traffic, showing what percentage of the known vulnerabilities in each category (attacks against clients, and against servers) was caught by each IPS.

The tool used in the tests are from mu Security. My, very rough, analysis of the results

• Juniper has the greatest detection and prevention rate with 87 procent catch rate of server-side attacks and 70 procent of client-side attacks. My conclusion is as such that IPS systems -at best- prevents us from roughly 80 procent of known vulnerabilities. Interestingly, this equals the ineffectiveness of anti-malware technology.
• By doing a quick overview of the results I would say that the avarage prevention rate is around 35 procent of known vulnerabilities, validating that my saying that IPS-systems in general provide very little value.

A very important thing to say about the test is that it in no way models the nature of the threat. The tests are based on publically known vulnerabilities and exploits which all of the vendors have had access to if they had care to look for them (or contact mu Security for a couple of test runs). In reality, we face issues such as evasion, noise, unkown vulnerabilities and unknown services. The results of this test are as such the best possible outcome and should be considered overly optimistic. Still interesting, and WAY better than SC Magazines attempt.

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.