Presentation on theme: "How to Improve your Firewall Performance"— Presentation transcript:
1 How to Improve your Firewall Performance Prof. Avishai WoolAlgoSec CTO & Co-Founder and Tel Aviv University
2 Does Your Firewall Look like this? AgendaThe ProblemStatic AnalysisUsage-based AnalysisRule ReorderingDemoDoes Your Firewall Look like this?
3 Causes for Clutter in Firewall Rules Dynamic business environment leads to constant rate of rule changes (dozens of changes per week!)Multiple administrators, Staff turnoverOutsourced firewall management (Managed Security Service Providers)Results: “Configuration Clutter”Check Point Firewall with 1,200 rules and 15,000 objectsPIX configuration with 50,000 lines
4 Results of Configuration Clutter Firewall slows down – may become a bottleneckHardware size limitations – may need bigger hardwareSlow and cumbersome management interfaceBut also…
5 Configuration Clutter is a Security Risk Source: IEEE Computer magazine, June 2004A survey of the firewall policies of 30 US-based large corporations suggest that more complex policies are more exposed to serious risk.Rule-base complexity = Rules + Objects + (Interfaces) **22
7 Some definitions are clearly useless Unattached Object / Unattached VPN user group: An object thatdoes not appear in any ruleevery group it belongs to does not appear in any ruleIn any policy on any firewallEmpty Objects:Do not refer to any IP addressUnattached VPN Users:Do not appear in any user group have no accessUnattached access-list (Cisco)Not connected to any interface
8 Time-based cleanup Expired VPN users Disabled Rules: No longer have accessDisabled Rules:Maybe it’s time to delete them?Time-Inactive rules:Timed Rules are active on a certain days of the month, days of the week, or times of the day…… But you cannot set a year.Identify the expired rules before they will become active again next year.
9 Duplicate objects Vendor tools cannot answer the question Result: “does this definition already exist with another name?”Result:Administrators often define the same object (Host, Subnet, or Group) multiple timesDifficult to find without software assistance
10 Covered rules – basicsFirewalls process the rules in-order (“first match”)If “early” rules match every packet that a “late” rule could match – the “late” rule is covered (== useless!)Easy cases:single rule covers another rulethe object names match exactlyMost vendors don’t check. Check Point can catch simple cases.
11 Covered Rules – In-depth analysis The combination of rules 15 & 33 covers rule 35Need to dive into the definitions !Requires some algorithmics to discoverName is different – but all IP addresses are covered !
12 Redundant special case rules If “late” rules can match every packet that an “early” rule matches …… and no rule between them reverses the decision… then the “early” rule is a special case… (and can probably be eliminated)Vendors don’t check – requires algorithmics.Confidential
13 Example 1: Redundant special case rule SourceDestinationServiceAction7/16telnetpass…52/24AnyAll_tcp_portsRule 7 is a special case of rule 52Confidential
14 Example 2: need to be careful… SourceDestinationServiceAction7/16telnetpass…16Anydrop52/24All_tcp_portsRule 7 is not a special case: rule 16 gets in the wayConfidential
16 General Approach Over time: Result: Firewalls still have the rules – Applications are discontinuedServers are relocated to other IP addressesTest environments move to productionBusiness partnerships changeNetworks are re-architectedRouting is changedResult: Firewalls still have the rules –but the traffic is goneIdea: flag rules and objects that have not been used “recently”
17 Usage Information: Logs Firewalls can log each matched packetLog includes rule number, timestamp, and moreNaïve approach: Filter the logs based on rule number and find the missing numbersChallenge #1: Logging is configured per ruleSome rules don’t produce logsSolution #1: List rules that do not produce logs separately
18 Challenge #2: Unreliable rule numbers Which rule was “rule 9” on March 11?
19 Unreliable rule numbers - solutions Solution #2: Vendor attaches a unique “rule_id” to each rule, such that:Reported to logRemains with rule through rule add/remove/modifyCheck Point – feature available starting with NGX R60Consider an upgrade…Cisco – feature available starting with PIX/ASA v7.xJuniper Netscreen: unique rule_id exists, but not reported to log!Need to work around this limitation…
20 Usage Information: hit counters Cisco Firewalls & Routers maintain a per-rule hit-counterAdvantages:Unrelated to logging: un-logged rules are counted tooRule insertions & deletions do not affect the hit-countersChallenge:hit-counters are reset to zero when device rebootsSolution:Take periodic snapshotsAttach pseudo rule_uids, homogenize the snapshotsMake sure not to double-count …
21 Maintain a long history Some rules only work occasionally or rarelyHigh-shopping seasonDisaster recovery rules – tested semi-annuallyNeed usage information of many monthsChallenge:Log files can become hugeLogs are discarded or rotatedHit-counters are occasionally set to 0Solution:Process the raw usage information –… But only keep concise summaries (forever)
22 Now that we have usage information Unused Rules:have not matched traffic in the last NNN daysUnused Objects:Do not belong to any rule that matched traffic in the last NNN daysUnused Objects within used rulesMost / Least used rulesLast date that rule was usedEven if it is listed as “unused”
24 Rule order basics Reminder: Firewalls process the rules in-order Once a connection is matched – firewall moves to next connectionAmount of CPU time spent depends on position of matching rule in the rule-base:1st rule: firewall only tests one rule – minimal CPULast rule: firewall tests all the rules – high CPUReordering approach (first attempt):Move the popular rules to the top
25 Not every reordering is acceptable Again: Firewalls process the rules in-orderIf a rule is moved to the top – it may supersede (and contradict) the policy!Ridiculous Example:Last rule in the rule-base is the default “from any to any with any service, drop”Moving it to position 1 will drop all traffic (very efficiently)Reordering approach (better):Move the popular rules as high as possible without changing the firewall policy
26 Do it scientifically: A new firewall performance model RMPP – Rules Matched Per PacketIntuition: calculate the average number of rules the firewall tested until it reached the rule that matched a connectionAverage is taken with respect to usage statistics
27 RMPP examples Example 1: Policy of only one rule: (Deny all or permit all)RMPP = 1Example 2: Policy of 100 rules:Usage: rule #1: 20%, rule #10: 30%, rule #100: 50%:RMPP = 1*20% + 10*30% + 100*50% = 53.2On average, the firewall tests 53.2 rules per connection
28 Correct reordering approach Arrange the rules to minimize the RMPP, without changing the firewall policyNote:RMPP is a modelIt ignores some causes for CPU utilizationYour mileage may vary…
29 Human considerationsReordering 100’s of rules via point-and-click is unrealisticBut: Often a very small number of rule moves produces a very big change in RMPPSolution:Suggest Top-10 most effective rule movements
30 The AlgoSec Firewall Analyzer Live demo – Optimization Confidential30