Expand description
A framework for developing high speed network traffic analysis applications that run on commodity hardware.
Iris provides a high-level interface for analyzing five-tuple-defined network connections, including reassembled payloads and parsed application-layer sessions, from an in-network vantage point.
Iris developers interact with network connections by defining subscriptions. Each subscription consists of one or more data types (data to analyze), a filter (traffic of interest), and a callback (analysis code). Each application can consist of one or more subscriptions.
For simple use-cases, Iris provides built-in data types in the Iris (built-in) data types crate and a Wireshark-like filter DSL documented in the Iris compiler crate. For example, only a few lines of code are needed to capture HTTP requests with a specific user agent:
#[callback("http.user-agent contains 'Mozilla'")]
fn log_http(http: &HttpRequest, ft: &FiveTuple) {
log::info!("{}: {}", ft.src_subnet(24), http);
}For more complex use-cases, Iris developers can define custom filters and data types, as well as stateful and streaming callbacks.
Iris processes packets in a connection as they arrive, advancing connections through a set
of protocol state machines. Developers can hook into states and state transitions to extract
data, perform additional computation, or attach state for later use.
The currently-supported states are documented in [crate::conntrack::conn_state::StateTransition].
Developers indicate that a struct, type, or function should hook into Iris using the macros exported by
the Iris compiler crate.
For example, we can define a data type that extracts features from the body of a connection:
#[datatype]
struct FeatureChunk { /* ... */}
impl FeatureChunk {
fn new(first_pkt: &L4Pdu) -> Self { /* ... */}
#[datatype_fn("FeatureChunk,InL4Conn")]
fn update(&mut self, pdu: &L4Pdu) {
/* ... */
}
}Iris compiles user-defined subscriptions with framework functionality into a connection processing and analysis pipeline, as described in the paper. When compiling an application, Iris prints out the “action trees” (mapping from filter predicates to incremental processing steps) that it will apply at each state transition. We recommend using this as a sanity check for application behavior.
Re-exports§
pub use self::conntrack::conn_id::ConnId;pub use self::conntrack::conn_id::FiveTuple;pub use self::conntrack::pdu::L4Pdu;pub use self::conntrack::StateTransition;pub use self::conntrack::StateTxData;pub use self::lcore::CoreId;pub use self::memory::mbuf::Mbuf;
Modules§
- config
- Configuration options.
- conntrack
- Per-core connection state management.
- filter
- Utilities for compile-time filter generation and subscription handling.
- lcore
- Utilities for managing and monitoring Iris cores.
- memory
- Packet memory buffer management.
- multicore
- Multicore processing management.
- protocols
- Protocol parsing and manipulation.
- stats
- utils
- Utility modules.
Structs§
- Runtime
- The Iris runtime.
Functions§
- rte_
lcore_ ⚠id - Returns the application thread ID of the execution unit.
- rte_
rdtsc ⚠ - Reads the timestamp counter (TSC) register.