Re: Argus-info Digest, Vol 137, Issue 2
Kjell Tore Fossbakk <[email protected]> Mon, 24 Sep 2018 09:48:51 +0200
| Newsgroups | gmane.network.argus |
|---|---|
| Message-ID | <CABNi_Ay2fJeejWZzxsL0rv4XOdfBsDgodUDpzz4s734O=y0=9g@mail.gmail.com> |
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 <[email protected]> wrote: > Send Argus-info mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: Argus <[email protected]> > Subject: Re: [ARGUS] Odd records issue > Message-ID: <[email protected]> > 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 <[email protected]> > To: Argus <[email protected]> > Subject: Re: [ARGUS] Odd records issue > Message-ID: <[email protected]> > 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" <[email protected]> > To: "'mike tancsa'" <[email protected]> > Cc: "'Argus'" <[email protected]> > Subject: Re: [ARGUS] Odd records issue > Message-ID: <[email protected]> > 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= > [email protected]] On Behalf Of mike tancsa via Argus-info > Sent: Tuesday, January 10, 2017 1:55 PM > To: Argus <[email protected]> > 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 <[email protected]> > To: [email protected] > Cc: "'Argus'" <[email protected]> > Subject: Re: [ARGUS] Odd records issue > Message-ID: <[email protected]> > 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= > [email protected]] On Behalf Of mike tancsa via Argus-info > > Sent: Tuesday, January 10, 2017 1:55 PM > > To: Argus <[email protected]> > > 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 > [email protected] > https://lists.andrew.cmu.edu/mailman/listinfo/argus-info > > > ------------------------------ > > End of Argus-info Digest, Vol 137, Issue 2 > ****************************************** >