System Monitoring and Network Intrusion Detection using DDS and CEP

(1)

1

System Monitoring and

Network Intrusion Detection

using DDS and CEP

OMG RTESS Workshop

Washington DC, July 14-16, 2008

Gerardo Pardo-Castellote, Ph.D. (RTI)

Joe Schlesselman (RTI)

www.rti.com

(2)

2

Background

This presentation describes the results and

architecture of a DoD-funded research effort to

develop a common normalized information picture

combining data from System Monitoring Tools

and Intrusion Detection Systems.

The purpose of this work is to increase the speed

and effectiveness of the technologies used to

(3)

3

Project Partners

z

RTI (Prime) DDS

z

Coral8

CEP

z

SL

Visualization

z

Promia

IDS Hardware

(4)

4

Outline

z

The problem of [Distributed] System Monitoring

–

System Monitoring

–

Intrusion Detection

z

Available Technologies

–

Ganglia, Nagios

–

Snort, Nessus, Saint

(5)

5

System Monitoring & Network Intrusion

z

Middleware Technologies, such as DDS help build large

distributed systems 100s or 1000s or computers with an

order of magnitude more processes

–

Functionally the system may be correct

–

… but it may still fail operationally…

z

These large systems require monitoring. We focus on

two aspects:

–

Network Intrusion Detection

–

System Monitoring

–

Information Sharing/Normalization

–

Information Processing

z

The integration of these technologies illustrates the

essence of the open integration problem we are trying to

address.

(6)

6

100’s of Available Tools

Tool Categories:

z Network Intrusion Detection Systems

– Snort

– OSSEC NDIS

z Vulnerability Scanners

– Nessus, Nmap

– Saint, GFI LanGuard

z Sniffers

– Wireshark, Kismet,

– Netcat, Metasplot, hping,

z OS fingerprinting, Service identification

– Nmap, P0f

z System Monitoring

– Ganglia

z Knowledge Repositories

– IDS Rules

– Vulnerability Databases (CVE)

z Analysis, Detection, Decision Making

– General purpose (e.g. CEP)

– Specialized (e.g. Snort rules)

z Monitoring, Visualization/HMI Tools

– HP OpenView

– SL RTView, Promia Asset Viewer

(7)

7

The tool Integration problem

z

Many open source and COTS tools

–

Complementary functionality

–

Overlapping functionality

z

Each tool must combine:

–

Sensors, Rules, Alerts/Notifications, Visualization…

z

“Each Tool and Isolated Island”

–

Rules/knowledge bound to the tool/sensor

–

Must learn specifics of each sensor

–

Can’t easily multiple sensors in a rule

–

Limited to what each sensor offers

z

The Result: Cost, Complexity, Limited Power:

(8)

8

Each tool an isolated island

Sensor1 Detection Engine1 Rules1 Visualization1 Sensor2 Detection Engine2 Rules2 Visualization2 Sensor3 Detection Engine3 Rules3 Visualization3

(9)

9

Shared Information Bus / Normalized Information Picture

A better approach!

IDS Detection Engine Snort Archive General Analysis Engine Ganglia Visualization Network Management nmap nessus SAINT Custom Classified Visualization (3D Asset Viewer)

new sensors COTS UTM custom CEP

normalized sensor data inputs normalized alarm/event outputs Custom Code new processors ossec

(10)

10

A better approach with Standards & COTS

COTS Middleware (DDS Global Data Space)

Vulnerability Signature Database

COTS

Recording/ Auditing COTS HMI/ Dashboards

COTS System Sensors (Ganglia)

Host Sensor Host Sensor

COTS Event Processing Email ` Send updated signature COTS Vulnerability Sensors

(Nmap, Nessus, Saint)

Custom/Classified IDS Sensors

Custom Sensors

COTS IDS Sensors (Snort)

(11)

11

Infrastructure Technology Selection

z

DDS

was selected because it provides a

Standard API and Network Protocol able to

handle large volumes of real-time information

and prioritize it by setting QoS policies.

z

CEP

was selected because it provides a familiar

(SQL-like), powerful and extensible language

able to process large amounts of streaming

data, aggregate the information, correlate it, and

uncover interesting events and threats.

(12)

12

Focus:

Network Intrusion & System Monitoring

z

Network Intrusion Detection System (IDS)

–

Sensor: Monitor “raw” network packets

–

Process

z Dissect packets, Identify conversations, Look inside

z Look for: known attack patterns, scans, unusual activity

–

Output: Generate Alarms, Filter/drop packets

–

Example: Snort, OSSEC

z

System Monitor

–

Sensor: Host sensors, look at CPU, memory, file system, network, …

–

Process: Detect unusual loads or changes

–

Output: Status, Alarms

–

Example: Ganglia

z

System and Service Identification

–

Sensors: Host sensors, Network packet capture

–

Output: List of hosts, OS fingerprints, List of open services

(13)

13

IDS: Snort Overview

z

Open source software (Linux, Windows)

–

Commercial support available

z

Can operate as:

–

Sniffer / packet logger,

–

Inline Mode: Intrusion Prevention System (IPS)

z Interfaces with IP tables to drop/reject packets/connections and log the alert

z Can also modify bytes in the packets

–

Network intrusion detection system (NDIS)

z Uses lib PCAP to monitor traffic & generate alerts

z Can also operate from a saved PCAP file

z Can match src/dst and do deep packet inspection

z Can produce references to know attack databases (e.g. NIST’s CVE)

z

Simple rule language for NDIS

–

Customizable/extensible by end user

(14)

14

Snort deployment

Internet

Detect all intrusion events Detect intrusion events that get thought the firewall

(15)

15

Snort Implementation

Analyzes,

modifies and takes actions like: Alert, Log, Drop, Reject. Applies rules Detects “intrusion” events Outputs alerts To files, database, Socket, …

(16)

16

Snort rules

z The rule matches if all elements match: protocol, src, destination, … content, etc.

– <direction> can be “->” or “<>”

– “content:” used for deep-packet inspection. There is a mini language:

z Can specify offsets and depth,

z Can relate to other matches in same packet

z Can use PERL regular expressions

– Can also do matches in the packet (IP/TCP,UDP) headers

z If a rule matches the action is taken:

– Alert, log, pass,

z Rules are applied in sequence

alert tcp any any -> 10.10.100.0/24 111 \

(content:“|00 01 86 a5|”; msg:”mountd access”;)

keyword

protocol source destination action

keyword

(17)

17

Snort Actions

z alert – generate alert and log packet

z log - log packet

z pass – ignore packet

z activate – alert and turn on dynamic rule

z dynamic – inactive rule until activated then log Inline-mode only:

z drop – drop packet and log

z sdrop – drop packet without logging

z reject – drop packet, log, and send reset/ICMP port unreachable to sender Custom actions can also be used to bind to specific output plugins:

Ruletype dds_alert { type alert

output dds_write: domain=36 topic=“SnortAlert” }

(18)

18

Normalized IDS Alert information

struct NormalizedAlert { SensorDetails sensor; NodeInfo source; NodeInfo target; ProtocolInfo protocolInfo; Timestamp alarmTimestamp; string alertMsg; short priority; sequence<ExtraValue> extra; }; struct SensorDetails { string name; string version; long agentId; long type; NodeInfo node; }; struct NodeInfo { NetworkAddr networkAddr; unsigned short port;

PhysicalAddress phylAddr; string hostName; }; struct ProtocolInfo { string type; UdpInfo udpInfo; TcpInfo tcpInfo; IpInfo ipInfo; IcmpInfo icmpInfo; EthernetInfo ethInfo; };

(19)

19

System Monitoring: Ganglia Overview

z

Open source software (Linux, Windows)

–

Originally developed at UC berkeley

z

Distributed Monitoring system for Clusters/Grids

–

Has scaled to clusters with 2000 nodes

z

Many built-in metrics

–

CPU, Network, IO, Memory, Disk

(20)

20

Ganglia Deployment (data collection)

z Host-based (gmond daemon on each host)

–

monitor changes in host state

–

announce relevant changes

–

listen to the state of other ganglia nodes

–

answer requests for an XML description of the cluster state.

z Outputs:

– Metrics to multicast UDP

z Sent at configured period

… or when value changes beyond configurable threshold

– Responses to requests received via TCP

GMOND GMOND GMOND GMOND GMOND GMOND

multicast

GMETRIC

APP

(21)

21

Ganglia Implementation & Deployment

GMOND Cluster 1 GMOND GMOND GMOND Apache Web Server Cluster 2 Poll Poll

HMI

GMETAD GMETAD GMOND Cluster 3 m u ltic_as t RR Database RR Database TCP TC P GMETRIC APP GMETRIC APP

(22)

22

Normalized System Monitoring Information

struct StandardMetrics{ DoubleMetric disk_total; LongMetric cpu_speed; LongMetric swap_total; StringMetric os_name; FloatMetric cpu_user; FloatMetric cpu_system; FloatMetric bytes_out; FloatMetric pckts_in; … }; struct NormalizedSysMon { SensorDetails sensorDetails; ClusterInfo clusterInfo; StandardMetrics stdMetrics; }; struct ClusterInfo { string name; Timestamp localtime; string owner; string latlong; string url; };

(23)

23

CEP Overview

Capabilities:

• Filtering • Pattern Detection • Aggregation, transformation • Time-Correlation

… Across multiple streams

Real-Time

Data Feeds

Real-Time

Data Feeds

. . .

Alerts

Actions

Composite

Events

Real-Time

Data Feeds

Real-Time

Data Feeds

CEP Engine

Alerts

Actions

Composite

Events

Event

Storage

(24)

24

CEP – Example 1

activity: disk free

tool: Ganglia CEP DDS Topic activity: ftp request tool: Snort

RTI

Recorder

DDS Topic _If_free_diskRule:_<_10%_and ftp request

Then send DDS topic

alert

RTView DDS

Topic

(25)

25

CEP – Example 2

event: CPU load

tool: Ganglia CEP DDS Topic activity: ssh tool: Snort

RTI

Recorder

DDS Topic _If_CPURule:_>_50%_and sshrequest Then send DDS topic

alert

RTView DDS

Topic CEP

_CEP

(26)

26

Potential

z

Information normalization would allow rules to be written

independent of sensors

z

Use of CEP would

–

allow rules to apply across sensors

–

enable much more sophisticated rules that mix historical data,

time-windows, causality, etc.

z

Use of DDS would

–

enable prioritization and other QoS

–

provide unified API to access all data with highest performance

–

allow segmentation and parallelization of processing

–

enable easy visualization using general purpose tools

–

Provide many out of the box services: recording, durability…

across all sensors with no additional work

(27)

27

Status: RTI Prototype Demo CONOPS v0.1

Shapes Traffic

CEP via Coral8 Engine

Shapes traffic = UDP/IPv4 DDS traffic created by RTI DDS Shapes demo application Windows

Solaris

Linux

Generic Traffic = legitimate and illegitimate random TCP/IPv4 network traffic

Legitimate = valid, well-formed packets of various protocols created using network traffic stimulator Illegitimate = invalid, non-well-formed but not malicious packets of various protocols

Rogue = packets that violate one or more security policies, whether or not malicious Generic Traffic Shapes Traffic Generic Traffic Shapes Traffic Generic Traffic Linux Producers Sensors SAINT Nmap Snort Nessus OpenPMF Processors

Promia Raven UTM

Naughtiness Rogue DDS Shapes Traffic Windows Solaris Linux Generic Traffic Shapes Traffic Generic Traffic Shapes Traffic Generic Traffic Consumers RTC Database (SQL, Archive) RTI Developer Platform Tools (Analyzer, Wireshark) SL RTView Ganglia RTI DDS

(28)

28

Future objectives

z

Integrate additional sensors of each class &

refine the Normalized data format

z

Gather IDS data in real scenarios

z

Develop more sophisticated CEP rules based

on IDS data

(29)

29