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:
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:
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:
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.