Strange results on a normal nmap-scan
elof2 at sentor.se
elof2 at sentor.se
Wed Jan 21 07:33:40 EST 2015
Yepp, argus is doing the right thing.
Nice to learn something new out of my mistake with the -f/-F flag.
/Elof
On Wed, 21 Jan 2015, Carter Bullard wrote:
> Hey /Elof,
> If nmap is fragmenting SYN packets, then it's not sending real fragments, but pseudo-fragments, where the fragment splits the TCP header. This is not suppose to happen, as it violates the IP protocol. No IP police here, of course, so we do see them in attacks. These fragments result in a condition where no ingress packets in the flow are "real" TCP packets, as they don't have all the TCP identifiers. Argus can't generate a 5-tuple flow key from the zero offset fragment, so Argus creates 3-tuple keys: src, dst, and proto. The SYN_ACK or RST responses are not fragmented, so Argus will generate 5-tuple flows for those packets, going in the opposite direction. The complete collection of flow records will look weird, but that is the clue.
>
> In the argus record, the fragment size is reported, and that is a giveaway that someone is doing something funky, first fragment size << MTU. If you see these, you've got a problem, so argus is doing the right thing.
>
> Carter
>
>
>
>> On Jan 21, 2015, at 5:34 AM, "elof2 at sentor.se" <elof2 at sentor.se> wrote:
>>
>>
>> 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