Watching the watchers
A lot of companies today have various IDS and IPS devices implemented in their internal network (especially if you must be compliant with PCI DSS, for example). So these devices get implemented to monitor various traffic at various interfaces/perimeters in a company, but the question I got asked is how can we be sure that the IDS/IPS is doing its job?
Obviously, some simple monitoring should be in place – this typically consists of pinging the device or collecting various counters such as memory, CPU usage and similar. This is normally enough to make sure that the device is up and operational. But the question is – how do we make sure that the IDS/IPS is actually detecting malicious traffic or network attacks?
An obvious answer to this question is to try to send something malicious and to see if the IDS/IPS correctly identified the attack. So the following options (or all of them) can be implemented:
- We can automatically download eicar.com and see if the IDS/IPS detected the malicious file.
- We can perform an automatic scan with nmap or execute any NSE nmap script. Typically, a normal scan (a SYN scan) should trigger the IDS/IPS. This is also a good test to see if the IDS/IPS is detecting network behavior.
- We can send an exploit over the network. While thinking what to send I browsed through pytbull, which is an IDS/IPS testing framework (more at http://pytbull.sourceforge.net/). Pytbull comes with a bunch of attacks that can be used to test your IDS/IPS installations. At the end I decided that it was too complex, so it was much easier just to take some shellcode, prepend NOP sled to it (yea, so it looks real) and use scapy to send it.
The above "attacks" can now be scheduled – for every schedule, the IDS/IPS device should detect (and/or block) such attacks. To confirm that everything is working ok, it should also generate an appropriate log file which can be then automatically verified with a SIEM; if an attack was executed and there was no detection we know something went wrong with either the IDS/IPS device or the network between the probe and the device – no matter what our standard monitoring is saying.
So, what mechanisms do you use to verify your IDS/IPS is working OK? Let us know!
--
Bojan
@bojanz
My next class:
Web App Penetration Testing and Ethical Hacking | Amsterdam | Mar 31st - Apr 5th 2025 |
×
Diary Archives
Comments
Anonymous
Apr 3rd 2014
1 decade ago
Anonymous
Apr 3rd 2014
1 decade ago
Anonymous
Apr 3rd 2014
1 decade ago
Anonymous
Apr 3rd 2014
1 decade ago
Recently, I've found a tool, WAF Walker http://www.waftesting.com/
Do you know any other tool to test web application firewalls?
Anonymous
Apr 3rd 2014
1 decade ago
Anonymous
Apr 3rd 2014
1 decade ago
Anonymous
Apr 3rd 2014
1 decade ago
This has happened with two big-name IPS vendors so far. After trying to work with one of them for years to solve the issue with no traction, we finally removed their appliances. The second vendor we're still working with. They claim they'll fix it, but have taken the stance that the IPS is only supposed to alert to possible issues, and it's the customer's job to investigate. While that may be true to an extent, systems like that are called "Detection" and not "Prevention".
Anonymous
Apr 3rd 2014
1 decade ago
Good point. I believe what might be happening is that the IPS is blocking some of the malicious SQL injection packets but not all. I know this happens with our IPS as well because while we see blocked events from a certain IP in the IPS logs, we might still find that IP in the server logs - indicating as you stated that some of the traffic made it through.
What we have done as a countermeasure is to automatically quarantine an IP if it triggers certain filters, such as SQL injection. This way, once there is any hint of malicious traffic from an IP, it gets quarantined and therefore all future traffic from the suspect IP is blocked. However, this has to be configured carefully because you don't want to quarantine valid IPs.
Anonymous
Apr 3rd 2014
1 decade ago
Apu, nice idea about measuring time it took to detect the alert. I also like the fact that you test this during peak hours as well.
Anonymous
Apr 3rd 2014
1 decade ago