Investigating the efficiency of modern Intrusion Detection Systems (IDS) in detecting current evasion techniques – Part 6 – Scenario One Findings – No Evasion


Scenario One – No evasion

The overall purpose of this stage was really to confirm that the IDS was configured correctly and to ensure it can detect the attacks that will be used.

When attackers attack networks they first perform some reconnaissance to map out the target network, at this stage they’d want to know the IP range used by the organisation, DNS servers, email addresses, etc. then a network scan is performed to find out which hosts are live, what services and version of services they’ve running and what operating systems they use, this is so they can choose suitable exploits to launch at the systems. There are many tools available out there to perform such steps; however nmap is the most popular tool that’s being used by the majority of professionals as well as attackers and it is the tool of choice for this study. All the attacker needs to do to achieve this is provide nmap with an IP address or a range of IP addresses and the type of scans to use.

To test the IDS it was configured to monitor network 192.168.0.0/16 and two types of scans were performed using nmap. These were as follows:

  • Nmap SYN scan.
  • Nmap fragmented SYN scan using nmap fragmentation option.

It is also important to note that for the experiments throughout the study the emphasis is not the returned results of the attack, the aim here is weather snort detects the attack or not.

Experiment one – Normal SYN Scan

RULES ONLY

Command:    nmap –sS –n 192.168.59.130     ß target system

A simple SYN scan was sent to the target, the IDS had the pre-processors disabled and is monitoring the network using the rules only mode.


Figure 6.2: Nmap SYN scan



Figure 6.3: Snort console screen

As illustrated by the screenshots of figure 6.3, Snort happily detected the scan by just using the rules only mode.

PRE-PROCESSORS ONLY

Although the pre-processors decode or normalises traffic before passing it to the signature engine, they were activated and the rules deactivated to better understand the system and examine if the IDS would still be able to detect the attack by just using the pre-processors.

Command:    nmap –sS –n 192.168.59.130


Figure 6.4: Snort console screen on standby


Figure 6.5: Snort Statistics

As shown above activating the pre-processors and deactivating the rules resulted in snort not being able to detect the scan, in the statistics it can be seen that there was 2024 sessions while the number of alerts was 0 due to the signatures (rules) being deactivated. This also demonstrates the importance of monitoring all sources of data the IDS offers and not just the alert console.

FULL MODE (PRE-PROCESSORS AND RULES)

This is exactly the same as the previous experiments except this time the configuration was modified to enable the rules and the pre-processors. As shown below the scans were also detected.


Figure 6.6: Snort alert console screen


Figure 6.7: Snort Statistics screen for full mode

RESULTS:

This part of the experiment demonstrates snorts architecture and how each part complements the other, it is clear that because snort had the correct signatures and pre-processors it was able to detect the attack. When only the pre-processors was used snort failed, however when snort was operated in rules only mode it was also able to detect the scans. This was because the attacks were simple attacks and thus can be detected even with the pre-processors being disabled; however if these attacks were complicated and needed to be decoded first then snort would’ve failed, which highlights the importance of correct configuration as many state-of-the art IDSs fail due to misconfiguration.

Experiment Two – Nmap Fragmented SYN scan

RULES ONLY

Command:     nmap –f –mtu 8 –sS 192.168.59.130


Figure 6.8: Nmap fragmented SYN scan – rule only


Figure 6.9: Snort Statistics A and B for nmap’s fragmented SYN scan – rules only


Figure 6.10: Snort Statistics C for nmap’s fragmented SYN scan – rules only


Figure 6.11: Snort Alerts – rules only

The above screenshots clearly shows that although the pre-processors were disabled snort was still able to detect the scan even thus nmap’s fragmentation option was used.

PRE-PROCESSORS ONLY

With the pre-processors only mode the same command was executed, which produced the following results:


Figure 6.12: Snort starting up


Figure 6.13: Snort standing by


Figure 6.14: Snort Statistics for nmap fragmented SYN scan – Pre-processors only

Although there was no alerts displayed as expected; comparing snort statistics with the statistics shown before fragmentation was used (any of experiment 6.1.1 stats) it is clear that there are approximately twice as many packets here than the previous scans.

FULL MODE:


Figure 6.15: Snort’s Full mode alerts for nmap fragmented SYN scan


Figure 6.16: Snort’s Full mode statistics for nmap fragmented SYN scan

Also for this final experiment of scenario one it can be seen that the scan was also detected by snort.

RESULTS:

At this stage it is fully understood how each of snort’s components works with the other, which demonstrates the importance of correct configuration. IDSs might have all the needed tools to detect the most deceiving evasion attacks; however a single misconfiguration could render the device useless.

It was shown that snort did actually detect the simple fragmentation using the rules only mode and produced alerts because it had a signature for it. Also in the second example (pre-processor only mode) no alerts were produced because all the signatures were deleted, however some indications of unusual activity can be seen by looking at the statistics. Hence it is very essential to monitor all sources of data and not only the alerts console, it is recommended to take occasional looks at statistical data sources like snort statistics as it will show if there is any odd activity the alert console didn’t show, also this demonstrates the importance of making sure that all signatures are up-to-date and each of the IDS’s components needs to be frequently maintained.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s