1 next generation kernel activity monitoring edward balas, indiana university michael davis, savid...

1

Next Generation Kernel Activity Monitoring

Edward Balas, Indiana UniversityMichael Davis, Savid Technologies

IU Partners in Crime:Camilo VieccoGregory Travis

2

Agenda

Introduction to Kernel based activity monitoring (Sebek as context)

Performance evaluation A possible solution Revaluate performance Roadmap

3

Kernel based Activity Monitoring Motivation

Goal is to observe activity while minimizing disruptions.

Network data analysis is no longer sufficient Intruders started using session

encryption Desire to study intra-system behavior

Process vs User behavior

4

Kernel Activity Monitoring Basics

Basic tasks Observe system call

activity Record Data Export Data

5

Kernel Activity Monitoring Basics II

Try to make it hard to detect Fail, Try, Fail… Notice that nobody

bothers looking Implemented as

Loadable Module or kernel patch

Lets not call it a Rootkit, but a system enhancement.

6

Sebek as Kernel Activity Monitor

Linux developed by Balas Win32 developed by Davis Latest versions collect

Keystrokes / read data Process heritage Files opened by a process Sockets opened by a process

GenIII Honeynet design based in part on this type of data.

7

Illustration of Data’s Value

8

Illustration of Data’s value

9

Sebek as Firehose

Sebek defies one of the claimed values of honeynets “They only collect data of value”

Rudimentary of control on what it collects Makes more analysis work Limits use in operations Provides potential for detection

10

Delay imposed by Sebek

Micro RDTSC based, Macro “dd” based 1 bytes Reads from /dev/zero 1,000,000 times Linux 2.6 Sebek

11

Quantity of “uninteresting” data

Per hour record generation rates: Idle Keystroke only ~5,212 Idle Full Read ~98,000 Slowly surfing porn w/ Full Read ~750,000

12

What is the problem? Delay could be used as basis for

detection Create per CPU profiles determine if test

data exceeds delay threshold Generalize distribution and look for

deviations in curve shape Unintended data capture/sensitive

data Data Volume

13

Obvious Solution: don’t record uninteresting

Depending on use case, a prior sense of what is of interest is present Is /dev/zero ever of interest? If we are watching for remote connections, do

we care about unrelated local activity Recall that recent version of Sebek records

process tree, sockets and file activity… Applicable for any Kernel-based Activity

Monitoring

14

Filtering approach

Make it feel like firewall filters Make decisions based on

Process name Socket parameters File names User names

Use process tree to make filters dynamic

15

Example: Monitor a remote user

Action=keystrokes user=ebalas sock=(proto=tcp local_port=22) opt=(follow_child_proc)

Keystroke monitor ebalas when he logs in remotely via ssh. Also monitor any processes decendant from the process that serviced the socket.

16

More Examples

action=ignore file=(name=/var strict inc_subdirs) Ignore any activity associated with files

in the /var sub directory action=keystrokes user=bob

file(name=/var/sekrit/squirel.txt opt=(follow_child_proc) Silly honeytoken.

17

Okam prototype Other Kernel Activity Monitor(OKAM) Based on Sebek Binary flags are added to inode and

process data structure to control if we record.

Tagging occurs when A process forks File is opened Socket activity is observed

18

Filtered Performance

Volume of data at idle reduced dramatically Performance when not recording similar to stock Depends on good filter selection for improvement

but control is good.

19

Future Direction Benchmark other monitored system

calls Explore HTB / fair queuing as a way to

prevent local process level logging Dos.

Release Okam or integrate into Sebek? Trademarks,Copyright Oh my! Hopefully have something out in May