RE: Help understanding a trace of an nmap scan

From: Omar Herrera (
Date: 09/09/04

  • Next message: Steffen Kluge: "RE: Patch management tool"
    Date: Wed, 08 Sep 2004 21:33:59 -0500

    Ok, let's break it down. Some answers just seem to be overlapped.

    14:16:23.098150 > icmp: echo request
    14:16:23.108150 > icmp: echo reply
    -- (Ping and corresponding reply; unless you specify -P0 as an nmap option
    it will send a ping to confirm the host is up before performing the scan)

    14:16:23.108150 > . ack
    901588830 win 1024
    14:16:23.108150 > R
    901588830:901588830(0) win 0 (DF)
    -- (Ack packet to port 80 and corresponding rst; this is because ack number
    is not related to any existing connection, so this is the expected behavior)

    -- Now, here are the RST that I suppose you are referring to ...

    14:16:23.428150 > S
    2950063922:2950063922(0) win 5840 <mss 1460,sackOK,timestamp 51097216
    0,nop,wscale 0> (DF)
    14:16:23.438150 > S
    1866105343:1866105343(0) ack 2950063923 win 5792 <mss 1460,sackOK,timestamp
    138541011 51097216,nop,wscale 0> (DF)
    14:16:23.438150 > . ack 1
    win 5840 <nop,nop,timestamp 51097217 138541011> (DF)
    -- (3 way handshake, you send a syn packet with seq # 2950063922, host
    answers with a SYN+ACK packet, with seq #1866105343 and acknowledging your
    seq #+1)

    14:16:23.438150 > R 1:1(0)
    ack 1 win 5840 <nop,nop,timestamp 51097217 138541011> (DF)
    -- (After completing 3 way handshake, your systems resets the connection
    with a RST packet)

    Interesting ports on (
    -- (Watch it, wipe IP addresses as well ;-) )

    14:16:23.448150 > P 1:27(26)
    ack 1 win 5792 <nop,nop,timestamp 138541012 51097217> (DF)
    -- (Oops, server is sending data... don't worry, this is normal behavior,
    after you completed the 3 way handshake the daytime service sends you the
    daytime, it won't usually expect you to send an RST right after you
    established the connection, so it is just doing it's job...)

    14:16:23.448150 > R
    2950063923:2950063923(0) win 0 (DF)
    -- (What?, we asked to tear the connection but received a PSH+ACK packet
    with data instead, well, maybe that host didn't get the message so we try
    again. It seems that this connection closing algorithm is generic, son nmap
    won't distinguish between this behavior and that of other TCP based services
    where the client usually sends something before the server starts

    14:16:23.448150 > F 27:27(0)
    ack 1 win 5792 <nop,nop,timestamp 138541012 51097217> (DF)
    -- (Ok, each host minds its own business, after sending the daytime this
    server knows that it is time to close the connection, so it starts to
    actively close the connection with a FIN packet. If both hosts were still
    synchronized an ACK packet with ACK number +1 from your host should

    14:16:23.448150 > R
    2950063923:2950063923(0) win 0 (DF)
    -- (...But your nmap host is just too busy telling the other host to shut

    It's not such a mess after all, and If I'm not mistaken the last 2 RST
    packets from your machine will be sent automatically by the TCP stack
    (others will correct me if I'm mistaken). It turns out that Linux TCP/IP
    stack takes its job seriously and it will participate in any connection
    (since you already sent the first RST it won't see the PSH+ACK and the FIN
    packets related to any connection in your machine and will send the last 2
    RST packets on its own).

    You can see this behavior as well by setting up a sniffer and spoofing a SYN
    packet with certain tools (like HPING) and sending it to some open port on
    some other host. After receiving the SYN+ACK packet you will see in your
    sniffer that your systems sends automatically a RST packet, because the
    original SYN packet was not created through the kernel stack (this behavior
    appears on kernels 2.4 and later). The only way to avoid your stack from
    answering to your own handmade packets is to set up a filter (through
    iptables/netfilter for example).

    I'm not too sure if these 3 way handshake connections are created through
    the kernel by nmap or using the raw packets, but your trace would suggest
    they use raw packets, and that nmap would disable this filter even though it
    still keeps capturing all packets related to the same hosts and ports
    involved in the scan.

    I will let those with more knowledge on nmap internals to clarify this
    behavior (if I'm correct in my perception).

    Best regards,

    Omar Herrera

    > -----Original Message-----
    > From: Richard Moore []
    > Sent: Monday, September 06, 2004 9:11 AM
    > To:
    > Subject: Help understanding a trace of an nmap scan
    > I wonder if anyone can help me make sense of this packet trace. It shows
    > nmap running 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.
    > --
    > Richard Moore, Principle Software Engineer,
    > Westpoint Ltd,
    > Albion Wharf, 19 Albion Street, Manchester, M1 5LN, England
    > Tel: +44 161 237 1028
    > Fax: +44 161 237 1031

    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.

  • Next message: Steffen Kluge: "RE: Patch management tool"