firewalls and intrusion detection systemsusers.ece.cmu.edu/~dbrumley/courses/18487-f13...firewalls...

Firewalls and Intrusion Detection Systems

David Brumleydbrumley@cmu.eduCarnegie Mellon University

IDS and Firewall Goals

Expressiveness: What kinds of policies can we write?

Effectiveness: How well does it detect attacks while avoiding false positives?

Efficiency: How many resources does it take, and how quickly does it decide?

Ease of use: How much training is necessary? Can a non-security expert use it?

Security: Can the system itself be attacked?

Transparency: How intrusive is it to use?

Firewalls

Dimensions:

1. Host vs. Network

2. Stateless vs. Stateful

3. Network Layer

Firewall Goals

Provide defense in depth by:

1. Blocking attacks against hosts and services

2. Control traffic between zones of trust

Logical Viewpoint

Inside OutsideFirewall

For each message m, either:

• Allow with or without modification

• Block by dropping or sending rejection notice

• Queue

Placement

Host-based Firewall

Network-Based Firewall

Host Firewall Outside

Firewall OutsideHost B

Host C

Host A

Features:• Faithful to local

configuration• Travels with you

Features:• Protect whole network• Can make decisions on

all of traffic (traffic-based anomaly)

Parameters

Types of Firewalls

1. Packet Filtering

2. Stateful Inspection

3. Application proxy

Policies

1. Default allow

2. Default deny

Recall: Protocol Stack

Application(e.g., SSL)

Transport (e.g., TCP, UDP)

Network (e.g., IP)

Link Layer(e.g., ethernet)

Physical

Application message - data

TCP data TCP data TCP data

TCP Header

dataTCPIP

dataTCPIPETH ETH

Link (Ethernet)

Header

Link (Ethernet)

Trailer

IP Header

Stateless Firewall

Filter by packet header fields

1. IP Field(e.g., src, dst)

2. Protocol (e.g., TCP, UDP, ...)

3. Flags(e.g., SYN, ACK)

Application

Transport

Network

Link Layer

Firewall

Outside Inside

Example: only allow incoming DNS packets to nameserver A.A.A.A.

Allow UDP port 53 to A.A.A.ADeny UDP port 53 allFail-safe good

practice

e.g., ipchains in Linux 2.2

Need to keep state

Inside Outside

Listening

Store SNc, SNs

SNCrandC

ANC0Syn

SYN/ACK:SNSrandS

ANSSNC

Established

ACK: SNSNC+1ANSNS

Example: TCP Handshake

Firewall

Desired Policy: Every SYN/ACK must have been preceded

by a SYN

Stateful Inspection Firewall

Added state (plus obligation to manage)

– Timeouts

– Size of table

Application

Transport

Network

Link Layer

Outside Inside

e.g., iptables in Linux 2.4

Stateful More Expressive

Inside Outside

Listening

Store SNc, SNs

SNCrandC

ANC0Syn

SYN/ACK:SNSrandS

ANSSNC

Established

ACK: SNSNC+1ANSNS

Example: TCP Handshake

Firewall

Record SNc in table

Verify ANs in table

State Holding Attack

Firewall AttackerInside

SynSyn

...1. SynFlood

2. Exhaust Resources

3. Sneak Packet

Assume stateful TCP policy

Fragmentation

Octet 1 Octet 2 Octet 3 Octet 4

Ver IHL TOS Total Length

ID 0DF

Frag ID

Frag 1 Frag 2 Frag 3

IP Hdr DF=0 MF=1 ID=0 Frag 1

IP Hdr DF=0 MF=1 ID=n Frag 2

IP Hdr DF=1 MF=0 ID=2n Frag 3

say n bytes

DF : Don’t fragment (0 = OK, 1 = Don’t)MF: More fragements(0 = Last, 1 = More)Frag ID = Octet number

Reassembly

IP Hdr DF=0 MF=1 ID=0 Frag 1

IP Hdr DF=0 MF=1 ID=n Frag 2

IP Hdr DF=1 MF=0 ID=2n Frag 3

0 Byte n Byte 2n

Octet 1 Octet 2 Octet 3 Octet 4

Source Port Destination Port

Sequence Number

...DF=

1MF=1 ID=0 ...

1234(src port)

80(dst port)

...Packet 1

Overlapping Fragment Attack

...DF=

1MF=1 ID=2 ... 22 ...Packet 2

1234 8022

Assume Firewall Policy: Incoming Port 80 (HTTP) Incoming Port 22 (SSH)

Bypass policyTCP Hdr(Data!)

Stateful Firewalls

• More expressive

• State-holding attack

• Mismatch between firewalls understanding of protocol and protected hosts

Application Firewall

Check protocol messages directly

Examples:

– SMTP virus scanner

– Proxies

– Application-level callbacks

Application

Transport

Network

Link Layer

Outside Inside

Firewall Placement

Demilitarized Zone (DMZ)

Inside OutsideFirewall

Dual Firewall

Inside OutsideHubDMZ

InteriorFirewall

ExteriorFirewall

Design Utilities

Solsoft

Securify

References

Elizabeth D. Zwicky

Simon Cooper

D. Brent Chapman

William R Cheswick

Steven M Bellovin

Aviel D Rubin

Intrusion Detection and PrevetionSystems

Logical Viewpoint

Inside OutsideIDS/IPS

For each message m, either:

• Report m (IPS: drop or log)

• Allow m

• Queue

Overview

• Approach: Policy vs Anomaly

• Location: Network vs. Host

• Action: Detect vs. Prevent

Policy-Based IDS

Use pre-determined rules to detect attacks

Examples: Regular expressions (snort), Cryptographic hash (tripwire, snort)

Detect any fragments less than 256 bytesalert tcp any any -> any any (minfrag: 256; msg:

"Tiny fragments detected, possible hostile activity";)Detect IMAP buffer overflowalert tcp any any -> 192.168.1.0/24 143 (

content: "|90C8 C0FF FFFF|/bin/sh"; msg: "IMAP buffer overflow!”;)

Example Snort rules

Modeling System Calls [wagner&dean 2001]

Entry(f)Entry(g)

Exit(f)Exit(g)

open()

close()

exit()

getuid() geteuid()

f(int x) {

if(x){ getuid() } else{ geteuid();}

fd = open("foo", O_RDONLY);

f(0); close(fd); f(1);

exit(0);

Execution inconsistent with automata indicates attack

Anomaly Detection

Distribution of “normal” events

New Event

Attack

Example: Working Sets

Days 1 to 300

reddit xkcd

slashdot

working setof hosts

Day 300

outside working set

reddit xkcd

slashdot

fark18487

Anomaly Detection

• Does not require pre-determining policy (an “unknown” threat)

• Requires attacks are not strongly related to known traffic

• Learning distributions is hard

Automatically Inferring the Evolution of Malicious Activity on the Internet

David BrumleyCarnegie Mellon University

Shobha VenkataramanAT&T Research

Oliver SpatscheckAT&T Research

Subhabrata SenAT&T Research

<ip1,+> <ip2,+> <ip3,+> <ip4,->

Tier 1

Spam Haven

Labeled IP’s from spam assassin, IDS logs, etc.

Evil is constantly on the move

Goal:Characterize regions

changing from bad to good (Δ-good) or

good to bad (Δ-bad)

Research Questions

Given a sequence of labeled IP’s

1. Can we identify the specific regions on the Internet that have changed in malice?

2. Are there regions on the Internet that change their malicious activity more frequently than others?

Spam Haven

Tier 1

Tier 2

Per-IP often not interesting

... DSL CORP

Challenges

1. Infer the right granularity

Previous work:Fixed granularity

Per-IPGranularity

(e.g., Spamcop)

Spam Haven

Tier 1

Tier 2

... DSL CORP

BGPgranularity

(e.g., Network-Aware clusters [KW’00])

Challenges

Previous work:Fixed granularity

Spam Haven

Tier 1

Tier 2

Coarse granularity

... DSL CORP

Challenges

EE CORP

Idea:Infer granularity

Medium granularity

Well-managed network: fine

granularity

Spam Haven

Tier 1

Tier 2

... DSL SMTP

Challenges

2. We need onlinealgorithms

fixed-memory device high-speed link

Research Questions

Given a sequence of labeled IP’s

1. Can we identify the specific regions on the Internet that have changed in malice?

2. Are there regions on the Internet that change their malicious activity more frequently than others?

Δ-Change

Δ-Motion

We Present

Background

1. IP Prefix trees

2. TrackIPTree Algorithm

Spam Haven

Tier 1

Tier 2

... DSL CORP

1.2.3.4/32

8.1.0.0/16

IP Prefixes:i/d denotes all IP addresses

i covered by first d bits

Ex: 8.1.0.0-8.1.255.255

Ex: 1 host (all bits)

OneHost

WholeNet0.0.0.0/0

0.0.0.0/1 128.0.0.0/1

128.0.0.0/2 192.0.0.0/20.0.0.0/264.0.0.0.0/

An IP prefix tree is formed by masking each bit of an IP address.0.0.0.0/32 0.0.0.1/32

0.0.0.0/31

128.0.0.0/3 160.0.0.0/3

128.0.0.0/4 152.0.0.0/4

0.0.0.0/0

0.0.0.0/1 128.0.0.0/1

0.0.0.0/264.0.0.0.0/

2128.0.0.0/2 192.0.0.0/2

A k-IPTree Classifier [VBSSS’09]

is an IP tree with at most k-leaves, each leaf labeled with

good (“+) or bad (“-”).

128.0.0.0/3 160.0.0.0/3

128.0.0.0/4 152.0.0.0/4

0.0.0.0/32 0.0.0.1/32

0.0.0.0/31

6-IPTree

Ex: 64.1.1.1 is bad

Ex: 1.1.1.1 is good

-In: stream of labeled IPs

... <ip4,+> <ip3,+> <ip2,+> <ip1,->

TrackIPTree Algorithm [VBSSS’09]

Out: k-IPTree

TrackIPTree

Δ-Change Algorithm

1. Approach

2. What doesn’t work

3. Intuition

4. Our algorithm

Goal: identify online the specific regions on the Internet that have changed in malice.

T1 forepoch 1

T2 forepoch 2

Δ-Bad: A change from good to bad

Δ-Good: A change from bad to good

Epoch 1 IP stream s1 Epoch 2 IP stream s2 ....

T1 forepoch 1

T2 forepoch 2

False positive: Misreporting that a

change occurred

False Negative: Missing a real change

Idea: divide time into epochs and diff• Use TrackIPTree on labeled IP stream s1 to learn T1

• Use TrackIPTree on labeled IP stream s2 to learn T2

• Diff T1 and T2 to find Δ-Good and Δ-Bad

T1 forepoch 1

T2 for epoch 2

Different Granularities!

Δ-Change Algorithm Main Idea: Use classification errors between Ti-1 and Ti

to infer Δ-Good and Δ-Bad

Ti-2 Ti-1 TiTrackIPTree TrackIPTree

Si-1 Si

Ann. with class. error

Told,i-1

Ann. with class. error

Told,i

compare (weighted)

classificationerror

(note both based on same tree)

Δ-Good and Δ-Bad

Δ-Change Algorithm

Comparing (Weighted) Classification Error

/16IPs: 200Acc: 40%

IPs: 150Acc: 90%

IPs: 110Acc: 95%

Told,i-1

IPs: 40Acc: 80%

IPs: 50Acc: 30%

/16IPs: 170Acc: 13%

IPs: 100Acc: 10%

IPs: 80Acc: 5%

Told,i

IPs: 20Acc: 20%

IPs: 70Acc: 20%

Δ-Change Somewhere

/16IPs: 200Acc: 40%

IPs: 150Acc: 90%

IPs: 110Acc: 95%

Told,i-1

IPs: 40Acc: 80%

IPs: 50Acc: 30%

/16IPs: 170Acc: 13%

IPs: 100Acc: 10%

IPs: 80Acc: 5%

Told,i

IPs: 20Acc: 20%

IPs: 70Acc: 20%

Insufficient Change

/16IPs: 200Acc: 40%

IPs: 150Acc: 90%

IPs: 110Acc: 95%

Told,i-1

IPs: 40Acc: 80%

IPs: 50Acc: 30%

/16IPs: 170Acc: 13%

IPs: 100Acc: 10%

IPs: 80Acc: 5%

Told,i

IPs: 20Acc: 20%

IPs: 70Acc: 20%

Insufficient Traffic

/16IPs: 200Acc: 40%

IPs: 150Acc: 90%

IPs: 110Acc: 95%

Told,i-1

IPs: 40Acc: 80%

IPs: 50Acc: 30%

/16IPs: 170Acc: 13%

IPs: 100Acc: 10%

IPs: 80Acc: 5%

Told,i

IPs: 20Acc: 20%

IPs: 70Acc: 20%

Δ-Change Localized

Evaluation

1. What are the performance characteristics?

2. Are we better than previous work?

3. Do we find cool things?

Performance

In our experiments, we :

– let k=100,000 (k-IPTree size)

– processed 30-35 million IPs (one day’s traffic)

– using a 2.4 Ghz Processor

Identified Δ-Good and Δ-Bad in <22 min using <3MB memory

changes. Our experiments were run on a on a 2.4GHz

Sparc64-VI core. Our current (unoptimized) implementa-

tion takes 20-22 minutes to process a day’s trace (around

30-35 million IP addresses) and requires less than 2-3 MB

of memory storage.

We note that the ground truth in our data provides labels

for the individual IP addresses, but does not tell us the pre-

fixes that have changed. Thus, our ground truth allows us to

confirm that the learned IPTree has high accuracy, but we

cannot directly measure false positive rate and false nega-

tive rate of the change-detection algorithms. Thus, our ex-

perimental results instead demonstrate that our algorithm

can find small changes in prefix behaviour very early on real

data, and can do so substantially better than competing ap-

proaches. Our operators were previously unaware of most

of these ∆ -change prefixes, and as a consequence, our sum-

marization makes it easy for operators to both note changes

in behaviour of specific entities, as well as observe trends in

malicious activity. 7

4.1 Comparisons with Alternate ApproachesWe first compare ∆ -Change with previous approaches

and direct extensions to previous work. We compare two

different possible alternate approaches with ∆ -Change: (1)

using a fixed set of network-based prefixes (i.e., network-

aware clusters, see Sec. 2.2) instead of a customized IP-

Tree, (2) directly differencing the IPTrees instead of using

∆ -Change. We focus here on only spam data for space rea-

Network-aware Clusters. As we described in Sec-

tion 3.2, our change-detection approach has no false pos-

itives – every change we find will indeed be a change in

the input data stream. Thus, we only need to demonstrate

that ∆ -Change finds substantially more ∆ -changes than

network-aware clusters (i.e., has a lower false negative rate),

and therefore, is superior at summarizing changes in mali-

cious activity to the appropriate prefixes for operator atten-

We follow the methodology of [29] for labeling the

prefixes of the network-aware clusters optimally (i.e., we

choose the labeling that minimizes errors), so that we can

test the best possible performance of network-aware clus-

ters against ∆ -Change. We do this allowing the network-

aware clusters multiple passes over the IP addresses (even

though ∆ -Change is allowed only a single pass), as detailed

in [29]. We then use these clusters in place of the learned

IPTree in our change-detection algorithms.

We first compare ∆ -change prefixes identified by the

network-aware clustering and ∆ -Change. This compari-

son cannot be directly on the prefixes output by the two ap-

7As discussed in Section 1, our evaluation focuses exclusively on

changes in prefix behaviour, since prior work [28, 29] already finds per-

sistent malicious behaviour.

15 20 25 30 350

Interval in Days

f D−

D−Change

Network−aware

(a) ∆ -change Prefixes

15 20 25 30 3510

Interval in Days

in D−

D−Change

Network−aware

(b) IPs in ∆ -change prefixes

Figure 11. Comparing ∆ -Change algorithm with

network-aware clusters on the spam data: ∆ -Change

always finds more prefixes and covers more IPs

proaches, as slightly different prefixes may reflect the same

underlying change in the data stream, e.g., network-aware

clusters might identify a /24 while ∆ -Change identifies a

/25. In order to account for such differences, we group

together prefixes into distinct subtrees, and match a group

from the network-aware clustering to the appropriate group

from ∆ -Change if at least 50% of the volume of changed

IPs in network-aware clustering was accounted for in ∆ -

Change. In our results, network-aware clustering identified

no∆ -change prefixes that were not identified by ∆ -Change;

otherwise, we would have do the reverse matching as well.

Furthermore, this is what allows us to compare the num-

ber of ∆ -changes that were identified by both algorithms,

otherwise we would not be able to make this comparison.

Fig. 11(a) shows the results of our comparison for 37

days. Network-aware clustering typically finds only a small

fraction of the ∆ -change prefixes discovered by ∆ -Change,

ranging from 10% − 50%. On average, ∆ -Change finds

over 2.5 times as many∆ -change prefixes as network-aware

clusters. We compare also the number of IPs in ∆ -change

prefixes identified by the network-aware clustering and ∆ -

Change in Fig. 11(b). The ∆ -change prefixes discovered

by ∆ -Change typically account for a factor of 3-5× IP ad-

dresses as those discovered by the network-aware cluster-

ing. It indicates that network-aware clustering does not dis-

cover many changes that involve a substantial volume of the

input data. On many days, especially on days with changes,

the fraction of IP addresses not identified by network-aware

clusters, however, is still smaller than the fraction of pre-

fixes that it does not identify. This indicates that network-

aware clustering identifies the larger, coarser changes, but

misses the fine-grained changes.

Network-aware clusters perform so poorly because the

prefix granularity required to identify ∆ -changes typically

does not appear at all in routing tables. Indeed, as our anal-

ysis in Section 4.2 shows, a large number of ∆ -change pre-

fixes come from hosting providers, many of which do not

even appear in BGP prefix tables.

Possible Differencing of IPTrees. We now show that

the possible differencing approach described in Section 2.2

2.5x as many changes on average!

How do we compare to network-aware clusters?(By Prefix)

Grum botnet takedown

Botnets22.1 and 28.6 thousand new

DNSChanger bots appeared

38.6 thousand new Confickerand Sality bots

Caveats and Future Work

“For any distribution on which an ML algorithm works well, there is another on which is works poorly.”

– The “No Free Lunch” Theorem

Our algorithm is efficient and works well in practice.

....but a very powerful adversarycould fool it into having many false negatives. A formal characterizationis future work.

Detection Theory

Base Rate, fallacies, and detection systems

Let Ω be the set of all possible events. For example:

• Audit records produced on a host• Network packets seen

Set of intrusion events I

Intrusion Rate:

Example: IDS Received 1,000,000 packets. 20 of them corresponded to an intrusion.The intrusion rate Pr[I] is:Pr[I] = 20/1,000,000 = .00002

Set of alerts A

Alert Rate:

Defn: Sound

Defn: Complete

Defn: False PositiveDefn: False Negative

Defn: True Positive

Defn: True Negative

Defn: Detection rate

Think of the detection rate as the set ofintrusions raising an alert normalized by the set of all intrusions.

Think of the Bayesian detection rate as the set of intrusions raising an alert normalized by the set of all alerts. (vs. detection ratewhich normalizes on intrusions.)

Defn: Bayesian Detection rateCrux of IDS usefulness!

About 18% of all alerts are false positives!

Challenge

We’re often given the detection rate and know the intrusion rate, and want to calculate the Bayesian detection rate

– 99% accurate medical test

– 99% accurate IDS

– 99% accurate test for deception

– ...

Proof:

Calculating Bayesian Detection Rate

So to calculate the Bayesian detection rate:

One way is to compute:

Example

• 1,000 people in the city

• 1 is a terrorists, and we have their pictures. Thus the base rate of terrorists is 1/1000

• Suppose we have a new terrorist facial recognition system that is 99% accurate.– 99/100 times when

someone is a terrorist there is an alarm

– For every 100 good guys, the alarm only goes off once.

• An alarm went off. Is the suspect really a terrorist?

(this times 10)

Example

Answer: The facial recognition system is 99% accurate. That means there is only a 1% chance the guy is not the terrorist.

(this times 10)

Formalization

• 1 is terrorists, and we have their pictures. Thus the base rate of terrorists is 1/1000. P[T] = 0.001

• 99/100 times when someone is a terrorist there is an alarm.P[A|T] = .99

• For every 100 good guys, the alarm only goes off once.P[A | not T] = .01

• Want to know P[T|A]

(this times 10)

• 1 is terrorists, and we have their pictures. Thus the base rate of terrorists is 1/1000. P[T] = 0.001

• 99/100 times when someone is a terrorist there is an alarm.P[A|T] = .99

• For every 100 good guys, the alarm only goes off once.P[A | not T] = .01

• Want to know P[T|A]

(this times 10)

Intuition: Given 999 good guys, we have 999*.01 ≈ 9-10 false alarms

False alarms

Guesses?

Unknown

Recall to get Pr[A]

Proof:

..and to get Pr[A∩ I]

Proof:

For IDS

Let – I be an intrusion,

A an alert from the IDS

– 1,000,000 msgsper day processed

– 2 attacks per day

– 10 attacks per message

False positives

True positives

70% detection requires

FP < 1/100,000

80% detection generates 40% FP

From Axelsson, RAID 99

Conclusion

• Firewalls

– 3 types: Packet filtering, Stateful, and Application

– Placement and DMZ

• IDS

– Anomaly vs. policy-based detection

• Detection theory

– Base rate fallacy

Questions?

Thought

Overview

• Approach: Policy vs Anomaly

• Location: Network vs. Host

• Action: Detect vs. Prevent

Type Example

Host, Rule, IDS Tripwire

Host, Rule, IPS Personal Firewall

Net, Rule, IDS Snort

Net, Rule, IPS Network firewall

Host, Anomaly, IDS System call monitoring

Host, Anomaly, IPS NX Bit?

Net, Anomaly, IDS Working set of connections

Net, Anomaly, IPS

firewalls and intrusion detection systemsusers.ece.cmu.edu/~dbrumley/courses/18487-f13...firewalls...

Documents

firewalls & network security with intrusion detection...

firewalls and intrusion detection

firewalls, tunnels, and network intrusion detection

firewalls & network security with intrusion detection and...

firewalls & network security with intrusion detection...

firewalls, intrusion detection, traffic shapers, and filters

firewalls and intrusion detection systems vyas sekar...

evading ids, firewalls, and honeypots… · module 17 -...

firewalls & network security with intrusion detection and...

firewalls & network security with intrusion detection and...

computer security: principles and practice chapter 9 –...

lab 8: firewalls & intrusion detec6on systems

firewalls and intrusion detection john mitchell cs 155may...

firewalls & intrusion detection systems

denial of service, firewalls, and intrusion detection

network defense tools: firewalls, traffic shapers, and...

firewalls and intrusion detection systems -...

firewalls, ids and ips - temple mis...firewalls, ids and ips...

trusted systems, firewalls, intrusion detection systems

firewalls and intrusion detection systems david brumley...