The Science of Firewall Analysis Presented By Athena Security Secure by Analysis 25 th 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: 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: 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? 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 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 data is transmitted between computers.

The OSI reference model Sending Computer Receiving Computer

The IP Header IP address is a logical address Netmask FFFF FFFF FFFF /24 Protocols IPv4, IPv6, IPSec, ICMP

TCP and UDP Headers Transport Control Protocol Header User Datagram Protocol Header Source and Destination Ports Integers between 0 and 255

Firewall State Machine The IPTables Linux 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 Address Space Rule Space intersected space is acted upon by the rules and accepted or denied. non intersected space is acted upon by the default action. Input Address Space = UNIVERSAL SPACE Output Address Space = FIREWALL POLICY 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 policy that 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 eq https –access-list inbound permit tcp any host eq https Redundant –access-list inbound deny tcp any eq https –access-list inbound deny tcp any host eq https

Rule Conflicts - Examples Correlation –object-group network rfc1918 –network-object –network-object –network-object –access-list inbound permit icmp any any –access-list inbound deny ip object-group rfc1918 any Generalization –access-list inbound permit tcp any eq https –access-list inbound deny tcp any 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

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 Route rules SNAT rules Filter rules DNAT rules Filter rules denied accepted transformed non routable routed transformed 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 j th rule in a rule set, we define the current state ‘S’ as where A j and D j denote the packets accepted and denied before the j th rule. Let R j be For the first rule: R 1 = I, A 0 = B 0 = { } For each subsequent rule, the current state ‘S’ is updated by the following transformation until the last rule is covered. If, = R j+1 = R j – (A j  P j )

Geometrical Intersection A input B rule  = A1A1 A2A2 A3A3 B2B2 B1B1 Geometries have 5 dimensions 1. Source address 2. Destination address 3. Source port 4. Destination port 5. Protocol Universal Address Space Rule Application

Examples access-list inbound permit tcp any eq https access-list inbound deny tcp any host 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 /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 any access-list inbound deny ip object-group rfc1918 any object-group network rfc1918 network-object network-object network-object 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 You and Questions