bro: a system for detecting network intruders in real-time
DESCRIPTION
Bro: A System for Detecting Network Intruders in Real-Time. Presented by Zachary Schneirov CS 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. - PowerPoint PPT PresentationTRANSCRIPT
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
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
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
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