Re: Help understanding a trace of an nmap scan

From: Martin Wasson (martin_wasson@mastercard.com)
Date: Wed Sep 08 2004 - 15:12:35 EDT


Well, it looks to me like it's going down like this:

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

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

You're doing a connect scan, so NMAP performs a full connect with the Syn
-- Syn Ack -- Ack three way handshake, right. So NMAP now knows
everything it needs to know about the daytime port...it's up, it's
answering. So it sends a "reset" packet, because it's threw with that
port. NMAP was sent to get data, and it's not playing nicely. So it
performs an "abortive release" with the RST packet, instead of performing
an "orderly release" with a FIN. Plus, you want NMAP to be fast, right?
NMAP was programmed with the knowledge that an abortive release only takes
ONE packet; a single RST. Resets are designed to elicit no response,
whatsoever. It's when you just get the "Dear John" letter instead of your
girlfriend saying "we need to talk". Heh heh. So if NMAP has a choice to
either send a FIN, go into a FIN_WAIT state and wait for an ACK and then a
FIN, and then send a final ACK, OR just dump the whole session with a
single RST, the choice is quite clear. It sends the "Dear John" RESET.
Note that NMAP is providing the target with everything it needs to know; it
has a sequence number and provides an ACK. Also note that in the second
packet (the SYN - ACK from the target to the host), the target is expecting
byte 2950063923 to be delivered next, but the sequence number it got in the
RST was 1.

>>Interesting ports on other.host.name (194.153.168.235)

%host 194.153.168.235
235.168.153.194.in-addr.arpa domain name pointer five.fluff.org.
%sed -e "s/other.host.name./five.fluff.org./g" < nmap.out

>>14:16:23.448150 five.fluff.org.daytime > host.name.deleted.1073: P
1:27(26) ack 1 win 5792 <nop,nop,timestamp >>138541012 51097217> (DF)

But alas, the target TCP doesn't want to accept the fact that it's all
over. It still has 26 bytes of data in its send buffer that it wants to
clear. So it sends the data and turns on the PUSH flag.

>>14:16:23.448150 host.name.deleted.1073 > five.fluff.org.daytime: R
2950063923:2950063923(0) win 0 (DF)

Again, not interested in long goodbyes, NMAP attempts to abort the session
with a RESET packet, but this time it uses the sequence number the target
is expecting, not a sequence number of 1.

>>14:16:23.448150 five.fluff.org.daytime > host.name.deleted.1073: F
27:27(0) ack 1 win 5792 <nop,nop,timestamp >>138541012 51097217> (DF)

Where this FIN ACK comes from, I honestly don't know. The target has
received no FIN to FIN ACK, but it DID get the sequence number it was
expecting, so that may be why.

>>14:16:23.448150 host.name.deleted.1073 > five.fluff.org.daytime: R
2950063923:2950063923(0) win 0 (DF)

Again, the attack box repeats the RST because resets are designed NOT to
elicit a response.

That's my take. Hope it helps.

Marty Wasson, CISSP

                                                                                                                                       
                      Richard Moore
                      <rich@westpoint.l To: pen-test@securityfocus.com
                      td.uk> cc: (bcc: Martin Wasson/STL/MASTERCARD)
                                               Subject: Help understanding a trace of an nmap scan
                      09/06/2004 09:11
                      AM
                                                                                                                                       
                                                                                                                                       

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
14:16:23.098150 host.name.deleted > other.host.name: icmp: echo request
14:16:23.108150 host.name.deleted.45639 > other.host.name.http: . ack
901588830 win 1024
14:16:23.108150 other.host.name > host.name.deleted: icmp: echo reply
14:16:23.108150 other.host.name.http > host.name.deleted.45639: R
901588830:901588830(0) win 0 (DF)
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)
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)
Interesting ports on other.host.name (194.153.168.235):
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)
14:16:23.448150 host.name.deleted.1073 > other.host.name.daytime: R
2950063923:2950063923(0) win 0 (DF)
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)
14:16:23.448150 host.name.deleted.1073 > other.host.name.daytime: R
2950063923:2950063923(0) win 0 (DF)
------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
-----------------------------------------
CONFIDENTIALITY NOTICE  This e-mail message and any attachments are only
for the use of the intended recipient and may contain information that is
privileged, confidential or exempt from disclosure under applicable law.
If you are not the intended recipient, any disclosure, distribution or
other use of this e-mail message or attachments is prohibited.  If you have
received this e-mail message in error, please delete and notify the sender
immediately. Thank you.
------------------------------------------------------------------------------
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