Bro: A System for Detecting Network Intruders in Real-Time Presented by Zachary Schneirov CS Professor Yan Chen

What is Bro? Bro is a stand-alone system that observes network traffic directly to detect intruders Emphasizes monitoring over blocking

Goals High speed passive network monitoring: 100Mbps at most Real time notifications Division between policy and mechanism Extensibility Assumption that the monitor will be attacked Should be difficult for users to make mistakes

System Structure/Flow Network -> Packet Filter -> Event Engine -> Policy Script Interpreter -> Real time notifications, other actions

As abstraction level increases, more processing can be performed at each level

Packet filter Uses libpcap for platform independence With BPF, packet discarding can occur in kernel space Captures only headers for packets with SYN, FIN, and RST flags Captures entire packet otherwise

Event engine Tracks TCP connection states Upon receiving an initial SYN Generates the following events: –SYN-ACK: connection_established –RST: connection_rejected –FIN: connection_finished For UDP, udp_request and udp_reply are generated based on source and dest. addresses

Policy Scripts Grabs events asynchronously from a FIFO queue Executes policy scripts in a special Bro language Calls predefined handlers in the script for different events generated

Event actions Scripts can generate new events from an event handler Log notifications with syslog Write packet traces to disk Or modify the internal state for further processing

Bro Language Designed to “avoid simple mistakes” Strongly typed Variable references always valid at runtime Domain specific: variable types include port and addr Does not support looping constructs to ensure constant time processing

Attacks on the monitor Overload Crash Subterfuge

Overload attack Overload the monitor until it drops packets Accomplished by indiscriminate flooding Or by repeatedly triggering events that require CPU or disk processing Attacker then conducts intrusion while packets are being dropped

Overloading defenses Attacker will not always know the full power and typical load of the monitor Attacker will not know the exact policy conditions and actions Event engine can also generate events in the case of dropped packets

Crashing attack Crash the monitor and attempt intrusion unnoticed Find a flaw to trigger an immediate crash Or exhaust available memory and/or disk space (e.g. through connection states)

Crashing defenses Attacker does not know the size of the disk Cannot assume that the monitor will not generate alerts after the disk is full Monitor process uses UNIX alarm signals to periodically test availability

Subterfuge Rely on unnoticed flaws in the system that create a difference between what the monitor sees and what an end-host sees Trick monitor into discarding packets with bad checksums Use a TTL that takes packets past monitoring point but not to end-host Set the MTU such that it passes through monitor but is rejected downstream

A sample attack Send packets with a smaller TTL containing benign keywords Send packets with a TTL that reach the host containing the actual malicious commands Give both sets the same TCP sequence numbers Monitor cannot decide which version to accept

Illustration

Subterfuge Defenses Generate an error upon receiving “retransmitted” packets with different payloads “Bifurcating analysis” –Spawn multiple threads for each possible interpretation of data

Application-specific processing Bro supports finger, FTP, portmapper, telnet, and rlogin protocols Extensible architecture allows easy addition of other protocols

Port scan detection Uses predefined thresholds for the ratio of attempted connections of each source address to unique destination peers and ports No restrictions on port or address order But generates false positives due to passive connections to FTP servers

Real world experiences Broken TCP implementations generate false positives; difficult to differentiate from subterfuge attacks Many unbalanced fragmented packets Incorrect application protocol implementations also cause problems

Future improvements Implement support for more applications Actively block bad connections Bifurcation analysis Sensors on end-hosts