Strange results on a normal nmap-scan
elof2 at sentor.se
elof2 at sentor.se
Wed Jan 21 05:34:27 EST 2015
Doh doh doh!
Ofcourse I meant to do -F.
Thanks for noticing.
With -F I got all my lines with S_RA and S_ as expected.
Interesting to see what happened in argus when a SYN packet was
fragmented.
/Elof
On Wed, 21 Jan 2015, el draco wrote:
> 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
>
More information about the argus
mailing list