From: Sebastian Garcia (sgarcia@citefa.gov.ar)
Date: Fri Feb 11 2005 - 16:02:27 EST
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
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:16 EDT