Storage–based Intrusion Detection: Watching storage activity for suspicious behavior
description
Transcript of Storage–based Intrusion Detection: Watching storage activity for suspicious behavior
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
New idea ...
detect intrusion by observing changes to stored files
some changes (like log tampering) are very suspicious
turns out to be quite effective
Types of Intrusion Detection Systems
Most of intrusion detection systems fall into one of two categories:
network based
host based (embedded in OS)
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
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
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
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
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
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
Independent storage
Warning signs
data/attribute modification
access patterns (particularly updates)
content integrity
suspicious content
Data/attribute modification
changes to files that administrator expects to remain unchanged
ex. system executables, configuration files, libraries
false alerts during system upgrades
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:1. immediate detection of changes2. can notice short-term changes3. avoids trusting OS to perform
the check
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
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
Content integrity
changes that are inconsistent with the file format
ex.: passwd file – 7 fields, legal shell, legal home directory, non-overlapping user ID
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
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
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)
Non-append patterns observed
7 toolkits hide intrusions by modifying audit log – overwriting entries related to intrusion
all cause alerts
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
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
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
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
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
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)
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
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
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
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)
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
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)
Space cost
minimal, only about 150KB for over 4700 watched files with author’s implementation
could be further reduced
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)
Questions ? Comments ?