Transcript Usable Firewall Configuration.

Usable Firewall Configuration
Weiwei Geng
Scott Flinn
John DeDourek
PST’05 — 14 October 2005
Policy Configuration
•
•
Authorization policy is surprisingly hard
Think of
– file system permissions
– web server access controls
– complex workflow models
– meta policy and jurisdictions
Firewall Configuration
•
Is it still error prone?
– Conflicting opinions
– Current trend is toward simplicity
•
If so, why?
– What elements are hard to simplify?
•
Is there a better way?
– Are the current tools sufficient?
Starting Simple
•
Many firewall types
– Packet filtering (stateful or not)
– Application based
– Personal firewalls
•
We focused on stateless packet filtering
Simple Rules
•
Rule content
– Source IP and port
– Destination IP and port
– Protocol
– Action
allow from 10.0.1.0/24 to 10.0.0.2 21 TCP
•
Rule list is matched sequentially
Typical Errors
•
How prevalent?
– 12 rule sets examined in a recent study
– 244 rules on average, maximum 1400
– all rule sets contained errors
•
What kind?
– shadowing anomaly
– correlation anomaly
– generalization anomaly
– redundant anomaly
•
Unanticipated interactions between multiple firewalls.
Causes of Errors
•
Arcane configuration language
– Mental translation from policy to rule
– Typos are easy
•
Interactions between rules
– Not explicit in rule language
– Powerful, but dangerous
•
Large rule sets
– Many exceptions
– Many interactions
– Complex configurations
Activity Cycle
Existing Approaches
•
•
•
•
Graphical tools
– Configure and maintain
– Focus is on specification
– Good at showing configuration, but not behaviour
Analysis tools
– Reason about rules
– Test configuration
– Focus is on understanding and identification
Models and queries
– Model policy, translate automatically
– Understand through interactive query
No mainstream tool integrates all three activities
Initial Specification
•
Could use modern graphical tools
•
We use simple configuration file
– network topology + security policy
DMZVLAN = {
type : "network",
netAddress:"10.0.3.0",
netMask: "255.255.255.0",
gateways: ["gateway"],
subNetworks: [],
superNetwork: "DMZVLAN",
hosts: ["webServer", "cvsServer"]
};
gateway = {
type : "gateway",
ruleFile :"e:\\example\\rule.txt",
gateways: [],
networks: [
"ResearchVLAN", "CorporateVLAN",
"DMZVLAN", "internet" ]
};
Understanding
Configuration
•
Could use rule-based approach
– complex because routing is implicated
•
We use simulation
– packet selection
– routing
– result aggregation
Identifying Errors
Result Visualization
Identification of Rules
Reducing Visual
Complexity
Reducing Visual
Complexity
Reducing Visual
Complexity
Update Configuration
•
Interaction with links highlights rules in editor
•
Edit rules in place and re-simulate to immediately see
effect
•
Incremental simulation is needed for interactive speed
Evaluation
•
Conceptual walk-through for each class of error
Conclusions
•
Activity cycle model is the primary contribution
•
Three integrated components, one for each step in the
cycle
– simulation bridges from understanding to error location
– visualization bridges from error location to specification
– direct manipulation bridges from specification to
understanding
•
Much need for polish, but we’re happy with the approach
•
Promising enough to warrant more rigorous user-centred
evaluation