Applying Visualization to the Management of Firewall Rulesets

Applying Visualizationto the Management of Firewall RulesetsShaun P. Morrissey7 October 2009

Thesis Committee:Prof. Grinstein, AdvisorProf. LevkowitzProf. Daniels

2

Outline

Context– What is a firewall?

Proxy versus firewall– What is a firewall rule?

Method– Calculation of the acceptance volume– Visual Approaches

Data – Issues & Solutions Visual Results Discussion & Directions

– What works– What needs to be done

3

Do we care about firewall rulesets?

(Google, 16 June 2005, ~1745 EDT) Results 1 - 10 of about 55,600 for "firewall setup". (0.39 seconds) Results 1 - 10 of about 62,100 for "firewall management". (0.04 seconds) Results 1 - 10 of about 18,100 for "firewall administration". (0.15 seconds) (Google, 26 April 2006, ~0935 EDT) Results 1 - 20 of about 185,000 for "firewall setup". (0.25 seconds) Results 1 - 20 of about 207,000 for "firewall management". (0.25 seconds) Results 1 - 20 of about 81,600 for "firewall administration". (0.28 seconds) (Google, 12 July 2009, ~1457 EDT Results 1 - 10 of about 1,710,000 for “firewall setup.” (0.37 seconds) Results 1 - 10 of about 17,800,000 for “firewall management.” (0.22 seconds) Results 1 - 10 of about 8,230,000 for “firewall administration.” (0.13 seconds).

4

Do they need help?

Network Managers need methods to quickly and efficiently analyze policy environment and impact of proposed changes on operational environment.– Industry analysts Gartner & IDC – 80% of unplanned outages are

a result of changes in IT policies or configurations Policy artifacts, the rulesets, are large, complex, difficult to

comprehend– Errors in interpretation, modification, and development– Demand for capable personnel exceed supply– Diagnostic capabilities desperately needed

5

What is a firewall?

Implementation tool to achieve security policy goal Border or Perimeter Device

– Generally two or more interfaces– Not limited to a single device

Packet-based decision– Packet decision - pass/deny/drop – Local action - alarm/log/record

Decision basis - Proxy vs firewall distinction– Content awareness - proxy– Packet header plus state– Packet header values (research bound)

6

Basic Firewall Concept

Exterior Network(Internet connection)

Interior Network

Hosts*

Firewall

7

Basic Firewall Concept Implementation


Interior Network

Hosts*

RouterX

X

Bastion Host

8

Screened Subnet (DMZ)


Interior Network

Hosts*

Perimeter NetworkRouter

Router Bastion Host(s)

(exterior/access)

(interior/choke)

9

Control of HTTP queries


Interior Network

Hosts*

Perimeter Network

Router

Router

Bastion Host(s)

(exterior/access)

(interior/choke)

http query

http queries

X

X

X

10

Outline






11

Firewall Rules: Intended Semantics

Source– Host– Group of hosts– Collection of hosts or groups

Destination– Host– Group of hosts– Collection of hosts or groups

Service– HTTP, SSL, SMTP, etc

Action– Accept/Deny

12

Packet Header Decision Fields

13

Service

Often listed with the same name as a protocol, – HTTP for web– SSL for secure connections– SSH for secure user connection

Technically defined by protocol and port combinations– HTTP - TCP with destination port 80

14

What is a firewall rule?

Firewall rules generally abstracted to a 5-tuple filter and an action– The components

Source address (IPv4, IPv6) Source port (0 - 65535) Destination address Destination port Protocol Action: Binary, Accept or Deny

– Addresses are often combinations of ranges and individuals– Ports are often ranges– Protocol maps to a single number– Other fields do appear, not considering them at this time.

Packet tests are order-dependent (sequential)

15

Example: Al-Shaer & Hamed, 2003

Rule #

Protocol Source Address

Source Port

Destination Address

Destination Port

Action

1 tcp 140.192.37.20 any *.*.*.* 80 deny

2 tcp 140.192.37.* any *.*.*.* 80 accept

3 tcp *.*.*.* any 140.192.37.40 80 accept

4 tcp 140.192.37.30 any *.*.*.* 21 deny

5 tcp 140.192.37.* any *.*.*.* 21 accept

6 tcp *.*.*.* any 140.192.37.40 21 accept

7 tcp *.*.*.* any *.*.*.* any deny8 udp 140.192.37.* any *.*.*.* 53 accept

9 udp *.*.*.* any 140.192.37.* 53 accept

10 udp *.*.*.* any *.*.*.* any deny

<tcp, 140.192.37.20, 4320, 140.192.37.40, 80>

16

So what are the problems?

Size complexity– Rulesets grow over time

Interaction Complexity– Field definition overlap– Deliberate use of order-dependence to achieve compactness

A Rule is not the Result!– List of rules– Total effect of file

Organizational issues lead to comprehension concerns– Administrators change– Policy Changes– Documentation lost

17

Pages 1 and 2, of 114.

18

Challenges

Dataset– Two distinct technical issues

Size complexity Interaction complexity

– Confidentiality issue at every front Examples provided, permission to use denied Training community structurally unresponsive

Internal ruleset storage/representation– Direct rule visualization

Interval (non-atomic) data field entries Closure property violation under logical operations Decomposition proofs provide some answers

– Acceptance set visualization 5-dimensional space: 5-cubes Embedded subsets not convex Extension of solid modeling with logical operations effective

Visualization of moderate dimensional data (<10D)

19

Research Objective

Create interactive visual representations of firewall rulesets that:– Enhance the speed & correctness of comprehension of ruleset

impact or function– Enhance detection of configuration errors– Support modification without the introduction of unacceptable

side effects. Required

– Calculate the acceptance volume– Display it– Enable editing in response

20

Related work?

First, NOTHING directly on point Point visualizations of 5-tuples

– Intrusion Detection– Network traffic– Static and time-dependent, partial and complete– But no range visualizations, not applicable

Data structures for firewall decision-making– Time & space efficient structures– Representations not unique– But none visualized

21

What’s out there?

And the research literature on firewall visualization was simply “None” until 2007.

PolicyVis – Tran et al., 2007

22

23

Outline






Calculate the Acceptance Volume

Basic Guttman Algorithm Implementation Choice: Constructive Solid Geometry

– Integer lattice– 5 dimensions – Penteracts– Axis-aligned – intervals only

Modifications– Add provenance– Add created voids– Convex solid decomposition

24

25

Outline






Guttman Algorithm

Convert order dependent ruleset to static set

Original formulation was recursive– Replaced by iteration from end

Requires two boolean operations– Union for accept predicates– Set Difference or subtraction for

deny-rule predicates

26

Clear ListIndex = last

Deny or Accept?

Union Subtract

Index-1

Done

DenyAccept

Restricted Constructive Solid Geometry

Treat intervals in five dimensions as a solid– Axis-aligned, intervals only– No rotations– Penteracts specified by 10 values, upper and lower limits

Integer Lattice– CSG packages use “regularized” operations to remove single

values– Single values needed for our work (Protocol #)– Do it yourself, don’t adapt packages

27

Boolean operations on solids

28

Work is done on an integer lattice of all non-negative values Critical operations are:

– Set Union A B∪– Set Difference A – B = A ∩ ~B

Goals include:– Always maintaining convex solid decompositions– ~(~B) = B– Making use of A – B = A – (A ∩ B) to limit need to handle general

case of ~B– Maintaining connection to rules that generated volumes– Creating solution approach that works in each dimension so that

it can be extended to 5-D with confidence

Issue with existing CSG codes

Existing Constructive Solid Geometry packages– Do not appear to go above 3-D– Carry sophistication to manage arbitrary object orientation

Our blocks are simple, axis-aligned– Use logic that eliminates single values in a given dimension

In solids with real dimensions, skin overlaps have no volume, and are eliminated

In our case “degenerate” solids, one value as both upper and lower limit, are real conditions that must be retained.

29

Penteract Constructive Solid Geometry(3D analogue)

30

Top face of rule A box (red) has been opened to expose A ∩ B

Use Convex Solid Decomposition

Simple Data Structure– Only penteracts required

Calculation Complexity– 371,293 types of penteract overlap– CSD allows one dimension at a time,

five pairs of cuts, 13 cases– Cost: longer list

Convex penteract can be visualized easily– Parallel Set Enclosure

Rule A: red volumes Rule B: green volumes B ∩ A : blue volume 1-D cuts

371,293 Cases? (13^5) of course!

Thirteen(13) cases exist for possible overlaps between the intervals in each of five dimensions– Actually, 25 cases can be enumerated, but 10 are aphysical and

two do not overlap In the following discussion, we use T as the target space, and

A for the volume being “added”.– T will in fact be only one component of a list of existing blocks– The overall algorithm will need to be executed against each

relevant block in the acceptance volume– The overall algorithm will need to account for A intersecting with

more than one component of the T’s The following analysis assumes initially that the dimensions

are not degenerate. – The resulting algorithm will then be checked to see if is robust to

handling degenerate cases.

32

Where does 13, 15 or 25 come from?

Consider an interval in a dimension of T, defined by upper and lower limits TL and TH.

There are five distinct regions where each of the boundaries of A (AL and AH, respectively) can fall– Two exterior regions– One interior region– Coincidence with two boundary values

33

TL TH

1 2 3 4 5

Analysis of One Dimension

25 possible cases, in general Impose AL ≤ AH, 10 cases removed Require intersection to exist

– AH 1, A is below T, no intersection∈– AL 5, A is above T, no intersection∈

25 – 10 – 2 = 13– Argument provides enumeration of cases to be handled– 13 cases times five dimensions is plausibly correct– Yields 1,198-line Java method– Alternative is (13^5) = 371,293 cases

34

Overlap cases for one dimension

AH 1∈ 2 3 4 5

AL 1∈ No intersect

action action action action

2X

action action action action

3X X

action action action

4X X X

action action

5X X X X

No intersect

35

Impose AL ≤ AH

Resulting Convex Solid Decomposition(3D)

36

Red volumes – rule AGreen volumes – rule B

Blue volume – rule A and rule B

Set operations as disposition rules for convex solid decomposition lists

Operation A – B A ∩ B B – AUnion Keep Keep Keep

Intersection Discard Keep Discard

Set Difference Keep Discard Discard

Void Difference Keep Re-label & Keep Discard

All of the operations are dispositions for three listsOnly one CSD generation method required for intersecting penteractOperations become wrapper around use of that methodClass PenteractSliceDice

Created Voids and Provenance

Created Void– Modify Guttman A-B– Normal: discard B ∩ A– Created Void: retain B ∩ A,

label with joint provenance– Creates visualizable artifact

Add provenance of rules– List of rules for each penteract– Connected to editor

38

Rule A: red volumes Rule B: green volumes B ∩ A : blue volume 1-D cuts

Thirteen cases, enumeration of actions

39

1) Create working copies of T, wT, and A, wA.

2) Pick a dimension.3) Select the case of the thirteen that

applies.4) Create a copy of wT, wTd, and of wA,

wAd, (or two of one of them, etc).5) Shift the boundary of wTd so it is the

excess beyond the common volume.6) Shift the boundary of wT so it is reduced

to the common volume.7) Shift the boundary of wAd so it is the

excess beyond the common volume.8) Shift the boundary of wA so it is reduced

to the common volume.9) Send wTd and wAd to their respective

output lists.10) Repeat starting at step 2 until all five

dimensions are done.

Handle multiple intersections

Remaining issue: Added penteract intersects with more than one in target list

Add queues for pieces, put penteracts back into queues if further work needed

40

41

Outline






Visual Approaches

Parallel Coordinates– Inselberg lossless multidimensional visualization for points– Use parallel set enclosures for display of penteracts– Ease of representation was one motivation for use of CSD

Flow Picture– Loose pipe or pipeline metaphor– Extended polyhedral representation in 3-space– Implemented in Java OpenGL for speed, interaction (Keyes)

Discussion will focus on design, not software implementation– Use visual completion for improved capture-anomaly

containment visualization

42

PC Screen Shot

43

Flow Picture Mockup

44

Flow Picture endpoints

45

46

Outline






Data Sources

Requests for operational data sets not favorably received– One permitted use case, port 32760 exclusion

Alternative approach - visualize taxonomy of interactions Al-Shaer & Hamed (2003)

– Firewall Policy Adviser – defined full range of interactions and created a complete example

Yuan, et al. (2006) – FIREMAN (A Toolkit for FIREwall Modeling and Analysis) –

defined similar structures with one addition and created examples

– Some examples only artifacts of CIDR notation These examples give us a “complete” set of issues to look at.

47

48

Example: Al-Shaer & Hamed, 2003

Rule #

Protocol Source Address

Source Port

Destination Address

Destination Port

Action

1 tcp 140.192.37.20 any *.*.*.* 80 deny

2 tcp 140.192.37.* any *.*.*.* 80 accept

3 tcp *.*.*.* any 140.192.37.40 80 accept

4 tcp 140.192.37.30 any *.*.*.* 21 deny

5 tcp 140.192.37.* any *.*.*.* 21 accept

6 tcp *.*.*.* any 140.192.37.40 21 accept

7 tcp *.*.*.* any *.*.*.* any deny8 udp 140.192.37.* any *.*.*.* 53 accept

9 udp *.*.*.* any 140.192.37.* 53 accept

10 udp *.*.*.* any *.*.*.* any deny

Al-Shaer, E.S. and Hamed, H.H. 2003a. Firewall Policy Advisor for anomaly discovery and rule editing, IFIP/IEEE Eighth International Symposium on Integrated Network Management, 2003, 24-28 March 2003, pp. 17 – 30.

Yuan, et al. (2006)

Yuan, L., Chen, H., Mai, J., Chuah, C-N, Su, Z., and Mohapatra, P., 2006. FIREMAN: a toolkit for firewall modeling and analysis, IEEE Symposium on Security and Privacy, 2006, 21-24 May 2006, pp. 213-227.

49

Anomalies versus Predicate Overlaps

50

Note: in this case, there is the additional requirement that there is no correlation or generalization anomaly involving Ri and any rule between it and Rj

Anomalies, by ruleset

51

Anomaly Pairs from Al-Shaer and Hamed (2003)

Yuan 2006 Script 1 Anomalies

52

Outline






Denial of 32760 in Parallel Coordinates

53

Denial of 32760 in Flow Picture

54

Selection action in PC view

55

Editor Frame with penteract selection

56

Generalization Anomaly ASH 1) and 2)

57

Generalization Anomaly ASH 1) and 2)

58

Illustration: SA split for Modified ASH 2)

59

Generalization, ASH 2) and 8)

60

Generalization, ASH 2) and 8)

61

Generalization Anomaly, Yuan 4) and 7)

62

Generalization Anomaly, Yuan 4) and 7)

63

Correlation Anomaly, ASH 1) and 3)

64

Correlation Anomaly, ASH 1) and 3)

65

Correlation Anomaly of Yuan 2) and 6)

66

Shadow Anomaly of Yuan 2) and 4)

67

Shadow Anomaly of Yuan 1), 3), and 5)

68

Shadow Anomaly of Yuan 1), 3), and 5)

69

Redundancy Anomaly of ASH 6) and 7)

70

Redundancy Anomaly of ASH 6) and 7)

71

72

Complete Ruleset, Al-Shaer & Hamed

73

Complete Ruleset, Al-Shaer & Hamed

74

75

Outline





– What works, and doesn’t– What needs to be done

What Works?

Containment is the issue for many anomalies– Shown better by the polyhedral representation– Effect likely due to assembly of sub-boxes into a single box in

the viewer’s mind– Suggests use of predicate for accept rules, and created voids

Created voids produce visual artifacts that – Provide awareness of why packets are denied– Supports editing to address that issue

Application of visualization directly to configuration space shows promise

76

What doesn’t work at present?

Accept rules preceding deny rules, for any anomaly type– Create no object in the calculation– Present no visual artifact– “state change” of denied to accepted is not captured

Deny-Deny overlaps have same problem– Response complicated by use of deny-all rules in subspaces

77

78

Outline






What needs to be done (local)?

Theoretical Developments– Extend modified-Guttman to encompass deny rules more

effectively Simplest extension, “denied void” complicated by deny all rules for

space and subspaces – leads to potentially massive expansion of CSD

– Examine display of accept predicates and created voids Reduces visual complexity by eliminating sliced accepts Uncertain at this time as to correctness May require that turning off created voids be disabled May require careful linked management of voids/accepts

– Define “relatedness” measures for support of visual controls

79

What needs to be done (local)?

Software Modifications– Zoom controls

May need to be specialized to two dimensional subspaces Enterprise defaults for destination space

– Rule-based selection lists Display penteracts touched by rules

– Consider predicate display in flow picture Modify color to prevent confusion of displays Supported by existing OpenGL software package

80

Global Directions

Firewalls– Sub-field needs a few good datasets to extend this work– Models for more sophisticated firewall rules

State-dependence NAT rules

Security configuration comprehension– The entire computer security domain needs to have visual

metaphors created and implemented.– Feasibility for display– Methods of interaction

81

Contributions

Created graphics pipeline for firewall configuration– Not traffic or just the rules

Showed benefit of maintaining provenance Defined concept to extend compilation process for rulesets

– Created voids capture certain historical aspects of acceptance volume calculation

Showed extension of history capture needed (denied void?) Showed feasibility of configuration visualization Showed potential for improved comprehension from

polyhedral representations using projection to two-dimensional space over lossless representations for interval data

82

BACKUPS

83

84

DAG Firewall RepresentationsHazelhurst 2000, Yuan 2006 Oriented Binary Decision Diagrams

Gouda 2004, Liu 2004 Firewall Decision Diagrams

Tarsa 2006, Fulp 2005 N-ary Tries

Baboescu 2005 Aggregate Bit Vectors

Singh 2003 Hypercuts, k-dimensional decision trees

Thorup 2003 Dynamic Stabbing

Eppstein 2001 Multidimensional binary search trees

Gupta 2001 HiCuts, multidimensional cutting

Qiu 2001 backtracking search and set pruning tries

Srinivasan 1999 Tuple space search

Suri 1999 Combined two-dimensional filters

Lakshman 1998 Multidimensional range matching

Srinivasan 1998 Grid of tries and cross-producting

85

All the pieces, unconnected

Firewall Analysis -> DAGs- Correctness (e.g., OBDD)- Packet Classification

Acceptance space- Compilation- Description

ComputationalGeometry

DAGVisualization

LosslessHigh Dimension

Visualization

Applying Visualization to the Management of Firewall Rulesets

Documents