Transcript Bro: A System for Detecting Network Intruders in Real-Time CS 395-0

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
• 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