Odd records issue
Carter Bullard
carter at qosient.com
Tue Sep 25 08:12:27 EDT 2018
Hey Kjell,
The concept is to provide awareness for your exact situation, tunneled attack traffic designed to by-pass any sensing and policy enforcement. If Argus had not reported its awareness of the contents of the GRE tunnel, would you have realized the botnet ? I’m sorry for the lack of elegance for your situation.
I’m glad that Argus has been able to help you for 13+ years. We’ve been working on commercializing Argus, and our ArgusPro sensor has better flow context support (ie more encapsulation parsing and retained identifiers) to help in analyzing this type of situation, especially for newer encapsulations, like GUE. We have Argus now for Mac,Win,and Linux endsystems and commercial boxes for 1,10,40 and 100Gbps. Would your organization be interested in commercial Argus software ?? We have focused on improving Argus for large scale deploymnets and more data at higher rates.
In open source Argus, we can add the GRE header info to the flow record, just like we do with the MPLS labels, and provide support to print, aggregate, filter, sort etc ... the end-to-end flows using the GRE info, just like we’ve done for MPLS. Do you add the MPLS labels to your flow keys when you’re monitoring MPLS traffic?? Would you want to add the GRE id’s to the Argus flow key to report on traffic stripping among multiple GRE’s ???
Do you think that you would ‘watch’ the GRE flows or would you still want to pay attention to the end-to-end flows? With one of your observation points being on the outside, I would be interested in the GRE contents, as that is where the interior relevant information is. I personally would not be satisfied seeing only that there was a new tunnel, or that the existing tunnels increased in load.
I could provide a configuration option so that Argus would stop parsing at the local L3 header, but that would eliminate the benefit of seeing into the tunnel. Although during an attack, it maybe nice to reduce the end-to-end flows based so you can manage the flow load.
All my time is devoted to the commercial Argus code, so I won’t be able to add GRE specific support anytime soon.
Oh and FYI when there are flgs collisions, ie the ‘*’, the ‘encaps’ field provides the means to see all the protocols that were parsed.
Carter
Carter Bullard • CTO
150 E 57th Street Suite 12D
New York, New York 10022-2795
Phone +1.212.588.9133 • Mobile +1.917.497.9494
> On Sep 25, 2018, at 2:36 AM, Kjell Tore Fossbakk <kjelltore at gmail.com> wrote:
>
> Hello Carter,
>
> I have been using Argus for ~13 years, and its main purpose for us is the source-of-truth on network traffic at specific points in our network, an sort of aggregated tcpdump continuously running on all the hosts and interfaces we are using Argus. I did not know that Argus was designed to report on the end-to-end flows, it explains the behavior we are experiencing. We are actually using this behavior when we look into MPLS traffic.
>
> In this particular case we have TAP traffic just outside an organizations connection to the Internet. Thus, the packets observed are only Internett routed traffic (non private addresses) with MAC addresses local between the routers. Since we have control on all the IP addresses/CIDRs of this organization we are very interested in new/rare IP addresses not belonging to the organization. Also, any connection pair we are seeing _must_ have the organizations IP in either the src or dest IP field - if not, there is something seriously wrong (as from how we expect to see things). This is how we spotted this traffic as we observed netflows without any of the organisations IP present. The botnet sends UDP packets with GRE contents containing randomized src/dest IP, src/dest port, payload etc. Since Argus is designed to report on the end-to-end flows we get netflows from randomized, non-existing traffic/sessions. For our analytics team this was misleading/inconsistent from how we expected and how we want Argus to behave. I would expect Argus, or I want to tell Argus, to report on the outer IP headers so we have a view on what's actually being transmitted on the network. Argus did report the '*' into the flgs fields indicating multiple sub-ip encapsulations, but we could not get the first IP header information.
>
> I see real use cases to get the end IP header inside encapsulated tunnels, e.g. MPLS. It would be helpful if Argus could be configured to stop parsing after the first IP header. Could another solution be to configure Argus to report on all the IP header layers?
>
> Argus made us aware of the tunneling, not not that it was botnet traffic. We used a Suricata signature to capture a pcap of the traffic which resolved the incident. Since we did not see the first IP header info in the netflow it was really difficult to see that all this traffic originated from one single IP.
>
> Sincerely,
> Kjell Tore
>
>
>> On Mon, Sep 24, 2018 at 1:43 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: Argus-info Digest, Vol 137, Issue 2 (Carter Bullard)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 24 Sep 2018 07:43:06 -0400
>> From: Carter Bullard <carter at qosient.com>
>> To: Kjell Tore Fossbakk <kjelltore at gmail.com>
>> Cc: Argus <argus-info at lists.andrew.cmu.edu>
>> Subject: Re: [ARGUS] Argus-info Digest, Vol 137, Issue 2
>> Message-ID: <4B948AF3-A080-475C-B423-184AAC2A45B0 at qosient.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hey Kjell,
>> Argus is an end-to-end flow sensor, parsing packets until it finds the end-to-end headers and the it reports on the end-to-end flows. Encapsulations like L2TP, MPLS, IPnIP, Teredo, GRE, GUE, are treated as encapsulations, and there presence is noted and reported in the ?flgs? field and in the ?encaps? field. In your case, Argus should indicate that it saw GRE, in the ?flgs? field and should print out the encapsulation indication if you print the ?encaps? field. Because there can be a lot of encapsulations, tunnels inside tunnels, Argus is designed to report on the end-to-end flows, and be brief about the rest, so it is consistent to its design.
>>
>> How was it misleading? Seeing the end-to-end IPs rather than a set of local IP addresses ?? What would you rather argus report to avoid the misleading part ??? Print GRE tunnel id?s and stop, or provide a way to print the GRE identifiers ?? Would you want to configure Argus to not parse beyound the first IP header ???
>>
>> Did Argus help you realize the botnet traffic, as that would be a success, in comparison to other tools. Did the lack of GRE information make it difficult to see the tunnel or attribute the botnet traffic to a specific source and sink ?? Having the GRE id?s would be very helpful in this case.
>>
>> We currently don?t store the GRE traffic headers in open source Argus. We do have them in the Pro version of software, if that would be useful.
>>
>> Hope all is most excellent,
>> Carter
>>
>> Carter Bullard ? CTO
>> 150 E 57th Street Suite 12D
>> New York, New York 10022-2795
>> Phone +1.212.588.9133 ? Mobile +1.917.497.9494
>>
>> > On Sep 24, 2018, at 3:48 AM, Kjell Tore Fossbakk <kjelltore at gmail.com> wrote:
>> >
>> > 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://lists.andrew.cmu.edu/mailman/private/argus-info/attachments/20180924/97c70fd5/attachment.html>
>>
>> ------------------------------
>>
>> 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 152, Issue 2
>> ******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20180925/7440e9e5/attachment.html>
More information about the argus
mailing list