Can we fully trust an IDS or IPS?

"Not everything that is counted counts, and not everything that counts can be counted."

       --- Albert Einstein

Nowadays, more and more network administrator introduce IDS or likewise system to their network to protect their network from being attacked, but the truth is, the IDS is not that reliable as we expected.

Most IDS systems are pattern based, requiring a large set (typically ~1500+) signatures to alert based on a specific combination of TCP flags in the header, or a set pattern in the payload. The accuracy of this approach depends, of course, on the skill of the administrator writing the signature, but in most cases this provides for very accurate detection of a specific attack, and will not catch new or modified attacks.

Because most NIDS systems operate in layer 2 (OSI), they simply feed raw traffic into a detection engine and rely on the pattern matching and/or statistical analysis to determine what is malicious. Packets are not processed by the host’s TCP/IP stack and upper layer applications – so the IDS analyzed traffic, the host would otherwise discard. This approach also has the disadvantage that packets can be intentionally crafted in such a way as to confuse pattern-matching IDS systems, while still being correctly assembled by the host TCP/IP stack to render the attack payload.

So IDS would possibly have a different views with the real end system which could be exploited by hack to fool the IDS system. There are two most prevalent techniques, Insertion and Evasion. Just like what those words literal meaning, the IDS could either see more words or less words than a real end system. They very well discussed, you could find more information here[1].

And we could find a real world example here[2]. You could easily figure out that, even for the most sophisticated IDS, it could do not detect all attacks. Because it could only read in a packet level, it could not replay the whole "stream", so it make any type of implementations inevitable to this flaw.

The discussions here are not aimed to shame any IDS implementations, the systems are still very good and they are also evolving too. We just want to emphasis that, IDS is not as its literally meaning, Intrusion Detection, it could do only part of it. In China, we have a saying like that, no one could do everything himself/herself, so we should think about other solutions for "stream" based and application based attack, fortunately, now, we have some solutions for that, OSSEC, a host based or a logs based analysis engine could help security admin to detect some attacks based on system or application logs. So all the application based attack could be well processed by OSSEC. But it is not the ending for our story, both OSSEC and other logs based analysis engine are pattern based too, which means that it could only reported problem which match a certain pattern, and if the pattern is not very well customized, it will generate a lot of false active reports.

So, manpower is still needed for now, we should always keep our eye on our systems, to keep the hackers away!

disadvantage of "-sI" option for nmap

Recently, I have been so obsessed by nmap, there is a very interesting option, "-sL", which will take advantage of a zombie machine to accomplish a stealth scanning. But the truth is not like what it's said.

From the official guide, we were told that it won't be problematic to find a zombie machine, but what is the truth? I am done several tests myself, but I found that, it is really hard to do that.

1. It is really hard to find a totally isolated host which there are merely IP level packets are received. Nowadays, all servers are equipped with loadbalancer, proxy, reverse-proxy, etc. Those applications will generate some TCP/ICMP/IGMP level packets to determine an host is alive. So even there is no effective requests at all from the clients, we could not grantee that there are no other IP packets bothered us.

2. The zombie host must open its 80 or 443 ports. continue with the prior problem, a lot of web applications are use some arbitrary ports instead of well known ports 80 and 443, they choose customized ports like 1443 or 8080, but nmap could not use those ports to perform ID incremental scanning.

3. No one really use or log-on to that host from SSH or made some development. As we all know, the most vulnerable hosts are dev hosts, those hosts are always welcome for everyone, in this case, they do not fit. there will be a lot of traffic for SVN, SSH and some other testing requests from developers.

Conclude with those 3 points, it's made zombie host based scanning an unpractical for a real world scanning.

I have set-up a lab myself, which should be very quite environment than a real world, but the results were always different. here is my lab environment:

zombie: 192.168.1.100, a http server
target: 192.168.1.101, ports 22, ports 80, ports 8080 are opened

I scanned for three times, but I got three different results:

First:

PORT     STATE           SERVICE
22/tcp   closed|filtered ssh
80/tcp   closed|filtered http
8080/tcp open            http-proxy

Second:

PORT     STATE           SERVICE
22/tcp   open            ssh
80/tcp   open            http
8080/tcp open            http-proxy

Third:

PORT     STATE           SERVICE
22/tcp   open            ssh
80/tcp   open            http
8080/tcp closed|filtered http-proxy

But do not be scared, you still be able to find a zombie host, but keep in mind, the zombie host must very do not proceed any IP or higher level request, otherwise the ID incremental will make no sense any more.

"The quieter you become, the more you are able to hear"