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 ?