Home
|
Introduction to Network Intrusion Detection Systems This is a brief introduction to the topic of Network Intrusion Detection, what it means, and how it all fits into the grand scheme of things. A few Years ago, I was using a relatively unpatched installation of Redhat 6 on an old laptop to connect to the net via a creaky old modem. It had a small number of firewall rules set up, and I had been using it for ages without any problems for intermittent connections to the net, but with hindsight, I was asking for trouble. At the time I was working on intrusion detection systems in a professional capacity, and I should have known better. One day, SSH stopped working, and a look through the shell command history showed that someone had obtained root privileges. Had they not bungled the installation of the root kit, I may not have realised until my modem connection slowed to a halt under the load of the attacker scanning other networks. I was running a single machine on a modem line, but imagine you are running a large corporate network. One day you walk briskly into work, but the faces of the users that greet you in the office tell you that some kind of compromise has occurred. Software has stopped working properly, and your network has slowed to a crawl. A hacker has been busy at work and has used a number of tools and trojans to gain administrator privileges and access to critical data within your network. This is a nightmare scenario, and is becoming a common occurrence. What is more, many attackers are able to so skilfully cover their tracks that people might never realise that their network is now a prize for a spotty teenager on the other side of the globe. Of course, you might just be running bad software, and all this talk of an intruder is only serving to raise your blood pressure. The fact is, with oodles of traffic rushing through your firewall, there is no way that you can sit at a screen, matrix fashion and watch megabits of information flow by and hope to make any sense of it. This is where Network Intrusion Detection Systems, or NIDS might come into play. These work by analysing traffic passing through a network interface. A NIDS will search for suspicious patterns within the packets, or certain sequences of packets, and when a signature is matched then an alert is raised, often giving useful information about the signature that was matched, the source and target addresses and any other relevant information. So, that's about it then. Problem solved. Just sit back and drink a cup of tea, while you tail the NIDS log. If you spot any activity, you can Google for it, or take a look at the web page for that specific NIDS signature. Well, obviously, it isn't that simple, few things are. Based on signatures, most intrusion detection systems require updating to keep in line with all of the known forms of attack and exploit. If you don't update your signature database, the silence may lull you into a false sense of security. If you use a number of less specific signatures, you may be swamped with false alerts. Often you will need to trim back the rule set if there is legitimate software on the network that mimics less desirable software. OK, so you've get a cron job that downloads all the new attack signatures, and you've employed someone to trim out all the false alerts. You have an effective NIDS, but you are deceiving yourself if you think this affords any degree of protection from attack. Perhaps in times past you could have tracked an intruder and effectively prevented any loss or damage to your network, but automation of exploits has now rendered the romantic notion of the hacker and sysadmin battling against each other at the command line in a duel of skill completely obsolete. The best you can hope for is knowing what caused your network to fall over just as it falls over. There really is no substitute for maintaining secure firewalls, keeping software patched, and eliminating unused services. So what use is a NIDS? A NIDS should form part of your sysadmin toolkit. It is your eyes on the network, your CCTV security system. With clever scripting, you can use a NIDS to react to attack. For one of the clients for which I have worked, we used Snort (a popular NIDS) to detect the activity from the "code red" virus on a large public sector network. This virus spread by exploiting windows web servers by sending carefully crafted http requests. The NIDS was set up to trigger a firewall update that blocked all port 80 traffic from infected machines for 48 hours. This prevented infected machines on the inside of the network scanning anyone on the outside. We weren't in a position to patch the infected machines, but we were in a position to control the spread of infection, thanks to Snort. Introduction to Snort Snort is one of the most popular NIDS around, and is available under the GNU software licence. A typical general-purpose installation will have several hundred exploit signatures, or rules. This is an example of a snort rule:
alert TCP $EXTERNAL any -> $INTERNAL 80 (msg: "IDS552/web-iis_IIS ISAPI Overflow ida"; dsize: >239; flags: A+; uricontent: ".ida?"; classtype: system-or-info-attempt; reference: arachnids,552;) This rule will create an alert if TCP traffic on port 80 travelling from the external network to the internal network (defined in snort.conf) contains the string ".ida?" Does this sound familiar? This rule will trigger an alert when someone requests an .ida file from a web server. The code red worm was one of many to use an exploit using the default.ida script. If you suddenly get a blizzard of these kinds of alerts, you may have a worm infestation. This isn't the actual rule used for the example I gave earlier, as it is a very general rule. To put in place a rule for every worm would bloat the rule set, and possibly waste CPU cycles, so in most cases this rule will be fine for detecting suspicious traffic, but if you needed to detect an attack from a specific worm, you'd have to create a more specific rule. For those who have a legitimate use for .ida scripts on their network they'd have to think about it a bit more. You probably shouldn't be accessing .ida scripts from the Internet, so depending on where you have sited your NIDS, you could redefine your $EXTERNAL network to include only hostile networks (e.g. red side internet, or 802.11) Installing Snort I'm not going to discuss how to build and install Snort from source, as that's beyond the scope of this document (it'd take ages) if you are lucky enough to run debian Linux, Snort can be installed by typing at the prompt:
% apt-get install snort This will fetch and install a set of default rules in /etc/snort and log to /var/log/snort. Alerts appear in /var/log/snort/alerts The main config file is /etsc/snort/snort.conf, and here you can enter the various network aliases. The application installer will choose some sensible defaults, and more often than not, an installation will work out of the box. Snort can also be configured to log to a database, which is jolly useful if you want to browse activity via the web using something like Acid, a Snort log viewer. Locating your NIDS on the network Many people run a NIDS tool on their main Internet gateway firewall, as it has visibility of all of the traffic passing in and out of the network. If you have a firewall that isn't running Unix (Cisco or Nokia for example), many people run intrusion detection as an appliance. Caution must be advised for this route, as the Snort box itself can be exploited if not properly protected. Other tools I recommend: Firewall The primary means of protecting your network. A good firewall installation denies all traffic, and lets through only what is required. A firewall (certainly most traditional firewalls) can only block traffic by packet type, source, destination, size, port number and any number of other variables, but it will not filter by traffic content. You may open port 80 so that your web server works, but you cannot then block exploit traffic. Your web server should be prepared to deal with whatever rubbish is thrown at it. Tripwire This is a handy utility that monitors the state of your filesystem and generates alerts if there are any inconsistencies. It is practically impossible to do anything on Unix without changing the contents of files. Ethereal Ethereal is a very powerful protocol analyser, with the ability to reconstruct protocol streams from the individual packets, so that it is possible to monitor network conversations. Useful URLs
www.cert.org Ohp Article date: 19-Nov-2003 |
Home