Presentation on theme: "How to Improve your Firewall Performance"— Presentation transcript:
1How to Improve your Firewall Performance Prof. Avishai WoolAlgoSec CTO & Co-Founder and Tel Aviv University
2Does Your Firewall Look like this? AgendaThe ProblemStatic AnalysisUsage-based AnalysisRule ReorderingDemoDoes Your Firewall Look like this?
3Causes 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
4Results of Configuration Clutter Firewall slows down – may become a bottleneckHardware size limitations – may need bigger hardwareSlow and cumbersome management interfaceBut also…
5Configuration 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
7Some 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
8Time-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.
9Duplicate 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
10Covered 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.
11Covered 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 !
12Redundant 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
13Example 1: Redundant special case rule SourceDestinationServiceAction7/16telnetpass…52/24AnyAll_tcp_portsRule 7 is a special case of rule 52Confidential
14Example 2: need to be careful… SourceDestinationServiceAction7/16telnetpass…16Anydrop52/24All_tcp_portsRule 7 is not a special case: rule 16 gets in the wayConfidential
16General 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”
17Usage 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
18Challenge #2: Unreliable rule numbers Which rule was “rule 9” on March 11?
19Unreliable 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…
20Usage 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 …
21Maintain 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)
22Now 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”
24Rule 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
25Not 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
26Do 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
27RMPP 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
28Correct 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…
29Human 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
30The AlgoSec Firewall Analyzer Live demo – Optimization Confidential30