Intrusion Detection
NMAP scanning and PortSentry Evasion
This paper will discuss the methods used to circumvent intrusion detection technology employed by Psionic's PortSentry software. It will look at normal modes of operation where PortSentry binds itself to monitored ports at a userland level, and stealth modes, where it operates with raw sockets at a kernel level. The discussion of advanced stealth scan detection and the implications, pros and cons of auto-blocking portscanning attackers, as well as more advanced IDS systems, are beyond the scope of this paper. A basic undertanding of the OSI model and the TCP/IP suite of protocols, including UDP, is assumed, as well as the ability to effectively read tcdump output and syslog generated messages. Scans have been conducted using nmap 3.50 against Portsentry version is 1.2. Scanning machine is a P166 64 MB RAM, 1GB HD running Slackware 9.1 (kernel version 2.6.7) without X windows, at IP address 10.0.0.15. The victim machine is a P2.4Ghz 512 MB RAM 80 GB HD running Slackware 10.0 (kernel version 2.6.8.1) with X windows, at 10.0.0.10. Neither the attacker nor victim have the iptables (or any other firewall, stateful or not) service running. This paper may contain facutal errors to a minor degree. I welcome any corrections and/or criticisms you may deem relevant.
Our first scan will be a normal TCP connect() scan against the default range of ports. We will be scanning a machine which is currently unprotected by PortSentry. The TCP connect() scan simply attempts to connect to a number of predetermined ports. If a connection is made, the port is listening. If no connection is made, that port is closed. The connection is then terminated to avoid SYN flooding the machine we are attempting to scan.
Given the command:nmap -sT 10.0.0.10
We see the following output:
Three ports are open. This is provided only as a refence so we may better understand the operation of PortSentry.Quote:
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-10-07 17:54 EDT
Interesting ports on 10.0.0.10:
(The 1656 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
631/tcp open ipp
6000/tcp open X11
Nmap run completed -- 1 IP address (1 host up) scanned in 2.909 seconds
We will now activate PortSentry in its most basic mode, TCP detection only and no stealth capabilities yet. We will also turn off the auto-blocking feature. After activating PortSentry on the victim machine and running the same scan, we arrive at the following output:
Well isn't that strange? There are actually more open ports with our shiny new PortSentry IDS running than there are without it. This is because portsentry binds itself to every port which it monitors instead of running raw sockets, which do not need to be bound to a specific port. When PortSentry starts, it informs the TCP/IP stack on the host machine that is wants to listen on the list of ports it has been given. Now when a connection request arrives on that port, the stack will complete the request and forward the data for PortSentry. This method, as opposed to using raw sockets, has two major drawbacks:Quote:
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-10-07 17:54 EDT
Interesting ports on 10.0.0.10:
(The 1634 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
1/tcp open tcpmux
11/tcp open systat
15/tcp open netstat
22/tcp open ssh
79/tcp open finger
111/tcp open rpcbind
119/tcp open nntp
143/tcp open imap
540/tcp open uucp
631/tcp open ipp
635/tcp open unknown
1080/tcp open socks
1524/tcp open ingreslock
2000/tcp open callbook
6000/tcp open X11
6667/tcp open irc
12345/tcp open NetBus
12346/tcp open NetBus
27665/tcp open Trinoo_Master
31337/tcp open Elite
32771/tcp open sometimes-rpc5
32772/tcp open sometimes-rpc7
32773/tcp open sometimes-rpc9
32774/tcp open sometimes-rpc11
54320/tcp open bo2k
Nmap run completed -- 1 IP address (1 host up) scanned in 2.960 seconds
PortSentry gives an attacker that there is a plethora of open ports available for exploitation on the victim machine. While this is not true, it will certainly pique interests and make the machine a more tempting target. The attacker may also realize that this machine is being guarded by PortSentry by noticing which ports are open; this is far more than most machines on the Internet today. This will tell the attacker which ports are tripwired. By using more advanced scanning techniques which could circumvent the PortSentry IDS, the attacker could determine exactly which ports to avoid scanning with 'louder' techniques, choosing instead to probe ports which he/she knows PortSentry is not guarding.
If other services are already bound to these ports, PortSentry is unable to monitor them. This can be seen in the following excerpt from my /var/log/messages file:
As you can see, PortSentry is unable to monitor port 22 because the ssh service is already listening on that port. A machine with a large number of available services could render PortSentry useless. Also, If we cannot detect port scans against open ports, we are missing the whole point of having an IDS in the first place. PortSentry is therefore much more valuable on a machine with no services running such as a border router or a firewall, and not on a webserver or mailserver.Quote:
Oct 8 00:14:22 picard portsentry[4094]: adminalert: Going into listen mode on TCP port: 15
Oct 8 00:14:22 picard portsentry[4094]: adminalert: Going into listen mode on TCP port: 22
Oct 8 00:14:22 picard portsentry[4094]: adminalert: ERROR: could not bind TCP socket: 22. Attempting to continue
Oct 8 00:14:22 picard portsentry[4094]: adminalert: Going into listen mode on TCP port: 79
However, all is not lost. On a machine running PortSentry, I am unaware of any known scanning method which could be used to differentiate between the zombie ports opened by PortSentry and real ports opened by a legitamite service -- at least not without triggering an alert. This will at least slow down most attacks, since PortSentry can be set with a hair trigger which will log an alert when someone attempts to connect to any port on its watch list, even once. This is another excerpt from my /var/log/messages file showing the log entries during the time of the scan:
As you can see, PortSentry reacts rather quickly to this portscan. Only two ports have been probed before PortSentry logs it as an attack. As we discussed previously, when PortSentry establishes a connection with a remote host, it immediately tears it down. Most legitamite services will wait for some kind of input from you before doing so. In this manner, an attacker could telnet to ports reported open by his/her scanner and see if they have services running behind them. In this case, PortSentry recognizes even one attempt to connect to a tripwired port as an attack and reacts accordingly. By the second attempt, PortSentry logs a notice saying action has already been taken and it is now ignoring this activity. This kind of aggressive reporting may generate a lot of false positives, but it will also keep a lot of attackers away from you.Quote:
Oct 8 00:47:28 picard portsentry[4240]: adminalert: Going into listen mode on TCP port: 40421
Oct 8 00:47:28 picard portsentry[4240]: adminalert: Going into listen mode on TCP port: 49724
Oct 8 00:47:28 picard portsentry[4240]: adminalert: Going into listen mode on TCP port: 54320
Oct 8 00:47:28 picard portsentry[4240]: adminalert: PortSentry is now active and listening.
Oct 8 00:47:29 picard sshd[4241]: Did not receive identification string from 10.0.0.15
Oct 8 00:47:30 picard portsentry[4240]: attackalert: Connect from host: 10.0.0.15/10.0.0.15 to TCP port: 49724
Oct 8 00:47:30 picard portsentry[4240]: attackalert: Connect from host: 10.0.0.15/10.0.0.15 to TCP port: 79
Oct 8 00:47:30 picard portsentry[4240]: attackalert: Host: 10.0.0.15 is already blocked. Ignoring
Oct 8 00:47:30 picard portsentry[4240]: attackalert: Connect from host: 10.0.0.15/10.0.0.15 to TCP port: 143
We will now attempt a SYN stealth scan against the victim computer. A SYN stealth scan sends an initial SYN packet to the victim machine, but does not respond to the SYN,ACK packet, instead sending a REST packet, terminating the connection attempt. This can be seen in the following tcpdump output on the victim machine:
We can see the SYN packet from the attacker, and send the usual SYN,ACK packet back. However, the attacker then sends a REST packet, and never completes the connection. Since PortSentry is currently monitoring for connections on its watch list, it ignores these attempts since no connection is actually made. The attacker, however, receives a SYN,ACK packet, showing him/her that there is a service responding on this port. While the presence of PortSentry, as previously deterrmined, will give the appearance of services where none exist, PortSentry will not detect this scan. Based on the specific set of responses received, a set that is unique to the default installation of PortSentry, this will alert the attacker to the presence of our IDS on this machine without revealing him/herself. The command nmap -sS 10.0.0.10, issued from the attacking machine, will generate the same results as nmap -sT 10.0.0.10, but will remain undetected.Quote:
01:12:49.885153 IP 10.0.0.15.55064 > picard.sympatico.ca.ssh: S 3369530623:3369530623(0) win 2048
01:12:49.885179 IP picard.sympatico.ca.ssh > 10.0.0.15.55064: S 3492815075:3492815075(0) ack 3369530624 win 5840 <mss 1460>
01:12:49.885405 IP 10.0.0.15.55064 > picard.sympatico.ca.ssh: R 3369530624:3369530624(0) win 0
An attacker could also choose to use UDP scans agains a victim machine. With PortSentry currently monitoring only for TCP activity, this type of scan will pass through undetected. Several vulnerable services operate on UDP, such as snmp, tftp, NFS, and others. Because UDP communication is connectionless, no reply can be solicited from the victim. Another technique must be employed. Null UDP packets (0 byte packets) are sent to the victim machine. A host receiving a UDP packet destined for a closed port should issue an ICMP port unreachable message, as seen in the following tcpdump output:
If no response is received, the port is assumed to be open. Unfortunately, without stealth mode activated, PortSentry binds to the ports it is monitoring and they appear open when scanned. The pros and cons of UDP scans against PortSentry protected hosts are remarkably similar, therfore, to those of TCP connect() scans. Quite often, ICMP port unreachable messages are blocked from leaving a local network. UDP scans can also become excruciatingly slow, due to a suggestion in RFC 1812 (4.3.2.8) which limits the rate of ICMP error message generation, upon which these scans rely. For this reason, and the lack of documentation in RFC 768, UDP scans can be quite slow and inaccurate, and are not generally used by attackers. However, once a host has been compromised, it can be used to launch effective UDP scans from within a local network, since no error messages ever leave and latency is quite low. PortSentry will therefore be more effective when UDP scan detection is used as a means to detect compromised hosts or with internal attacks. At the network perimiter, although PortSentry does a fine job of detecting UDP scans (when told to with the command portsentry -udp), implement a firewall rule preventing ICMP port unreachable messages from leaving, thereby rendering external UDP scans useless.Quote:
02:47:31.374353 IP 10.0.0.15.47613 > picard.sympatico.ca.ariel3: UDP, length: 0
02:47:31.374414 IP picard.sympatico.ca > 10.0.0.15: icmp 36: picard.sympatico.ca udp port ariel3 unreachable
02:47:32.176119 IP 10.0.0.15.47613 > picard.sympatico.ca.671: UDP, length: 0
02:47:32.176180 IP picard.sympatico.ca > 10.0.0.15: icmp 36: picard.sympatico.ca udp port 671 unreachable
We will now place PortSentry in stealth mode. In this mode, PortSentry operates using raw sockets. This does not require the binding of PortSentry to individual ports to see traffic coming in on them. It does, however, require root (or administrator) privileges, because we are now operating at a kernel level, examining packets before TCP does. The following is the output of the command nmap -sT 10.0.0.10 agains a PortSentry protected machine running in stealth mode:
Because PortSentry does not complete the connection when the request is made, only ports with actual services running behind them are shown as open (that's because they are open). PortSentry is also able to detect SYN stealth scans in stealth mode, since it is now monitoring for connections requests at a kernel level and not connection establishments at a userland level. A SYN scan will reveal the same information as a connect() scan, and although it is harder to detect, PortSentry does its job here quite admirably, as shown in the following /var/log/messages excerpt:Quote:
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-10-07 18:14 EDT
Interesting ports on 10.0.0.10:
(The 1656 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
631/tcp open ipp
6000/tcp open X11
Nmap run completed -- 1 IP address (1 host up) scanned in 4.381 seconds
PortSentry detects the SYN scan, and differentiates it from a normal connect() scan. This type of scan is more indicative of malicious intent, as a normal service request nearly always completes a connection. This scan does not.Quote:
Oct 8 03:30:10 picard portsentry[4569]: adminalert: Going into stealth listen mode on TCP port: 32774
Oct 8 03:30:10 picard portsentry[4569]: adminalert: Going into stealth listen mode on TCP port: 40421
Oct 8 03:30:10 picard portsentry[4569]: adminalert: Going into stealth listen mode on TCP port: 49724
Oct 8 03:30:10 picard portsentry[4569]: adminalert: Going into stealth listen mode on TCP port: 54320
Oct 8 03:30:10 picard portsentry[4569]: adminalert: PortSentry is now active and listening.
Oct 8 03:30:24 picard portsentry[4569]: attackalert: TCP SYN/Normal scan from host: 10.0.0.15/10.0.0.15 to TCP port: 32772
Oct 8 03:30:29 picard portsentry[4569]: attackalert: TCP SYN/Normal scan from host: 10.0.0.15/10.0.0.15 to TCP port: 32774
Oct 8 03:30:29 picard portsentry[4569]: attackalert: Host: 10.0.0.15/10.0.0.15 is already blocked Ignoring
Oct 8 03:31:46 picard portsentry[4569]: attackalert: TCP SYN/Normal scan from host: 10.0.0.15/10.0.0.15 to TCP port: 143
Oct 8 03:31:46 picard portsentry[4569]: attackalert: TCP SYN/Normal scan from host: 10.0.0.15/10.0.0.15 to TCP port: 27665
Oct 8 03:31:46 picard portsentry[4569]: attackalert: Host: 10.0.0.15/10.0.0.15 is already blocked Ignoring
When placed into UDP stealth mode, PortSentry does much the same thing as above, although it does not add any detection capabilities. In this mode, it is much more difficult for the attacker to realize that PortSentry is running on the victim machine. See the output below:
Although PortSentry is listening on a set number of ports, no indication of this is given in the scan output. It does, however, detect and log the scan:Quote:
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-10-07 23:44 EDT
All 15 scanned ports on 10.0.0.10 are: closed
Nmap run completed -- 1 IP address (1 host up) scanned in 9.989 seconds
Here PortSentry picks up the UDP scan on the first packet and reacts accordingly. We have successfully detected the attack from the attacker's machine and given no indication that PortSentry even exists here.Quote:
Oct 8 03:44:41 picard portsentry[4662]: adminalert: Going into stealth listen mode on UDP port: 32774
Oct 8 03:44:41 picard portsentry[4662]: adminalert: Going into stealth listen mode on UDP port: 31337
Oct 8 03:44:41 picard portsentry[4662]: adminalert: Going into stealth listen mode on UDP port: 54321
Oct 8 03:44:41 picard portsentry[4662]: adminalert: PortSentry is now active and listening.
Oct 8 03:44:43 picard portsentry[4662]: attackalert: UDP scan from host: 10.0.0.15/10.0.0.15 to UDP port: 161
Oct 8 03:44:44 picard portsentry[4662]: attackalert: UDP scan from host: 10.0.0.15/10.0.0.15 to UDP port: 31335
Oct 8 03:44:44 picard portsentry[4662]: attackalert: Host: 10.0.0.15/10.0.0.15 is already blocked Ignoring
We will now initiate some more advanced scans. We will start with the ACK scan. In this scan, an arbitrary packet is sent to the victim with the ACK flag set. In all cases, the victim host should respond with a RST packet, unless of course the ACK packet never reaches the host due to a firewall. If we solicit a response with an ACK packet that we cannot achieve with a SYN packet, we know that there is a firewall between us and the host which is dropping SYN packets. If we know the target host exists and neither packet gets through, we are dealing with a stateful firewall. If only the ACK packet gets through, we are dealing with a simpler packet-filtering device. This is the output from a TCP ACK scan against the victim machine:
And the responsible TCP traffic looks like this:Quote:
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-10-08 00:01 EDT
All 1659 scanned ports on 10.0.0.10 are: UNfiltered
Nmap run completed -- 1 IP address (1 host up) scanned in 8.914 seconds
This is not surprising, as I do not have a firewall running on this victim machine. We can see here the RST packets being sent in reply to the unexpected ACK packets the victim is receiving. If the victim here had never received these ACK packets, he/she would not be able to send an RST in reply. This would indicate a firewall dropping the packets somewhere along the way.Quote:
04:01:31.871139 IP picard.sympatico.ca.sfs-config > 10.0.0.15.62029: R 2844304146:2844304146(0) win 0
04:01:31.871494 IP 10.0.0.15.62029 > picard.sympatico.ca.nced: . ack 2844304146 win 4096
04:01:31.871543 IP picard.sympatico.ca.nced > 10.0.0.15.62029: R 2844304146:2844304146(0) win 0
04:01:31.871899 IP 10.0.0.15.62029 > picard.sympatico.ca.9992: . ack 2844304146 win 4096
04:01:31.871937 IP picard.sympatico.ca.9992 > 10.0.0.15.62029: R 2844304146:2844304146(0) win 0
04:01:31.872270 IP 10.0.0.15.62029 > picard.sympatico.ca.pdap: . ack 2844304146 win 3072
04:01:31.872309 IP picard.sympatico.ca.pdap > 10.0.0.15.62029: R 2844304146:2844304146(0) win 0
04:01:31.872636 IP 10.0.0.15.62029 > picard.sympatico.ca.724: . ack 2844304146 win 2048
04:01:31.872684 IP picard.sympatico.ca.724 > 10.0.0.15.62029: R 2844304146:2844304146(0) win 0
Note, however, that PortSentry did not pick up this scan. This scan could be used to determine firewall rulesets against a PortSentry protected firewall bastion host, if one only knows the address of the firewall or any machine behind it. While not revealing any open ports on any hosts, we can determine which packets to send through later to make our scans more effective.
XMAS, NULL, and FIN scans work by sending illegal flag combinations. According to RFC 793 (page 64),
Open ports are required to ignore these packets, while closed ports must respond with an RST packet. With a FIN scan, only the FIN bit is set. With the XMAS scan, the FIN, URG, and PUSH flags are all activated. In a normal communication exchange, no packet will ever have these three flags on simultaneously. Therefore, the host should respond with an RST packet, signalling its intention to immediately terminate this connection, which it believes to be fubared. A NULL scan turns off all flags; either the SYN or the ACK flag is always set during normal communications. The victim then responds with an RST flag.Quote:
"If the state is CLOSED (i.e., TCB does not exist) then
all data in the incoming segment is discarded. An incoming
segment containing a RST is discarded. An incoming segment not
containing a RST causes a RST to be sent in response. The
acknowledgment and sequence field values are selected to make the
reset sequence acceptable to the TCP that sent the offending
segment."
<snip>
" If the state is LISTEN then
first check for an RST
An incoming RST should be ignored. Return."
The previous three scans (ACK, XMAS, and NULL) were not detected by PortSentry. This is because PortSentry is monitoring for half-finished connection attempts, in which an SYN,ACK was sent in reply to a SYN packet but an RST was received in place of an ACK packet. Since these three scans never send a SYN packet through, no connection is ever half-open and therefore we pass by PortSentry like reality passes by George Bush.
As a final note, if PortSentry is left in non-stealth mode, we will present an attacker with a multitde of supposedly open ports. We still have not found a way to differentiate between PortSentry zombie ports and ports with actual services running behind them without triggering an alarm.
References:
nmap 3.5 manpages Insecure.Com LLC
RFC 768 - User Datagram Protocol J. Postel
RFC 793 - Transmission Control Protocol prepared for the Defense Advanced Research Projects Agency
by the Information Sciences Institute, University of Southern California
RFC 791 - Internet Protocol prepared for the Defense Advanced Research Projects Agency
by the Information Sciences Institute, University of Southern California
This paper is licensed under the GNU Free Documentation License, available at http://www.gnu.org/copyleft/fdl.html
