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