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
