Sourcefire Event Filtering, Dynamic States, Alerting and Comments

We saw earlier how to create a custom signature in our Sourcefire system. Then we created a rule without tweaking it, but sometimes this is something we have to do in order to fight false positives or reduce amount of data logged to our DC. Let’s imagine we are under attack. One rule triggers and generates event in the database. Same rule triggers again, log entry is created. Again and again and again, … If a rule is triggered one million times, how many log entries there would be? Tough math, but it’s obvious that this poses a huge problem to our IPS system. Fortunately, Firesight, by default, logs only one event for one attack to one destination IP for duration of one minute. This greatly reduces number of events logged to the database and improves performance. This global setting can be overridden on a rule basis, or turned off, for some reason.

Let’s focus on rule “PROTOCOL – FTP CWD ~root attempt“, a rule with GID:1 and SID:336. We can find this rule by typing ~root in Filter edit box and hitting <ENTER>:

31-Jul-2015 10-34-55 AM

This rule is disabled by default, which is indicated by dimmed green right pointing arrow. What this rule does is it detects regular FTP user trying to reach root user’s folder. Now days this attack is not possible on most systems, because they are compiled or set up to disallow this, but back in days it was pretty common. I like to use this rule because it is easy to set up a test environment. This rule exists on all IPS systems I worked with and we just need to enable it. We only need a FTP server we have access to and testing is very simple: we log in to our FTP server and issue “cd ~root” command.

At this point, nothing will happen, because this rule is disabled. So, let’s enable it by selecting it’s check box, clicking “Rule State” button and select “Generate Events“:

31-Jul-2015 10-42-57 AM

Now the green right pointing arrow is not dimmed, which means this rule is enabled. Let’s commit our changes and apply the access control policy. When all changes are applied, let’s test our rule:

31-Jul-2015 10-48-13 AM

We did the attack and can verify it’s logged by going to “Analysis->Intrusion->Events“:

31-Jul-2015 10-52-00 AM

We can see that the attack is caught and the hit count is one. Previous log entry is from my first try, half an hour ago. What is going to happen when we try this attack several times within very short period of time? Let’s open four command shells, log to our FTP server, type in “cd ~root” in all four, and hit <ENTER> in each console as quicker as possible.

31-Jul-2015 3-06-25 PM

We didn’t expect this, did we? We hit the server four times but only one log entry showed up. Well, there is a default setting for an IPS policy that is named “Global Rule Threshold“. This setting can be found at “Policies->Intrusion->Intrusion Policy->CEH POLICY“. This is our current test policy. If we edit this policy, clicked “Advanced Settings“, we could find “Intrusion Rule Threshold->Global Rule Thresholding” option which is enabled by default:

31-Jul-2015 2-52-17 PM

If we click yellow pencil icon, we could see the defaults:

31-Jul-2015 2-52-56 PM

We will deal with these options later in this blog. For now, we can remember that no matter how many same attack instances occurs within sixty seconds and they all target the same destination address, only single log entry will be produced. Excellent! This is why we attacked four times and yet only one log entry is found.

Let’s disable this option for the sake of demonstration. We find this setting and select Disabled.

31-Jul-2015 3-10-41 PM

Then  we reapply our policies.

Let’s try our attack four times again.

31-Jul-2015 3-20-11 PM

There are now  all four events logged. If we select this event and click View, we would see all of them:

31-Jul-2015 3-25-45 PM

Of course this is bad. Our database will fill up very quickly. We will turn this feature globally back on later. Before we do that, let’s start what this blog post is all about. Setting event filters.

Let’s open our IPS policy and find our 1:336 rule. We click on it and “Show details” button appears at the bottom. When clicked, rule details appears:

31-Jul-2015 3-31-52 PM

Let’s go through all of these options.

  •  Thresholds This setting controls how many entries will be logged for each attack event per time period. This overrides previously described global setting. Let’s say that we want to log a single event for every five attacks within ten seconds. We click Add button and specify five for Count field and ten for Seconds field.

31-Jul-2015 3-52-44 PM
Track By” option can be source based or destination based. Source based tracking aggregate different source IPs to single within given parameters, whether destination based tracking does the same for destination IPs. In our case it does not matter because we always attack the same server from the same laptop.

31-Jul-2015 4-00-14 PM

Now we open six (or more) terminals and pull off this attack. It does not matter how many times we attacked our server within ten seconds period, Sourcefire will log only five, because this is our threshold:

03-Aug-2015 12-34-27 PM

    • Suppressions We can use suppressions to exempt hosts and/or networks from producing log events for some particular rule without disabling the rule. For example we want our “CWD ~root” rule to be active and produce a log event for all source IPs but our IP of 10.77.3.1, which could be an IP from which we do penetration testing and vulnerability assessments. So, let’s make this change:03-Aug-2015 12-41-39 PM
      We can prevent or suppress event creation based od Source IP, Destination IP or Rule. This only prevents events from being logged, but does not have any influence on rule action. So, in our case, if the attack is performed from 10.77.3.1, the Sourcefire will not produce an log entry, but the action will be carried, for example connection will be dropped.
  • Dynamic State This is very powerful option. We can say for some rule that we want it just to produce alerts, but when the number of events crosses some boundary, we want to become more aggressive and begin dropping connections for some time, after we switch back to producing alerts.

03-Aug-2015 12-58-31 PM
In the above example, we said that if the attacker’s IP is 10.77.3.1 and he/she tries pulling this attack off more than three times in ten seconds, we switch from just generating logs to dropping connections and we will stay in this state for fifteen seconds, before we switch back to just producing alerts.

  •  Alerts With this option we specify that whenever the rule is triggered, we want to send a SNMP trap to a management station defined in our IPS Policy, under “Advanced Settings->External Responses->SNMP Alerting“. There is no any options here, just Add/Delete.

 

  •  Comments In this section security engineer can add comments about something that is changed, about rule behaviour  or something similar. For example:
    03-Aug-2015 1-18-38 PM

Once the comment is added, it cannot be removed. All other filters we can remove if we want to.

  •  Documentation  This section provide us with the documentation regarding this rule. Here we can see how this attack can be performed, what are the implications, where we can find more about it and how this rule is written in Snort notation:03-Aug-2015 1-21-39 PM

 

If we have any filter turned on, this is displayed by a row of icons next to the name of our rule. In the following example, we can see that we have both Threshold and Suppression turned on (indicated by number two in the front of filter icon), and that we also have a Comment attached to this rule:

03-Aug-2015 1-53-48 PM

After any change in these options, we have to commit them and reapply our access control policy. At the end, let’s not forget turning the global thresholding back on, because we have previously disabled it.

 

I think about wrapping it up for now, and I hope to see you guys soon.

Thanks for reading.

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

One Response to Sourcefire Event Filtering, Dynamic States, Alerting and Comments

  1. Pingback: Sourcefire Fighting False Positives | popravak

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