Storage–based Intrusion Detection: Watching storage activity for suspicious behavior

1. Storage–based Intrusion Detection: Watching storage activity for suspicious behavior Adam G. Pennington, John D. Strunk, John Linwood Griffin, Graig A. N. Soules, Garth R. Goodson, Gregory R. Ganger Presented by: Anna Majkowska

2. New idea ... • detect intrusion by observing changes to stored files • some changes (like log tampering) are very suspicious • turns out to be quite effective

3. Types of Intrusion Detection Systems Most of intrusion detection systems fall into one of two categories: • network based • host based (embedded in OS)

4. Network-based IDSs • implemented in firewalls or sniffers • scan traffic to, from and within network for suspicious content • look for attacks rather than finding an already successful intruder

5. Host-based IDSs • embedded in the host’ operating system • examine local information (ex. system calls) for suspicious behavior • can be disabled or fed misinformation by an intruder

6. Storage-based IDSs • observe suspicious manipulation of files • intruder cannot hide from storage-based IDS if it wants to run across reboots • can look for intrusions after successful compromise, if independent of host’s OS

7. How it works ... • IDS observes all disk activity looking for signs of intrusion • if detection rule triggers, alert is sent to administrator • administrator decides if it is real or false alarm

8. Assumptions • attacker software control over the host but no physical access to its hardware • storage device and admin console are not compromised • no host’s user or software (including the OS kernel) have administration privileges on the storage IDS

9. Are this assumptions sensible ? • storage devices (file servers, disk array controllers, IDE disks) are separate hardware with its own software • storage devices have fewer network interfaces and no local users – it should be more difficult to compromise than a client system

10. Independent storage

11. Warning signs • data/attribute modification • access patterns (particularly updates) • content integrity • suspicious content

12. Data/attribute modification • changes to files that administrator expects to remain unchanged • ex. system executables, configuration files, libraries • false alerts during system upgrades

13. Storage IDS versus checksumming • utilities like Tripwire periodically check the storage state against data in a reference database (stored elsewhere) • storage IDS improves this approach: • immediate detection of changes • can notice short-term changes • avoids trusting OS to perform the check

14. Suspicious access patterns • usually updates • modifying append-only files , ex. changing log files to scrub evidence • timestamp reversal – to hide information about modifications, false alarms - tar

15. Suspicious access patterns – cont. • denial of service attacks – allocating all the free space • suspicious attribute modifications – enabling set UID or reducing permissions needed to run an application

16. Content integrity • changes that are inconsistent with the file format • ex.: passwd file – 7 fields, legal shell, legal home directory, non-overlapping user ID

17. Suspicious content • detect known viruses by scanning for signatures • large number of hidden files – used for storage by the attacker, or empty files – slowing down file operations

18. Limitations • false alarms • intrusions that do not cause suspicious storage behavior will not be detected – use storage IDS together with network and host IDSs • performance cost

19. Case study • 18 intrusion tools tested (worms, rootkits, trojans) • two categories of actions: hiding evidence of the intrusion and providing reentry mechanism (backdoor) • 15 out of 18 intrusions detected (the other 3 removed after reboots)

20. Non-append patterns observed • 7 toolkits hide intrusions by modifying audit log – overwriting entries related to intrusion • all cause alerts

21. System file modifications observed • 15 toolkits modify system files, 3 replace them with files of matching size and CRC checksum • hiding intruder’s presence: ps, ls, netstat, grep, find, du, pstree • creating backdoors: telnetd, sshd, PAM module

22. Hidden files and directories observed • 12 toolkits create hidden files (does not have to cause alert) • 3 create directories that look like “.”or “..”, by appending spaces “.. ” – causes alert

23. Kernel modification methods Six toolkits modified the running OS kernel: • loadable kernel modules (LKMs) • inserting directly into /dev/kmem • modification of exec() to use a replacement – checksumming won’t work

24. Kernel modification detection • rootkits were detected only because they placed files in watched directories • detection can be avoided • trade-off: go undetected or persist across reboots

25. Secure administration • secure interface needed for specifying detection rules and receiving alerts • prevents client from forging or blocking administrative messages • no user on client system has administrative access to storage device

26. Secure administration - architectures Two methods of access: • local administration terminal, if physical access possible • cryptographic channel between the storage device and the administrator (can us OS as an untrusted component)

27. Checking the detection rules • simple for operations on individual files • for operations on directories, whole directory tree must be analyzed • rules about files that currently do not exist

28. Responding to rule violations • send an alert • slow down suspect’s storage access – false alarms will not cause applications’ failures • deny access – false alarms can cause application failure

29. Preventing loss of data - versioning • versioning for every suspicious operation until administrator approval – difficult reintegration • versioning after intrusion is detected – some data will likely be lost

30. Using Network IDS for storage watch • NFS traffic goes over a network • Storage IDS could be implemented in network IDS • NIDS would have to watch LAN activity (now used mostly for Internet connections)

31. Using NIDS for storage watch – cont. Suspicious content • replication of work • replication of data (ex. mappings of file handles to files held in NIDS) • NIDS would require read permission to all files for integrity and update pattern checks

32. Performance cost • SSH-build and PostMark benchmarks were used for tests • tested for the case where no rules are violated • max. 1.3% performance cost • for single file and directory operations – 0.5 – 3.3 % (rename dir and remove)

33. Space cost • minimal, only about 150KB for over 4700 watched files with author’s implementation • could be further reduced

34. False alarms • most false alarms follow a pattern and can be recognized and ignored by administrator’s console • many false alarms caused by programs like tar – perhaps time reversal rule is a bad idea (not used in any toolkit)

35. Questions ? Comments ?