Penetration Testing mailing list archives
RE: Help understanding a trace of an nmap scan
From: Omar Herrera <oherrera () prodigy net mx>
Date: Wed, 08 Sep 2004 21:33:59 -0500
Ok, let's break it down. Some answers just seem to be overlapped. 14:16:23.098150 host.name.deleted > other.host.name: icmp: echo request 14:16:23.108150 other.host.name > host.name.deleted: icmp: echo reply -- (Ping and corresponding reply; unless you specify -P0 as an nmap option it will send a ping to confirm the host is up before performing the scan) 14:16:23.108150 host.name.deleted.45639 > other.host.name.http: . ack 901588830 win 1024 14:16:23.108150 other.host.name.http > host.name.deleted.45639: R 901588830:901588830(0) win 0 (DF) -- (Ack packet to port 80 and corresponding rst; this is because ack number is not related to any existing connection, so this is the expected behavior) -- Now, here are the RST that I suppose you are referring to ... 14:16:23.428150 host.name.deleted.1073 > other.host.name.daytime: S 2950063922:2950063922(0) win 5840 <mss 1460,sackOK,timestamp 51097216 0,nop,wscale 0> (DF) 14:16:23.438150 other.host.name.daytime > host.name.deleted.1073: S 1866105343:1866105343(0) ack 2950063923 win 5792 <mss 1460,sackOK,timestamp 138541011 51097216,nop,wscale 0> (DF) 14:16:23.438150 host.name.deleted.1073 > other.host.name.daytime: . ack 1 win 5840 <nop,nop,timestamp 51097217 138541011> (DF) -- (3 way handshake, you send a syn packet with seq # 2950063922, host answers with a SYN+ACK packet, with seq #1866105343 and acknowledging your seq #+1) 14:16:23.438150 host.name.deleted.1073 > other.host.name.daytime: R 1:1(0) ack 1 win 5840 <nop,nop,timestamp 51097217 138541011> (DF) -- (After completing 3 way handshake, your systems resets the connection with a RST packet) Interesting ports on other.host.name (xxx.xxx.xxx.235): -- (Watch it, wipe IP addresses as well ;-) ) 14:16:23.448150 other.host.name.daytime > host.name.deleted.1073: P 1:27(26) ack 1 win 5792 <nop,nop,timestamp 138541012 51097217> (DF) -- (Oops, server is sending data... don't worry, this is normal behavior, after you completed the 3 way handshake the daytime service sends you the daytime, it won't usually expect you to send an RST right after you established the connection, so it is just doing it's job...) 14:16:23.448150 host.name.deleted.1073 > other.host.name.daytime: R 2950063923:2950063923(0) win 0 (DF) -- (What?, we asked to tear the connection but received a PSH+ACK packet with data instead, well, maybe that host didn't get the message so we try again. It seems that this connection closing algorithm is generic, son nmap won't distinguish between this behavior and that of other TCP based services where the client usually sends something before the server starts responding) 14:16:23.448150 other.host.name.daytime > host.name.deleted.1073: F 27:27(0) ack 1 win 5792 <nop,nop,timestamp 138541012 51097217> (DF) -- (Ok, each host minds its own business, after sending the daytime this server knows that it is time to close the connection, so it starts to actively close the connection with a FIN packet. If both hosts were still synchronized an ACK packet with ACK number +1 from your host should follow...). 14:16:23.448150 host.name.deleted.1073 > other.host.name.daytime: R 2950063923:2950063923(0) win 0 (DF) -- (...But your nmap host is just too busy telling the other host to shut up) It's not such a mess after all, and If I'm not mistaken the last 2 RST packets from your machine will be sent automatically by the TCP stack (others will correct me if I'm mistaken). It turns out that Linux TCP/IP stack takes its job seriously and it will participate in any connection (since you already sent the first RST it won't see the PSH+ACK and the FIN packets related to any connection in your machine and will send the last 2 RST packets on its own). You can see this behavior as well by setting up a sniffer and spoofing a SYN packet with certain tools (like HPING) and sending it to some open port on some other host. After receiving the SYN+ACK packet you will see in your sniffer that your systems sends automatically a RST packet, because the original SYN packet was not created through the kernel stack (this behavior appears on kernels 2.4 and later). The only way to avoid your stack from answering to your own handmade packets is to set up a filter (through iptables/netfilter for example). I'm not too sure if these 3 way handshake connections are created through the kernel by nmap or using the raw packets, but your trace would suggest they use raw packets, and that nmap would disable this filter even though it still keeps capturing all packets related to the same hosts and ports involved in the scan. I will let those with more knowledge on nmap internals to clarify this behavior (if I'm correct in my perception). Best regards, Omar Herrera
-----Original Message----- From: Richard Moore [mailto:rich () westpoint ltd uk] Sent: Monday, September 06, 2004 9:11 AM To: pen-test () securityfocus com Subject: Help understanding a trace of an nmap scan I wonder if anyone can help me make sense of this packet trace. It shows nmap running a connect scan against port 13 of a host. The part I don't understand is why there are 3 RST packets sent to the target machine? If it helps anyone the target host is a Debian box running 2.4.26 Linux kernel and the source machine was a RedHat box running 2.4.7-10. The version of nmap used is 3.48. Cheers Rich. -- Richard Moore, Principle Software Engineer, Westpoint Ltd, Albion Wharf, 19 Albion Street, Manchester, M1 5LN, England Tel: +44 161 237 1028 Fax: +44 161 237 1031
------------------------------------------------------------------------------ Ethical Hacking at the InfoSec Institute. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. Check out our Advanced Hacking course, learn to write exploits and attack security infrastructure. Attend a course taught by an expert instructor with years of in-the-field pen testing experience in our state of the art hacking lab. Master the skills of an Ethical Hacker to better assess the security of your organization. http://www.infosecinstitute.com/courses/ethical_hacking_training.html -------------------------------------------------------------------------------
Current thread:
- Help understanding a trace of an nmap scan Richard Moore (Sep 07)
- RE: Help understanding a trace of an nmap scan Omar Herrera (Sep 09)
- Re: Help understanding a trace of an nmap scan Jose Maria Lopez (Sep 10)
- <Possible follow-ups>
- Re: Help understanding a trace of an nmap scan Martin Wasson (Sep 08)