RangerIDS - Intrusion Detection System (IDS)
Problems With IDS
So, you have been out and bought your shiny new IDS system and installed it somewhere on your network. You are now secure and immune from attack, right? Wrong!
To begin with, deployment of IDS requires careful thought and planning if you are to get the most from it. What kind of resources are you protecting? If you have a DMZ containing only Unix-based Web servers, you could disable all IDS signatures to do with Windows NT or DNS servers. Some IDS products will go so far as to try and perform this step automatically for you depending on what operating systems and services are found during a network scan.
To do the job properly, however, you should acquire some good Vulnerability Assessment tools and scan your own network. This should provide a good starting point in determining which machines need protecting, and from what sort of attacks.
Are you worried about intruders breaking through your firewall and launching DoS attacks against your machines? Then perhaps a Network or Network Node IDS would be a good buy. Or are you more concerned about Trojans on your desktops and file servers? File Integrity Assessment could be the best bet. Or perhaps you are worried about your own users making off with company secrets? In which case, Host IDS would be the right choice.
If attacks against your Web servers are your chief concern, however, Intrusion Prevention Systems might be more appropriate. Most likely you will actually need a combination of all these technologies, and there is some considerable overlap in the host-based products, with the Host Intrusion Prevention Systems providing many of the capabilities of the more “traditional” Host IDS.
Having selected your products, where are you going to install them? Host IDS, Network Node IDS, and Host IPS are simple - you put them on the hosts that need protecting. But Network IDS is another matter. Placing a network interface card into promiscuous mode generates an awful lot of material to be processed. All the traffic passing by on the subnet being monitored has to be collected and examined by the IDS sensor and compared against a database of known attack signatures, or analysed for protocol violations.
Nor is it enough to simply look at this traffic on a packet by packet basis, since some attacks are spread over several packets, or may be fragmented deliberately to confuse the IDS. This necessitates a time- and memory-consuming process of buffering packets and maintaining state tables to keep track of individual sessions. To defeat the common IDS evasion techniques such as packet fragmentation, out-of-order fragments and so on, it is also necessary to perform some heavy-duty processing within the IDS itself to reassemble packets back into the form that will eventually be seen by the target host (or capture the packets at a higher level in the TCP stack of the sensor machine). Or perhaps a full protocol decode is performed. All of these options are likely to slow the detection process, but only then can the true packet contents be determined and compared against the signature database.
And all this must be done While eliminating – or at least keeping to a minimum – the risk of the “false positive”. In an ambiguous situation, there is no point in raising an alert “just to be on the safe side”, otherwise the IDS runs the risk of crying wolf once too often and eventually being ignored altogether. In the case of the Network IPS, of course, the false positive has even more serious ramifications, potentially introducing a Denial of Service condition as it blocks a legitimate packet flow that has been misidentified.
Quite a bit is involved behind the scenes then, and While most IDS products could quite happily keep up with traffic on a 10Mbit network, leased-line or DSL connection, it is much more difficult to do all this at wire speed on a 100Mbit network.
Gigabit presents even more problems. Not only are we now looking at a significant increase in bandwidth – and thus a significant increase in the volume of traffic to be analysed – but we have also moved into the realms of the purely switched network. Don’t forget that the promiscuous mode sensor can only see traffic on its own segment, and in a switched environment, every connection to the switch is, effectively, a single segment. In the 10Mbps or 100Mbps world, this can be overcome by the use of network taps or mirroring all the switch traffic to a SPAN (Switched Port ANalyser) port, to which is attached an IDS sensor.
But with Gigabit, the result would be a seriously overloaded sensor. Building IDS technology into the switch hardware itself, allowing the sensor to grab traffic directly from the back plane, may be one solution. Another is to move to a pure Network Node IDS implementation, where the agents are concerned only with the traffic directed at the host on which they are installed.
A third option would be to invest in one of the more recent Gigabit IDS products that make use of improved high-performance hardware and software architectures to perform analysis and detection at something approaching wire speed on Gigabit networks. For those who need to go even further, solutions incorporating custom ASICs and FPGAs provide the highest levels of performance, making it feasible to detect - and even prevent - intrusions on multi-segment multi-Gigabit networks with a single device… at a price.
One final point to consider is that of encrypted traffic. Companies that make extensive use of VPN’s will find problems with Network IDS, since the traffic picked from the wire will obviously be encrypted, thus rendering any pattern matching or protocol analysis completely useless. The obvious choice would be to install a VPN tunnel termination device at the network border, which would then forward the data to the destination device in plain text.
If it is not acceptable to decrypt data at the network border, however, then once again the only solution is to install Network Node IDS, so that the IDS agent has access to the data stream as it is decrypted at the VPN end-point.