Transcript fw-ids - SysSec (System Security) Lab

Defending Against Network Intrusion
(Firewalls, Intrusion Detection Systems)
IS511
Firewalls
2
Firewalls
 A firewall is a system that typically sits at some point of
connectivity between a site it protects and the rest of the
network.
 It is usually implemented as an “appliance” or part of a
router, although a “personal firewall” may be
implemented on an end user machine.
 Firewall-based security depends on the firewall being the
only connectivity to the site from outside; there should
be no way to bypass the firewall via other gateways,
wireless connections, or dial-up connections.
Firewalls
A firewall filters packets flowing
between a site and the rest of the
Internet
Firewalls
 Divides a network into a “more-trusted zone” internal to
firewall, and a “less-trusted zone” external to firewall.
 This is useful if you do not want external users to access
a particular host or service within your site.
 Firewalls may be used to create multiple zones of trust,
such as a hierarchy of increasingly trusted zones.
 A common arrangement involves three zones of trust:
the internal network; the DMZ (“demilitarized zone”);
and the rest of the Internet.
First Generation: Packet Filter
 Developed by Bill Cheswick and Steve Bellovin
 Decision typically based on five tuples of a packet
 Source and destination IP addresses
 Source and destination port numbers
 Protocol (TCP or UDP)
 They are configured with a table of addresses that
characterize the packets they will, and will not, forward.
 Also called L3 firewall
Second Generation: Stateful Firewall
 Also called stateful filters or L4 firewall
 Packets filters were vulnerable to spoofing attacks
 Manages state per connection
 Five tuples, TCP state, and sequence numbers
 Only relevant packets that belong to existing connections or new
connections that are configured to be allowed are forwarded
 Any irrelevant packets will be dropped
 Examples:
 An internal IP s connects to an external IP x, all packets that
belong to this connection are allowed
 IP s connects to FTP port (21) of IP x, and FW remembers the
incoming port ‘d’ requested by s
Third Generation: Application Firewall
 Extension to stateful firewalls, L7 firewall
 Understand application semantics
 Web application firewalls (HTTP)
 FTP and DNS
 Monitor if application protocols are being abused
 DNS tunneling?
 Filter any known attacks
 The most heavyweight firewall
 Typically implemented as proxies
Limitations of Firewalls
 Perimeter defense
 Cannot detect internal misuse
 Sometimes, easy to bypass firewalls
 Block only well-known ports
 Allow all HTTP traffic
 Attacks on firewalls
 DDoS attacks – stateful, application-level firewalls
9
Intrusion Detection System
10
Network Intrusion Detection Systems (NIDS)
 Detect known malicious activities

Port scans, SQL injections, buffer overflows, etc.
 Deep packet inspection

Detect malicious signatures (rules) in each packet
 Desirable features


High performance (> 10Gbps) with precision
Easy maintenance
 Frequent ruleset updates
NIDS
Attack
Internet
11
Signature Matching vs. Anomaly Detection
 Signature-based IDS
 Detect known signatures
 A list of attack strings and/or regular expressions
 Snort, Suricata, etc.
 Anomaly detection
 Different from normal behavior?
 Ports, bandwidth, protocols, etc.


Probabilistic approach: false positives
Snort, Bro, etc.
12
Typical Signature-based NIDS Architecture
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80
(msg:“possible attack attempt BACKDOOR optix runtime detection"; content:"/whitepages/page_me/100.html";
pcre:"/body=\x2521\x2521\x2521Optix\s+Pro\s+v\d+\x252E\d+\S+sErver\s+Online\x2521\x2521\x2521/")
Packet
Acquisition
Preprocessing
Decode
Flow management
Reassembly
Match
Multi-string
Pattern Matching Success
Match Failure
(Innocent Flow)
Rule Options
Evaluation
Evaluation Failure
(Innocent Flow)
Evaluation
Success
Output
Malicious
Flow
Bottlenecks
* PCRE: Perl Compatible Regular Expression
13
Aho-Corasick String Matching
 Most widely-used string matching algorithm
 Ensures to have O(n) for scanning n-byte packet s
 Dictionary matching algorithm
 Matches all patterns simultaneously
 Deterministic finite automata (DFA)
14
Example of an Aho-Corasick DFA
 String patterns = {he, his, she, hers}
From http://www.cs.uku.fi/~kilpelai/BSA05/lectures/slides04.pdf
15
Perl-Compatible Regular Expression
 Extended regular expression (RE)
 characters, ., ?, *, +, …, etc.
 Mostly regular language
 Each can be converted to DFA
 Merging multiple REs is difficult
 State explosion: requires huge memory for DFA table
 Typical IDS employs two stages
 Aho-Corasick multi-string matching
 Run PCRE if the first stage is a hit
 Many works that optimize pattern matching
 XFA, D2FA, HybridFA, etc.
16
Flow Management
 Per-packet pattern matching
 Finds the pattern inside one packet
 How to evade such detection?
 Flow management
 Pattern matching on reassembled TCP segments
 Complexity: TCP state diagram, IP fragments,
packets delivered out of order, malicious (?)
retransmission, etc.
 Typical source of performance overhead
 How many concurrent flows are supported?
 How much data is being scanned?
17
Challenges in IDS/IPS
 Requires high performance


Match against thousands of patterns in real time
10+G network interfaces (even at network edge)
 Implementation challenges
 Vulnerabilities in IDS/IPS implementation
 Every corner of network protocol
 Ruleset update
 Attacks are localized – attack patterns in Korea different from
those in the U.S.
 Who’s building the ruleset?
18
Research Issues in IDS/IPS
 Towards higher performance
 Different matching algorithms for faster execution
 Parallelism is the key: multicore, manycore
 Efficient memory access
 TCAM, GPU, FPGA, etc.

Performance and flexibility
 How to evaluate IDS/IPS?
 How to compare IDS A and B?
 A optimized at flow management while B optimized at pattern matching

Develop a standard benchmarking tool?
 Performance against pattern matching
 Performance against defending against active attacks
19
Limitations of IDS/IPS
 Shares the same problems with firewalls
 Mostly perimeter defense
 Screen against only known attack patterns
 How to react to unknown attacks? (anomaly detection)
 IDS can be extended to monitor internal traffic
 Advanced Persistent Attack (APT)?
 Distributed systems that monitor N vantage points
 Collect the traffic and infer relationship?
 Or is there a simpler way?
20
Bro: A System for Detecting
Network Intruders in Real-Time
21
Bro IDS
 Supports signature-based & anomaly detection
 Started as a research system
 The first paper published in 1998
 Being actively developed
 http://www.bro.org/
 Current version: 2.2 (release Nov, 2013)
22
Goals of Bro
 High-speed, large volume monitoring
 At that time, FDDI (100Mbps) links , 20 GB/day
 No packet filter drops
 Fast enough not to overrun the buffer
 Attackers can attack the monitor itself
 Run-time notification
 Should take low delay in attack detection
 Separate policy from mechanism
 Well-known system design principle
 Allows simplicity and flexibility
 Extensible
 Avoid simple mistakes
 The monitor will be attacked – source code revealed
23
Bro Structure
 libpcap – packet capture library (tcpdump)
 Abstracts the links, improves portability
 Can employ BPF to pre-screen traffic
 Event Engine
 Performs integrity checks on the packet headers
 TCP flow events – connection_attempt, connection_established,
connection_rejected, connection_finished
 UDP flow events – udp_request, udp_reply
 Policy Script Interpreter
 Process all events including timer events
 Scripts in Bro language as event handler
24
Bro Language
 For policy scripts
 Avoid simple mistakes as guiding principle
 Scripts should work as expected
 Strongly-typed language: easily catch errors
 Directly deal with hostnames, IP addresses, port
numbers, etc.
25
Bro Language
 Data types
 Atomic types: bool, int, count, double, string, time, port,
addr
 String: length + byte array. Why?

Aggregate types: record, table, set, file, (list, pattern)
 Operators
 C-like operators (record fields: accessed with $)
 “in”, “!in”: e.g., 23/tcp in sensitive_services
 Variables
 local vs. global, const
 Statements
26
Attacks on the monitor
 Assumption: Bro source code is public but
per-site policy script is not exposed
 Overload attacks
 Drives the monitor to overload and attempts a
network intrusion
 Send more flows – use better hardware?
 Trigger more events
 Trigger events that lead to logging/recording to disks

Periodic net_states_update: # of dropped packets
27
Attacks on the monitor
 Crash attacks
 Attackers attempt to crash the monitor and proceeds
with an intrusion
 Uses vulnerability at the source code level
 Careful coding and testing?
 Watchdog – periodically check if the monitor is stuck
 Script that runs Bro logs unduly exit event
 And run tcpdump
28
Attacks on the monitor
 Subterfuge attacks
 Attackers attempt to mislead the monitor about the meaning of
the traffic it analyzes
 More difficult to defend
 No trace and the attacks can be quite subtle
 E.g., attacker sends text with an embedded NULL
 E.g., attacker sends IP fragments to elude monitors that fail to
reassemble IP fragments

Attacker sends an innocent packet first, followed by
retransmission
 “USER nice” followed by “USER root” as retransmission
 Makes sure that the first packet is dropped before reaching the
destination – (e.g., incorrect TCP checksum, small TTL, ec.)
 Defense: check whether retransmission packets have the same
payload as before
29
Pros and Cons of Bro
 Great flexibility
 Can automate a series of operations in responding
to a seemingly-malicious attempts
 Policy script
 Steep learning curve
 Need to learn the domain-specific language
 Performance
 Originally single threaded, but multi-threaded
version is out
 Script as a event handler
30