Download - 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