CS463.10 Intrusion Detection

1. CS463.10Intrusion Detection UIUC CS463 Computer Security Based on slides provided by Matt Bishop for use with Computer Security: Art and Science

2. Intrusion Detection • Definition • Models • Network Intrusion Detection • Intrusion Response

3. Readings • Chapter 25, 25.1-25.3, 25.5, 25.6 • Exercises: • 1, 2, 5, 7-10

4. Intrusion Characteristics • Main idea: a compromised system has different characteristics than a normal one • Statistical patterns of activity • Suspicious activity • Specifications

5. Adversarial IDS model • Attackers want to mask traces of intrusion • Slow down response • Exploit compromised system for longer • Tools to do this are called “root kits” • e.g. Sony DRM, Spyware • Main goal of IDS: detect root kits • Main goal of root kits: avoid IDS

6. Root kit techniques • Hide presence of intrusions • Alter log files • Change monitoring software • New versions of ls, ps, netstat, … • Change kernel • Virtualization / sand boxes

7. Root Kit difficulties • A system has many monitoring facilities • Resource utilization, timings, etc. • e.g. detecting presence of a new file • ls, find, “echo *”, du, df, … • A determined effort to find a root kit will probably succeed • Root kit cannot cover all bases • “No perfect crime”

8. IDS difficulties • IDS only monitors a finite number of parameters • Root kits can cover all the bases the IDS knows • IDS is an alarm system, not forensics • Arms race ensues

9. IDS goals • Detect wide range of intrusions • Including previously unknown attacks • Detect intrusions quickly • Allow timely response • A good IDS can be used for intrusion prevention • Explain intrusions well • Allow intelligent response • Detect accurately

10. Accuracy • False negatives • Fail to detect an intrusion • False positives • Alert an intrusion when there isn’t one • Most designs allow a trade-off between the two • e.g. 0% false positives is easy to achieve with 100% false negatives

11. False Positives & Rare Events • e.g. fingerprint matches • False positive rate = 0.01% • Number of fingerprints on record = 1 million • Suppose a fingerprint at the scene matches someone in the database • 100 positive matches using this matcher • But only 1 would be valid. • Odds are 100-1 that person is innocent! • Intrusions are rare • False positive rate must be very low to be usable

12. Anomaly Models • Manual models • Describe what behavior is correct or anomalous • Statistical models • Learn what is the normal behavior

13. Statistical Models • Monitor system in normal state • Learn patterns of activity • Various statistical models to do this • Decide an intrusion threshold • e.g. 2 standard deviations from normal • Adapt over time (optional)

14. Simple Model (Normal) • Measure values of parameters • e.g. network load • Calculate mean & standard deviation • Set a threshold based on a confidence interval • e.g. 2 standard deviatons =~ 95% • 3 standard deviations =~ 99.7% • Alert for values outside the threshold

15. Markov Models • Consider anomalous sequences of operations • Usually system calls • Markov models: next operation depends on current one • e.g. read follows open • Transition probabilities computed by training • Can classify likelihood of sequences

16. Higher Order Markov Models • First order Markov models consider only the previous state • i.e. likelihood of each digram of operations • e.g. if training set is: • how is it going? • the sky is blue. • Then the sentence “how is blue” falls within the model • Higher order Markov models consider several previous states

17. n-grams • Another way to think about previous states is with n-grams open read write open mmap write fchmod close • 3-grams are: open read write read write open write open mmap open mmap write mmap write fchmod write fchmod close fchmod close

18. Statistical Models • Pro: • No need to know what is “normal” in advance • Flexibility between installations • Adaptive • Control of false positive rates

19. Statistical Models • Con: • Statistical model may be wrong • e.g. not normally distributed data • Training set may be inadequate • Same problem as testing • Alerts difficult to explain • Attacks may be able to get around them

20. Misuse specification • Look for patterns of activity that shouldn’t happen • e.g. swiping many doors in Siebel • e.g. control transfer to a randomized location • e.g. traffic with internal address coming from outside • Usually very low false positive rate • But only detects known attacks

21. Specification-based Detection • Specify correct operation, everything else an attack • e.g.rdist specification • open world readable files • open non-world readable files rdist creates • create files in /tmp • chown/chmod files it creates • Any other filesystem operation is an error

22. Automated Specification • Manual specification labor-intensive and error-prone • Idea: take specification from source code • Static analysis to build model of system calls • Different models considered: • FSA, PDA, n-gram • Advantage: no false positives • Disadvantage: • Only detects control flow hijacking • Mimicry attacks

23. Mimicry Attacks • Tailor attack specifically to an IDS • e.g. pad system calls sequences to look legitimate • Normal sequence: open read write close open fchmod close exec • Naïve attack: open read exec • Mimicry attack (digrams): open read write close exec

24. Mimicry Attacks • More precise models better defend against mimicry • Mimicry exploits similarity between attack and detection • Makes attack sequences look non-anomalous • Continues arms race

25. Network Intrusion Detection • Most attacks come from the outside network • Monitoring outside link(s) easier than monitoring all systems in an enterprise • Network Intrusion Detection Systems (NIDS) a popular tool

26. NIDS challenges • NIDS Challenges • Volume of traffic • Attacks on the monitor • Uncertainty about host behavior

27. Volume of Traffic • Organizations can easily have 100Mbps – 1Gbps links to the outside world • NIDS must examine all traffic • Reconstruct communications context • Keep state about connections

28. Attacks on Monitor • Deliberate attacks on monitor can compromise detection • Step 1: • Overload monitor • Cause it to crash • Step 2: • Carry out attack • Performance becomes an adversarial task

29. Speed of Processing • Discard things that aren’t interesting • Packet filters • Fast rules for selecting interesting packets • Flow rules • Ignore flow after it’s deemed safe / uninteresting • e.g. look at first 1000 bytes of connection • Parallelize • Can work to a limited extent

30. Memory Usage • Keep state as small as possible • Ideally, no state at all, but this impacts accuracy • Delayed state allocation • e.g. don’t create state for half-open TCP connections • Careful use of expensive analyzers • e.g. HTTP analyzer might use a lot of RAM • Attacker can cause many HTTP requests to crash the NIDS

31. Tricks • NIDS reconstructs state at the host • What packets it saw • How it interpreted them • Reconstruction may be imperfect • Different packet lifetimes at NIDS and at host • Unexpected semantics

32. IP fragments • IP has an option to split packets into fragments • Not used often, ignored by early NIDS • Attackers use fragments to hide their attacks

33. Overlapping Fragments Fragment 1 login: roger Fragment 2 ot\n rm -rf / • Does the packet get reconstructed as: • login: roger… • login: root…

34. TCP retransmits Packet 1 logi n: ro Packet 2 ger\n Packet 3 Retransmit Packet 3 ot\n

35. Network Tricks • Time-to-Live (TTL) field • Set TTL low enough so that NIDS sees the packet, but host doesn’t • NIDS may be able to detect this, but only if it knows distance to all hosts • Don’t Fragment (DF) flag • If a link between the NIDS & the host has small MTU size, DF flag could cause the packet to be dropped • …

36. Resolving Ambiguity • How to resolve the ambiguity? • It depends! • Implementation on the host • Network topology • Congestion

37. Split • Solution 1: Split Analysis • Spawn two threads, each making an alternate choice • Watch host response, kill any thread that’s inconsistent with host behavior • Expensive • May be exploited by attackers • Generates false alarms

38. Non-Solution • Treat ambiguities as attacks • Generates too many false alarms • Experience in practice sees all of these in normal usage • DF packets • Inconsistent IP fragments • Inconsistent retransmits

39. Vulnerability Detection • Detect attempts to exploit vulnerability • Can be done independently of patching • Can be performed by a NIDS, guarding some potentially unpatched computers • Caveat: only works against known vulnerabilities

40. System Compromise • Run an intrusion detection system on the host • Detect compromise • Honey pots – systems designed specifically to detect (worm) attacks • Not normally used, so any connection is likely to be an attack

41. Intrusion Response • Once intrusion is detected, what to do? • Prevention • Stop the attack if detected fast enough • Containment • Prevent further damage • Eradication • Restore system to known good state • Follow-Up • Track down attackers • Most work is on eradication

42. Prevention • Ideally, IDS should stop an attack in progress • In reality, false positives get in the way • IDS should not impact availability more than attacks • Denial of service possible

43. Containment • Passive containment • Monitor attack in progress • Prevent any damage • Track down attacker • Active containment • Shut down machine • Disconnect it from the network • Boot from CD

44. Eradication • Restore system to a known-good state • Need to track down when intrusion occurred • Lose all work in between • Timely & accurate IDS helps • Other tools: auditing & forensics • Forensics track down initial intrusion • Auditing tracks changes affected by compromise

45. Eradication • Active research area: fast recovery improves availability • If we can recover from attacks quickly, damage from attacks is minimized • e.g. large services take a recovery approach to service reliability • Confidentiality failures are still a problem • When confidentiality is an issue, intrusion prevention becomes more important

46. Follow-Up • Track down where the intrusion came from • Notify owner of machine / network • Take legal action, if appropriate • Done less often today, since most compromises are stepped through “zombie” machines • Counter-compromise? • Don’t do it!