Argus-info Digest, Vol 137, Issue 2

Kjell Tore Fossbakk kjelltore at gmail.com
Mon Sep 24 03:48:51 EDT 2018


Hello.

We experience the same issue: we receive a UDP packet with a GRE tunnel
inside a vlan 802.1q frame. The traffic we see is from a botnet which
generates GRE ethernet/IP flooding

What Argus outputs is inconsistent and misleading: we get the IP header
details of the contents inside the GRE tunnel written to the FAR V3
ARGUS_FLOW_DSR (ARGUS_TYPE_IPV4). The packet is received on a VLAN, and
Argus output the correct information into the ARGUS_VLAN_DSR.

Was this issue resolved? Is there a workaround?

Argus 3.0.8.2



On Wed, Jan 11, 2017 at 4:30 PM <argus-info-request at lists.andrew.cmu.edu>
wrote:

> Send Argus-info mailing list submissions to
>         argus-info at lists.andrew.cmu.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.andrew.cmu.edu/mailman/listinfo/argus-info
> or, via email, send a message with subject or body 'help' to
>         argus-info-request at lists.andrew.cmu.edu
>
> You can reach the person managing the list at
>         argus-info-owner at lists.andrew.cmu.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Argus-info digest..."
>
>
> Today's Topics:
>
>    1. Re:  Odd records issue (mike tancsa)
>    2. Re:  Odd records issue (mike tancsa)
>    3. Re:  Odd records issue (David Edelman)
>    4. Re:  Odd records issue (mike tancsa)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 10 Jan 2017 13:55:20 -0500
> From: mike tancsa <mike at sentex.ca>
> To: Argus <argus-info at lists.andrew.cmu.edu>
> Subject: Re: [ARGUS] Odd records issue
> Message-ID: <db0090e1-66d8-3dab-f20c-65a1bfe15cbe at sentex.ca>
> Content-Type: text/plain; charset=utf-8
>
> 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
> >
> >
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 10 Jan 2017 15:36:25 -0500
> From: mike tancsa <mike at sentex.ca>
> To: Argus <argus-info at lists.andrew.cmu.edu>
> Subject: Re: [ARGUS] Odd records issue
> Message-ID: <12229a3b-e7b2-a266-82d8-1b102fe0f47c at sentex.ca>
> Content-Type: text/plain; charset=utf-8
>
> 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
> >>
> >>
> >
> >
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 10 Jan 2017 15:57:18 -0500
> From: "David Edelman" <dedelman at iname.com>
> To: "'mike tancsa'" <mike at sentex.ca>
> Cc: "'Argus'" <argus-info at lists.andrew.cmu.edu>
> Subject: Re: [ARGUS] Odd records issue
> Message-ID: <07a301d26b84$21d68e10$6583aa30$@iname.com>
> Content-Type: text/plain;       charset="utf-8"
>
> As a rule I always suggest that you start the troubleshooting session by
> adding -X as the first argument on the command line that starts Argus. This
> might solve the problem and then you know to look at *ALL* of the argus
> configuration files.
>
> Just a guess, the configuration parameter  ARGUS_TUNNEL_DISCOVERY  may be
> set to yes and have some impact. Since the default value is set to no
> killing the consumption of the configuration files may help.
>
> --Dave
>
> -----Original Message-----
> From: Argus-info [mailto:argus-info-bounces+dedelman=
> iname.com at lists.andrew.cmu.edu] On Behalf Of mike tancsa via Argus-info
> Sent: Tuesday, January 10, 2017 1:55 PM
> To: Argus <argus-info at lists.andrew.cmu.edu>
> Subject: Re: [ARGUS] Odd records issue
>
> 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
> >
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 11 Jan 2017 10:29:58 -0500
> From: mike tancsa <mike at sentex.ca>
> To: dedelman at iname.com
> Cc: "'Argus'" <argus-info at lists.andrew.cmu.edu>
> Subject: Re: [ARGUS] Odd records issue
> Message-ID: <19f23921-79c6-50ee-73bc-17e625f836b0 at sentex.ca>
> Content-Type: text/plain; charset=utf-8
>
> On 1/10/2017 3:57 PM, David Edelman wrote:
> > As a rule I always suggest that you start the troubleshooting session by
> adding -X as the first argument on the command line that starts Argus. This
> might solve the problem and then you know to look at *ALL* of the argus
> configuration files.
>
> >
> > Just a guess, the configuration parameter  ARGUS_TUNNEL_DISCOVERY  may
> be set to yes and have some impact. Since the default value is set to no
> killing the consumption of the configuration files may help.
>
> Hi,
> The challenge is that by displaying only the tunnel payload, I have no
> way of finding out via argus what IP delivered that payload. Its also
> inconsistent.  With the botnet traffic, it saves the inner payload as a
> record. with "normal" GRE traffic, it saves the transport GRE packet.
>
> Tunnel Discovery is off.
>
>
> eg, a tcpdump shows
>
> 10:22:19.945153 IP aa.bb.153.25 > xx.yy.xx.58: GREv1, call 10112, seq
> 24045, ack 28268, length 60: IP 10.0.0.210 > 224.0.0.22: igmp v3 report,
> 1 group record(s)
>
> and argus shows
>
>  10:22:19  *           gre        xx.yy.xx.58          <->
> aa.bb.153.25              14      13437   CON
>
> But there is no mention in the argus file of the host 10.0.0.210.  It
> only seems to happen with the botnet generated GRE traffic.
>
>         ---Mike
>
>
>
> >
> > --Dave
> >
> > -----Original Message-----
> > From: Argus-info [mailto:argus-info-bounces+dedelman=
> iname.com at lists.andrew.cmu.edu] On Behalf Of mike tancsa via Argus-info
> > Sent: Tuesday, January 10, 2017 1:55 PM
> > To: Argus <argus-info at lists.andrew.cmu.edu>
> > Subject: Re: [ARGUS] Odd records issue
> >
> > 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
> >>
> >>
> >
> >
> >
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Argus-info mailing list
> Argus-info at lists.andrew.cmu.edu
> https://lists.andrew.cmu.edu/mailman/listinfo/argus-info
>
>
> ------------------------------
>
> End of Argus-info Digest, Vol 137, Issue 2
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20180924/63c74d38/attachment.html>


More information about the argus mailing list