Data Security in Local Area Network Using Distributed Firewall
Distributed Firewall Policy Validation
23
Distributed Firewall Policy Validation by Kyle Wheeler
description
Distributed Firewall Policy Validation. by Kyle Wheeler. 1. Introduction Justification Requirements 2. Design Approaches Architecture. 3. Implementation Requirements Graphing Example Policy Example 4. Conclusions. Outline. Security is IMPORTANT. Computer-based attacks are increasing - PowerPoint PPT Presentation
Transcript of Distributed Firewall Policy Validation
Distributed Firewall Policy Validation
by Kyle Wheeler
Outline 1. Introduction
Justification Requirements
2. Design Approaches Architecture
3. Implementation Requirements Graphing Example Policy Example
4. Conclusions
Security is IMPORTANT Computer-based attacks are increasing
Code Red: 2000 hosts/minute (2001) Slammer: 55 million scans/second (2003)
Attacks are becoming more damaging CISCO’s IOS code stolen Valve’s HalfLife 2 code stolen Trend Micro says:
• $13 billion in 2001• $20 billion in 2002• $55 billion in 2003 (source)
Security is HARD Firewalls
Most popular security method Rules can and do become very complex Not only method, however
Large networks have: Many different administrators Diverse software
Security of large networks requires: Centralized control Uniform software
No unified method of verifying security policy implementation For example, The University of Notre Dame network
Rules for the Solution Few Requirements
Network-connectivity independent Mostly system-setup independent Cannot require root access Independent of firewall implementations
Flexible Testing Out-of-order data collection (some support) Non-uniform distribution of testing nodes
Define a testable security policy language
Analysis Approaches
Static Vulnerability Analysis Splint
Threat Modeling Regression Testing
Static Vulnerability Analysis
The Good Avoids logical
ambiguity Avoids common
loopholes and mistakes
Easy to understand
The Bad Requires detailed
knowledge of the implementation
Implementation-specific
Does not address system interactions
Threat Modeling
The Good Models entire system Views system as an
attacker would Determines
vulnerability “surface”
The Bad Requires full
knowledge of all system details
Regression Testing
The Good Does not need
implementation-specific details
Easy to understand
The Bad Effectiveness is tied
to the completeness of the policy
Can miss some vulnerabilities
Data Collection Framework Hierarchical organization
Handles complex networks Allows asynchronous operation
Wizard Big picture management, handles policy testing
setup Manager
Organization, Coordination, Retrieval Prober
Low-level testing, yes/no answers
Managers & Probers
Good Features Subordinate Managers Commands can be any length
Key Features Hierarchical Naming Maildir-like communication
Hierarchical Naming Names contain routing information Names are given or assigned
Network must be laid out intelligently No auto-discovery Manually connectable
Must be a root to the tree (base) Three kinds of sub-names
base.m1.m1.p2.t1.t Example, slide 17, 12
Maildir-like Algorithm Benefits
No locks: NFS safe No partial-files No new communication server to secure
Two-step file creation Create in tmp, then move to new Need unique new name
• Use pid and random• Could use more (inode#, for example)
Waiting For Results Requires Polling
Given a complex network…
Administrator’s Console
Firewall Firewall
FirewallProber
Manager
ProberManager
ProberManagerProber Prober Prober
Prober Prober
Prober Prober Prober
… Handled Nicely
Prober Prober Prober Prober Prober Prober
Prober Prober
ProberManager
ProberManager
ProberManager
Administrator’s Console
Firewall Firewall
Firewall
Or, More Realistically…
192.168.0.131 192.168.0.131 192.168.0.131
24.11.249.68
internet
129.74.152.6 129.74.152.2129.74.155.226
172.16.0.16 172.16.0.17
... Which Can be Organized
192.168.0.130Wizard & Manager
base
192.168.0.132Proberbase.p1
192.168.0.131Proberbase.p2
129.74.152.2Prober
base.m1.p2
172.16.0.17Prober
base.m1.m1.p2
172.16.0.16Prober
base.m1.m1.p1
129.74.155.226Manager - base.m1
Prober - base.p3
129.7.152.6Manager - base.m1.m1
Prober - base.m1.p1
24.11.249.68Proberbase.p4
The Implementation Requirements:
ttcp installed in PATH• Binary connection testing
bash available, in PATH• Written in bash
SSH access, without password• Security issue• Impact can be reduced with careful administration
Graphing with Graphviz
Raw Manager Capability Hosts, fully connected:
wopr.memoryhole.net iss.cse.nd.edu salinan.cse.nd.edu itisfast.cse.nd.edu
Legend: Black line = confirmed
connection Dotted line = one side reported
connection Red line = one side reported,
one side denied
The Wizard
Interchangeable element Interprets policy language Generates and spawns tests
At least three per assertion Otherwise 50% of all possible
Interprets results of tests Must have control of “base” Manager
Example Policy
network iss 172.16.0.0 255.255.0.0network nd 127.74.0.0 255.255.0.0network brk 192.168.0.0 255.255.0.0brk -> ndbrk -> iss via 129.74.152.6 nd -> brk via 24.11.249.168 nd -> iss via 129.74.152.6iss -X ndiss -X brk
16
Conclusions Design is feasible Implementation works as expected Being generic is hard Future Work
Investigate long-running “continuous” testing Policy language needs further flexibility Speed of testing
Any Questions?
