1 / 24

IDS

IDS. SOEN321, Fall 2004 Serguei Mokhov. Contents. IDS intro What it is good for How can you do it (anomaly detection, misuse detection) How it can be compromised (at least, automatic forms of it) Biggest problems. Intro. Started as detection of anomalous network traffic

sagittarius
Télécharger la présentation

IDS

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. IDS SOEN321, Fall 2004 Serguei Mokhov

  2. Contents • IDS intro • What it is good for • How can you do it (anomaly detection, misuse detection) • How it can be compromised (at least, automatic forms of it) • Biggest problems.

  3. Intro • Started as detection of anomalous network traffic • Difference with the firewalls? (prevention vs. detection) • More sophisticated: monitoring behavioral patterns of programs (system calls)/users (typical commands/activities)

  4. Principles • Actions of users and processes are statistically predictable. • Actions of users and processes do not include sequences of commands that subvert security. • Actions of processes lie inside a set of actions permitted by the security policy. • Violation of any of the above is an indicator of an attack.

  5. Example • An attacker wants to install a backdoor. • He enters as an ordinary user and then becomes root. • This is unusual if the user is not part of the admin group (principle 1). • While becoming root, the attacker uses "evil" sequences of commands (principle 2). • Moreover, any changes to system files may cause them to behave in ways they are not supposed to (principle 3). • Also, modifying a user file may allow processes executing on behalf of that user to, say, connect to sites they were unable to connect to before or by executing commands they could/did not executebefore (principle 1). • Note: Intrusions can be arbitrarily sophisticated.

  6. Rootkits and Attack Tools • Definition: An attack tool is an automated tool designed to violate asecurity policy. • Example: 'rootkit' is an attack tool; among other things, it sniffs passwords.It also installs fake versions of system programs.  These include fake: • netstat: conceals certain network connections • ps: conceals certain processes (e.g., the sniffer) • ls: conceals certain files (as does 'du')ifconfig: conceals promiscuous mode • login: accepts "magic" password • The cryptographic checksums of the fake programs are perfect. • We see that most of the obvious traces of an attack have been hidden.But, there are still certain integrity checks: • used blocks plus free blocks = all blocks • 'ls' should tell the truth about file counts • load average should reflect number of running processes • We can assess these quantities by programs other than the fake ones and do the analysis.  'Rootkit' did not corrupt the kernel/file structure, so otherprograms will continue to report correct information; only the fake programslie.

  7. Tripwire • File modification checks • Good against rootkits

  8. Automation • Can we automate the intrusion-detection process? • We want to automate: - anomaly detection - misuse detection - specification-based detection

  9. Goals of an IDS • Detect a wide variety of intrusions (including from insiders). • Detect intrusions in a timely fashion (both in real and non real time). • Digest/abstract. Present summary to expert human. • Accuracy (false positives, negatives). • Generally • anomaly models are statistically based • misuse models are signature based • specification models are specification based

  10. Anomaly Detection • Anomaly detection requires adaptive statistical profiling. • There is an infinite range of possibilities if only because there is an infinite range of variables. • Suppose I'm a mole and I want to read sensitive files without attractingattention.  My daily average is to peruse 5 files a day.  So, I plan ahead,opening 6, then 7, then 8, ... until my profile will not be disturbed as Iforage widely in files outside my "need-to-know" range. • Urban legend: Nervous people are shaky (they emit "tells") when they usetouchtone phones.  Back-of-the-envelope absurdity, if untargeted.  But,there is biometrics, typing rhythms, pseudopolygraphs.  Formally, thisrequires either pure math (some form of statistics) or AI (machine learningof predictive models. • Note that data mining is a generalization of statistics so many, many things are possible in principle.

  11. Misuse Modeling • Signature analysis actually generalizes to rule-based detection, but this requires a knowledge of system vulnerabilities. • This gets us into different flavors of AI. • One stab at a distinction: • Does the sequence of data match any of the rules (of bad stuff) as opposed to is it kind of unusual? • There is some brittleness here because you first have to have a good set of rules. • If anomaly detection is the art of looking for unusual states, then misuse detection is the art of looking for states known to be bad. • (Admins can tweak the rules, say in Network Flight Recoder, NFR.)

  12. Agent • Who gathers the information? • Obviously, it needs to be filtered (downselected) before it can be analyzed. • host-based information gathering: system and application logs • network-based information gathering: monitor network traffic (tcpdump), detect network-oriented attacks, use network sniffing • The major subtlety is that the analysis software must ensure that the view of the network traffic is identical across the set {analyzer, host1, host2, ...}.

  13. Notifier • Automatic or incident response. • Automatic: • If the IDSs on fw1 and fw2 detect a coordinated attack, they can instruct fw3 to reject packets from the source(s) of the attacks. • Let's look at an example of an IDS for detecting network intruders in realtime. - passively monitor network link over which an intruder's traffic passes - filter the network-traffic stream into a sequence of higher-level events - feed events into an analysis engine that checks conformity with the   security policy • We will also - look at a number of attacks that attempt to subvert passive monitoring   systems fw1 fw2 fw2

  14. Design Goals for a Network Monitor • no packet-filter drops: the missing traffic might contain precisely the interesting traffic; after all, an attacker might attack the monitor itself • real-time notification • extensible to include knowledge of new types of attacks

  15. Attacks on the monitor • overload, crash, subterfuge: • Overload: Drive the monitor to the point of overload, then attempt a network intrusion.  Defense: Can be mysterious about how much load you can handle. • Crash attacks: Kill the monitor (failure, resource exhaustion), then attack as before.  Defense: not particularly interesting. • Subterfuge attacks: The key idea is to find a traffic pattern that is interpreted in one way by the monitor and by an entirely different way by the receiving endpoint (target host). • Example: What if the monitor sees a particular packet that the endpoint doesnot?  How could this be accomplished by the attacker?  Launch a packet with an IP "Time to Live" (TTL) field just sufficient to get it past the monitorbut not sufficient to reach the endpoint.  Or, suppose the endpoint has asmaller "Maximum Transmission Unit" (MTU).  Just send a packet that is toobig with the "Do not fragment" bit set.

  16. Signature analysis • is when the IDS is programmed to interpret a certain series of packets, or a certain piece of data contained in a packet, as an attack. • Example: • An IDS that watches web servers might be programmed to look for the string "phf" as an indicator of a CGI-script attack. Most signature analysis is simple pattern matching: • Find "phf" in "GET/cgi-bin/phf?“ • Let's look at insertion and evasion attacks.

  17. Insertion attack • Here, an IDS accepts a packet that the end system rejects. • Thus, the IDS alone might see the "funny" packets. • This defeats signature analysis because it defeats the pattern matching.  To illustrate, consider:  GET/cgi-bin/....p....h....f....?where the dots stand for funny packets that only the monitor sees.

  18. Evasion attack • Here, the end-system accepts a packet that the IDS rejects. • There are all kinds of reasons why one computer can be more or less strict about accepting packets than another (checksums, fragments, sequence numbers, ...). • Since the packets are rejected by the monitor, the attack is not seen.

  19. Conceptual basis • IDS either- generates a model of a program's or system's response to known inputs, or- requires the generation of a rule base • An IDS that monitors raises an alarm if it detects a deviation from the model or a rule fires. • But how can you machine-learn the model?  We need some human help. • Expert Systems?

  20. Cont’ • Can we detect when an application has been penetrated and is then exploited to do harm to other parts of the system?  app   |    frame IDS problem as a sandbox problem   |   v    specify allowed sequences of system calls  O S • Think of the (uncorrupted) application as a finite-state machine (transition system) whose outputs are sequences of system calls.  A transition system can only generate _certain_ sequences of calls. • If you observe an impossible call sequence, it is likely that an attacker has introduced malicious code into the application's thread of control by means of a buffer overflow, a format-string attack, or whatever.

  21. Cont’ • We detect the insertion of malicious code by observing sequences of system calls that normally could not have occurred.  We use human intelligence to build a very abstract model of the application we wish to monitor. • We quickly detect "exploit code" running with the application's privilege. We first build a very abstract model of the application's (normal) behavior. • Most existing exploit scripts grab full root privilege and take other distinctive actions, such as launching a shell under the attacker's control. This is so blatant it does not require a sophisticated IDS to detect it. • But this abstract-model approach is able to detect when some of the backdoors (fake programs) of 'rootkit' are executed, which causes the behavior to deviate from that specified by the original source code and captured in the abstract model.

  22. Problems with IDS • Biggest: false positives • Require high level of expertise • Attacks (previously mentioned can be conducted).

  23. IDS vs. Firewall • Would you choose one of if you can afford only one of them: • IDS • Firewall • If you can afford both, would you opt for IDS? • Recall: firewalls prevent what IDSs detect.

  24. Refs • These slides largely based on Dr. Probst transcripts and the textbook.

More Related