Avoiding IDS Rules – Port Scanning

For research purposes, I have setup a Security Onion Virtual Machine (VM) that will monitor the network while I conduct various attacks against the Metasploitable2 VM using the Kali Linux distro. My goal is to see which alerts trigger and then analyze the alert rules for potential workarounds. My lab setup is relatively simple. I am running Kali 2.0, Security Onion, and metasploitable2 in bridged mode on VMware Workstation. The IDS rule sets for the Security Onion and the Kali configurations are default.

The first test will be an Nmap scan against matasploitable2 (192.168.0.20), which by default uses a SYN scan on the most common 1000 ports (detailed in the nmap-services file). The ‘-n’ flag specifies that I do not want Nmap to attempt to resolve the domain name associated with the IP address:

root@kali:~# nmap -n 192.168.0.20

Starting Nmap 7.01 ( https://nmap.org ) at 2016-06-03 11:31 EDT
Nmap scan report for 192.168.0.20
Host is up (0.0036s latency).
Not shown: 977 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
23/tcp   open  telnet
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
512/tcp  open  exec
513/tcp  open  login
514/tcp  open  shell
1099/tcp open  rmiregistry
1524/tcp open  ingreslock
2049/tcp open  nfs
2121/tcp open  ccproxy-ftp
3306/tcp open  mysql
5432/tcp open  postgresql
5900/tcp open  vnc
6000/tcp open  X11
6667/tcp open  irc
8009/tcp open  ajp13
8180/tcp open  unknown
MAC Address: 00:0C:29:FA:DD:2A (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.71 seconds

 

This scan triggered six alerts on SGUIL, which is a GUI version of Snort IDS that is built into Security Onion:

sguil_alerts

 

A glance at the event messages show that the alerts were generated because of suspicious inbound packets to well-known database ports and VNC ports. You can tell SGUIL to show the rule to determine exactly why this alert occurred:

sguil_rule

 

So in this case, any traffic that contains a SYN flag going to the server on port 1433 will cause an alert. So, to get around this rule we would need to scan the port without sending a packet with the SYN flag set, however we still want to ascertain the status of the port. We can do this using a null scan, which will report the port is shut if a RST is returned or open|filtered if nothing is returned (More details at https://nmap.org/book/man-port-scanning-techniques.html).  Here is an example of this against a shut port. The ‘-sN’ indicates a null scan and ‘–reason’ will print the response that Nmap uses to determine the state of the port:

root@kali:~# nmap -n -sN -p 1433 192.168.0.20 --reason

Starting Nmap 7.01 ( https://nmap.org ) at 2016-06-03 12:28 EDT
Nmap scan report for 192.168.0.20
Host is up, received arp-response (0.00064s latency).
PORT     STATE  SERVICE  REASON
1433/tcp closed ms-sql-s reset ttl 64
MAC Address: 00:0C:29:FA:DD:2A (VMware)

 

And against an open port:

root@kali:~# nmap -n -sN -p 3306 192.168.0.20 --reason

Starting Nmap 7.01 ( https://nmap.org ) at 2016-06-03 13:07 EDT
Nmap scan report for 192.168.0.29
Host is up, received arp-response (0.00065s latency).
PORT     STATE         SERVICE REASON
3306/tcp open|filtered mysql   no-response
MAC Address: 00:0C:29:FA:DD:2A (VMware)

 

With this knowledge you can bypass a default IDS ruleset by conducting your port scan using the ‘–exclude-ports’ switch to exclude the ports that will alert, and then scan those ports using a null scan:

I’ll clear the SGUIL alerts and start my scanning:

root@kali:~# nmap -n --exclude-ports 1433,1521,3306,5432,5900-5920,5800-5820 192.168.0.20

Starting Nmap 7.01 ( https://nmap.org ) at 2016-06-03 12:43 EDT
Nmap scan report for 192.168.0.20
Host is up (0.0017s latency).
Not shown: 980 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
23/tcp   open  telnet
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
512/tcp  open  exec
513/tcp  open  login
514/tcp  open  shell
1099/tcp open  rmiregistry
1524/tcp open  ingreslock
2049/tcp open  nfs
2121/tcp open  ccproxy-ftp
6000/tcp open  X11
6667/tcp open  irc
8009/tcp open  ajp13
8180/tcp open  unknown
MAC Address: 00:0C:29:FA:DD:2A (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.98 seconds

 

Now, I’ll scan the ports I excluded from the SYN scan using a null scan:

root@kali:~# nmap -n -sN -p 1433,1521,3306,5432,5900-5920,5800-5820 192.168.0.29

Starting Nmap 7.01 ( https://nmap.org ) at 2016-06-03 12:45 EDT
Nmap scan report for 192.168.0.29
Host is up (0.00043s latency).
Not shown: 43 closed ports
PORT     STATE         SERVICE
3306/tcp open|filtered mysql
5432/tcp open|filtered postgresql
5900/tcp open|filtered vnc
MAC Address: 00:0C:29:FA:DD:2A (VMware)

Nmap done: 1 IP address (1 host up) scanned in 1.54 seconds

 

And my SGUIL alerts:

sguil_blank

Nothing. Success!

While this method isn’t perfect, it is one way of getting around alerts. It should be noted that it is very easy to create alerts for a null scan, (or any alert specific to the TCP flags). However, the more rules that are created, the more false positives are generated, so many times an organization is fine with the default rule sets, and usually trim them down even further by commenting out rules.

 

Leave a Reply

Your email address will not be published. Required fields are marked *