Transcript Security and Robustness in an Agent

Security and Robustness
in an Agent-based
Network Monitoring System
Plan B Project
Koka Muralidhar
Advisor: Prof. Tripathi
University of Minnesota
Outline
1.
2.
3.
4.
5.
6.
Motivation
Monitoring System Overview
Security
Robustness
System Capabilities and Experiences
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


Dynamic extensibility


Change in configuration of software components,
administrative policies
Addition of new monitoring functions, tools
Active monitoring

Alter detection policies in response to critical
events
Goals

Secure


Robust


Detect failed components and restore them
without stopping the system
Scalable


System itself should be protected from attacks.
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-Agent
Communication
X
Y
Agent Server 1
Agent
Migration
Server- Server
protocol
Host A
Y
Agent Server 2
Host B
Physical
Network
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
System Management Servers
MA
SA
Monitor Agent
Subscriber Agent
Host A
MA
AA
Agent Server
policy
policy
Launch Agent
Launch Agent
Host B
MA
Agent Server
MA
IA
Event Notifications
Host F
SA
AA
Agent
Migration
Agent Server
AA
SA
Agent Server
Events
Database
AA
Auditor Agent
IA
Agent Server
Host E
Inspector Agent
Host D
Host C
AA
IA
MA
Agent Server
Subscriber Agent
Subscriber Interface
Remote Interface
Monitor Interface
Event Processor Thread
Event Queue
A
(1)
(3) CheckEvent
Trigger Table
Event Notification
A  (B,C)
(2)
A
(5)
Event Detector
B
(4)
Event Handler
trigger
C
trigger
Monitor Table
Database
Subscriber List
Trigger Dependencies
Event Generation
Detector Triggering
TimerEvent
TimerEventDetector
TimerEventHandler
SyslogEventDetector
SyslogEventHandler
XDMEventDetector
XDMEventHandler
SyslogEvent
XDMEvent
SshStpEvent
SshSftpEventDetector
SshSftpEventHandler
LoginEventDetector
LoginEventHandler
LoginEvent
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 Agent Servers 



assumed trusted and secure
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



# don’t accept any agents coming from a specific domain



domain = cs.umn.edu, user = *
!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
A1
A2
AS1
AS2
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.
Inter-Agent Communication
1. A1 sends challenge
A1
AS1




2. A2 signs challenge, sends response
3. A1 signs response
A2
AS2
Uses Needham-Schroeder’s challengeresponse 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
Method Invocation
M (…, Ticket)
M (…, Ticket t) {
check if t is valid
check if A1 from AS1
has permission for M
A1
AS1
}
// Method..
A2
AS2
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))


A1 makes the following checks



N2 is a new nonce to be signed by A1
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
URN
LOCATION
….




addDetector java.lang.String, ajanta.util.Ticket
URN:ans:plato.cs.umn.edu/U2/AS2/A2
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
TimerEvent
TimerEvent
AgentAliveEvent
AS1
A1
A2
AS2
FailureEvent
Install Detector
or Agent
SMS


Failure of all detectors in an agent is construed as
agent failure
Failure to install an agent is construed as agent
server failure
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
ALE (seq = 20)
ALE (seq = 20)
TimerEvent
AS1
A1
Install Detector
A2
A3
AS2
AS3
FE (seq = 20)
FE (seq = 20)
SMS
ALE: AgentAliveEvent
FE: FailureEvent
Discarded by SMS
Agent Failure
FailureEventDetector
Triggered by TimerEvent
AS1
A1
A2
A1
Install Agent
SMS
FE: FailureEvent
AS2
FE
Agent Server Failure
FailureEventDetector
Triggered by TimerEvent
AS1
A1
A2
AS2
Install Agent
A1
SMS
FE: FailureEvent
FE
SMS would not be able to
install the agent. Informs
the 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
Tanvir Ahmed
Sumedh Pathak
Megan Carney
Abhijit Pathak
-
Overall
Initial Implementation
,,
,,
File System Monitoring