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:
- Re: Help understanding a trace of an nmap scan Sebastian Garcia (Feb 11)