Is a firewall the ultimate solution?
The term “firewall” is already a buzzword in computer literature. Firewall marketing companies have generated a straightforward association in the mentality of budget administrators: “We have a firewall in place and therefore our network must be secure”.
However, total reliance on the firewall tool, may provide a false sense of security. The firewall will not work alone (no matter how it is designed or implemented) as it is not a panacea. The firewall is simply one of many tools in a toolkit for IT security policy.
Let us briefly examine what tasks are attributed to contemporary firewalls. Firewalls control both incoming and outgoing network traffic. They can allow certain packets to pass through or else disable access for them. For example, a firewall can be configured to pass traffic solely to port 80 of the Web server and to port 25 of the email server. This simple example shows that a firewall cannot evaluate the contents of “legitimate” packets and can unknowingly pass through some attacks on the Web server.
There are different types of firewalls. In the firewall market there are many solutions – from firewall imitations to very advanced application filters.
Basically, a firewall removed from its packing and installed between the network and the Internet adds little improvements to the security of the system. Human intervention is also required to decide how to screen traffic and “instruct” the firewall to accept or deny incoming packets. It is de facto a complex and sensitive task. Just a single security policy rule established for the wrong reasons can lead to a system being vulnerable to outside attackers. Once must also remember, that a poorly configured firewall may worsen the system’s effective immunity to attacks. This is because system administrators may believe that their systems are safe inside the “Maginot Line” and will become lax towards internal day to day security standards, if a firewall is in place.
Similarly to “firewall” another buzzword has recently become very popular – “IDS”. IDS solutions are designed to monitor events in an IT system, thus complementing the first line of defense (behind firewalls) against attacks. This article will explain the IDS related terminology and take a closer look at the protection technology basics.
Monitoring IT systems: why and how?
It is common knowledge that a system administrator is similar to a policeman, (or to a security guard, if you like) since he/she is responsible for preventing outside attacks on an IT system. The difference is that policemen work on a shift basis providing round-the-clock coverage, therefore a non-stop watch is guaranteed. However such a situation goes beyond the expectations of the administration of an IT system. Another difference is that the Internet is not inherently secure, therefore contemporary IT systems are exposed to attacks that come from hackers worldwide for criminal intent. So, what should a contemporary “policeman” look like? How can one proactively protect one’s assets against unknown threats derived from unknown sources that are likely to appear at any time during the day or night? The answer is simple – using automatically operated systems to assist “policemen” in their work. IDS tools are those which perform the function of such a “policeman”, by taking care of the security of IT systems and detecting potential intrusions. An important caveat to remember: firewalls are tools only to be used by people.
What is IDS?
IDS stands for Intrusion Detection System and for purposes of simplicity it is a system that detects burglary attempts. If one wishes to compare to a home anti-burglary system, firewalls perform the role of door and window locks. These types of locks will stop the majority of burglars but sophisticated intruders may circumvent security devices that protect an intended target i.e. a home. Therefore, most people use a combination of sophisticated locks with alarm systems. An IDS performs the role of such an alarm system and adds the next preventive layer of security by detecting attacks that penetrate IT systems.
IDS’ originators assumed that no protection system could make a network 100 percent secure against outside attacks. Once the protection barrier has been negotiated, such an anomalous situation must be reported to the system administrator as quickly as possible. It would be useful to view what an intruder was doing in an IT system. These are the key tasks for Intrusion Detection System programs.
How does an IDS operate?
IDS performs a continuous monitoring of events. The intrusion detection software monitors the server and logs any unauthorized access attempts and aberrant behavior patterns. Of course, an IDS must be instructed” to recognize such events. IDS can process various types of data. The most frequent are: traffic eavesdropping, packets flowing into system logs, information on users’ activities. In operational terms, three primary types of intrusion detection systems are available:
– Host-based systems – HIDS,
– Network-based systems – NIDS,
– Network node-based systems – NNIDS.
Host-based IDS (HIDS)
This is a firewall software that is based on auditing whatever information it can glean as generated by the OS’ activities. Such information can include system-generated logs, system events (e.g. unauthorized login attempts, aberrant file accesses, file status etc.). Generally – an IDS deals with all IT systems that can be monitored.
Log Auditing
The primary task of HIDS is to audit system log data. This means that they basically rely on an appropriate configuration of the OS log mechanisms, e.g., EventLog in Windows-based systems, Syslog -in Unix. HIDS collects data flowing into system logs and searches for any information that triggers alerts. This task is relatively simple to implement and is similar to that used by test processor dictionaries. The host-based ID can be “instructed”, for example, to trigger an alarm after a triple unauthorized login attempt within one minute. LogCaster service is an example of a log analyzer discussed here.
Click Here for a list of Log Auditing based Intrusion Detection systems
File integrity checking
Increasingly, HIDS are using technologies, which allow them to detect alterations to important system files and assets. As a rule, the files to check are periodically check summed and compared against a checksum database. If a checksum does not match the current result stored in a checksum database, this means that the file integrity has been altered. Obviously, this rule can be used to monitor only critical non-alterable system files.
Certain HIDS are able to verify features of certain assets. It is well known, for example, that system log files are incremental files. Therefore, the system should be configured so that an alarm is triggered as soon as the system detects any abnormal logs.
A number of products that deal with monitoring of files and assets are available on the market. They are denoted with a FIA (File Integrity Assessment) abbreviation. The first program likely to employ file integrity assessment by checksum verification was Tripwire.
When deploying HIDS software, attention must be paid to provide security for the databases used by the system (event detection rule files, checksum files). Imagine if your operating system is brought under attack and the attacker knows that your OS uses HIDS coverage. By making changes to the system, the attacker may also modify the database containing signatures of changed files. Therefore, it is a good idea to store signatures and other databases, as well as configuration files and HIDS binaries using a non-erasable method – for example, a write-protected diskette or a CD-ROM.
Click Here for a list of File Integrity Checkers
Intrusion prevention system
The biggest disadvantages of the majority of host-based systems HIDS is that they are passive, which means that they have to wait for an event to be an indication of an attack, and cannot proactively prevent it. Recently, HIDS are being provided with intrusion prevention technology aimed at detecting certain symptoms of an attack and the possibility to resist it before any damage can occur. One such advanced hybrid ID is based on monitoring system Application Programming Interface (API) software calls, (made in OS or kernel), and in capturing calls that are prohibited under the established security policy rules. Thus, a system will not only detect an aberrant action but also prevent it. For example, if a system user (or a process) attains elevated permissions in an operating system as a result of intrusive actions, (or a trojan) and is trying to destroy an important file, a passive system will detect a lack or modification of this file. A proactive system, in addition to notifying the system administrator, will also be able to prevent data from damage. This technique was used, among others, by the Linux Intrusion Detection System (LIDS).
Network-based IDS (NIDS)
The software belonging to this IDS group analyzes network packets. A NIDS agent places the network interface card into “promiscuous” mode and audits all traffic crossing the interface. As a general rule, it should be able to analyze all traffic within a specific network segment. Therefore, with switched networks, a NIDS agent should be connected to the monitoring port of the hub. A NIDS agent functions as an appropriate software module that resides on one of servers within a LAN segment. However, one must remember that the volume of packets sent over contemporary LANs is enormous. And this volume must be analyzed by a NIDS. If the agent has inadequate capacity to handle extreme loads, it can miss packets due to congestion on the network link that it is monitoring it and fail to collect the next packets that are received. Therefore, functioning under a regime close to the real-time mode is a must for a NIDS. On the other hand, a NIDS agent itself may overload the system it resides in and “incapacitate” the system to perform other tasks. This weakness spurs NIDS manufacturers to develop data collecting agents as a dedicated system to be installed on a separate robust PC (for instance, NFR NID-100 is offered as a CD-ROM to boot the system). Another option is a complete system encompassing both hardware and software (for example, Cisco NetRanger is a Cisco software-based PC running on Solaris operating system).
NIDS are installed per network segment coverage associated with characteristic attacks (for example ping of death or IIS .ida) or else used to deal with lesser events that are not simply attacks but preparative steps (for example, port scan).
For detecting aberrant traffic, NIDS use some other techniques as presented below.
Pattern Matching
This is a basic technique that has been used by NIDS programs since their origins. Each packet on the network is received by the listening system, the NIDS, it is then filtered and compared on a byte-code matching basis, against a database of known attack signatures (or patterns). The attack signature is a known technique used by anti-virus programs. CA eTrust uses the same engine – InoculateIT – as the anti-virus software of the same manufacturer. This method is easy to deploy, but requires a powerful system to reside on. In addition, a simple math indicates that there is an exponential relation between the amount of processed data or detected attacks (signatures) and the demand for computational power.
Protocol-based Anomaly IDS
This approach to IDS works on the principle that the traffic-monitoring agent has a database of known protocol-specific vulnerabilities and thereby is able to detect certain suspicious packets. With “ping of death” attacks, for example, that send an unusually large ICMP-echo (ping), a NIDS that analyzes protocols will detect the attack – this very large ICMP-echo packet. Adding the protocol-based technology considerably enhances attack detection that uses signature databases, because headers are dropped away and only the payload is taken for analysis.
With this technique added, NIDS agents have also gained mechanisms allowing them to analyze correlation between successive packets. Thus, SYN flood attacks or scanning to search for open port type attacks can be detected.
Another substantial enhancement to NIDS’ capabilities has been given with a protocol-related packet defragmentation technique. A NIDS agent not provided with this function may have difficulty in revealing the presence of an attack hidden in fragmented packets (a common technique used to deceive “ordinary” firewalls).
Session-based Packet Analysis
IDS designers have been taking steps to extend the functionality of intrusion detection systems – in addition to single packet analysis, they have been providing NIDS with the capability to monitor session-based attacks, which may occur over a course of a dialog between systems. A NIDS agent set up in this way will be able to reassemble packet data streams. It is a task that poses high requirements for a CPU, but it allows a full review of anomalous activities, without being restricted to single packets. For example, there can be identified attempts to manipulate TCP stream or to bypass inspection firewalls.
Full Protocol Analysis
An advanced NIDS should have a database with the majority of contemporary protocols and be able to handle various options of these protocols. Suppose that an evader is attacking a Web server by sending commands of a particular format to a cgi.bin script (for example, test.cgi or showcode.asp). A signature -based IDS would have to match some specific patters to identify the attack. Another example would be if an intruder created a variation using UNICODE. A “simple’ NIDS would never even notice such a modified attack. Only a sophisticated, full-protocol-based system that is able to “normalize” audited data before processing (in this case, by using pure ASCII) can detect such attacks. This is a common technique when hiding attacks from a NIDS.
Specialized Network Drivers
Network drivers supplied with OSes today are not designed for high efficiency network analysis of traffic associated with all computers on a specific network segment. Besides, standard drivers themselves have been the source of insider threats. Therefore, vendors of sophisticated NIDS sometimes supply their own drivers. They are optimised for traffic listening and especially tuned by discarding portions that are unnecessary for NIDS applications.
Proactive solutions
Like HIDS, a part of NIDS is able not only to detect but also to proactively prevent an attack before any damage can occur. Normally, sessions are interrupted when an attack is detected. Advanced IDSes are able to inter-operate within firewalls (for example, Cisco NetRanger and Cisco routers) and disable traffic from the source of the attack. Note, however, that this apparently interesting feature may make DINS vulnerable to Denial of Service (DoS) attacks. For example, a site using firewall-configured IDSes under a DoS attack using spoofed address within the Web/Web server (for example, www.onet.pl or a main corporate server’s address). After an IDS intervention, this address would be denied access by the firewall.
Network Node IDS (NNIDS)
This IDS sub-approach is a specific modification of NIDS. Traditional NIDS agents, with the network interface set properly, collect data intended for the whole network. On the other hand, NNIDS are composed of micro agents distributed over each workstation within a network segment. Each micro agent monitors the network traffic directed to that workstation only, greatly reducing the capacity requirements needed by the NIDS. NNIDS weaknesses are associated with the requirement to have and manage a huge amount of micro agents as well as with the fact that NNIDS may have difficulty detecting attacks for which the coverage of the entire network is required, for example, to detect TCP Stealth Scanning. Such a traffic analysis approach is a must in VPNs, when the end-to-end encryption technique is employed. No traditional NIDS will be able to audit such traffic, as it is encrypted. A NNIDS analyses instantly, after decryption is made.
Attack Databases
From this review of IDS technology solutions it can be seen that certain IDSes (particularly NIDS) use attack signatures. Therefore, it is of key importance to have a frequently updated signature database to ensure effectiveness of IDS solutions. One must remember that signature updates are sometimes dependent upon the version of the NIDS software that may not be able to detect attacks that do not have fingerprints in the system database.
Today, IDS designers periodically issue signature database updating information. When choosing an IDS solution, remember to consider primarily how often the vendor updates the signatures, and what the vendor response rate in terms of the interval between BugTraq publication/vendor’s information to the appearance of the specific signature in the IDS would be. Remember, that a potential intruder or trojan rummaging through your Web site will take advantage of the newest information on bugs and exploits.
Certain vendors provide automated response mechanisms (for example, ISS Real Secure X-Press Updates).
Sometimes a “build your own” approach is possible with more advanced IDS software i.e. user-written signature-related plug-ins are possible as they are compiled with the use of high-level programming language. This is a very useful option for knowledgeable security administrators as they can customize their NIDS. Snort and NFR scripting languages (N-Code language that resembles Perla and C) have this option. With such IDS approaches, the problem of producing false-positives (see below for explanation) can be considerably alleviated.
Problems with IDSes
The primary problem with IDS software usage is that it is prone to “false-positives” (false alerts). Both the triggers and the attack signatures are generally not that sophisticated and precise when in use. Therefore, it is possible that an intrusion detecting system generates an alert when no problem was actually present with the network traffic. This is known as a false positive. If a system generates a number of alerts that appear to be false positives, the network administrator may ignore these alerts, possibly allowing a serious attack to pass unnoticed. The implication is that prior to implementing an IDS, a detailed tuning of alerting and triggering rules must be performed to match the environment the IDS will work in.
Security administrators or integrators wishing to install IDS, must take into consideration that this is a serious task. Therefore, it is critical to understand the properties of IDS technologies and the working environment to be used and also to have a broad knowledge of contemporary intrusion types. Contrary to firewall solutions, with IDS a more rigorous configuration policy is necessary, as they are much more sophisticated tools. Therefore, it is a good idea outsource the implementing of an IDS service to specialists.
IDS Modules
Basically, the current generation of IDS programs has a modular architecture. In its most basic form, IDS architecture consists of the following modules:
-
IDS agents that collect information. These are software programs that reside on servers (HIDS), within critical network segments (NIDS), or on each network node (NNIDS). Agents are key issues for IDS functioning. They may generate alerts for malicious activities.
-
Database. Here, all data collected by agents is stored. By auditing data gathered by all agents, certain attacks that are threats for the entire network can be detected and also attack trends and patterns on the network may be tracked.
-
Manager. This is a console that manages all modules. The manager is the administrator’s interface.
-
Alert Generator. This module is responsible for notifying the administrator about a potential threat. There are a variety of currently available IDS approaches. Certain IDS are limited to generate alerts (which may be logged) or others which may be placed on the management console only (Snort, Cisco RealSecure) and are based on outside software for information processing purposes (Cisco recommends, for example, netForensics). Other solutions can take the form of a wide range of sophisticated notifications (e-mail, SNMP trap, displaying a console box, fax, SMS, sending messages to the managing software, launching any deliberate program).
The alerting module may be included either in an agent or in the central data acquisition system.
-
Report Generator. This is a software module designed to generate reports based on the collected data.
Often, (particularly with IDS) the database, the manager and the reporting software are integrated within a single console.
Vendors sometimes offer, for example, extra modules that can consolidate IDS with the centralized management console (HP OpenView, Tivoli).
When fitting an IDS within the rest of the security framework, protection of inside communication is to be considered with proper care. If the inter-module transmission is prone to sniffing and eavesdropping, the IDS itself will be vulnerable to attacks. Inter-module communications should be encrypted using all well recognized security standards. Avoid using ad hoc encryption standards produced by early adapters or non-published standards. Secure and trusted IDS employ IPSec technology to encrypt packets. If a specific IDS is not provided with such a function or its encryption protocol seems untrustworthy, the transmission between the centralized console and the agents should be protected from using outside programs. I would like to emphasize once again: IDS inside transmission security is a key issue. Over-reliance on an IDS mechanism that cannot ensure data integrity while en route cannot be tolerated!
Summary
IDS are complex organisms. While the proponents of IDS software are moving to offer their products as complete as possible, the step towards IDS implementation within an organization is a very serious and complex task that requires a great deal of knowledge and skills.
Compared to firewalls, IDS are more sensitive to configuration errors and misleading design assumptions and product mix choices. So, a careful performance check of any IDS infrastructure is needed before its planned purchase and installation. This may include:
-
System architecture,
-
System management,
-
Capacity,
-
Database integrity,
-
Updating frequency,
-
IDS infrastructure security,
-
System effectiveness (handling false-positives),
-
Notification countermeasures,
-
Seamless interaction with other network infrastructure components,
-
Reporting facility.
What is most important – human intervention is still required i.e. from security-aware persons who will be responsible for IDS setup and maintenance and will be alerted about security breach attempts. An IDS cannot do the job alone and cannot be a “magic wand” to make IDS the only security required for our systems. This is just a tool to be used by people, for this purpose a prerequisite suit of response procedures should be prepared for the users to observe strictly. Otherwise, IDS will remain an expensive gadget only.
For those who wish to try IDS, I can recommend Snort – the project by OpenSource (http://www.snort.org). This is a freely downloadable IDS agent featuring huge possibilities in attack detection. In particular, I suggest installing it over your Internet connection to verify how many attack attempts are being performed everyday on your “less valuable” data.
