NMAP
SCANNING AND PORTSENTRY EVASION
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:
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
Three ports are open. This is provided only as a refence so we may
better understand the operation of PortSentry.
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:
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
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:
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:
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
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.
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:
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
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.
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:
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
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.
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:
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
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.Cool 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.
We will now place PortSentry in stealth mode. In this mode, PortSentry
operates using raw sockets.
Original Tutorial
Submitted by Striek for TheTAZZone-TAZForum
Originally posted on September 8th, 2006 here
Do not use, republish, in whole or in part, without the consent of
the Author. TheTAZZone policy is that Authors retain the rights to the
work they submit and/or post...we do not sell, publish, transmit, or
have the right to give permission for such...TheTAZZone merely retains
the right to use, retain, and publish submitted work within it's
Network.