Odd records issue

mike tancsa via Argus-info argus-info at lists.andrew.cmu.edu
Tue Jan 10 15:36:25 EST 2017


Another datapoint.  It seems argus treats GREv0 and GREv[1-2] packets
differently-- or at least traffic generated by this botnet.  If its v1
or v2, the outside, transport source and dest address get recorded as
expected. If its this botnet traffic (mirai net)  than tcpdump shows as
GREV0, argus "seems" to get confused and instead records the inside.

tshark acts a little odd too.

% tshark -s0 -nr gre.pcap frame.number == 261
261  28.284577 186.161.19.142 ? 240.14.203.151 UDP 66 44583?2135 Len=0

If I grep for the transport IP
% tshark -s0 -nr gre.pcap | grep 220.132.189.166
%
nada... vs looking for the inside IP

% tshark -s0 -nr gre.pcap | grep 186.161.19.142
261  28.284577 186.161.19.142 → 240.14.203.151 UDP 66 44583→2135 Len=0
% tshark -s0 -nr gre.pcap | grep 186.161.19.142

but if I do

-% tshark -s0 -nr gre.pcap ip.host == 220.132.189.166
261  28.284577 186.161.19.142 ? 240.14.203.151 UDP 66 44583?2135 Len=0

it knows enough to show the right packet.

Frame 261: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: Jan 10, 2017 11:59:09.972482000 EST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1484067549.972482000 seconds
    [Time delta from previous captured frame: 0.044772000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 28.284577000 seconds]
    Frame Number: 261
    Frame Length: 66 bytes (528 bits)
    Capture Length: 66 bytes (528 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:gre:ip:udp]
Ethernet II, Src: 78:19:f7:38:57:6c, Dst: 90:e2:ba:01:37:80
    Destination: 90:e2:ba:01:37:80
        Address: 90:e2:ba:01:37:80
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: 78:19:f7:38:57:6c
        Address: 78:19:f7:38:57:6c
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 220.132.189.166, Dst: 206.51.25.39
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable
Transport (0)
    Total Length: 52
    Identification: 0xdb33 (56115)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 51
    Protocol: Generic Routing Encapsulation (47)
    Header checksum: 0xeae1 [validation disabled]
    [Header checksum status: Unverified]
    Source: 220.132.189.166
    Destination: 206.51.25.39
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
Generic Routing Encapsulation (IP)
    Flags and Version: 0x0000
        0... .... .... .... = Checksum Bit: No
        .0.. .... .... .... = Routing Bit: No
        ..0. .... .... .... = Key Bit: No
        ...0 .... .... .... = Sequence Number Bit: No
        .... 0... .... .... = Strict Source Route Bit: No
        .... .000 .... .... = Recursion control: 0
        .... .... 0000 0... = Flags (Reserved): 0
        .... .... .... .000 = Version: GRE (0)
    Protocol Type: IP (0x0800)
Internet Protocol Version 4, Src: 186.161.19.142, Dst: 240.14.203.151
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable
Transport (0)
    Total Length: 28
    Identification: 0x0cd0 (3280)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0xa42b [validation disabled]
    [Header checksum status: Unverified]
    Source: 186.161.19.142
    Destination: 240.14.203.151
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 44583, Dst Port: 2135
    Source Port: 44583
    Destination Port: 2135
    Length: 8
    Checksum: 0xbf89 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 51]

	---Mike

On 1/10/2017 1:55 PM, mike tancsa via Argus-info wrote:
> OK, I figured this out. It seems the contents of GRE packets are being
> recorded by argus as if they are actual packets.  Is there a way to flag
> these or keep these separate ?
> 
> e.g. a tcpdump shows
> length 578: 220.133.125.107 > 206.51.25.216: GREv0, proto IPv4 (0x0800),
> length 544: 185.125.128.61.53714 > 112.93.217.129.37883: UDP, length 512
> 
> % ra -nr border.arg -sproto:3,saddr,sport,daddr,dport,size - host
> 185.125.128.61
> Pro            SrcAddr  Sport            DstAddr  Dport
> udp     185.125.128.61.53714      112.93.217.129.37883
> 
> Its nice that this is saved, but it would be good if it were treated as
> "special" or different from the actual packet on the wire.
> 
> 	---Mike
> 
> On 1/10/2017 11:02 AM, mike tancsa via Argus-info wrote:
>> While I was trying to track down an issue with some unaccounted packets,
>> I noticed that argus was creating a lot of records that dont make sense.
>>
>> One one of my sensors, I changed the config so that I would record a
>> pcap.  In theory, both files should show the same data, no ? Instead, I
>> have a LOT of addresses that are not in my network, and almost always
>> 582 bytes.
>>
>> % ra -nr argus.out -s saddr,sport,daddr,dport, bytes:4 ,pkts:2,proto:3 -
>> bytes 582 and pkts 1 | head -30
>>            SrcAddr  Sport            DstAddr  Dport TotB To Pro
>>       66.14.58.118.4710        165.57.97.129.62304   582  1 udp
>>     228.44.123.180.32215       130.71.80.142.169     582  1 udp
>>       42.80.37.245.64417        217.93.18.80.13594   582  1 udp
>>       42.80.37.245.64417        217.93.18.80.13594   582  1 udp
>>    184.111.255.119.46797       220.83.180.38.46450   582  1 udp
>>     208.20.172.166.10533     155.189.252.142.23409   582  1 udp
>>       87.96.180.21.42185       156.23.175.50.42394   582  1 udp
>>     135.215.238.69.41005      244.71.183.157.49514   582  1 udp
>>     42.118.169.234.64017      24.169.111.198.5837    582  1 udp
>>      62.150.25.153.2414        39.220.44.122.58128   582  1 udp
>>      113.20.11.165.45467      200.106.11.169.57598   582  1 udp
>>      172.180.78.96.51016       139.173.29.46.15019   582  1 udp
>>      172.180.78.96.51016       139.173.29.46.15019   582  1 udp
>>     44.122.117.130.20546      180.167.75.128.60420   582  1 udp
>>     44.122.117.130.20546      180.167.75.128.60420   582  1 udp
>>     235.102.137.81.59403     110.104.217.242.31414   582  1 udp
>>     235.102.137.81.59403     110.104.217.242.31414   582  1 udp
>>      52.15.123.178.12147        210.93.8.106.19146   582  1 udp
>>      52.15.123.178.12147        210.93.8.106.19146   582  1 udp
>>     68.195.206.107.19522      184.118.84.142.48695   582  1 udp
>>       173.129.21.3.5450      252.255.127.111.49931   582  1 udp
>>       173.129.21.3.5450      252.255.127.111.49931   582  1 udp
>>      94.187.10.197.3147       162.181.187.17.16443   582  1 udp
>>     208.189.73.229.33307        155.175.43.8.62169   582  1 udp
>>      115.98.69.100.4716         84.194.54.90.31643   582  1 udp
>>     181.61.176.121.25337       230.174.10.75.38614   582  1 udp
>>     17.126.194.240.59882         67.78.7.236.64742   582  1 udp
>>       68.209.4.147.38113        82.176.3.109.8904    582  1 udp
>>       68.209.4.147.38113        82.176.3.109.8904    582  1 udp
>>
>>
>> But looking at the pcap file AND a tcpdump of the interface, I never see
>> any such packets.
>>
>> % ls -l
>> total 3779656
>> drwxr-xr-x  2 root  wheel  -        512 Jan 10 10:03 .
>> drwxr-xr-x  3 root  wheel  -       3072 Jan 10 10:03 ..
>> -rw-r--r--  1 root  wheel  -  207937088 Jan 10 10:57 argus.out
>> -rw-r--r--  1 root  wheel  - 3661365248 Jan 10 10:57 packet.out
>>
>> % tcpdump -nr packet.out greater 580 and less 583
>> reading from file packet.out, link-type EN10MB (Ethernet)
>>
>> % tcpdump -ner packet.out host 68.209.4.147 or host 17.126.194.240 or
>> host 235.102.137.81
>> reading from file packet.out, link-type EN10MB (Ethernet)
>>
>> Any idea whats going on ?
>>
>> If I tcpdump the interface, it never sees any such traffic where as
>> argus implies there is a LOT
>>
>> % ra -nr argus.out -s stime,saddr,daddr - bytes 582 and pkts 1 | head
>>          StartTime            SrcAddr            DstAddr
>>    10:03:46.217241       66.14.58.118      165.57.97.129
>>    10:03:46.536733     228.44.123.180      130.71.80.142
>>    10:03:47.724602       42.80.37.245       217.93.18.80
>>    10:03:47.724589       42.80.37.245       217.93.18.80
>>    10:03:49.187933    184.111.255.119      220.83.180.38
>>    10:03:53.051873     208.20.172.166    155.189.252.142
>>    10:03:57.551938       87.96.180.21      156.23.175.50
>>    10:04:00.120709     135.215.238.69     244.71.183.157
>>    10:04:02.452829     42.118.169.234     24.169.111.198
>>
>> Ra Version 3.0.8.2
>> Argus Version 3.0.8.2
>>
>>
> 
> 




More information about the argus mailing list