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

Bro: A System for Detecting Network Intruders in Real-Time

Presented by Zachary SchneirovCS 395-0

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