Strange results on a normal nmap-scan

el draco eldraco at gmail.com
Wed Jan 21 04:19:46 EST 2015


Hi list and Elof

Notice that in your nmap command you explicitly asked for fragments to be
sent (-f). Maybe you wanted to put -F? fast mode?
So it makes sense what Carter said about the fragments. The icmp lines are
ok since that is how you told nmap to see if the host is up.

The SA_R lines should be the responses from the open ports, but it is weird
that you only have those lines for port 53 and 22 in our output. Since nmap
shows you that also ports 25, 587 and 9102 are open you should at least see
those ones too. Is the output complete?

The CON line is udp, which is also weird because you explicitly said to
nmap to use TCP SYN. My only conclusion is that you were using your own DNS
server for your own purposes at the same time that you were scanning your
computer. That would explain why argus saw the udp connection. In those
situations it may be better to be sure that no other connections are being
generated apart from the ones you are doing as a test.

In my test, I see a lot of S_RA lines.

sebas



On Wed, Jan 21, 2015 at 12:25 AM, Carter Bullard <carter at qosient.com> wrote:

> Do you have a packet capture ??  That will say a lot !!
> The single line represents fragments ( 'F') notice that there aren't any
> port numbers.
> Not sure why they are seen as fragments, but it may actually be that way
> on the wire ????
>
> The other records look right, as if you're only seeing the response, and
> not  the SYN.
>
> Packet capture would be great !!
> Carter
>
>
> On Jan 20, 2015, at 11:39 AM, elof2 at sentor.se wrote:
>
>
>
> 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
>
>


-- 
https://pgp.mit.edu/pks/lookup?op=get&search=0x9D9A358CA10F1601
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20150121/2b23e9b0/attachment.html>


More information about the argus mailing list