From: Omar Herrera (oherrera@prodigy.net.mx)
Date: Wed Sep 08 2004 - 22:33:59 EDT
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
-------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:04 EDT