TAZforum: Computer and Security Assistance, Tutorials, Games, and a...

http://tazforum.thetazzone.com/viewtopic.php?f=28&t=3441&sid=91...

Home

FAQ

Search

12:34:16 AM - Sun, 25th Dec

TAZ Forum Community

A Friendly and Very Laid-Back Community
Login Register Options

Board index Original Member Tutorials: Why not write one Today Security Tutorials

Page 1 of 1

Tutorial - NMAP Scanning and PortSentry Evasion

Author Message
Post subject: Tutorial - NMAP Scanning and PortSentry Evasion

Topic Options

Striek

Posted: Fri Sep 08, 2006 6:29 am

Intrusion Detection
NMAP scanning and PortSentry Evasion
I hit my head again Joined: Wed Jun 07, 2006 10:36 pm Posts: 417 Location: Toronto, ON, CA

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

1 din 5

25.12.2011 00:34

TAZforum: Computer and Security Assistance, Tutorials, Games, and a...

http://tazforum.thetazzone.com/viewtopic.php?f=28&t=3441&sid=91...

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

2 din 5

25.12.2011 00:34

TAZforum: Computer and Security Assistance, Tutorials, Games, and a...

http://tazforum.thetazzone.com/viewtopic.php?f=28&t=3441&sid=91...

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

3 din 5

25.12.2011 00:34

TAZforum: Computer and Security Assistance, Tutorials, Games, and a...

http://tazforum.thetazzone.com/viewtopic.php?f=28&t=3441&sid=91...

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/

_________________ Government is like fire - a handy servant, but a dangerous master - George Washington Government is not reason, it is not eloquence - it is force. - George Washington.
Last edited by Striek on Wed Sep 27, 2006 5:00 am, edited 2 times in total.

cemetric

Post subject:

Posted: Fri Sep 08, 2006 9:40 am

Nice writeup Striek ...Very detailed ...Just the way I like it .C.

Corporate Spy Joined: Tue Dec 27, 2005 12:33 pm Posts: 3641 Location: Paradise Corrupt

_________________

4 din 5

25.12.2011 00:34

TAZforum: Computer and Security Assistance, Tutorials, Games, and a...

http://tazforum.thetazzone.com/viewtopic.php?f=28&t=3441&sid=91...

J_K9

Post subject:

Posted: Fri Sep 08, 2006 8:12 pm

Great article, Striek. I remember reading about ACK scans, but also that the more advanced scans (XMAS/FIN/NULL) were a little less useful, as they could only be used to extract information from certain OSs (I suppose it depends on the OS' networking implementation). As you said, ACK scans are only useful to test the firewall's rulesets, and to see if it is a SPI or not.
THE Prancing Pirate Joined: Fri Feb 24, 2006 10:47 pm Posts: 8123

Thanks for the refresher!

_________________ "Don't gain the world and lose your soul, wisdom is better than silver or gold." - Bob Marley [CS:Source Admin]

jaymill230

Post subject:

Posted: Tue May 27, 2008 10:20 pm

wow, missed this before, great tutorial

UtterTazNutter Joined: Thu Jan 04, 2007 9:59 pm Posts: 2227 Location: Camp Lejeune, NC

_________________ oo-rah www.jaymill.net

Search for

Go

Page 1 of 1

Who is online
Users browsing this forum: No registered users and 4 guests

Display posts from previous:

All posts

Sort by

Post time

Ascending

Go

Jump to:

Security Tutorials

You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum

X-Static Skin - Designed by Alpha Trion Skin-Lab 2008 Powered by phpBB 2000, 2002, 2005, 2007 phpBB Group

5 din 5

25.12.2011 00:34