Post on 04-Jan-2016
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