Transcript Storage –based Intrusion Detection: Watching storage activity for

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 changes
2. can notice short-term changes
3. 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 ?