NMAP
SCANNING AND PORTSENTRY EVASION CONT...
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:
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
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:
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
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.
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:
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
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:
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
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.
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:
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
And the responsible TCP traffic looks like this:
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
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.
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),
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."
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.
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 Creative Commons
Attribution-NonCommercial-ShareAlike 2.5 License, available at
http://creativecommons.org/licenses/by-nc-sa/2.5/ca/
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.