Odd records issue
Kjell Tore Fossbakk
kjelltore at gmail.com
Tue Sep 25 02:36:12 EDT 2018
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/4b2ae47d/attachment.html>
More information about the argus
mailing list