Penetration Testing mailing list archives

Re: Help understanding a trace of an nmap scan


From: Sebastian Garcia <sgarcia () citefa gov ar>
Date: Fri, 11 Feb 2005 12:02:27 -0900

Hi Richard, 

Be careful with your terminal!, you disclosed a public ip address in
your nmap output. 

I don't know exactly why this is happening, here is my 2 cents analisys.

I think there are 2 diferent classes of nmap RSTs in your trace.

Your First RST
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)

This packet is nmap trying to be nice with the other host. It's closing
the conection so the other tcp/ip stack stops waiting for further data.

Your first recived Push
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)

This is how daytime service works. It automatically sends you the
requested information.

After this, daytime FINishes the connection sending you a FIN packet.
Nmap should honours the FIN handshake sending an ACK, BUT your nmap
didn't send it.


In your first RST, nmap is using a socket connection. So we can see a
5840 byte window and ip optins with timestamp. (Also you can confirm
that this packet is related to the SYN/ACK packet because it has the
correct "138541011" SYN/ACK timestamp on it).

BUT second and third RST packets, are nmap crafted packets. They doesn't
belong to a socket connection. They have a 0 byte window and no ip
options. 

Your Second RST
14:16:23.448150 host.name.deleted.1073 > other.host.name.daytime: R
2950063923:2950063923(0) win 0 (DF)

We can be sure that this RST packets belong to this scan looking at
packet capture time.

We see a first burst of packets with capture time "14:16:23.428150",
then, one second later, daytime sends the data and nmap responds with a
second burst of packets with capture time "14:16:23.448150".
Although it's very unlikely to respond so quickly, i believe is a matter
of time configuration in the tcpdump host.




In a clean nmap scan to port 13, connect scan. We should see something
like this.

10:48:49.130733 IP yy.yy.yy.yy.40771 > xx.xx.xx.xx.13: S
1611027253:1611027253(0) win 5840 <mss 1460,sackOK,timestamp 171762977
0,nop,wscale 0>
10:48:49.130970 IP xx.xx.xx.xx.13 > yy.yy.yy.yy.40771: S
1131021469:1131021469(0) ack 1611027254 win 5792 <mss
1460,sackOK,timestamp 76453060 171762977,nop,wscale 2>
10:48:49.131014 IP yy.yy.yy.yy.40771 > xx.xx.xx.xx.13: . ack 1 win 5840
<nop,nop,timestamp 171762977 76453060>
10:48:49.132197 IP xx.xx.xx.xx.13 > yy.yy.yy.yy.40771: P 1:27(26) ack 1
win 1448 <nop,nop,timestamp 76453061 171762977>
10:48:49.132265 IP yy.yy.yy.yy.40771 > xx.xx.xx.xx.13: . ack 27 win 5840
<nop,nop,timestamp 171762979 76453061>
10:48:49.132271 IP xx.xx.xx.xx.13 > yy.yy.yy.yy.40771: F 27:27(0) ack 1
win 1448 <nop,nop,timestamp 76453061 171762977>
10:48:49.172272 IP yy.yy.yy.yy.40771 > xx.xx.xx.xx.13: . ack 28 win 5840
<nop,nop,timestamp 171763019 76453061>
10:48:49.238035 IP yy.yy.yy.yy.40771 > xx.xx.xx.xx: R 1:1(0) ack 28 win
5840 <nop,nop,timestamp 171763084 76453061>

Note the changeing times.


Cheers.

Sebastian Garcia




On Mon, 2004-09-06 at 15:11 +0100, Richard Moore wrote:
I wonder if anyone can help me make sense of this packet trace. It shows 
nmap runing 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.
plain text document attachment (nmap-dump)
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
-------------------------------------------------------------------------------
-- 
Sebastian Garcia
Div. Seguridad Informática
DINFO - CITEFA
San Juan B. de La Salle 4397 
B1603ALO Villa Martelli - Pcia. Bs. As.
Tel: (54-11) 4709-8289 
e-mail: sgarcia () citefa gov ar - www.citefa.gov.ar/si6
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x4305E810


Current thread: