Sourcefire Access Control Policies – Part Two

From our previous blog, we have our SFR module passing all the traffic. We talked a little bit about Access Control Policies (ACP). Let’s now deep dive into details of these policies.

Our topology has not changed from last time. We will now modify our “allow all” policy to block telnet access to certain hosts. Let’s go to “Policies->Access Control->WP TEST POLICY” and click the yellow pencil icon on the right. Access Policy Editor opens.

20-May-2015 8-23-41 AM

For now, we will focus ourselves to first two tabs. The Rules tab is where we will be spending most of our time. Here we create our rules. The Targets tab contains all of our modules, separated in two sections. The Available Devices section lists all available modules, and the Selected Devices contains modules that this policy applies to. Now let’s go back to the Rules tab. We want to create a rule that will block telnet traffic to two servers: 10.a.b.111 and 10.a.b.115. They are important to us and we don’t want our users to pass plain text credentials through the SFR and the rest of network all over to those servers. We will permit everything else. Actually, we will deny this type of connection only for user sasa.popravak, because we don’t like him and he is kinda suspicious 🙂

Before we begin creating our rule, we will create an object that contains one server – 10.a.b.115. This is just to show how we can work with objects that can contain multiple hosts, addresses and so on. For server 10.a.b.111 we will use its IP address.

Let’s create our server object. We go to “Objects->Object Management->Network->Individual Objects“, then we click “Add Network” and fill  the name and the IP address in:

19-May-2015 1-44-36 PM

Now we switch back to policy editor, Rules tab. We click “Add Rule” and an “Add Rule” editor opens. This dialog contains ten tabs and we will walk through all of them. But first we give this rule a name, for example “WP BLOCK TELNET ACCESS“, make sure the rule is enabled and we specify the action for the rule.

We have several actions at our disposal:

  • allowThis action allows traffic to pass and optionally does Advanced Malware Protection (AMP) and/or Intrusion Prevention (IPS). If both AMP and IPS policies are set, first the AMP is executed. If it drops the flow, the IPS does not execute.
  • trustThe trust action passes the flow without any inspection, AMP and/or IPS.
  • monitorLogs the end of connection (cannot be modified) and proceeds to the next rule in the policy or the default rule. We cannot attach the AMP/IPS policy to the monitor action.
  • blockBlocks the flow without any further inspection or processing. We can optionally log the beginning of the session.
  • block with resetDoes the same as Block, but sends RST to both ends of connection and thus saves some resources by not waiting for session to time out. We can log only the beginning of the session and cannot do any inspection.
  • interactive blockThis action is for HTTP traffic. The rule with this action will present a user with a portal where he/she can decide to proceed or not. In the case that user wants to proceed, this action is treated as Allow, otherwise as Block.
  • interactive block with reset Same as with Interactive Block, but sends RST to both ends.

Let’s now continue with our configuration. For the action we will chose “Block with reset” and we carry on with filling the tabs in. The rule is going to be placed into the rule category “Standard Rules” by default.

1. Zones

Here we can specify source and destination zones for the traffic we are engineering. We should be familiar with zone based firewall concept by now. The idea behind this is that we group one or more interfaces into zones and we then apply security policy to all interfaces at once, instead on each interface individually. These zones are defined elsewhere in the DC. We select SFR_TEST_INSIDE zone as a source and SFR_TEST_OUTSIDE zone as a destination zone:

19-May-2015 1-33-26 PM

2. Networks

In the Networks tab we can be more specific. In the zones we stated that the destination zone is SFR_TEST_OUTSIDE, but we want only two hosts to be affected by this rule instead of all hosts sitting in that zone. Here we can use predefined objects or list IP addresses. Important thing to note here is that the items listed in the same category, for example “Destionation Networks” are ORed and that the relation between different categories is AND. We could read the following example as: this rule will block whatever application/port we want, if “Source Networks” are any AND the “Destination Networks” are TELNET_SERVER OR 10.a.b.111.

20-May-2015 9-28-30 AM

In the Networks tab, we select predefined object from the list “Available Networks” and click “Add to Destination“. If we want to add the IP address or network without creating an object we enter the IP address in the “Enter an IP address” field under “Destination Networks” and click Add.

3. VLAN Tags

This tab has no meaning for Sourcefire deployed as an ASA module.

20-May-2015 12-48-41 PM

4. Users

From this tab we can select users or groups for which we want this rule to apply. The users and groups are pulled from the Active Directory by the help of User Agent installed somewhere in our domain. More on this some other time. For now we will chose our user(s) and click “Add to Rule“. If we don’t have user agent installed, we can skip this tab and the rule will apply without taking this tab into consideration.

19-May-2015 1-35-50 PM

5. Applications

Here we can specify application(s) we want to block. We can search applications by name, category, tag, risk level, business relevance and so on. We will type Telnet in the “Search by name” field, under “Available Application“. From the filtered list we select Telnet and click “Add to Rule“:

19-May-2015 1-36-25 PM

6. Ports

This is where we can use ports instead of applications to block something. For example, if we knew for sure that the Telnet application always uses TCP/23 port, we could skip the settings from the Application tab and list TCP/23 as a “Selected Destination Port“. Another example would be our custom application that uses port UDP/54321, for example. We could use that port as a destination port, instead of writing rules to recognize our application. In our scenario we will not use destination port, but in the picture below, it is given for illustration purposes only:

20-May-2015 9-49-11 AM

7. URLs

The traditional, old fashion URL filtering. Here we can block certain web categories, such as “Computer and Internet Security“, “Adult and Pornography” and so on. We could also block based on reputation, for example block all sites with high risk reputation. This does not apply to our scenario:

20-May-2015 9-53-54 AM

8. Inspection

We can have traffic flow inspected by AMP policy and/or IPS policy. Because our action is set to “Block with reset” we cannot apply these policies, because it does not make any sense. If we had Allow as an action, we could specify one or both policies. If we specify both, first the AMP will trigger and only if it does not block the flow, the IPS will also apply. The actions that cannot have AMP/IPS policies applied are: Trust, Monitor, Block and Block with reset”. Actions that can have AMP/IPS policies assigned are: Allow, “Interactive Block” and “Interactive Block with reset”.

20-May-2015 12-47-29 PM

9. Logging

In the Logging tab we specify if, how and where we will log this rule. For some actions we have an option to log only the beginning of the flow, for some we can log the beginning and/or end and for Monitor action we cannot specify an option because the “Log at End of Connection” is implied. By default all logs are sent to the “Defense Center“, but optionally we can also send logs to Syslog server, a SIEM solution, for example, or send a SNMP trap to monitoring station:

19-May-2015 1-49-02 PM


Comment tab is the place where admins can attach their comments regarding changes they have made:

20-May-2015 10-06-38 AM


Finally, we have designed our rule as per request. We click Add and the rule appears in the “Standard Rules” section:

20-May-2015 12-54-59 PM

We need to apply our changes and click “Save and Apply“. Now we try to telnet to three servers: 10.a.b.11, 10.a.b.111 and 10.a.b.115 and see what happens:

20-May-2015 10-26-22 AM

Cool, our policy works! Not quite. We expected only 10.a.b.11 to go through, but we can see that all of them passed. So, what’s the catch? Remember the part of this blog post where we said that the objects of the same type are ORed and the objects of the different type ANDed? Well, in our policy we have several object types that are ANDed and two of them that are ORed:

(DestionationZone=”SFR_TEST_OUTSIDE”) AND (DestinationNetwork=TELNET_SERVER OR 10.a.b.111) AND (SelectedUser=sasa.popravak) AND
(Application=Telnet) AND

Yes, and? And we are trying to match Application=Telnet AND DestionationPort=UDP/54321 which is unlikely to happen.

So we will kick the destination port condition out, save our changes and try again:

20-May-2015 10-35-57 AM

That’s what I’m talking about 🙂

We now know how to write basic rules. Next time we will extend our knowledge by adding the IPS into equation.

Thanks for reading!

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

3 Responses to Sourcefire Access Control Policies – Part Two

  1. mikgruff says:

    This is great stuff!!

  2. mikgruff says:

    Great information. Would you mind sharing your ideas regarding best practices for building an initial file policy?


Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s