Strange results on a normal nmap-scan

elof2 at sentor.se elof2 at sentor.se
Tue Jan 20 11:39:09 EST 2015



I just ran:
# nc -nv 10.234.5.6
(UNKNOWN) [10.200.8.4] 1234 (?) : Connection refused


# nmap -sS -f 10.234.5.6
Starting Nmap 6.00 ( http://nmap.org ) at 2015-01-20 17:15 CET
Nmap scan report for foobar (10.234.5.6)
Host is up (0.0023s latency).
Not shown: 995 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
25/tcp   open  smtp
53/tcp   open  domain
587/tcp  open  submission
9102/tcp open  jetdirect

Nmap done: 1 IP address (1 host up) scanned in 6.84 seconds


The first netcat command resulted in:
       StartTime      Flgs  Proto            SrcAddr  Sport Dir 
DstAddr  Dport  SrcPkts  DstPkts     SrcBytes     DstBytes         State
17:13:50.701444  e           tcp        10.123.4.5.36358   -> 
10.234.5.6.1234          1        1           74           60 
S_RA

Everything looks good. I sent a SYN and got a RESET-ACK back since port 
1234 is closed.


The nmap SYN-scan should produce lots of lines with S_, S_, S_, S_, S_ or 
S_RA, S_RA, S_RA, but instead I get this:
       StartTime      Flgs  Proto            SrcAddr  Sport Dir 
DstAddr  Dport  SrcPkts  DstPkts     SrcBytes     DstBytes         State
17:15:21.343940  e          icmp        10.123.4.5.0x0008 <-> 
10.234.5.6.0x9cac        1        1           56           60 
ECO
17:15:21.344884  e  S F      tcp        10.123.4.5         ?> 
10.234.5.6            3408        0       190848            0 
_
17:15:21.345134  e           tcp         10.234.5.6.443     ?> 
10.123.4.5.55213         2        0          120            0 
RA_
17:15:21.345719  e    F     icmp        10.123.4.5.0x000d <-> 
10.234.5.6               3        1          168           60 
TST
17:15:21.347765  e           udp        10.123.4.5.37485  <-> 
10.234.5.6.53            1        1           83          188 
CON
17:15:21.352116  e           tcp         10.234.5.6.111     ?> 
10.123.4.5.55213         1        0           60            0 
RA_
17:15:21.352986  e           tcp         10.234.5.6.22      -> 
10.123.4.5.55213         1        1           60           56 
SA_R
17:15:21.354002  e           tcp         10.234.5.6.1025    ?> 
10.123.4.5.55213         1        0           60            0 
RA_
17:15:21.354925  e           tcp         10.234.5.6.110     ?> 
10.123.4.5.55213         1        0           60            0 
RA_
17:15:21.355825  e           tcp         10.234.5.6.53      -> 
10.123.4.5.55213         1        1           60           56 
SA_R
17:15:21.356719  e           tcp         10.234.5.6.1720    ?> 
10.123.4.5.55213         1        0           60            0 
RA_
17:15:21.357615  e           tcp         10.234.5.6.143     ?> 
10.123.4.5.55213         1        0           60            0 
RA_
17:15:21.358508  e           tcp         10.234.5.6.8888    ?> 
10.123.4.5.55213         1        0           60            0 
RA_
17:15:21.359391  e           tcp         10.234.5.6.3306    ?> 
10.123.4.5.55213         1        0           60            0 
RA_
17:15:21.360296  e           tcp         10.234.5.6.5900    ?> 
10.123.4.5.55213         1        0           60            0 
RA_
17:15:21.362378  e           tcp         10.234.5.6.256     ?> 
10.123.4.5.55213         1        0           60            0 
RA_
17:15:21.363184  e           tcp         10.234.5.6.445     ?> 
10.123.4.5.55213         1        0           60            0 
RA_
17:15:21.364210  e           tcp         10.234.5.6.139     ?> 
10.123.4.5.55213         1        0           60            0 
RA_
17:15:21.364996  e           tcp         10.234.5.6.135     ?> 
10.123.4.5.55213         1        0           60            0 
RA_
17:15:21.365960  e           tcp         10.234.5.6.3389    ?> 
10.123.4.5.55213         1        0           60            0 
RA_
17:15:21.366715  e           tcp         10.234.5.6.113     ?> 
10.123.4.5.55213         1        0           60            0 
RA_

If I try again, now with -P0 to prevent nmap from first pinging the host, 
the ra results are the same. One line with thousands of packets.


Why is all the SYNs aggregated into one line with a strange state of "_" 
and not put on 3408 separate rows with status "S_" or "S_RA"?

/Elof



More information about the argus mailing list