Security and Robustness in an Agent-based Network Monitoring System

1
Security and Robustness in an Agent-based
Network Monitoring System

• Plan B Project
• Koka Muralidhar
• Advisor Prof. Tripathi
• University of Minnesota

2
Outline

1. Motivation
2. Monitoring System Overview
3. Security
4. Robustness
5. System Capabilities and Experiences
6. Conclusions and Future Work

3
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

4
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 administrators response to critical
  events
• contd

5
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

6
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

7
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.

8
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

9
2. Mobile Agents in Ajanta
Agent-Agent Communication
Agent Migration
X
Y
Y
Agent Server 1
Agent Server 2
Server- Server protocol
Host A
Host B
Physical Network
10
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.

11
Network Monitoring Architecture
System Management Servers
Inspector Agent
IA
policy
policy
Launch Agent
Launch Agent
Auditor Agent
AA
Host D
Host B
Host C
Host A
MA
IA
MA
AA
MA
MA
AA
IA
Agent Server
Agent Server
Agent Server
Agent Server
Event Notifications
Host F
Host E
Agent Migration
SA
SA
AA
AA
Agent Server
Agent Server
Events Database
12
Subscriber Agent
Subscriber Interface
Remote Interface
Monitor Interface
Event Processor Thread
Event Queue
A
(1)
(3) CheckEvent
Event Notification
Trigger Table
A ? (B,C)
(2)
A
Event Detector
Event Handler
Subscriber List
B
(4)
(5)
trigger
C
trigger
Monitor Table
Database
13
Trigger Dependencies
Event Generation
Detector Triggering
TimerEvent
SyslogEvent
XDMEvent
SshStpEvent
LoginEvent
Feb 17 151239 newton sshd10899 ID 800047
auth.info Accepted password for koka from
128.101.35.177 port 45827 ssh2
14
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

15
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
• dont 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
  urnansplato.cs.umn.edu/koka

16
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

17
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.

18
Inter-Agent Communication
1. A1 sends challenge
A2
A1
2. A2 signs challenge, sends response
3. A1 signs response
AS1
AS2

• Uses Needham-Schroeders 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

19
Method Invocation
M (, Ticket t)
M (, Ticket)
check if t is valid
check if A1 from AS1 has permission for M
// Method..
A1
A2
AS1
AS2
20
Various Parameters

• A1cred agent A1s credentials
• U1cert user U1s 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

21
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

22
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))

23
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..

24
Agent Access Control Policy Spec.

• METHOD addDetector java.lang.String,
  ajanta.util.Ticket
• URN URNansplato.cs.umn.edu/U2/AS2/
  A2
• LOCATION URNansplato.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.

25
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

26
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

27
Robustness
TimerEvent
TimerEvent
AgentAliveEvent
A1
A2
AS1
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

28
Robustnessconstraints

• 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
• Dont install agents/detectors unless it is
  necessary

29
Detector Failure
ALE (seq 20)
TimerEvent
ALE (seq 20)
A1
AS1
A2
A3
AS2
Install Detector
AS3
FE (seq 20)
FE (seq 20)
Discarded by SMS
SMS
ALE AgentAliveEvent FE FailureEvent
30
Agent Failure
FailureEventDetector Triggered by TimerEvent
A1
A2
AS1
AS2
A1
FE
Install Agent
SMS
FE FailureEvent
31
Agent Server Failure
FailureEventDetector Triggered by TimerEvent
A1
A2
AS1
AS2
FE
A1
Install Agent
SMS
SMS would not be able to install the agent.
Informs the administrator
FE FailureEvent
32
5. System Capabilities

• System log monitors
• Process monitors
• File Consistency inspectors
• Host fingerprint inspectors
• Integrated Snort

33
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

34
Performance

• Figurewhat can you do to reduce
• CPU usage

35
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

36
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

37
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

38
Acknowledgements

• Prof. Tripathi - Overall
• Tanvir Ahmed - Initial Implementation
• Sumedh Pathak - ,,
• Megan Carney - ,,
• Abhijit Pathak - File System Monitoring