Packet capture based on protocol #11
openargus
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Packet Capture in Argus
Argus has the ability to write out packets that it processes as libpcap packet capture files. This feature is designed to support packet header parsing debugging and testing, and its managed using the argus.conf file variable ARGUS_PACKET_CAPTURE_FILE. Historically, if this variable was set, argus would write out all the packets that it receives and dump them to a single file.
This feature was implemented so that if argus dies, the packet that it died on would be in the packet capture file, and you could remove the file, rename it, etc, and argus would recreate the file.
Capturing all the packets in busy networks just doesn't work out that well, and we extended the feature in Argus 3.0 so that we could capture packets only when there were header parsing errors. Argus is tolerant to poorly formed packets, and resiliance is a part of Argus's defenses to directed sensor attack.
Recently, a few sites have encountered unexpected protocols within unexpected tunnels in their core network. In response to an issue where a core network was seeing some weird TCP in GRE in VxLan in IP tunnels at a 100G bps, we've added "packet capture on protocols".
This feature will dump packets based on the occurrence of a specified protocol header type, regardless of where it is in the packet. At this 100G site, they were seeing GRE packets once every 2-3 minutes (~ 1 : 200M pkts), and the contents were pretty weird, foreign addresses, zero length UDP packets inside tunnels within the GRE. The GRE was seeing primarily in VxLan tunnels, but not always, and because GRE was not a tunnel type the network supported, the occurrence of GRE was a big surprise and a big deal, but very difficult to capture, at 100G bps.
For this site, capturing the actual packets for this rare occurrence is important in the investigation, and its also showing that the packets are real, and not a network sensor error.
We've added this to argus-5.0.1 and we'll evolve it to be a real feature.
Beta Was this translation helpful? Give feedback.
All reactions