Distributed Firewall Anomaly Detection Through LTL Model Checking

838 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
838
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Distributed Firewall Anomaly Detection Through LTL Model Checking

  1. 1. 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
  2. 2. 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. . .
  3. 3. Sylvain HalléSylvain HalléWhats wrong with this filter?FSMLTL. . .AlgosToolsRule # Interval Decision12345AcceptDenyAcceptAcceptDeny502 33 93392
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. Sylvain HalléRoutersIncoming trafficOutgoing trafficSource Destination Next hop192.*16.10.*10.1.1.2. . .10.*16.10.*50.1.*. . .R1R2R3. . .
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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!
  19. 19. 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①
  20. 20. 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]: ⊥
  21. 21. 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...
  22. 22. 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
  23. 23. 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
  24. 24. 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.
  25. 25. 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
  26. 26. 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)
  27. 27. 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
  28. 28. 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= ⊤
  29. 29. 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= ⊥
  30. 30. 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] : ⊤
  31. 31. Sylvain HalléLTL propertiesAnomalies become properties on traces expressed inLinear Temporal Logic (LTL)Ex.: shadowingιR ιDρL ρR ρDιL =⊥≤ ∧ ≥ =⊤ ∧∧G ( )
  32. 32. Sylvain HalléAnomaly detectorFirewall rulesRouting tableEncoderDecoderKripke structureNuSMVCounter-exampletraceAnomaly explanationNode 1Firewall rulesRouting tableNode n. . .Anomalies expressedas LTL formulæAnalysis tool
  33. 33. 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...
  34. 34. 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"
  35. 35. Sylvain Hallé0.1101,000Time(s)Total number of rules in network50 100 150 2502002-2-2 3-3-3Empirical results
  36. 36. Sylvain Hallé0.00111,000Time(s)Number of nodes in network1 5 10 2050 rules 100 rulesEmpirical results
  37. 37. Sylvain HalléThe endThank you!Questions?

×