This is sist3m's personal profession blog. Covering security news, howto's, discussions, incidents vulnerability & discovery, including exploitation development..... and anything else I see fit to throw in there !

Saturday, 6 January 2007

Why Intrusion Detection Systems Fail As Well


The second most common misconception is the role that Network Intrusion Detection Systems (NIDS) play in web security scenarios. NIDS are a reactive strategy rather than a protective strategy. This does not mean that they do not serve an important service. They are fairly effective in identifying known web based attacks, but actually acting upon the malicious requests is another matter. This is due in part to their deployment location ont he network.

Most often, NIDS are deployed in a passive, third-party way such that they do not interfere with the network traffic. An example network diagram for a common NIDS deployment is shown below.

They are simply able to view the data by utilizing data from a SPAN port or TAP. They are often reconfigured to remove their IP stack, as to minimize the chance of responding to network activity. While this strategy does help to conceal the presence of a NIDS sensor on the network, the flip side is that this makes it more difficult to execute any sort of flexible response on identified attacks. By flexible response, Im refering to the capability to attempt to reset TCP connections by sending spoofed TCP Reset packets to both ends of the connection.

There has been numerous documented tests for Snort's flexible response capabilities. The effectiveness of this setup is mixed if you consider the different result catagories of most web attacks:

  • Denial of Service. In DoS attacks against web servers, the malicious packets just need to make it to the web server. The attackers do not usually need to have any data returned for the attack to be successful.
  • Command Execution/Injection. Similar to DoS attacks, these malicious requests normally only need to make it to the web server in order for the attack to be successful. If Snort prevents the outbound data from being returned to the attacker, this does make it more difficult for the attacker to accurately conduct a large command execution attack, as they do not have any verification of success/failure of their commands. This becomes a "blind" execution attack.
  • Obtaining Information. The goal of the attack is to obtain information from the web server, such as the contents of the /etc/passwd file. In this attack, if the attacker does not receive the results of the command, then the severity of the attack has been lessened as you have prevented information disclosure.

From the results of such documented test, due to the speed and overhead of creating the TCP reset packets, Snort was just not quick enough to tear down the malicious requests connections prior to reaching the web server. This means that it was not successful at mitigating the DoS and Command Execution attack categories. On the flip side, it was rather successful at preventing the information discolsure attacks by terminating the connection prior to the data reaching the attacker.

Don't get the wrong impression with test result you may find on the net about NIDS preventing web attacks. NIDS serve a critical purpose in web security; however, prevention of attacks will not be achieved unless the architectural deployment strategy of NIDS is changed. This is where the concept of an "inline" IDS emerged.


Next, we'll look at Deep packet Inspection Firewalls, Inline IDS, and Web Application Firewalls