Security and Robustness in an Agent-based

Network Monitoring System

Plan B ProjectKoka Muralidhar

Advisor: Prof. TripathiUniversity of Minnesota

Outline

1. Motivation2. Monitoring System Overview3. Security4. Robustness5. System Capabilities and

Experiences6. Conclusions and Future Work

1. Motivation Develop tools and techniques that

help system administrators monitor computing environments. Guard against malicious users

Attacks and misuse Check for misconfigurations Alert on resource failures

Challenges Involved Increasing number of components in

computing environments:

New hardware/software components are added New monitoring tools and policies are required

Large amount of monitoring data needs to be collected and digested

Monitoring data in different formats Delay in administrator’s response to critical events

contd…

Challenges Involved (contd…) A comprehensive monitoring system

requires correlation of data from diverse sources related to different aspects of a network system E.g. user activities, network traffic, file

systems …

Goals Dynamic configurability

Change in configuration of software components, administrative policies

Dynamic extensibility Addition of new monitoring functions, tools

Active monitoring Alter detection policies in response to

critical events

Goals Secure

System itself should be protected from attacks. Robust

Detect failed components and restore them without stopping the system

Scalable Scale as the number of nodes in the network

increases Acceptable system performance

Should not interfere with the normal functioning of the host.

Mobile-agent based Implementation

Agents can migrate to the monitored nodes providing local processing of events

Agents can encapsulate policies for event monitoring and filtering

New monitoring functionalities can be installed dynamically at remote nodes

Agent policies can be securely controlled remotely

Agents can cooperatively monitor the network Agent can autonomously adapt and react

2. Mobile Agents in Ajanta

Agent Server 1

X

Host A

Agent Server 2

Y

Host B

Y

Agent Migration

Server- Server protocol

Physical Network

Agent-Agent Communication

Event Model

Basic Event Represents a significant change in the

state of a resource being monitored Example: User login event, disk-full event

Compound Event These events are detected by

correlation of events from different nodes

Example: Multiple root login attempts across different hosts by an unauthorized user.

Network Monitoring Architecture

Auditor Agent

Inspector Agentpolicy

Launch Agent

Agent Server

Host A

Host FHost E

Host DHost CHost B

MA IAMAAAMA

SASA

MA

System Management Servers

Agent Migration

Event Notifications

AA

AAAA

IA

Agent ServerAgent ServerAgent Server

Agent ServerAgent Server

policy

AA

IAMonitor Agent

Subscriber Agent

MA

SA Launch Agent

Events Database

Subscriber Agent

Database

Monitor Table

Subscriber Interface Remote Interface Monitor Interface

trigger

trigger

Event Detector Event Handler Subscriber List

Event Notification

A

B

C

A (B,C)

A

Event Queue Event Processor Thread

(1)

(2)

(4)(5)

Trigger Table(3) CheckEvent

Trigger Dependencies

TimerEventDetector

TimerEvent

SyslogEvent

XDMEvent

SshStpEvent

LoginEvent

SyslogEventDetector

XDMEventDetector

SshSftpEventDetector

LoginEventDetector

TimerEventHandler

Event GenerationDetector Triggering

SyslogEventHandler

XDMEventHandler

SshSftpEventHandler

LoginEventHandler

Feb 17 15:12:39 newton sshd[10899]: [ID 800047 auth.info] Accepted password for koka from 128.101.35.177 port 45827 ssh2

3. Security Name Service - assumed trusted and

secure Agent Servers - assumed trusted and

secure Use Java security policy Give permissions based on code base and

principal on whose behalf an agent is running Admission Policy – accept agents coming from

authorized entities only

“Security in the Ajanta Mobile Agent System”, N. Karnik and A. Tripathi, S P & E, 2001

Agent Admission Policy Spec.

Based on the tuple (host/domain, user/agent server) Specify +ve, and -ve permissions and wild card

characters

# accept agents coming from a specific domain domain = cs.umn.edu, user = *

# don’t accept any agents coming from a specific domain

!ip_addr = 128.101 or ip_addr = 128.101 or !user = *

# accept agents coming from a specific host and a specific user

host = plato.cs.umn.edu, user = urn:ans:plato.cs.umn.edu/koka

Security Monitor/Subscriber Agents

Migrate/terminate the agent Modify the agent behavior

E.g. delete detectors Subscribe to events Delete subscription Send false events Might modify agent control policies

Solution: Secure Inter-Agent Communication and allowing only authorized entities

to communicate with an agent

Inter-Agent Communication

Constraints: One of the entities could be an agent server AS1 should not be able to invoke the RMI on behalf of A1, if A1

is not hosted by AS1. When A1 makes the RMI call, it should not be able to disguise

its hosting server AS1. If A1 is successful in making an RMI when it is on AS1, all

further invocations of M should fail if either of A1 or A2 migrates.

AS1

A1

AS2

A2

Inter-Agent Communication

Uses Needham-Schroeder’s challenge-response based authentication protocol

Agents do not carry private keys They ask their hosting servers for

temporary private keys Certificates are issued for different

validity periods

AS1 AS2

A2

1. A1 sends challenge

2. A2 signs challenge, sends response

3. A1 signs responseA1

M (…, Ticket t) {

}

Method Invocation

A1

AS1

A2

AS2

M (…, Ticket)

check if t is validcheck if A1 from AS1 has permission for M

// Method..

Various Parameters A1cred : agent A1’s credentials

U1cert : user U1’s certificate issued by Name Service (NS)

A1loc-cert : location certificate issued by NS

A1cc : cascaded certificate issued by agent server AS1 to

agent A1

A1temp-cert : certificate issued by AS1 to A1, part of A1cc

AS1cert : certificate issued by NS to AS1, part of A1cc

NScert : certificate of NS

KA1- - private key of agent A1

Authentication Protocol A1 to A2: (A1cred, U1cert, A1loc-cert, A1cc, N1)

N1 is a nonce that A2 has to sign

A2 makes the following checks: Validity of U1cert using NScert

Verify A1cred using the public key in U1cert

Validity of A1loc-cert using NScert

Validity of A1cc i.e., AS1cert is valid and that

A1temp-cert is signed using public key in AS1cert

Name in AS1cert is the same as the one in

A1loc-cert

Authentication Protocol If all the checks are valid, A2 sends to A1:

(…, N2, Sig(A1, N1)) N2 is a new nonce to be signed by A1

A1 makes the following checks Checks similar to A2

Verifies if the signature is for the nonce N1

When A1 wants to invoke method M, it

sends the ticket (A1, Sig(A2, N2))

ISSUES Nonce is incremented instead of

authenticating every time A1loc-cert can be verified by going to

the Name Service every time If an agent server is compromised..

Agent Access Control Policy Spec.METHOD addDetector java.lang.String, ajanta.util.TicketURN URN:ans:plato.cs.umn.edu/U2/AS2/A2LOCATION URN:ans:plato.cs.umn.edu/U3/AS2…. URN can be an agent, agent server, or Ajanta

domain LOCATION: agent server hosting the agent Wild card characters can be used to simplify

policy specification Administrator specifies policies for who can

add/modify detectors, subscribe events, modify policies, etc.

4. Robustness Self-Monitoring … heart beats Automated recovery as much as possible Use existing event delivery infrastructure

Failures: Detector in an agent Agents Agent Servers/Hosts

Robustness Failure events are modeled as regular

events Each agent runs an

AgentAliveDetector which generates heart-beat events

FailureEventDetector determines failures. They can be run by an agent.

Failures are handled by the SMS

Robustness

Failure of all detectors in an agent is construed as agent failure

Failure to install an agent is construed as agent server failure

AS1 A1 AS2A2

SMS

AgentAliveEvent

FailureEventInstall Detector

or Agent

TimerEvent TimerEvent

Robustness…constraints Any number of FailureEventDetectors could

be running AgentAlive and FailureEvent detectors

could run with different frequencies Restoration could take any amount of time Multiple failure events need to be handled

simultaneously SMS can be disconnected Don’t install agents/detectors unless it is

necessary

Detector Failure

AS1 A1

AS2

A2

SMS

FE (seq = 20)

Install Detector

TimerEvent

AS3

A3

ALE: AgentAliveEventFE: FailureEvent

ALE (seq = 20)

ALE (seq = 20)

FE (seq = 20)

Discarded by SMS

Agent Failure

AS1 A1

AS2

A2

SMS

Install Agent

FE: FailureEvent

FE

A1

FailureEventDetectorTriggered by TimerEvent

Agent Server Failure

AS1 A1

AS2

A2

SMS

Install Agent

FE: FailureEvent

FEA1

FailureEventDetectorTriggered by TimerEvent

SMS would not be able to install the agent. Informsthe administrator

5. System Capabilities System log monitors Process monitors File Consistency inspectors Host fingerprint inspectors Integrated Snort

Detectors Examples Monitor users switching accounts Correlate login events network wide Snort to detect port scans Correlate login with Snort Runaway processes, daemons

failure, malicious programs System Files consistency

Performance

Figure…what can you do to reduce CPU usage

Experiences Implementation of Syslog detector Dynamic modification of detectors Termination of detectors Deletion and addition of detectors Storage model of detectors Need for a feedback mechanism

6. Conclusions Mobile-agents can be used to build

network monitoring systems System presented is dynamic

configurable and extensible, actively monitors networks, secure, robust and has acceptable resource usage

Future Work Test the scalability of the system Test the utility of the system by

asking system administrators to use it

Develop agents to facilitate software installations

Applying data mining concepts

Acknowledgements… Prof. Tripathi - Overall

Tanvir Ahmed - Initial Implementation

Sumedh Pathak - ,, Megan Carney - ,, Abhijit Pathak - File System

Monitoring