Fact of the week
Most breaches of security in high level organizations come from within. When looking for the alien, don't just point your telescope at the skies!
So far in the course we have talked about avoiding the possibility of break-ins, exploitation and breaches of privacy. We have looked at ways of verifying identity, placing access controls on data, encrypting communication and some software rules for keeping out hackers. Now let us turn our attention to another issue: how do we know if all of our security was successful or not? How can we determine whether security was breached? This is the issue of intrusion detection or security surveillance.
As with cryptography, intrusion detection systems (IDS) are the latest craze in computer security. As with cryptography, IDS is overhyped but nonetheless interesting. An IDS is the last thing you should think of implementing at at site. There is no sense in having a security camera to watch thieves rob your bank, unless you lock the door. Otherwise this is just a kind of voyeurism. IDS will probably not save you from any advanced attacks, because the sophisticated intruder knows how to get around the alarms, or fool them. Probably the best one can hope for with an IDS is to gauge an impression of how many potential intruders are trying the lock.
What is an intrusion or an attempted intrusion? This can be difficult to define. If someone tries to login at root once? If someone tries to login at root fifty times? Port scanning, SATAN or ISS scan? Someone trying a known security hole?
The aim of an intrusion detection system is to detect break-ins in progress so that something can be done about them. Obviously the first thing one should worry about is how difficult it is to break in in the first place. If we have done the job of securing data well enough, why are we worried that anyone will be able to get in?
Intrusion detection is a form of fault-diagnosis. Faults (in a security system) are not supposed to happen, but the fact is that they do happen. As with all fault diagnosis systems, IDS give the wrong answers from time to time. Because it is so difficult to define what intrusion actually means in a generic sense (it's political) intrusion detection systems tend to err on the side of caution and report many false positives, i.e. false alarms.
This is a very difficult problem to do in real time. What does real-time mean? Some attacks are stealthy and occur over many hours or days. HOw can we make a prompt notification about such attempts? The intrusion detection will have to be fast to detect quick break-ins, but have a long memory in order to see slow ones (like the thief digging a tunnel into the bank with a tea-spoon).
How will we be alerted or notified about intrusions? By alarm on the screen? By E-mail or pager alert? What if the attacker first knocks out E-mail or the pager link?
User privacy is also a problem. If an intrusion detection system examines everything going on within the system, looking for suspicious behaviour, is that an intrusion of privacy? What if humans never see the data, but only the warnings? Where do we draw the line between justified and unjustified surveillance? Law enforcement agencies have been arguing about that one for years!
In 1986 Dorothy Denning published a paper "An intrusion detection model" which has been the basis of much of current thinking on the subject. Basically one audits the activities of the system, and the communications traffic on the network, looking for suspicious signatures. What is a signature?
Note that analyzing network traffic becomes impossible as traffic is encrypted, so this approach does not have much of a future, when IPv6 comes along. Today intrusion detectors have to try to reassemble fragmented packets to follow data streams long enough to analyze their content. This requires work at very high speed. Packets get dropped. The detectors can be fooled. They probably have exploitable bugs.
- File existence/checksum violations (Viruses, Trojan horses)
- File permission violations
- Illegal processes/missing processes
- Packet sniffers
- Port scanners (nmap)
- Covert communications (eggdrop, irc-bots)
- Suspicious traffic
- Tampering with a honey-pot.
There are two types of intrusion detection
- Rule based intrusion detection: testing for specific occurrences, e.g. seeing whether a particular private port is accessed.
- Statistical anomaly detection: looking for anything out of the ordinary, by collecting data on what `ordinary' is.
What is suspicious? This requires a large knowledge-base of things which people have identified as suspicious already. Signatures are also specific to OS flavours, in practice that means you will find off-the-shelf stuff for NT and Solaris, maybe GNU/Linux. The databases need to be updated all the time to detect new signatures.
IDS can detect a few things quite well, but this approach is no more advanced than military censorship of the mail during wartime. How can they know about every protocol? What about meta-protocols like RPC and SMB?
A very interesting idea which might be used both in fault-diagnosis and security intrusion detection is the idea of anomaly detection. In anomaly detection we are looking for anything abnormal. That could come from abnormal traffic, patterns of kernel activity, changes in the statistical profiles of usage.
Need some method for tracking patterns in statistical samples. Neural networks have been used for this, but the problem here is that no one really understands how neural networks work: they classify information by lumping similar things into similar categories. Neural networks first have to be trained using "normal" data, then they can be switched into production mode in order to detect anomalies. There is a coarse graining of information which means that networks throw away all but the information parameters which the network models. When a network detects a signature, there is never enough information left to be able to say why they produce the result they do! This can lead to embarrassing problems.
Basically anomaly detection is an unsolved problem, but there is a lot of research into it because it is very interesting and it has the potential to solve a general problem without a rule-base. But these systems have to look at data over long periods of time and this costs a lot of data storage.
A common way for hackers to gather information about a network, is to perform a port scan. A port scanner is simply a program which attempts to establish a network connection to every single port number 1,2,3,4,5....5000,... on every host on the network. By seeing what kind of response it gets, the program is able to guess what network servives are running on which hosts. This gives hackers a good idea about what services can be exploited. Often it is also possible to see version numbers of software and thereby idetify any servers which have known security holes.A port scan looks like this:
Port scanners are freely available. nmap is such a program. Because early port scanners could be detected as they activated little used ports, or all ports in a sequence, newer port scanners have so-called stealth scan functionality: a stealth scan occurs over a long period of time, and randomizes the order of the ports scanned.
host% nmap 192.0.2.* Starting nmap V. 2.07 by Fyodor (email@example.com, www.insecure.org/nmap/) Host (192.0.2.0) seems to be a subnet broadcast address (returned 23 extra pings). Skipping host. Strange error from connect (101):No ports open for host (192.0.2.0) Interesting ports on cadeler30-gw.uninett.no (192.0.2.1): Port State Protocol Service 23 open tcp telnet 79 open tcp finger 6001 open tcp xwin Interesting ports on sigmund.iu.hio.no (192.0.2.2): Port State Protocol Service 9 open tcp discard 13 open tcp daytime 37 open tcp time 79 open tcp finger 80 open tcp http 111 open tcp sunrpc 487 open tcp saft 515 open tcp printer 706 open tcp unknown 751 open tcp kerberos_master 1024 open tcp unknown 1025 open tcp listen 2003 open tcp cfingerd 2049 open tcp nfs 5308 open tcp cfengine 6000 open tcp xterm ....
We can rig up alarms on specific objects which reflect the way they are used and ways in which they should not be used. For instance, if someone edits the password file without registering first with a monitor.
It is a sobering thought that the most efficient intrusion blocking and detection system which exists is in the human body. Only one in ten million harmful organisms entering the body ever get past our inital defenses. Of those, many will be destroyed by natural killer cells which react to the vandalism caused by bacteria and viruses. Those which remain are targeted by a specific immune response (B and T lymphocytes) which are able to detect something like 1012 different harmful entities. Even with this vast repertoire of security checks, we still get sick and need the help of doctors!
The human immune system has been the inspiration for several approaches to computer security. Researchers in New Mexico have tried looking for suspicious acitivity by matching signatures of kernel system call patterns. This allows one to detect exploits in programs which are not Trojan horses. (i.e. when the MD5 checksum is correct, but when a program is being exploited to do something dangerous, as in a buffer overflow).
Thought for the week
The big problem with intrusion detection is that the intrusion detection itself system becomes a target for attack. Since they generally work very hard, on the edge of what is possible, it is probably not hard to fool them, or at least execute a denial or service attack on them.