1 / 38

Security and Robustness in an Agent-based Network Monitoring System

Security and Robustness in an Agent-based Network Monitoring System. Plan B Project Koka Muralidhar Advisor: Prof. Tripathi University of Minnesota. Outline. Motivation Monitoring System Overview Security Robustness System Capabilities and Experiences Conclusions and Future Work.

chill
Télécharger la présentation

Security and Robustness in an Agent-based Network Monitoring System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security and Robustness in an Agent-based Network Monitoring System Plan B Project Koka Muralidhar Advisor: Prof. Tripathi University of Minnesota

  2. Outline • Motivation • Monitoring System Overview • Security • Robustness • System Capabilities and Experiences • 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 administrator’s 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 eventsfrom different nodes • Example: Multiple root login attempts across different hosts by an unauthorized user.

  11. MA Monitor Agent SA Subscriber Agent Network Monitoring Architecture System Management Servers Inspector Agent IA policy policy Launch Agent Launch Agent AA Auditor Agent Host D Host B Host C Host A MA AA MA AA MA IA IA MA Agent Server Agent Server Agent Server Agent Server Event Notifications Host F Host E Agent Migration SA AA AA SA Agent Server Agent Server Events Database

  12. Subscriber Agent Subscriber Interface Monitor Interface Remote 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 (5) (4) trigger C trigger Monitor Table Database

  13. TimerEventHandler SyslogEventHandler XDMEventHandler SshSftpEventHandler LoginEventHandler TimerEventDetector SyslogEventDetector XDMEventDetector SshSftpEventDetector LoginEventDetector Trigger Dependencies Event Generation Detector Triggering Feb 17 15:12:39 newton sshd[10899]: [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 = * • # 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

  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 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. A1 A2 AS1 AS2

  18. Inter-Agent Communication 1. A1 sends challenge • 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 A1 A2 2. A2 signs challenge, sends response 3. A1 signs response AS1 AS2

  19. Method Invocation M (…, Ticket) M (…, Ticket t) { } check if t is valid check if A1 from AS1 has permission for M // Method.. A1 A2 AS1 AS2

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

  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 URN:ans:plato.cs.umn.edu/U2/AS2/A2 LOCATION 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.

  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 • Failure of all detectors in an agent is construed as agent failure • Failure to install an agent is construed as agent server failure A1 A2 AS1 AS2 FailureEvent Install Detector or Agent SMS

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

  29. Detector Failure ALE (seq = 20) ALE (seq = 20) TimerEvent A1 AS1 A2 A3 Install Detector AS2 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 • Figure…what 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

More Related