SSL_IPsec

1
Defending Against Network Intrusion (Firewalls,
Intrusion Detection Systems) IS511
2
Firewalls
3
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.

4
Firewalls
A firewall filters packets flowing between a site
and the rest of the Internet
5
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.

6
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

7
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

8
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

9
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

10
Intrusion Detection System
11
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 (gt 10Gbps) with precision
• Easy maintenance
• Frequent ruleset updates

Attack
NIDS
Internet
12
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.

13
Typical Signature-based NIDS Architecture

alert tcp EXTERNAL_NET any -gt HTTP_SERVERS 80
(msgpossible attack attempt BACKDOOR optix
runtime detection" content"/whitepages/page_me/1
00.html" pcre"/body\x2521\x2521\x2521Optix\sPr
o\sv\d\x252E\d\SsErver\sOnline\x2521\x2521\x2
521/")
Match Success
Evaluation Success
Packet Acquisition
Multi-string Pattern Matching
Rule Options Evaluation
Output
Preprocessing
Decode Flow management Reassembly
Match Failure (Innocent Flow)
Evaluation Failure (Innocent Flow)
Malicious Flow
Bottlenecks
PCRE Perl Compatible Regular Expression
14
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)

15
Example of an Aho-Corasick DFA

• String patterns he, his, she, hers

From http//www.cs.uku.fi/kilpelai/BSA05/lectures
/slides04.pdf
16
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.

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

18
Challenges in IDS/IPS

• Requires high performance
• Match against thousands of patterns in real time
• 10G 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.
• Whos building the ruleset?

19
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

20
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?

21
Bro A System for Detecting Network Intruders in
Real-Time
22
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)

23
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

24
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

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

26
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

27
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

28
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

29
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

30
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