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

InternetInternetInternetInternet

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

11

NIDSNIDSAttackAttackAttackAttack

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

13

PacketAcquisition

Preprocessing

DecodeFlow management

Reassembly

MatchSuccess

Match Failure(Innocent Flow)

Multi-string Pattern

MatchingEvaluation Failure(Innocent Flow)

EvaluationSuccess

Rule Options Evaluation

Output

MaliciousFlow

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/")

Bottlenecks

* PCRE: Perl Compatible Regular Expression

Aho-Corasick String Matching

Most widely-used string matching algorithm Ensures to have O(n) for scanning n-byte

packet sDictionary matching algorithm

Matches all patterns simultaneously Deterministic finite automata (DFA)

14

Example of an Aho-Corasick DFA

String patterns = {he, his, she, hers}

15From http://www.cs.uku.fi/~kilpelai/BSA05/lectures/slides04.pdf

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

tableTypical 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 ManagementPer-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 overheadHow many concurrent flows are supported?How much data is being scanned?

17

18

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?

19

Research Issues in IDS/IPS

Towards higher performance Different matching algorithms for faster execution Parallelism is the key: multicore, manycore

Efficient memory accessTCAM, 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 matchingPerformance 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?

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

21

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

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 scriptsAvoid 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, addrString: 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 intrusionSend more flows – use better hardware?Trigger more eventsTrigger events that lead to logging/recording to

disks Periodic net_states_update: # of dropped

packets27

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 defendNo trace and the attacks can be quite subtleE.g., attacker sends text with an embedded NULLE.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 retransmissionMakes 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 scriptSteep learning curve

Need to learn the domain-specific languagePerformance

Originally single threaded, but multi-threaded version is out

Script as a event handler 30