Tuning your Intrusion System

Tuning your Intrusion System

Tuning an IDS/IPS does not have to be a complicated matter. Though it does require a basic understanding of your network topology and design, and the location on your network that you’ve placed your intrusion system. With inline intrusion systems the compulsion will be to set it in IPS mode immediately, but taking a short period of time to do some basic tuning at the beginning will save you considerable amounts of time and frustration later.

First, most, but not all, intrusion engines have two primary variables that need to be defined. These are the Homenet and Externalnet (home network and external network). The simplest way to think of these two variables is as of the Homenet as the list of networks you want to protect, and the Externalnet as the list of networks you want to protect the Homenet from. I known that this explanation is a bit of an over simplification, but it works for getting started with tuning. Intrusion engines use these two variable when defining the directionality of traffic in a signature. Is it inbound? Externalnet to Homenet. Is it outbound? Homenet to Externalnet. Or maybe it is looking for lateral movement where the Externalnet variable is not used in the signature and the signature is looking for Homenet to any, or any to Homenet traffic.

Now, the Homenet is pretty easy to identify. This is generally the networks that are behind the intrusion system (for an line IDS/IPS) or on the interior on the network (for a sniffing IDS). There are two schools of thought when defining the Externalnet. The first (and my preference) is to set the Externalnet to !Homenet (not Homenet). This means that everything that is not the home network will be considered an external network. The second option is to set the Externalnet to any, that is, any traffic will be considered an external network. The advantage of setting the Externalnet to !Homenet is that you will reduce the number of false positives for Homenet to Homenet traffic. Critics will say this reduces your visibility of potential lateral movement attacks. However, as I pointed out earlier, signature writers take directionality into mind when they are writing signatures. So what little additional visibility you may achieve from having the Externalnet set to any, you are going to lose in event fatigue dealing with false positives and potentially blocked legitimate traffic with an inline IPS.

We’ve now defined the Homenet and Externalnet at this point and before we move on to reviewing events I recommend whitelisting/trusting the IP addresses of any known vulnerability scanners on your network if the platform you are using supports whitelisting (most, but not all do). There are two reasons for this; One, we dont want to have to deal with the false positives vulnerability scanners are going to generate; and Two, if the end goal is to place the intrusion system into IPS mode, blocking our vulnerability scanners is going to defeat their purpose of identifying vulnerabilities on endpoints.

Now we want to let the intrusion system generate some events so we have a baseline to start working with. I recommend a weeks time. This is generally long enough that we will have seen any regular legitimate traffic and if it was going to generate a false positive we should have an event.

Now that we have let the system run for a period of time we need to review the events that have generated. We are mainly looking for false positives that we need to tune out, but you can often identify other interesting patterns. This requires a certain level of knowledge of the network and the purpose of the various systems running on it. If the appropriate people are not involved or the knowledge of the network is incomplete; the tuning process can be protracted and even derailed.

When preparing to review events I like to export the following information into a spreadsheet (CSV works), all IDS/IPS events will contain the following details, the names of fields may differ though; SID (Signature ID), Message, Source IP, Destination IP. Once we have have this exported into a spreadsheet we are going to created a pivot table using Message (or SID), Source IP, and Destination IP as Rows, and Count of the Message (or SID) as the Value. Then we want to sort the table by the count, largest to smallest.

Now that we have exported and done some basic parsing on the events we’re ready to start reviewing the results. When we look through the events we are mainly looking for IP addresses that we own that are triggering alerts . These are likely to be false positives (we hope!). For example if we see the same source IP triggering multiple signatures it is likely a vulnerability scanner. Other possibilities are developers testing web apps, backup servers, and monitoring services. Regardless, when we see a source IP that we own triggering events we need to review. Assuming that after we have reviewed the system, running services, and the traffic, we have determined that the events are false positives, we need to stop it from matching on the signature. How we can go about this varies from platform to platform, but in general falls into a few different categories; First you can bypass or trust (aka whitelist) the traffic. This is useful if you trust the source and destination and can limit the trust to a specific port (or ports). A trust or bypass generally means the traffic will not be inspected, so use common sense; A second option is to edit the signature to exclude the source IP from the signature. This way that signature will not be applied to that source IP, but the traffic still gets inspected and evaluated against other signatures; Another option is to disable the signature. Which makes sense if you are not susceptible to the vulnerability in your environment the signature is providing coverage for (ie a linux vulnerability when you are windows only shop). You have to have a very good handle on the assets in your network to be able to confidently make this assessment; Finally, you can also suppress the alert. This works for IDS systems that will not block the traffic or on signatures that only alert on an IPS systems. Use caution when doing this on an IPS system. If the action of the signature, which they do occasionally with signature updates, you might have traffic start being blocked and not receive any alerts for it. As you can imagine this can be very difficult to track down.

I know that I started out saying that tuning an IDS/IPS system does not have to be complicated and by now you are probably questioning if I known what ‘complicated’ actually means. However, if you take the time to step logically through the tuning process and thoroughly review events at the beginning you will appreciated it down the road. AsĀ  a final note remember that the number and type of alerts that an IDS/IPS system generates can change drastically over time as the exploits and vulnerabilities that threat actors are using and scanning for changes. Do not be surprised if you see a spike or drop off in events.

Happy Hunting