Re: Help understanding a trace of an nmap scan

From: Sebastian Garcia (sgarcia_at_citefa.gov.ar)
Date: 02/11/05

  • Next message: MARTEAU Jean-Louis: "RE : Data Mining for PIX Firewall Logs"
    To: pen-test@securityfocus.com
    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
    

  • Next message: MARTEAU Jean-Louis: "RE : Data Mining for PIX Firewall Logs"

    Relevant Pages

    • RE: Help understanding a trace of an nmap scan
      ... it will send a ping to confirm the host is up before performing the scan) ... -- (Ack packet to port 80 and corresponding rst; ... is not related to any existing connection, so this is the expected behavior) ... It seems that this connection closing algorithm is generic, son nmap ...
      (Pen-Test)
    • Fw: Nmap 4.00 Released! (ARP scanning)
      ... I am pleased to announce that Nmap 4.00 is now available! ... It is now used automatically for any hosts that are ... the UDP probes will have their status changed to open. ... 'd' to increase the debugging level, 'p' to enable packet tracing, ...
      (Security-Basics)
    • Re: Suspected nmap listing - am I under attack?
      ... Read the documentation of nmap, it is very ... packet was sent by nmap but nothing came back. ... EARN A MASTER OF SCIENCE IN INFORMATION ASSURANCE - ONLINE ... The NSA has designated Norwich University a center of Academic Excellence ...
      (Security-Basics)
    • Nmap 4.00 Released
      ... I try not to burden the Bugtraq list with more than one Nmap ... packets via raw sockets. ... Nmap can now send raw ethernet ARP ... 'd' to increase the debugging level, 'p' to enable packet tracing, ...
      (Bugtraq)
    • Re: Help understanding a trace of an nmap scan
      ... > I wonder if anyone can help me make sense of this packet trace. ... > nmap running a connect scan against port 13 of a host. ... It looks as if nmap is sending RST packets until it receives a FIN ... The only people for me are the mad ones -- the ones who are mad to live, ...
      (Pen-Test)