Core Plugins

The Corsaro public release includes four Core Plugins which provide both useful trace analysis functionality, and also serve as a template for developing new plugins.

The four plugins are:

1. a Raw pcap filter
2. our FlowTuple packet aggregator
3. an implementation of Moore's RS DoS detection algorithm [3]
4. Smee - a port of the iatmon tool [2]

Raw pcap

The simplest plugin which ships with Corsaro is the pcap pass-through filter. It simply captures packets and writes them out to a file in pcap format.

If Corsaro is operating on existing traces files, the output file will be identical to the input (though potentially a different size due to compression). In testing we find that even using threaded IO for the gzip compression, the volume of data generated causes a bottle-neck in processing. As such, we strongly recommend against enabling the pcap plugin when processing existing trace files.

The pcap plugin becomes more useful when Corsaro is attached to a live interface. It allows Corsaro to simultaneously capture raw trace data (for archival and later analyis) and perform real-time analysis and aggregation with other plugins. As noted earlier, the gzip compression can cause a bottle-neck in processing when the thread writing the pcap data cannot clear the write buffer fast enough. This can be alleviated somewhat by tweaking the buffer size in libtrace.

This plugin provides a good starting point for developing a filter plugin, which uses some criteria to only save a subset of packets to a pcap file. For example, internally at CAIDA we have used a SIP filter plugin to extract all SIP packets from raw traces. While it would be possible to implement this using the BPF filter feature of the corsaro tool, implementing a filter as a plugin allows other plugins to continue to process the entire trace, thus reducing re-work.

FlowTuple

The FlowTuple plugin compresses a trace by counting the number of packets which share a common set of header fields. This is conceptually similar to a NetFlow report, but with a set of header fields specifically tailored to facilitate darknet data analysis.

We selected the fields for inclusion in the tuple based reviewing the types of analysis performed over the last decade using UCSD Network Telescope data. We found a combination of eight fields which would allow the majority of analysis to be carried out without needing to resort to full pcap traces.

The eight fields that the FlowTuple plugin aggregates packets based on are:

1. Source IP address
2. Destination IP Address
3. Source Port
4. Destination Port
5. Protocol
6. TTL
7. TCP Flags
8. IP Length

Note, if the Protocol value is 1 (ICMP), then the Source and Destination Port fields are used to represent the ICMP Type and Code fields, respectively.

The flows also have an extra implicit field, the class that the packets belong to. There are currently three possible classes:

1. Backscatter
2. ICMP Request
3. Other

These classes have been derived from the CAIDA crl_attack_flow software. The logic to classify a packet into a class is contained in the flowtuple_classify_packet function in the corsaro_flowtuple.c file.

The plugin maintains a table of flows for each class, and simply counts the number of packets that belong to each flow in a given interval. At the end of an interval, the plugin traverses each table and writes out a series of key-value pairs, where the key is the 8 fields and the value is the number of packets in the flow. The tables are then cleared and the process begins again for the next interval.

In the current implementation, the tables are sorted before being written out because we found with empirical testing that gzip compression was maximized by using the sort comparator found in corsaro_flowtuple_lt.

See the FlowTuple section of the File Formats page for information about the format of the output created by the FlowTuple plugin.

We also provide an efficient tool for re-aggregating the FlowTuple data based on a different time interval, a subset of key fields and/or a different value field. See cors-ft-aggregate for a more detailed description of the tool.

RS DoS

The RS DoS plugin uses heuristics described by Moore et al. in [3] to detect backscatter packets caused by Randomly Spoofed Denial of Service attacks, it then groups the backscatter by suspected attack victim and reports statistics about each attack.

In addition to keeping high-level statistics about the attack, the plugin also preserves a copy of the initial packet observed to be a part of the attack.

Todo:

describe the stats kept by this plugin and what they mean.

This plugin makes use of the plugin chaining feature described in Plugins to detect backscatter packets based on the classification performed by the FlowTuple plugin. As such, the RS DoS plugin requires the FlowTuple plugin to be enabled.

See RS DoS section of the File Formats page for information about the format of the output files written by the RS DoS plugin.

Smee

Unfortunately Smee is still under development and will not be officially included until the next release of Corsaro. Please contact corsa.nosp@m.ro-i.nosp@m.nfo@c.nosp@m.aida.nosp@m..org if you wish to help alpha test it, or simply use the iatmon tool.