Sourcefire Fighting False Positives

One important thing when dealing with IPS is fighting False Positives. A false positive is not solely an IPS term, and I think it’s adopted from medicine. For example, when our MD is checking our blood for presence of some bacteria, for example, and result comes back positive, but bacteria is not actually there – it’s a false positive. Positive here indicates a presence of a bacteria, but the finding is false, hence the expression.

There are similarity to this  in IT in general, as well as in IPS. In IPS a false positive would be an event that is logged as some sort of attack, but we know that the event is not an attack.

Why would we care about false positives (FP)? Well, first of all they affect the system performance by logging events to the database. Second, our disk space is filling with junk. And finally, they are taking away our precious time.

Before we show how to deal with FPs in Sourcefire, a little warning: we have to be very careful when declaring something as a FP. Some event should be declared as a FP only after thorough investigation, and we must know that some event may represent a FP in one environment, while may be a real attack in other.

Ok, let’s check our environment … A nice place to start would be one of our dashboards, for example “Application Statistics“. Here we can see a widget named “Impact 2 Events by Application“. We can set time range for one hour, one day and one month, for example, and we can see the following info:

01-1hr

01-1day

01-1mth

We can clearly see one application that has abnormal number of events, comparing to other applications. We can click a window icon left to the “SHOUTCast Radio” hyperlink and an “Application Detail View” window opens:

shoutcastradio

From here we can go to “Context Explorer” of our DC, which we will do in a second, we can open Wikipedia on this topic, or searching Google, Yahoo or Bing. Let’s try Google. We can see that this is the streaming protocol that we can use to listen to radio stations, for example. We have to find out why and who is using this protocol in our network and decide if this is something we should ignore in our logs in the future.

At this point, we don’t know if this is an attack or not, we just see lots of traffic.  Let’s deep dive into this by right clicking SHOUTCast application and selecting “Open In Context Explorer“. First we can see Traffic and Intrusion Events over time:

00-E

00-T

Then we can see Traffic by Source IP, looking at amount of traffic and number of connections:

04

And we can see that one host is “attacking” different IPs:

05

After investigation, we figured out why this is used in our network and decided that it can be declared as a false positive and hence as safe to ignore. It is a server that streams some audio/video to our clients for educational purposes. So, it’s safe to declare it as FP. While we are in “Context Explorer“, at the bottom of the page we can see that this traffic actually triggers the “HI_CLIENT_BARE_BYTE (119:4)” rule:

bb

If we click (left click) to this rule, we have options to dive deeper into events that triggered this rule. The option we need is “Drill into Analysis“:

09

First we see what rule has been triggered and how many times:

10

The number of hits is small because it represents a small period of time. In this particular environment, there are hundreds of thousands of these events logged. If we check a check box left to the rule message and select View, we are displaying all events related to this rule:

11

By now we already know that this is normal activity in our network and that the streaming server 192.x.y.6 is sending educational data to many of our clients. It’s time now to actually declare this as FP. If we right click the source IP of 192.x.y.6 (which is the IP of our “attacker”), we have several options displayed and we will select Suppression. We talked about suppression in our previous blog. A Suppression window opens:

13

We can suppress this rule within our current policy (the policy which investigation led us to this point) or suppress it in all IPS policies. We select current policy (red arrow points to this selection) and we have options to suppress based on Source, Destination or Rule. All about suppression can be found here. We don’t specify source or destination IP. When we click Source, the source IP is automatically populated based on the row we right clicked in previous step. Same goes with the Destination option. Because we have many number of PCs receiving this streaming, whose IPs we don’t know, we can select Source option, because this is the server that actually send this data and is considered to be an attacker. After we make our selection, we click “Save Suppression Options” and then “Close window“.

We can verify our settings as if we were going to suppress events like we did in previous blog. Within our IPS policy, we go to “Rules->Rule Configuration->Suppression->By Source” and we can see our rule and icons indicating that a filter is in place:

15

If we select this rule and click Details, we could see a familiar suppression settings:

16

Finally, we have to reapply our access control policy. When we do so, this 119:4 rule won’t trigger any more if the source is one we specified in our suppression settings. More precisely, it won’t generate log entries in our DC.

Our effort can be summarised through the following screenshot:

final

Previously, we had more than thousand events per hour, but now we don’t see any.

This example shows roughly the steps to perform in order to declare something as a false positive. The toughest thing to do is actually being sure that something is a FP. There could be many steps involved and many time spent to reach the point that we can safely say this is something we are not interested in.

 

Thanks for reading.

 

Advertisements
This entry was posted in Cisco, FirePOWER, IPS, Security, Sourcefire and tagged , , , . Bookmark the permalink.

One Response to Sourcefire Fighting False Positives

  1. Fred says:

    My understanding is that suppression keeps events from /logging/, but not from triggering. So if you are running SourceFire inline and the rule drops traffic, you will not only break your traffic, but you will also have no record of it. This seems like a very bad thing to me.

    As far as I can tell, SourceFire doesn’t have a way to make exceptions to rules for particular sources or destinations.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s