the science of firewall analysis

The Science of Firewall Analysis

Presented ByAthena Security

Secure by Analysis

25th April 2009

Contents

• Introduction to Firewall Concepts and Policy Analysis

• Firewall Complexity• Demo of Complexity Analysis• Firewall Rule Conflicts• Semantic Firewall Analysis• Semantic Analysis with Athena FirePAC• About Athena Security• Questions and Answers

Introduction To Firewall Concepts

• A firewall’s place in the network• Audit of firewalls• The OSI reference model• A firewall abstraction• Types of firewalls

From: http://www.netcraftsmen.net/welcher/papers/pix01.html

A Typical Network

Concepts:

• multi-homed device• firewall zones• DMZ• access paths• routing• direction of traffic• filtering• network address translation

Audit of Firewalls

• Firewall audits try to find out if the stated policy is the implemented policy.

• Firewall audits determine if network best practices are being followed.

• Firewall audits assess network risk.

Are RFC 1918 and reserved IP addresses blocked as sources?

Are insecure network services like HTTP, FTP, Telnet, SNMP, LDAP, Net BIOS, or X11 blocked?

Are potentially risky but required services such as HTTPS, SMTP, and DNS isolated in a DMZ?

From the SANS firewall checklist

From: http://www.netcraftsmen.net/welcher/papers/pix01.html

Auditing a Firewall

What other services besides http and ftp are allowed to the DMZ?

Are insecure services blocked from the external interface?

Can sources with private IP addresses enter through the external interface?

Audit of Firewalls

• Firewall audits require understanding firewall policy

• Firewall policy can be defined as the set of discrete source and destination addresses and services that are allowed or denied by the firewall at each of its interfaces

• Firewall policy is constructed from• Security rules or Access Control Lists (ACLs)

• Network Address Translation rules

• Route rules

• The nature of rule execution and sequence of rules• Firewall’s default behavior

Firewall Rules

• Security rules– Also called ACLs or filter rules– Primary access control responsibility– Most commonly changed in production

• Network Address Translation rules– Source or destination address translation– Used for anonymity or to share public IP addresses– Complex to manually interpret

• Routing rules– Data packet routing– Offers some degree of access control

Firewall Policy

• In general, firewall rules can be expressed as

< P, action > • where P is a predicate describing what packets to match and is an ‘n’ tuple

describing values for network sources, destinations and services.• where action is one of (allow, deny, route, snat, dnat)

• Complete analysis requires the following to be taken into account

• Rule order• All possible paths (physical and virtual)• Routing actions• Transformation actions

Lets take a quick recap of the OSI communications model and how datais transmitted between computers.

http://geekandpoke.typepad.com/geekandpoke/images/2008/01/21/twitterfeed.jpg

The OSI reference model

Sending Computer

Receiving Computer

The IP Header

IP address is a logical address192.168.1.100NetmaskFFFF FFFF FFFF 0000192.168.1.100/24

ProtocolsIPv4, IPv6, IPSec, ICMP

TCP and UDP Headers

Transport Control Protocol Header

User Datagram Protocol Header

Source and Destination PortsIntegers between 0 and 255

Firewall State Machine

The IPTablesLinux Firewall

Every firewall has a distinct state machine processing model.

Rules are collected into rulesets

Routing, address translation and filtering rulesets are processed in the sequence laid out by the firewall’s processing model.

An abstract firewall model

Input AddressSpace

Rule Space

intersected space is acted uponby the rules and accepted or denied.

non intersected space is acted uponby the default action.

InputAddressSpace

=

UNIVERSALSPACE

OutputAddressSpace

=

FIREWALLPOLICY

Rulesets

At each ruleset

Firewall Types

Classification by interception layer– Layer 2

• Transparent Firewalls• Bridges

– Layer 3,4• Network Firewalls

– Layer 7• Application Firewalls

Classification by statefulness– Stateless

• Not aware of sessions or traffic patterns

• Cannot detect replies that are forged

• fast

– Stateful• Aware of sessions and can

detect illegal replies.

Other Functions of a firewall

Network Address Translation (NAT) or Port Address Translation (PAT)

Content filtering (Java/ActiveX)

URL filtering

IPsec VPN

Support for leading X.509 PKI solutions

DHCP client/server

PPPoE support

Advanced security services for multimedia applications and protocols including Voice over IP (VoIP), H.323, SIP, Skinny and Microsoft NetMeeting

AAA (RADIUS/TACACS+) integration

Contents

• Introduction to Firewall Concepts and Policy Analysis

• Firewall Complexity• Demo of Complexity Analysis• Firewall Rule Conflicts• Semantic Firewall Analysis• Semantic Analysis with Athena FirePAC• About Athena Security• Questions and Answers

Firewall Complexity

• Firewall complexity defined.

• Complexity parameters.

• Correlation between complexity and errors.

• Reducing complexity.

• Complexity and firewall performance.

Firewall Complexity

Firewall complexity is a measure of the number of discrete elements of policythat is programmed into the device.

Firewall complexity expresses itself during computation by an explosion of independent policy geometries that have to be managed.

Effect of Complexity

• Likelihood of errors

• Cost of management

• Difficulty of test and audit

Correlation between Complexity and Errors

Rule-base complexity = Rules + Objects + Interfaces * (Interfaces -1) * 0.5 Source: IEEE magazine, June 2004

Complexity Parameters

• Number of native rules

• Number of security rules

• Number of address translation rules

• Number of interfaces

• Number of rules with ‘any’ source and ‘any’ destination

• Number of expanded rules

Reducing Firewall Complexity

• Benchmark complexity with respect to other firewalls

• Use tools to do periodic firewall analysis and clean up rule base– Discard unused rules– Avoid rule conflicts

• Audit the rule base for best practices• Always use specific addresses/services in a rule. • Avoid the use of “Any’.• Ensure rules are disjoint.

Firewall Performance

Measured By– Packets per Second

– Connections per Second

– Transactions per Second

– Maximum Concurrent Connections

– SMTP Sessions per Second

– DNS Requests per Second

– Latency

Complexity and Performance

• Performance inversely correlated to size of rule base– Most used rules may be deep down in the rule

order

• Difficult to improve performance through rule re-ordering– Rule movements can cause inadvertent policy

changes

– Optimization is difficult

Contents

• Introduction to Firewall Concepts and Policy Analysis

• Firewall Complexity• Demo of Complexity Analysis• Firewall Rule Conflicts• Semantic Firewall Analysis• Semantic Analysis with Athena FirePAC• About Athena Security• Questions and Answers

Contents

• Introduction to Firewall Concepts and Policy Analysis

• Firewall Complexity• Demo of Complexity Analysis• Firewall Rule Conflicts• Semantic Firewall Analysis• Semantic Analysis with Athena FirePAC• About Athena Security• Questions and Answers

Rule Conflicts - Types

– Shadowing• One or more preceding rules match a superset of the packets

matched by a given rule and the rules have different actions.

– Redundant• One or more preceding rules match a superset of the packets

that are matched by a given rule and the rules have the same action.

– Correlation• Two rules are correlated when each rule matches some of the

packets matched by the other and they have different actions.

– Generalization• A rule is a generalization of a previous rule if they have different

actions and the subsequent rule matches a superset of all the packets matched by the preceding rule.

Rule Conflicts - Examples

Shadowing

– access-list inbound deny tcp any 10.20.1.0 255.255.255.0 eq https

– access-list inbound permit tcp any host 10.20.1.89 eq https

Redundant

– access-list inbound deny tcp any 10.20.1.0 255.255.255.0 eq https

– access-list inbound deny tcp any host 10.20.1.89 eq https

Rule Conflicts - Examples

Correlation

– object-group network rfc1918– network-object 10.0.0.0 255.0.0.0– network-object 172.16.0.0 255.240.0.0– network-object 192.168.0.0 255.255.0.0– access-list inbound permit icmp any any– access-list inbound deny ip object-group rfc1918 any

Generalization

– access-list inbound permit tcp any 10.20.1.0 255.255.255.0 eq https– access-list inbound deny tcp any 10.20.1.0 255.255.255.0 any

Rule Conflicts - Consequences

Shadowed– A shadowed rule will never be activated. This rule conflict indicates a possible mis-

configuration where services are either being allowed or denied unintentionally.

Redundant– A redundant rule has no effect on policy.

Correlation– The action performed on the traffic that matches the intersection of the two rules is

dependent on the ordering of the rules.

Generalization– The preceding rule represents an exception to the policy applied by the following

rule.

The Policy Tree

http://www.crocodile.org/lord/fwpolicy.pdf

Impact of Rule Conflicts

• Potentially incorrect policy

• Potentially insecure configuration

• Degraded performance

• Increased maintenance effort

• Increased cost of compliance to standards

Optimal Rule Order

• Consider rule usage. – More frequently used rules should show higher up in

the rule base.

• Unused rules and disabled rules should be removed

• Rules without logging and without comments should be reviewed

• “Decaying” rules should be observed and subsequently removed

• Correlation of a rule with other rules should be considered

Contents

• Introduction to Firewall Concepts and Policy Analysis

• Firewall Complexity• Demo of Complexity Analysis• Firewall Rule Conflicts• Semantic Firewall Analysis• Semantic Analysis with Athena FirePAC• About Athena Security• Questions and Answers

Semantic Firewall Analysis

• Introduction to semantic firewall analysis

• Examples

• Common errors with pattern matching

• Demonstration

Semantic Analysis

Routerules

SNATrules

Filterrules

DNATrules

Filterrules

denied

accepted

transformed

non routable

routedtransformed

denied

accepted

IN

OUT

Semantic Analysis

• Not based on pattern matching (or syntactic analysis)– No false positives

• Includes NAT and ROUTE rules in analysis– Accurate

– Not possible with pattern matching

• Universal analysis– Comprehensive

– Full address space covered

Typical Analysis(between an ingress and egress interface)

• Depending on firewall, one or more rule sets may apply to the data flow path.

• Input set ‘I’ consists of the set of all packets with every possible source and destination addresses and ports and all protocols. That is, the entire address space.

• Analysis yields result set ‘A’ of all packets that can possibly reach the egress interface and the set ‘D’ of all denied packets.

• I = A union D

The mathematics of rule processing

For the jth rule in a rule set, we define the current state ‘S’ as <Aj, Dj> where Aj and Dj denote the packets accepted and denied before the jth rule.

Let Rj be <Aj>

For the first rule:R1 = I, A0 = B0 = { }

For each subsequent rule, the current state ‘S’ is updated by the following transformation until the last rule is covered.

If <Pj, accept>, <Aj+1, Dj+1> = <Aj (Rj Pj), Dj>

If <Pj, deny>, <Aj+1, Dj+1> = <Aj, (Rj Pj) Dj>

Rj+1 = Rj – (Aj Pj)

Geometrical Intersection

Ainput B

rule

=

A1

A2

A3 B2

B1

Geometries have 5 dimensions

1.Source address2.Destination address3.Source port4.Destination port5.Protocol

Universal Address Space

Rule Application

Examples

access-list inbound permit tcp any 10.20.1.0 255.255.255.0 eq https

access-list inbound deny tcp any host 10.20.1.89 eq https

OBSERVATIONS

1. The second rule denies the HTTPS service to a single host on the same subnet.2. The first rule permits inbound access to HTTPS service for all hosts on the

10.20.1.0/24 subnet.3. A shadow conflict!4. Easy to spot because rules are adjacent. May not be so always.5. Pattern matching may not discover problem.

Examples

access-list inbound permit icmp any anyaccess-list inbound deny ip object-group rfc1918 any

object-group network rfc1918network-object 10.0.0.0 255.0.0.0network-object 172.16.0.0 255.240.0.0network-object 192.168.0.0 255.255.0.0

OBSERVATIONS

1. Simple review might would find that potentially spoofed private IP addresses are blocked.

2. Reality is that an entire class of packets with illegal addresses would be allowed.3. A correlation conflict!4. Not easy to spot even when rules are adjacent. 5. Difficult to syntactically discover such anomalies.

Contents

• Introduction to Firewall Concepts and Policy Analysis

• Firewall Complexity• Demo of Complexity Analysis• Firewall Rule Conflicts• Semantic Firewall Analysis• Semantic Analysis with Athena FirePAC• About Athena Security• Questions and Answers

About Athena Security Inc.

• Established in 2007• Launched and funded by Lisle Technology Partners• Focus on analytical solutions for network security– Reduce testing effort for security

• FirePAC launched in September 2008– Automates firewall audits– Over 300 global users – Key markets – compliance and security audits

• Other products– Athena Verify for Networks

Thank YouandQuestions