I was directed to a great document on some theory of detection and prevention - or as the author likes to compare it with: solving mysteries and puzzles.

Puzzles can be solved; they have answers. But a mystery offers no such comfort. It poses a question that has no definitive answer because the answer is contingent; it depends on a future interaction of many factors, known and unknown

This is interesting:

Solving puzzles is useful for detection. But framing mysteries is necessary for prevention.

A great example of the issues of prevention of unknown vulnerabilities:

To analysts in the Pentagon, for instance, terrorists present the ultimate asymmetric threat. But the nature of the threat is a mystery, not a puzzle. Terrorists shape themselves to our vulnerabilities, to the seams in our defenses; the threat they pose depends on us. The 9/11 hijackers, for instance, did not come to their plan of attack because they were aviation buffs. They came to it because they had identified gaps in our aviation defenses.

Why we need to look for indications of suspicious activity, at different places, and correlate these:

By contrast, mysteries often grow out of too much information. Until the 9/11 hijackers actually boarded their airplanes, their plan was a mystery, the clues to which were buried in too much “noise�—too many threat scenarios. So warnings from FBI agents in Minneapolis and Phoenix went unexplored. The hijackers were able to hide in plain sight. After the attacks, they became a puzzle: it was easy to pick up their trail.

Finally on how medicine, which is very similar to reactive security efforts, correlates indications before they give treatment:

Doctors base an initial assessment of a patient’s health on propensity, as revealed by his or her medical history, and on diagnosis, determined through an examination. If the doctor’s initial assessment is of a high probability of disease, he or she orders more tests, which in turn refine that probability. For chronic concerns, such as high blood pressure leading to heart disease, the initial assessment leads to a decision about whether and how to treat, followed by subsequent tests to see if the original probability of problems can be revised downward.

There is no coincidance that a certain IPS-vendor claims their IPS to be a “DigitalVaccine”. Only, they apply their cure only by looking at a single packet. That perhaps why they sometimes get it wrong - all IPS products in some sense do. And in some cases, as with medicine and cure of a human with a decease, gettings things wrong isn’t acceptable - it could render in a even worse condition, death or block of absolutely bussiness critical traffic. But there are products that functions more like doctors.

Encrypted and encoded traffic has always been one of the troubles for IDS/IPS systems to handle. A vulnerability was disclosed last week, related to the encoding issue, affecting many systems that does some sort of content inspection of the HTTP-protocol. From the advisory:

Full-width and half-width encoding is a technique for encoding Unicode characters. Various HTTP content scanning systems fail to properly scan full-width/half-width Unicode encoded HTTP traffic. By sending specially-crafted HTTP traffic to a vulnerable content scanning system, an attacker may be able to bypass that content scanning system

Systems affected by the vulnerability includes most commercial and “free” IDS/IPS systems, including Snort, Bro, TippingPoint and ISS - and disables their detection/protection for attacks mounted in HTTP-sessions.

Interop (as in: “just another vendor conference”) is currently running at the other side of the pond. This is a conference were its common for vendors to release their new silver-bullet products - and IDS/IPS vendors is not an exception. The strange thing with many of the vendors of IDS/IPS-products, is that they seem to focus on relatively irrelevant features - not on these kind of issues that could increase their ability to detect and actually prevent intrusions. They seem to think that the biggest issue with their technology, or the greatest improvement, is to increase the speed at which the devices can inspect and block traffic. ISS is battling Tippingpoint, who can currently operate their IPS at 5 gbit speeds, with a system that can now run at 15 gbit (which in reality means more like 6 gbit). Still, no body with the intention of buying and IDS/IPS for getting increased security should let speed be deciding factor. These people might just as well look at a an firewall with some sort of novel deep inspection.

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.

BleedingSnort invoked a funky sound from the RSS feed-reader today when they announced the availability of a new anomaly-based preprocessor for Snort, called PortscanAI. The preprocessor uses a neaural network-based aproach to find portscans and should, according to the author, be successfull in detecting slow and carefully performed port scans.

Although that is nice news, I like the documentation provided by the project to be even cooler. One document presents, in a very brief and concise way, how a preprocessor is constructed and introduced in the Snort source. The “hello world” implementation does a great way of highlighting the basic steps, which I hope to go through some day. Another document carefully describes the internals of Snort, with the helps of loads of pictures and diagrams. Not eye candy, but sure as hell tells a couple of thousand words :)

I hope to benefit from these documents once I get my Master thesis going.

Many aspects of encryption is interesting, and one of them is the issue of detecting attacks hidden in encrypted sessions. One of the main advantages of running IDSs and IPSs in demilitarized zones is to detect and respond to intrusion attempts on the public available servers. We've all seen the vast number of (mostly automated) intrusion attempts in our apache logfiles. An IDS/IPS is commonly connected by a network tap to a switch in the DMZ, and can thus detetct these attempts too… if the attacking session doesn't connect to the server under HTTPS and performs their attempts. This is an interesting challange - How do we monitor and respond to attacks on our public servers if they are in encrypted sessions?

SSLDump is an interesting application, which utilises LibPCAP to sniff the network in promisc mode, and is able to decode SSL traffic on the fly - AND - most interestingly, decrypt the application layer data if supplied with the X.509 private key of one of the parties - A technique often refered to as "key escrow".

We supply ssldump with the private key of our apache webbserver, listens on interface eth0, and tell ssldump to decrypt the traffic. We connect our webbbrowser to the server under https, and fetch the unexisting webbpage secure.html. This session should not be viewable to our sniffer, as it's under HTTPS. Let's see how SSLDump manages this:

neewt@twosome:~$ sudo ssldump -d -k ./snakeoil-rsa.key -i eth0

After information of handshake messages and their containts, the following application layer data is presented, in decrypted form (The full output of the command is available as a plain text file).

11 10 0.2063 (0.1715) C>S application_data
---------------------------------------------------------------
GET /secure.html HTTP/1.1
Connection: Keep-Alive
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.3 (like Gecko) (Kubuntu package 4:3.4.3-0ubuntu1)
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
Accept-Encoding: x-gzip, x-deflate, gzip, deflate
Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5
Accept-Language: en
Host: 192.168.0.10

113
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /secure.html was not found on this server.<P>
<HR>
<ADDRESS>Apache/1.3.33 Server at 192.168.0.10 Port 443</ADDRESS>
</BODY></HTML>

SSLDump managed to decrypt the session on the fly. The interesting part of this, is that if SSLDump is somewhat modular, much of the code could be used in a pre-processor for Snort, to give it functionallity to decode and alert on malicious traffic inside SSL-sessions. I believe I've heard about plans of such a pre-processor. I know SourceFire co-operates with a vendor selling SSL-accelerators with decryption-capabilities which gives them the same functionallity in their appliances - This is probably why we haven't seen support for it in Snort yet :)

While studying Common Criteria evaluation-procedures, and the relationship between Protection Profiles (PP) and Security Targets (ST), I went to find out if Snort was evaluated. I recall that other opensource projects, such as SuSE 9 and some verison of Redhat, has recieved EAL4.

NIST seems to be housing information on evaluated STs and PPs, and in their intrusion dectection section I found out that SourceFire (perhaps we should call them SourcePoint, or CheckFire? ;) has their IDS sensors and management interface evaluated to EAL2, and with conformance with U.S governments PP U.S. Government Intrusion Detection System System Protection Profile, thius forfilling the requirements of IDSs protecting the whitehouse :) I believe, that this means that Snort is evaluated to EAL2 indirectly, as SourceFires sensors are relying plainly on Snort.

The summary of the evaluation says:

The evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) process and scheme. The criteria against which the Sourcefire TOE was judged are described in the Common Criteria for Information Technology Security Evaluation, Version 2.1 and International Interpretations effective on 19, February 2003. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 1.0. Science Applications International Corporation (SAIC) determined that the evaluation assurance level (EAL) for the product is EAL 2 family of assurance requirements. The product, when configured as specified in the installation guides and user guides, satisfies all of the security functional requirements stated in the Sourcefire Intrusion Detection System Security Target. A validator on behalf of the CCEVS Validation Body monitored the evaluation carried out by SAIC. The evaluation was completed in May 2005. Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report for Sourcefire Intrusion Detection System, prepared by CCEVS.

Other IDS's that are certified level 2 includes ones from Cisco, Checkpoints and other big names. The product with highest EAL is IntruShield Intrusion Detection System and Symantec Manhunt Version 2.11. But this does in not mean that they are better or more secure products that the others, just that more efforts have been put into analysing them in different criterias (which none of them are how well the IDS performs in the sence of detecting attacks etc, i believe).

Interesting.