Is a firewall the ultimate solution? 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. 1.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”.
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. 2.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. 3. 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. 4. 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. 5. 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. 6. 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 7. 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. 8. 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). 9. 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. 10. 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. 11. 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). 12. Session-based Packet Analysis DS 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. 13. Full Protocol Analysis n 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. 14. 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. 15. 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. 16. 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. 17. 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. 16. 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. 17. 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:
The alerting module may be included either in an agent or in the
central data acquisition system.
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! 18. 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:
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.
|

