IDS - The Intrusion Detection System
I'm going to take the next few posts to talk about IDS, Intrusion Detection Systems. I'll discuss it from the ground up for those who are new to Network Security.
An Intrusion Detection System is a host or piece of software that monitors either network traffic streams or logs and processes on one box for malicious activity. There are two distinct types of systems, NIDS and HIDS.
NIDS - Network Intrusion Detection System: A NIDS monitors network traffic. It can be placed about anywhere there is a need for it, but the most common placement is at an ingress point where Internet traffic comes into the network. There is some debate as to the optimal placement at an Internet choke point, as to whether it should monitor inside the firewalls or outside, but my experience is most experts agree if you only have one, inside is better. (Having one inside and one outside is, of course, even better).
There are several reasons for this. A NIDS that is placed inside the firewall is seeing traffic that was not dropped (either by design or unintentionally) by the various layers of border perimeter defenses. That traffic has traversed one or more border routers and was not prohibited by Access Control Lists, and has successfully passed one or more firewalls without being blocked by a rule. The assumption is this is normal, wanted traffic such as a customer accessing your web site. However, since ACL's block certain IP's and firewalls allow traffic to certain IP's on certain ports, this may just as easily be someone trying to exploit a vulnerability in the web sites application code. For discussion purposes, we're assuming the firewall in question isn't a multi-purpose appliance with IDS on board. Some firewall software also has a limited IDS signature set built in that may catch and block certain very well known attacks. A lot of network administrators are hesitant to run even this limited functionality because of the fear of blocking legitimate traffic by mistake.
A NIDS outside the firewall would alert as well. But you would be uncertain without checking logs on the firewall or a packet auditing system whether the traffic was allowed, or blocked by the firewall. With an internal IDS, you know instantly.
Another very good reason to have an internal NIDS is for tracing back internal compromises and outbreaks/infections. Let's say one of your end user desktop PC's get's popped and becomes part of a bot net. The code on the machine begins to connect out to the botnet controller to notify it that it's under control and to download other software or receive instructions. Assuming you use internal RFC 1918 IP addressing, that traffic will route out to your firewall, be translated to the hide address of your firewall and on to the Internet. Let's say your hide address is 66.66.66.1.
All hosts on your internal network would get translated to this IP address going out to the Internet.
A NIDS outside your firewall would only see the packets after they had been translated. Which of the desktops is infected and calling out to the botnet? Again, you'd have to rely on logs on your network infrastructure equipment, which is not only time consuming, but depending on how logging is set up, may not even help you. Because of sheer size of full logging, a lot of shops only log drops on the firewall and denies on routers, not allowed packets. A a packet that is accepted may not (probably not) even be logged.
But your internal NIDS sees the packets before the firewall, and hence, before they are translated, so your alert will identify the internal IP address, allowing you to easily trace back to the machine and do your incident response and shut it down.
In the next few posts, I'll cover different ways to monitor traffic, the different ways an IDS detects malicious traffic or activity, a few basics on tuning sensors and what Host-based Intrusion Detection is.
An Intrusion Detection System is a host or piece of software that monitors either network traffic streams or logs and processes on one box for malicious activity. There are two distinct types of systems, NIDS and HIDS.
NIDS - Network Intrusion Detection System: A NIDS monitors network traffic. It can be placed about anywhere there is a need for it, but the most common placement is at an ingress point where Internet traffic comes into the network. There is some debate as to the optimal placement at an Internet choke point, as to whether it should monitor inside the firewalls or outside, but my experience is most experts agree if you only have one, inside is better. (Having one inside and one outside is, of course, even better).
There are several reasons for this. A NIDS that is placed inside the firewall is seeing traffic that was not dropped (either by design or unintentionally) by the various layers of border perimeter defenses. That traffic has traversed one or more border routers and was not prohibited by Access Control Lists, and has successfully passed one or more firewalls without being blocked by a rule. The assumption is this is normal, wanted traffic such as a customer accessing your web site. However, since ACL's block certain IP's and firewalls allow traffic to certain IP's on certain ports, this may just as easily be someone trying to exploit a vulnerability in the web sites application code. For discussion purposes, we're assuming the firewall in question isn't a multi-purpose appliance with IDS on board. Some firewall software also has a limited IDS signature set built in that may catch and block certain very well known attacks. A lot of network administrators are hesitant to run even this limited functionality because of the fear of blocking legitimate traffic by mistake.
A NIDS outside the firewall would alert as well. But you would be uncertain without checking logs on the firewall or a packet auditing system whether the traffic was allowed, or blocked by the firewall. With an internal IDS, you know instantly.
Another very good reason to have an internal NIDS is for tracing back internal compromises and outbreaks/infections. Let's say one of your end user desktop PC's get's popped and becomes part of a bot net. The code on the machine begins to connect out to the botnet controller to notify it that it's under control and to download other software or receive instructions. Assuming you use internal RFC 1918 IP addressing, that traffic will route out to your firewall, be translated to the hide address of your firewall and on to the Internet. Let's say your hide address is 66.66.66.1.
All hosts on your internal network would get translated to this IP address going out to the Internet.
A NIDS outside your firewall would only see the packets after they had been translated. Which of the desktops is infected and calling out to the botnet? Again, you'd have to rely on logs on your network infrastructure equipment, which is not only time consuming, but depending on how logging is set up, may not even help you. Because of sheer size of full logging, a lot of shops only log drops on the firewall and denies on routers, not allowed packets. A a packet that is accepted may not (probably not) even be logged.
But your internal NIDS sees the packets before the firewall, and hence, before they are translated, so your alert will identify the internal IP address, allowing you to easily trace back to the machine and do your incident response and shut it down.
In the next few posts, I'll cover different ways to monitor traffic, the different ways an IDS detects malicious traffic or activity, a few basics on tuning sensors and what Host-based Intrusion Detection is.