• Like
  • Save
Distributed Firewall Anomaly Detection Through LTL Model Checking
Upcoming SlideShare
Loading in...5
×
 

Distributed Firewall Anomaly Detection Through LTL Model Checking

on

  • 465 views

 

Statistics

Views

Total Views
465
Views on SlideShare
465
Embed Views
0

Actions

Likes
1
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Distributed Firewall Anomaly Detection Through LTL Model Checking Distributed Firewall Anomaly Detection Through LTL Model Checking Presentation Transcript

    • Sylvain HalléSylvain Hallé, Éric Lunaud Ngoupé, RogerVillemaire, Omar CherkaouiFonds de recherchesur la natureet les technologiesCRSNGNSERCDistributed Firewall Anomaly DetectionThrough LTL Model CheckingUniversité du Québec à ChicoutimiCANADAUniversité du Québec à MontréalCANADA
    • Sylvain HalléSylvain HalléFirewallsIncoming trafficFiltered trafficSource IP Port Dest. IP Port Decision192.*16.10.*10.1.1.2. . .80*23. . .10.10.***. . .80*23. . .AcceptRejectAccept. . .
    • Sylvain HalléSylvain HalléWhats wrong with this filter?FSMLTL. . .AlgosToolsRule # Interval Decision12345AcceptDenyAcceptAcceptDeny502 33 93392
    • Sylvain HalléSylvain HalléWhats wrong with this filter?FSMLTL. . .AlgosToolsRule # Interval Decision12345AcceptDenyAcceptAcceptDeny502 33 93392Rule 2s packets are already handled by Rule 1:it is shadowedRules 2 and 3 apply a different decision to somepackets: they are correlatedAll of Rule 5s packets are applied the same decisionas Rule 2: it is redundant
    • Sylvain Hallé????start0exact?1exact?4superset?3Ry ℜIM Rx8redundant12shadowed11general13correlated14none15protoy=protoxprotoy⊂ protoxprotoy ⊃ protox superset?6srcy=srcxsrcy ⊇ srcxdsty⊆ dstxactiony =actionxactiony≠ actionxdsty⊆ dstxdsty⊇ dstxsrcy ⊂ srcxsrcy ⊃srcxsubset?2subset?5srcy⊆ srcxcorrelated?7srcy⊃srcxsrcy⊂srcxdsty⊆ dstxdsty⊃ dstxdsty ⊃dstxdsty ⊃dstxdsty⊂dstxsrcy≠srcxsrcy≠srcxsrcy≠srcxdsty≠dstxdsty≠dstxdsty≠dstxdsty≠ dstxprotoy≠protoxRxℜIMRy9actiony=actionxactiony ≠ actionxRx ℜC Ry10actiony ≠ actionxactiony=actionxPrevious resultsE. Al-Shaer & H. H. Hamed. Discovery of PolicyAnomalies in Distributed Firewalls. INFOCOM 2004.For every pair of rules R , R ...x y
    • Sylvain HalléPrevious resultsB. Khorchani, S. Hallé, R. Villemaire. Firewall anomaly detectionwith a model checker for visibility logic. IM 2012.BADtBABAA overlaps BA ⋂ BA occludes BA ⊆ BA obstructs BA ⊇ B◇*φ○*φ◻*φsome rule r, following r and suchthat r * r, satisfies φall rules r, following r and suchthat r * r, satisfy φthe first rule r, following r and suchthat r * r, satisfies φa ⋀ d◇⋂( ) ⋁ d ⋀ a◇⋂( ) ◇⊇TRUE-1a ⋀ a◇⊇( ) ⋁ d ⋀ d◇⊇( )-1 -1Correlation Shadowing Redundancy
    • Sylvain HalléRoutersIncoming trafficOutgoing trafficSource Destination Next hop192.*16.10.*10.1.1.2. . .10.*16.10.*50.1.*. . .R1R2R3. . .
    • Sylvain Hallé1 [5,8] : ⊥2 [0,1] : ⊤3 [6,8]: ⊥4 [2,5]: ⊤5 [9,9]: ⊤[0,3] #[4,8] Device 2[9,9] Device 3I Next hop1 [5,6] : ⊤2 [0,4] : ⊤3 [7,8] : ⊥4 [9,9] : ⊤5 [3,5] : ⊤[0,3] Device 1[4,8] #[9,9] Device 1I Next hop[0,8] Device 1[9,9] #I Next hopNode 1Node 2Node 31 [5,8] : ⊤2 [2,4] : ⊤3 [9,9] : ⊤4 [0,1]: ⊥All together now
    • Sylvain HalléRule 3.4 shadows Rule 1.2: packet accepted if entersfrom Node 1, rejected if from Node 31 [5,8] : ⊥2 [0,1] : ⊤3 [6,8]: ⊥4 [2,5]: ⊤5 [9,9]: ⊤[0,3] #[4,8] Device 2[9,9] Device 3I Next hop1 [5,6] : ⊤2 [0,4] : ⊤3 [7,8] : ⊥4 [9,9] : ⊤5 [3,5] : ⊤[0,3] Device 1[4,8] #[9,9] Device 1I Next hop[0,8] Device 1[9,9] #I Next hopNode 1Node 2Node 31 [5,8] : ⊤2 [2,4] : ⊤3 [9,9] : ⊤4 [0,1]: ⊥All together now
    • Sylvain HalléRules 1.1 and 3.1 are spurious: a packet to 5 enteringfrom Node 3 is routed to Node 1 where it is dropped1 [5,8] : ⊥2 [0,1] : ⊤3 [6,8]: ⊥4 [2,5]: ⊤5 [9,9]: ⊤[0,3] #[4,8] Device 2[9,9] Device 3I Next hop1 [5,6] : ⊤2 [0,4] : ⊤3 [7,8] : ⊥4 [9,9] : ⊤5 [3,5] : ⊤[0,3] Device 1[4,8] #[9,9] Device 1I Next hop[0,8] Device 1[9,9] #I Next hopNode 1Node 2Node 31 [5,8] : ⊤2 [2,4] : ⊤3 [9,9] : ⊤4 [0,1]: ⊥All together now
    • Sylvain HalléIs Rule 1.5redundant withrespect to Rule 3.3?1 [5,8] : ⊥2 [0,1] : ⊤3 [6,8]: ⊥4 [2,5]: ⊤5 [9,9]: ⊤[0,3] #[4,8] Device 2[9,9] Device 3I Next hop1 [5,6] : ⊤2 [0,4] : ⊤3 [7,8] : ⊥4 [9,9] : ⊤5 [3,5] : ⊤[0,3] Device 1[4,8] #[9,9] Device 1I Next hop[0,8] Device 1[9,9] #I Next hopNode 1Node 2Node 31 [5,8] : ⊤2 [2,4] : ⊤3 [9,9] : ⊤4 [0,1]: ⊥All together now
    • Sylvain HalléIs Rule 1.5redundant withrespect to Rule 3.3?Yes if Node 1 receives traffic only from Node 3...1 [5,8] : ⊥2 [0,1] : ⊤3 [6,8]: ⊥4 [2,5]: ⊤5 [9,9]: ⊤[0,3] #[4,8] Device 2[9,9] Device 3I Next hop1 [5,6] : ⊤2 [0,4] : ⊤3 [7,8] : ⊥4 [9,9] : ⊤5 [3,5] : ⊤[0,3] Device 1[4,8] #[9,9] Device 1I Next hop[0,8] Device 1[9,9] #I Next hopNode 1Node 2Node 31 [5,8] : ⊤2 [2,4] : ⊤3 [9,9] : ⊤4 [0,1]: ⊥All together now
    • Sylvain HalléIs Rule 1.5redundant withrespect to Rule 3.3?Yes if Node 1 receives traffic only from Node 3...No otherwise!1 [5,8] : ⊥2 [0,1] : ⊤3 [6,8]: ⊥4 [2,5]: ⊤5 [9,9]: ⊤[0,3] #[4,8] Device 2[9,9] Device 3I Next hop1 [5,6] : ⊤2 [0,4] : ⊤3 [7,8] : ⊥4 [9,9] : ⊤5 [3,5] : ⊤[0,3] Device 1[4,8] #[9,9] Device 1I Next hop[0,8] Device 1[9,9] #I Next hopNode 1Node 2Node 31 [5,8] : ⊤2 [2,4] : ⊤3 [9,9] : ⊤4 [0,1]: ⊥All together now
    • Sylvain HalléIs Rule 2.3shadowedby Rule 3.1?1 [5,8] : ⊥2 [0,1] : ⊤3 [6,8]: ⊥4 [2,5]: ⊤5 [9,9]: ⊤[0,3] #[4,8] Device 2[9,9] Device 3I Next hop1 [5,6] : ⊤2 [0,4] : ⊤3 [7,8] : ⊥4 [9,9] : ⊤5 [3,5] : ⊤[0,3] Device 1[4,8] #[9,9] Device 1I Next hop[0,8] Device 1[9,9] #I Next hopNode 1Node 2Node 31 [5,8] : ⊤2 [2,4] : ⊤3 [9,9] : ⊤4 [0,1]: ⊥All together now
    • Sylvain HalléIs Rule 2.3shadowedby Rule 3.1?No since no traffic ever flows from Node 3 toNode 2 (all traffic is dropped at Node 1)1 [5,8] : ⊥2 [0,1] : ⊤3 [6,8]: ⊥4 [2,5]: ⊤5 [9,9]: ⊤[0,3] #[4,8] Device 2[9,9] Device 3I Next hop1 [5,6] : ⊤2 [0,4] : ⊤3 [7,8] : ⊥4 [9,9] : ⊤5 [3,5] : ⊤[0,3] Device 1[4,8] #[9,9] Device 1I Next hop[0,8] Device 1[9,9] #I Next hopNode 1Node 2Node 31 [5,8] : ⊤2 [2,4] : ⊤3 [9,9] : ⊤4 [0,1]: ⊥All together now
    • Sylvain HalléIs Rule 2.5redundantwrt Rule 1.4?1 [5,8] : ⊥2 [0,1] : ⊤3 [6,8]: ⊥4 [2,5]: ⊤5 [9,9]: ⊤[0,3] #[4,8] Device 2[9,9] Device 3I Next hop1 [5,6] : ⊤2 [0,4] : ⊤3 [7,8] : ⊥4 [9,9] : ⊤5 [3,5] : ⊤[0,3] Device 1[4,8] #[9,9] Device 1I Next hop[0,8] Device 1[9,9] #I Next hopNode 1Node 2Node 31 [5,8] : ⊤2 [2,4] : ⊤3 [9,9] : ⊤4 [0,1]: ⊥All together now
    • Sylvain HalléIs Rule 2.5redundantwrt Rule 1.4?No since packets destined to 4-5 are never routedto Node 11 [5,8] : ⊥2 [0,1] : ⊤3 [6,8]: ⊥4 [2,5]: ⊤5 [9,9]: ⊤[0,3] #[4,8] Device 2[9,9] Device 3I Next hop1 [5,6] : ⊤2 [0,4] : ⊤3 [7,8] : ⊥4 [9,9] : ⊤5 [3,5] : ⊤[0,3] Device 1[4,8] #[9,9] Device 1I Next hop[0,8] Device 1[9,9] #I Next hopNode 1Node 2Node 31 [5,8] : ⊤2 [2,4] : ⊤3 [9,9] : ⊤4 [0,1]: ⊥All together now
    • Sylvain HalléIssuesThe presence of an anomaly between rules R andR depends on whether there is a possible pathfrom R to R...and also on the field ranges of each routing rulealong that path!
    • Sylvain HalléHow to detect an anomalyKeep track of an interval I of values and a decisionD, called a frozen interval and a frozen decisionIn the beginning, set I to the full range of possiblevalues, and D to "undefined"?Frozen interval Frozen decision①
    • Sylvain HalléHow to detect an anomalyPick some ingress node as a starting point②1 [5,8] : ⊥2 [0,1] : ⊤3 [6,8]: ⊥4 [2,5]: ⊤5 [9,9]: ⊤[0,3] #[4,8] Device 2[9,9] Device 3I Next hop1 [5,6] : ⊤2 [0,4] : ⊤3 [7,8] : ⊥4 [9,9] : ⊤5 [3,5] : ⊤[0,3] Device 1[4,8] #[9,9] Device 1I Next hop[0,8] Device 1[9,9] #I Next hopNode 1Node 2Node 31 [5,8] : ⊤2 [2,4] : ⊤3 [9,9] : ⊤4 [0,1]: ⊥
    • Sylvain HalléIn every node visited, go through the firewall rulesone by one in order1 [5,6] : ⊤2 [0,4] : ⊤3 [7,8] : ⊥4 [9,9] : ⊤5 [3,5] : ⊤③How to detect an anomaly...
    • Sylvain HalléOnce done scanning through the rules, pick onerouting entry...Intersect the freeze interval with the entry chosen...and move on to the destination node④[0,3] #[4,8] Device 2[9,9] Device 3I Next hop0 10 4 8⋂ =4 8How to detect an anomaly
    • Sylvain HalléAt some point in the walk (only once!), pick thecurrent firewall ruleIntersect the freeze interval with the rule chosenRecord the rules decision in the freeze decision⑤7 8⋂ =3 [7,8] : ⊥4 8 7 8? ⊥How to detect an anomaly
    • Sylvain HalléHow to detect an anomalyFrom this point on, compare the frozen interval/decision with the interval/decision of every firewallrule "visited"⑥5 [5,9] : ⊤7 8⊥5 9⊤FrozenSpuriousness anomalyvs.
    • Sylvain HalléSolution #1Repeat this process...for every start pointand every pathby alternatively freezing every firewall ruleΣk!k=1nnon-cyclic paths between n nodes
    • Sylvain HalléSolution #2For a given network, generate a Kripke structurewhose traces are all the walks behaving as in steps① to ⑥Send the problem to a model checkerExpress anomalies as temporallogic properties on these traces(reachability problem)
    • Sylvain HalléVariables in the Kripke structureEach state of the Kripke structure is a uniqueassignment of values to 7 state variablesιL ιR⊥ιD3 [7,8] : ⊥ρL ρRρDχBounds of frozenintervalFrozendecisionUnique rulenumberBounds of currentfirewall rule intervalCurrent ruledecision
    • Sylvain HalléTransitions in the Kripke structureEach transition between two states corresponds toone of the following actionsιRιD3 [7,8] : ⊥4 [9,9] : ⊤ρLρRρDχMoving to the next rule in the current firewallιL = a= b= d= 3= 7= 8= ⊥ιRιDρLρRρDχιL = a= b= d= 3= 9= 9= ⊤
    • Sylvain HalléTransitions in the Kripke structureEach transition between two states corresponds toone of the following actionsιRιD3 [7,8] : ⊥ρLρRρDχFreezing the current firewall ruleιL = a= b= ?= 3= 7= 8= ⊥ιRιDρLρRρDχιL = max(a, 7)= min(b, 8)= ⊥= 3= 7= 8= ⊥
    • Sylvain HalléTransitions in the Kripke structureEach transition between two states corresponds toone of the following actionsιRιD[4,8]: Device 2ρLρRρDχSelect an applicable routing table entry and moveto destination (first firewall rule)ιL = a= b= d= 3= 7= 8= ⊥ιRιDρLρRρDχιL = max(a, 4)= min(b, 8)= d= 1= 5= 6= ⊤1 [5,6] : ⊤
    • Sylvain HalléLTL propertiesAnomalies become properties on traces expressed inLinear Temporal Logic (LTL)Ex.: shadowingιR ιDρL ρR ρDιL =⊥≤ ∧ ≥ =⊤ ∧∧G ( )
    • Sylvain HalléAnomaly detectorFirewall rulesRouting tableEncoderDecoderKripke structureNuSMVCounter-exampletraceAnomaly explanationNode 1Firewall rulesRouting tableNode n. . .Anomalies expressedas LTL formulæAnalysis tool
    • Sylvain HalléSample input fileNode name: 00: 0, 0 : 0, 6, 7 : 0, deny1: 0, 0 : 0, 0, 0 : 0, accept2: 0, 0 : 0, 12, 13 : 0, accept...Routing table:12, 14, 128, 9, 15, 7, 3...
    • Sylvain Hallé- Starting at Node 1- Considering firewall rule 2 on Node 1: [1-5] accept- Going to Node 2 through routing rule 2:Node 1 -> [2-6] -> Node 2- The considered interval becomes restricted to [2-5]- Going to Node 3 through routing rule 1:Node 2 -> [2-6] -> Node 3- Shadowing anomaly with firewall rule 2 onNode 3: [2-5] accept vs. [3-4] rejectAnalysis toolhttp://github.com/sylvainhalle/FirewallCheckjava -jar NetworkChecker.jar -s -i "./*.txt"
    • Sylvain Hallé0.1101,000Time(s)Total number of rules in network50 100 150 2502002-2-2 3-3-3Empirical results
    • Sylvain Hallé0.00111,000Time(s)Number of nodes in network1 5 10 2050 rules 100 rulesEmpirical results
    • Sylvain HalléThe endThank you!Questions?