1 / 23

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

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.

lee-quinn
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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

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

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

  6. 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

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

  8. 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

  9. 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

  10. 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

  11. Attacks on the monitor • Overload • Crash • Subterfuge

  12. 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

  13. 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

  14. 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)

  15. 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

  16. 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

  17. 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

  18. Illustration

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

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

  21. 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

  22. 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

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

More Related