One of the most important tasks of a System Administrator is to keep the machine safe from information disruption. This includes hardware failures, user errors, information incoherence, attacks from outside, and many other troubles. Too many to be listed, too many to be solved. While it's almost impossible to prevent hardware failures (e.g.: if the hard disk stops working, there's nothing you can do to recover the data, except from sending it to a specialized lab and pay a lot of money), you can do something to protect your system and your network. The most important thing to remember is that nothing is perfect, so your well-working computer in your fast and reliable network could suddenly say "goodbye"; the best assumption to do is that you can never feel safe. It could sound catastrophic, but that is.
A lot of things have been done during the last years, and now we have some valid solutions to help us. For example, we have the RAID for the hard disks, Firewalls for network security, and so on. But they can't always be perfect. Firewalls offer a first protection against external attacks, but can't do much if the attack comes from our machine or network. So we will focus our attention on intrusions, actions that attempt to compromise the integrity, confidentiality or availability of a particular resource. There are many ways to protect from unauthorized intrusions: we could try to prevent them or we can try to detect them. The first thing to try is, in fact, to keep unfair users out of our resources, but there are a lot of situations in which it's not completely possible. Setting a strict security policy could bring to an unusable system, and regular users could have hard times to keep working. On the other hand, setting a fair policy could expose our precious devices to a lot of attacks and our important bytes could be compromised. We want to prevent it, as information integrity and reliability is our main task.
A general System Administrator's life could be described in some steps:
In order to allow a secure control on what comes in/gets out from our System (or from our LAN), we can set a powerful tool, which can be in the form of a program running on a machine (even our server, but that's not a good idea, especially for high loaded serverstypeset@protect @@footnote SF@gobble@opt There are some reasons why it's discouraged. One of them is that it could add some (sometimes much) load to the server. The performance could be compromised and the system could slow down too much to keep working efficiently. As second reason, we must keep in mind that no program is perfect and, one day or another, someone could find a bug and break into the firewall, getting root privileges. If the machine was just a firewall, it should not be a big issue, since he would not get access to any important data (at most it would bring just into a DoS), but if it was our main server server...) or a stand-alone machine (a dedicated machine, usually integrated with the router. It's a computer, too, but projected and optimized to do only those jobs and often in the form of a box with some ports behind for net cables). Both of them are secure as both of them are insecure, since their behavior is more or less the same. On Figure Fig:A General Firewall we can see a general representation of the use of this solution.
One of the biggest troubles to face when configuring and tuning a
firewall is the choice of a good rule-set.
There are some approaches, but we must find a compromise between security and usability, as shown in TableTab:Firewall Security Strategies.
So, to sum up, firewall approach has some pros and some cons.
So, what can we do to cach'em all?
As matter of facts, a firewall alone is not enough to sleep well at night. We have to set another layer of protection. It should not replace the firewall, should work together with it, side by side.
The firewall is a powerful tool to filter what's getting in and what's going out, but we've seen it's almost unuseful to find out internal attacks or attacks coming from a channel not controlled by the firewall. So we can't be sure we can prevent an intrusion, and we need a technique to discover it and reply. We can sum up this way:
IDS is an acronym of Intrusion Detection Systems, that is something that allows to detect an intrusion as it happens and be able to respond to it in an efficient manner. IDS is a generic concept, there is not a fixed standard for it. There may exist a lot of different IDS, behaving in really different ways, implemented in different languages (perl, C, even Java) and, of course, with different configurations and efficiency, often regulated by a policy. This brings, as usual, some troubles to the poor administrator. Being an automatic system, sometimes it could not detect properly what's happening. So we could have false positives or false negatives. Have a look at table Tab:IDS choice and sensibility tuning. As you can see, a strict policy can lead to a lot of false positives, which should normally be reduced, while a too permissive policy will lead to many false negatives, which have to be normally avoided.
False negatives, in turn, won't detect a real intrusion and the attacker will have all the time to do anything he wants, including turning off the firewall, the IDS, or clearing the logs and deleting the evidences of his passage. He could, as well, install a trojan horse and create a door to get in again without troubles (e.g.: back door). That's absolutely to be avoided: if the attacker has arrived here, he's already passed beyond the firewall, so no other protection will be availabletypeset@protect @@footnote SF@gobble@opt Apart from the single daemons' security routines, which could be buggy or intrinsically insecure. Often they have to get root access, at least to open the sockets. If an intruder knows it, he could easily get root privileges.. So, the questions could be:
A bastion host [Dillard1] is a computer that is fully exposed to attacks. The system is on the public side of the demilitarized zone, sometimes even unprotected by a firewall or filtering router. Frequently the roles of these systems are critical to the network security system. Indeed the firewalls and routers can be considered bastion hosts. Due to their exposure a great deal of effort must be put into designing and configuring bastion hosts to minimize the chances of penetration. Other types of bastion hosts include web, mail, DNS, and FTP servers. Some network administrators will also use sacrificial lambs as bastion hosts, these systems are deliberately exposed to potential hackers to both delay and facilitate tracking of attempted break-ins.
Effective bastion hosts are configured very differently from typical hosts. Each bastion host fulfills a specific role, all unnecessary services, protocols, programs, and network ports are disabled or removed. Bastion hosts do not share authentication services with trusted hosts within the network so that if a bastion is compromised the intruder will still not have ``the keys to the castle''. A bastion host is hardened to limit potential methods of attack. The specific steps to harden a particular bastion host depend upon the intended role of that host as well as the operating system and software that it will be running. Access Control Lists (ACLs) will be modified on the file system and other system objects; all unnecessary TCP and UDP ports will be disabled; all non-critical services and daemons will be removed; as many utilities and system configuration tools as is practical will also be removed. All appropriate service packs, hot fixes, and patches should be installed. Logging of all security related events need to be enabled and steps need to be taken to ensure the integrity of the logs so that a successful intruder is unable to erase evidence of their visit. Any local user account and password databases should be encrypted if possible.
The last step to securing a bastion host may be the most difficult: securing whatever network application the host is running. Very often the vendor of a web or streaming media server doesn't consider security risks while developing their product. It is usually up to the system administrator to determine through testing what ACLs they need to modify to lock down the network application as thoroughly as possible without disabling the very features that make is a useful tool. It is also necessary to closely track the latest announcements from the vendor regarding security problems, workarounds, and patches. The more popular network applications also tend to inspire the creation of independent mailing lists, newsgroups, and websites that can be tracked for additional insights.
Honeypots are programs that simulate one or more network services that you designate on your computer's ports. An attacker assumes you're running vulnerable services that can be used to break into the machine. A honeypot can be used to log access attempts to those ports including the attacker's keystrokes. This could give you advanced warning of a more concerted attack.
One honeypot program is called the Deception Tool Kit, which can be downloaded from http://www.all.net/dtk/. You can configure the responses for each port.
Honeypots are most successful when run on well-know servers, such as Web, mail, or DNS servers because these systems are often attacked. They can also be used when a system comes under attack by substituting a honeypot system for the target.
Year by year, the IDS technology has done a lot of steps and a lot of models have been invented and tested. Each model has its own features and its branch of develop, so we have to distinguish between some (main) categories:
A host based ID System consists mainly in loading a software program
(or a set of programs) into the system you want to keep controlled.
This software uses the system log and other security logs and/or auditing
agents to see what's happening. This involves that the System Administrator
must be enough competent and should know perfectly all the programs
installed (in order to distinguish between normal using and suspect
processes) and his user's habits (some careful SysAdms have detected
some attacks just ``feeling something different'' on the system's
behaviour or seeing users logged at strange hours).
So, it's important to remember that without a careful Administrator, the system can never be considered safe!
This kind of approach consists not only in checking network traffic getting in/going out, but also controlling the integrity of the system files and suspicious processes. If you're administering a network and you want to use this kind of solution, you have of course to install it on every single machine, as shown in figure Fig:Host Based IDS Example. There are two primary classes of host-based intrusion detection software: host wrappers/personal firewalls and agent-based software. Either approach is much more effective in detecting trusted-insider attacks (so-called anomalous activity) than is network-based ID, and both are relatively effective for detecting attacks from the outside.
This kind of IDS monitors continuously its associated network. This means that the only source of data is the network traffic. Usually, this is performed by placing a ``filter'' on the network interface and capturing a copy of the packets to analyze them. Because of this, if another interface is connected to the machine (and the IDS is not updated to face the changes), it will have no effect on the new device (and, of course, on the data flow passing through that path). An example can be seen on figure Fig:Network Based IDS:
About the ``Model Of Intrusion'' approach, there are some good
papers I will use to be clearer. One of them is [Gordeev1].
The first well known approach deals with detection of a certain anomaly in a user behaviour. Let's explain it in more detail. Each user of a computer system is capable of performing some tasks, according to his permissions. In other words, each user has a certain functionality within the system. Usually this functionality is observable and does not change a lot in time. For example, a secretary due to her or his job speciality usually deals with a limited number of tasks like typing various documents, reading and sending mail, etc. Unlikely he or she will start programming and using compilers. A system administrator accesses system configuration areas, run statistic, audit, installing and monitoring applications. A programmer's tasks is obvious - write a program, compile, and debug. This means that it is possible to define a set of actions usually performed by an user. Often, this set is also called a user profile that describes user's normal behaviour. Table Tab: Example: General common user profiles gives a rather general and intuitive example of a number of common user profilestypeset@protect @@footnote SF@gobble@opt Of course, profiles should not be too static. We can't forbid the boss to surf the net or do video conferencing, when needed. And we shouldn't be awaken up at 2AM because the secretary is trying to send a buisness mail she had forgotten of..
This is of course a rather general example. Real profiles deal with more precise categories (sometimes up to system calls) and are more flexible in constrains of a user normal behaviour (e.g. boss could sometimes send mail and browse Internet, so they should be not too static).
After such profiles are defined, it is already manageable to trace current user behaviour and to search for some deviations from it. Such deviations are called anomaly and indicate in most cases an intrusion. An intuitive example could be, when a secretary logs in at 9:00 pm, accesses management software and, finally, tries to get system administrator privileges. See table Tab: General common user anomaly for an an example on how to trace an anomaly.
Usage of this approach intends in a need in learning a normal user behaviour. In other words, it means that IDS must have a knowledge about the user behaviour priori its normal operationtypeset@protect @@footnote SF@gobble@opt Often it's not easy, so you should trace the common user profiles before starting the IDS.
Advantages of behavior based approaches are that they can detect attempts to exploit new and unforeseen vulnerabilities. They can even contribute to the (partially) automatic discovery of these new attacks. They are less dependent on operating system-specific mechanisms. They also help detect ``abuse of privileges'' types of attacks that do not actually involve exploiting any security vulnerability. In short, this is the paranoid approach:
Everything which has not been seen previously is dangerous.The high false alarm rate is generally cited as the main drawback of behavior-based techniques because the entire scope of the behavior of an information system may not be covered during the learning phase. Also, behavior can change over time, introducing the need for periodic online retraining of the behavior profile, resulting either in unavailability of the intrusion detection system or in additional false alarms. The information system can undergo attacks at the same time the intrusion detection system is learning the behavior. As a result, the behavior profile contains intrusive behavior, which is not detected as anomalous.
Almost any intrusion can be described in terms of its indications and signs. First of all, signatures of all known attacks must be described in some sort of database and given to the IDS. This patternstypeset@protect @@footnote SF@gobble@opt The ``signature'' is just composed by regular patterns are used later by the IDS to identify an intrusion. This is done in order to study the system audit information,to find some signatures matching to patterns known to be a part of system intrusions.
A good example to demonstrate this approach could be a well known SYN flood denial of service attack. Its goal is to prevent the target host from accepting new connections on a given IP port. The implementation of this attack utilizes a three-step handshake schema of a TCP/IP connection establishment and usually exploits a resource exhaustion vulnerability that is common for many TCP/IP implementations. The basic idea is the following: when a client opens a TCP/IP connection, it sends a SYN packet to the server, which receives it and allocates an entry in a connection queue. Such connection is referred as being half-open. Then the server sends a SYN-ACK packet to the client that must be acknowledged by a ACK packet sent by the client to the server. After receiving the acknowledgement, the server releases the corresponding entry in the queue. This procedure can be exploited by an intruder that sends series of SYN packets to the server and does not acknowledge them. This will result in a queue overflow, since the finite connections queue of the server will get filled up and will be not emptied until timeout periods will not expire. The result is: the server is not able to accept connections on the attacked port any more.
This attack is characterized in general by the following indications:
In a similar manner indications of other attacks can be figured out. They are represented in a certain form and coded to IDS. There is a number of methods for intrusions representation and their further recognition. Two of the most widely methods are state transition analysis and rule-based expert system.
The following sections are pieces of articles I've found surfing the net, which I've changed and adapted to satisfy our needs. They could give an idea of what can be done to ``teach'' the IDS how to work.
State transition analysis was developed few years ago by the Reliable Software Group at University of California, Santa Barbara (see [Ilgun95] for more details). This method is used for representing a sequence of actions that an intruder performs to break into a system. These actions and requirements to them are represented by a state transition diagram. It is based on a premise that all intrusions have the following two common features:
Apart from the states, signature actions are identified. Signature actions mean a minimal set of actions needed to complete the intrusion. If at least one of them is omitted, the intrusion will be not completed (e.g.: if the intruder is an internal user and can't get any higher permission and/or access to data he should not see, it's considered like if the attack. has failed, no alarm is generated).
Finally, the states, transitions and signature actions are represented graphically in a form of a state transition diagram. A good feature of this approach is that the threat scenario is represented in a visual form and very easy to read.
Lets demonstrate this approach with a small example. A number of security mailing lists have announced in January 2000 a vulnerability in a authentication schema of Intel InBusiness E-mail station, a small office application server. It lets remote users to connect to the server and perform some commands without any authentication. This could lead to giving an attacker a system command prompt under super-user privileges. This attack involves the following steps (see the visual form on figure Fig: State Transition Analysis Example):
Rule-based expert system are used very often as the ``engine'' of an intrusion detection system. One of the most interesting things about this approach is that it is used in both anomaly detection systems and misuse detection systems. In such systems, like in any other expert system, declarative knowledge related to intrusions is separated from an inference engine performing a reasoning about the fact basetypeset@protect @@footnote SF@gobble@opt So the ``brain'' of the program can change, but the database can be left unmodified. In other words, it means that, in general, three main components can be distinguished:
figure Fig:Heuristic Analysis: we could see the system as a machine where each check produces a response: ``ok'' or ``failed''. If all the checks say ``failed'', the system will alarm and say it's under attack.
Expert systems are also used for anomaly detection. As already explained before (see section Arg: Anomaly Detection Model), this approach needs some kind of learning of normal user behavior and anomalies in it. That is actually the basic difference in using rule based expert systems for anomaly and misuse detection. In the first case, the rules are generated using some other techniques. In the second case, the rules are given to the system in advance, so you probably will have to leave the system unprotected (or protected by other kinds of IDS) and trace a correct usage profile.
There is a number of methods used to obtain rules describing user behavior. One of the known methods is data mining[Stolfo98]. This method extracts descriptive models from huge amounts of data. In general, it uses three groups of algorithms originating from a variety of fields like statistic, pattern recognition, and machine learning:
Neural Networks offer an alternative means of maintaining a model of expected normal user behavior. They may offer a more efficient, less complex, and better performing model than mean and standard deviation, time decayed models of system and user behavior. Neural network techniques are still in the research stage and their utility have yet to be proven. They may be found to be more efficient and less computationally intensive than conventional rule based systems. However, a lengthy, careful training phase is required with skilled monitoring.
Many corporate networks and corporate security policies rely heavily on intrusion detection to alert administrators of intrusion. It would be impossible to do in other ways, even keeping in mind that it's not a perfect technology. With all of the features of modern intrusion detection systems there are some tragic flaws inherent in their design. These weaknesses apply to all other signature based intrusion detection engines.
Snort is an intrusion detection system written by Martin Roesch. Snort is was written as an open source project and is available for free under the GNU public license. The software is based upon a signature comparison engine optimized for speed. Snort offers many features that make it an ideal choice in the battle against Internet intruders. Here is a description of Snort from the Snort website:
Snort is a lightweight network intrusion detection system, capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching/matching and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more. Snort uses a flexible rules language to describe traffic that it should collect or pass, as well as a detection engine that utilizes a modular plugin architecture.Snort was written to take advantage of a highly modularized design. The application can take advantage of several different pre-processors to normalize, filter, and categorize data. Snort also has very powerful post-processors, or output plug-ins, that can be used to log the data generated by Snort in several different ways. Because Snort is an open source project and that it has many users its signature database is updated often and are simple to update.
Understanding how signatures work is essential to understanding how to defeat them. When Snort is given an incoming packet from the packet capture driver it compares that packet to its database of known signatures. The signature has some key aspect of the packet that it is compared against to look for a match. If a match occurs than Snort sends the output to a standard output mechanism or to one of the configured post-processor output plug-ins. For example if Snort received the following packet then it would compare it against its database:
03/21-13:02:34.978853 10.1.114.88:1272 -> 10.1.114.220:54320
TCP TTL:128 TOS:0x0 ID:48408 IpLen:20 DgmLen:44 DF
******S* Seq: 0x2BC3D9 Ack: 0x0 Win: 0x2000 TcpLen: 24
TCP Options (1) => MSS: 1460and match it to rule:
alert tcp $EXTERNAL_NET any -> $HOME_NET 54320 (msg: "BACKDOOR SIG - BO2K";)This event would trigger an alert message. Most signatures do not just look for what port a packet is to or from, but it also examines part of the payload. As new security holes and exploits are found new signatures are written to counteract the danger.
What Snort and other signature based intrusion detection systems count on is that malicious traffic will have unique patterns to it that can be matched against rules in the database. It then seems obvious that there are many ways of circumventing this signature. The first thing that we could do is vary the destination port, but it's often undesirable since the destination machine could be running a particular service listening to a particular port. Because of this, we could do a large scan of ip numbers trying to connect to that port. But, in this case, Snort could detect it. Let's do another example: Back Orifice, a trojan for windows, installed itself at port 54320 (as in the example written before). The port cannot (easily) be changed, so, to avoid signature matching, we've got to change something else on the header. This could be accomplished by using some very simple form of encryption, passing over Snort's checks but arriving where we want to. . Another twist of this technique could incorporate public key/ private key encryption. The private key for the server and the public key for the client could be sent or bundled with the original install. This would render all communication between the 2 hosts unintelligible and undetectable by intrusion detection systems.
It's now clear that Snort and other intrusion detection systems do their best job in detecting attacks on services that require an exploit and that cannot be encrypted. Attacks like this would include buffer overflows, scanning attempts, etc. These types of attacks are based on existing bugs within the victim machine. These flaws can typically only be exploited using a certain attack routine that will have a certain signature. In these cases signature based intrusion detection does very well at detecting these patterns and alerting (or stopping them).
The problem with intrusion detection as it relates to attacks on services is that it may take some (sometimes long) time for a new exploit to become known, especially if talking about rarely used pieces of software. After the exploit is known then a new signature can be written for it and distributed. This leaves many systems vulnerable to unknowin attacks for a certain period of time. It is possible that a well-executed attack will leave no trace of intrusion thereby rendering all of the effort placed into intrusion detection wasted. IDS are also hurt by a lack of supporting data for attacks that were not immediately recognized. To explain it better, we could say that the IDS will start logging only when an intrusion is detected. Sometimes, before being caught the attacker could have done a lot of things and damages. More, the source of his penetration could not be identified.
There are also some other ways to confuse an IDS. One of them is the ``Denial Of Service'' technique. The attacker can do a lot of noise before starting the real attack, confusing the IDS (that, trying to face and reply, could get overloaded) and the operators, which will have to spend a lot of time before catching out which one of the attempted attacks is the successful one. Another possible method of implementing a denial of service against an IDS would be to exhaust the resources of that IDS. This denial of service would flood the IDS with traffic that will generate alerts until the IDS runs out of resources. This would cause the IDS to have an incomplete log of the events that took place. Have a look at figure Fig: An Attempt to DoS a Signature Based IDS for a graphical example of this approach.
Silicon Defense's SPICE (Stealthy Portscan and Intrusion Correlation Engine) project is a DARPA-sponsored development-effort whose aim is to build a better mousetrap capable of detecting stealthy port scans. SPICE consists of two components, an anomaly sensor and a correlation engine. SPADE is the anomaly detector, which acts as a plug-in preprocessor to Snort(described on page ) . The correlation engine is still under development.
SPADE looks carefully at the network traffic, performs some calculations (I won't explain here, we'd go too deep) and tries to figure out what's happening. If everything is ``in line'' with the normal system's work, no alert is launched. Those calculations are made assigning an anomaly level (A) to any event occurring, which is dependant on the probability (P) that a particular event will happen. For example, a connection to the port 80 for a machine that is acting as a web server will have an high probability value and a low anomaly one. The higher P is, the lower A is, of course. The settings for SPADE need tuning to match the protected network. One tunable factor is the alert-threshold. This can be set manually and tuned by the analyst, or SPADE itself can be set to set its own threshold level. In default learning mode, SPADE will monitor network traffic for 24 hours. Then it will calculate the threshold level required to create 200 alerts in that monitoring period. The length of the monitoring period and the number of alerts to generate are selectable.
As it runs, SPADE will generate a probability table of observed network traffic. This table contains critical information and should be protected and backed-up. If this file is lost, SPADE will need to be retrained, exposing your network as the history is rebuilt and alerts are not generated. When operating in survey-mode, SPADE will generate reports on observed probability distributions of the network traffic. SPADE can be placed into statistical mode if one wishes to view the probability tables on a regular basis.
Currently, SPADE simply generates alerts on packets whose anomaly score (as calculated by SPADE,) exceeds the anomaly threshold level. These alerts are logged along with the other Snort alerts. It is the correlation engine, which is still under development, which promises to detect the stealthiest of port scans. The correlation engine is fed alerts from the anomaly detector. The alerts contain the event, and the anomaly score. The correlation engine will keep an event in memory based on its anomaly score. The higher the score, the more anomalous the event, thus the longer it will keep its state. The correlation engine then attempts to link the events into groups to possibly link rare events to a single cause. Links between a given pair of events are calculated by a series of heuristic functions. If the source IP or the destination port or network are the same in the two events, a given heuristic would fire.
There is still much work to be done in the field of anomaly based detection. Misuse detection based on signature matching has limitations; these limitations can be lowered through the use of anomaly based detection. The fusion of both misuse detection and anomaly detection techniques will result in a more effective and efficient Network Intrusion Detection System.
The IDS research is new in computer sciences. There are still a lot of steps to do and today's solutions are still young. However, the experience of last years demonstrated that there is a strong demand on intrusion detection systems. Very often, a need in them is expressed on a state level. For instance, the USA government has announced in January 2000 that a global intrusion detection system covering the governmental computer network will be created. A lot of enterprises of different size already use these system for ensuring their business security.
This document was generated using the LaTeX2HTML translator Version 2002-2 (1.70)
Copyright © 1993, 1994, 1995, 1996,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -no_subdir -split 0 -show_section_numbers /tmp/lyx_tmpdir13166NysWhv/lyx_tmpbuf2/relazione.tex
The translation was initiated by Stefano Marinelli on 2003-06-06