Sourcefire Access Control Policies – Part One

Let me stress out one more time that this blog series is all about ASA5500-X with the SFR module. Some things described here may be different for physical appliances.

Now we have all installed and set up and we want to create our security policy. First of all, on Sourcefire we have tons of policies: access control policy, health policy, system policy, network discovery policy, intrusion prevention policy, … In this blog post we will deal with access control policy (ACP).

So, what is access control policy? Well, it is what its name says: it controls the access through the SFR module. Pretty much the same ASA does, but with more power. Technically speaking, the SFR can drop any traffic that ASA can, but it’s not supposed to work that way. ASA  should drop traffic at L3/L4 of the OSI model, and the SFR should go above that, up to the L7.

Before we redirect traffic from our ASA box, we should make sure that the right policy is applied to our SFR module. We have some predefined ACPs that we can use and change, or we can make a copy of those policies and use copies to begin with.

Before we proceed, here is our simple lab topology:

19-May-2015 10-15-51 AM

Our ASA has the SFR module and runs in transparent mode. This is just one scenario. Like said earlier, it can run in routed mode as well, and also in A/S and A/A failover. On the left hand side we have SFR_TEST_INSIDE nameif interface and this interface connects to the network we want to protect. Here we have our test laptop which we will use to test our policies. On the right hand side, we have SFR_TEST_OUTSIDE nameif interface which connects to some sort of L3 device which routes traffic to the rest of the world. Pretty simple scenario.

For this lab, we allow all L2/L3 traffic to pass through the ASA, because ACLs on ASA is not what this blog is all about. We could have some traffic dropped and that traffic would not even make it to the SFR module. We want all traffic to go through. In the production network, we would perhaps permit only certain type of traffic and drop everything else. The traffic we allow, would be inspected by our SFR policies we are about to create.

Like I said, we have some predefined policies with no rules in them, but with the default actions. Because the policies are empty, whether the traffic will go through the  SFR depends on the default action. For example, we have two ACPs:

  • Default Access Control:

19-May-2015 10-00-36 AM

We can see that there are no rules and that the default action is “Access Control: Block All Traffic“. If we would direct our traffic from the ASA to the SFR, that traffic would be blocked. Unless we create some rules, of course.

  • Default Network Discovery

19-May-2015 10-34-04 AM

This policy is also empty, but the default action is “Network Discovery Only“, which allows all traffic to pass through, along with the detection of host types.

Depending on what we want to do, we can use one of these policies as a starting point. Let’s say that we will be less restrictive and will allow all traffic to pass and block only certain types of flows.

Let’s make a copy of “Default Network Discovery” policy. Under the Policies->Access Control, we click the Copy button of the policy we want to make a copy of:

19-May-2015 10-47-02 AM

We name the policy:

19-May-2015 10-51-49 AM

And we have the copy of the policy we can work on. We could also create our own policy by going to Policies->Access Control and clicking the “New Policy” button:

19-May-2015 10-41-30 AM

A dialog box opens:

19-May-2015 10-54-57 AM

We give it a name and select the default action.

Either way, we have our empty policy that allows all traffic redirected from ASA to pass through. Before we redirect the traffic from the ASA, this policy needs to be applied to one or more SFR modules. Let’s assume that we have these modules registered to the Defense Center as described in the previous blog post.

Now when we open our policy, we have several tabs. We click the “Targets (0)” tab. The zero in the name of the tab means that this policy does not target any modules at this time:

19-May-2015 11-00-57 AM

When we click this tab, we have our modules listed on the left, under “Available Devices“:

19-May-2015 11-04-00 AM

We select our SFR module and click the “Add to Policy” button in the middle of the window. Our module is now listed under “Selected Devices“:

19-May-2015 11-07-10 AM

We can remove this module by clicking the trash can icon. If we are satisfied with our selection, we click “Save and Apply” button:

19-May-2015 11-08-52 AM

We acknowledge dialog box that opens and wait for the policy to apply to module(s). We can track the progress by looking at “Task Status” under “System->Monitoring->Task Status“.

After the policy is applied, we can go to the ASA and redirect desired traffic. We will redirect all traffic. First we create a class map:

!
class-map SFR
match any
!

In a production environment, we could only monitor the HTTP/HTTPS traffic, for example. In that case we could create an access list:

!
access-list WEB extended permit tcp any any eq www
access-list WEB extended permit tcp any any eq https
!

And match only that traffic:

!
class-map SFR-WEB
match access-list WEB
!

At this point we just selected traffic to be sent to SFR, now we need to actually send it. We may create a policy map and apply it on a specific interface, but in this case we will use the global_policy:

!
policy-map global_policy
class SFR
sfr fail-open
!

This policy is already applied to all interfaces. We can verify that the traffic is sent to the SFR module:

ciscoasa#
ciscoasa# show service-policy sfr

Global policy:
Service-policy: global_policy
Class-map: SFR
SFR: card status Up, mode fail-open
packet input 491640, packet output 491654, drop 174, reset-drop 2
ciscoasa#

Finally, we can verify this on the module as well by going to  “Analysis->Connections->Events“. For testing, let’s do a ping from our laptop to the 8.8.8.8. Now we have this traffic logged on the DC. This would be true if we didn’t miss one important step. In our policy, under the default action we need to turn on logging. It is turned off by default:

19-May-2015 11-24-29 AM

19-May-2015 11-24-08 AM

We apply our changes and test our ping again:

19-May-2015 11-32-27 AM

Now we have our traffic going through the ASA and module and we can do whatever we want with it, and SFR allows us to do almost that. More about this in the next blog.

Here is the ASA config:

!
firewall transparent
hostname ciscoasa
enable password somepassword encrypted
names
!
interface GigabitEthernet0/0
 nameif SFR_TEST_OUTSIDE
 bridge-group 112
 security-level 0
!
interface GigabitEthernet0/1
 nameif SFR_TEST_INSIDE
 bridge-group 112
 security-level 100
!
interface GigabitEthernet0/2
 shutdown
 no nameif
 no security-level
!
interface GigabitEthernet0/3
 shutdown
 no nameif
 no security-level
!
interface GigabitEthernet0/4
 shutdown
 no nameif
 no security-level
!
interface GigabitEthernet0/5
 shutdown
 no nameif
 no security-level
!
interface GigabitEthernet0/6
 shutdown
 no nameif
 no security-level
!
interface GigabitEthernet0/7
 shutdown
 no nameif
 no security-level
!
interface Management0/0
 management-only
 nameif MANAGEMENT
 security-level 100
!
interface BVI112
 ip address 10.a.b.c 255.255.255.0
!
ftp mode passive
clock timezone CET 1
clock summer-time CET recurring last Sun Mar 2:00 last Sun Oct 3:00
!
access-list SFR_TEST_OUTSIDE_L3 extended permit ip any any
access-list SFR_TEST_OUTSIDE_L2 ethertype permit any
!
access-list SFR_TEST_INSIDE_L2 ethertype permit any
access-list SFR_TEST_INSIDE_L3 extended permit ip any any
!
access-list WEB extended permit tcp any any eq www
access-list WEB extended permit tcp any any eq https
!
pager lines 24
mtu MANAGEMENT 1500
mtu SFR_TEST_OUTSIDE 1500
mtu SFR_TEST_INSIDE 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
no arp permit-nonconnected
!
access-group SFR_TEST_OUTSIDE_L2 in interface SFR_TEST_OUTSIDE
access-group SFR_TEST_OUTSIDE_L3 in interface SFR_TEST_OUTSIDE
access-group SFR_TEST_INSIDE_L2 in interface SFR_TEST_INSIDE
access-group SFR_TEST_INSIDE_L3 in interface SFR_TEST_INSIDE
!
route MANAGEMENT 0.0.0.0 0.0.0.0 10.a.b.c 1
timeout xlate 3:00:00
timeout pat-xlate 0:00:30
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
user-identity default-domain LOCAL
aaa authentication ssh console LOCAL
no snmp-server location
no snmp-server contact
crypto ipsec security-association pmtu-aging infinite
crypto ca trustpool policy
telnet timeout 5
no ssh stricthostkeycheck
ssh 0.0.0.0 0.0.0.0 MANAGEMENT
ssh 0.0.0.0 0.0.0.0 SFR_TEST_OUTSIDE
ssh 0.0.0.0 0.0.0.0 SFR_TEST_INSIDE
ssh timeout 5
ssh key-exchange group dh-group1-sha1
console timeout 0
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
ntp server 10.a.b.c
ntp server 10.a.b.c
dynamic-access-policy-record DfltAccessPolicy
username someuser password somepassword encrypted
!
class-map SFR
 match any
!
class-map inspection_default
 match default-inspection-traffic
!
class-map SFR-WEB
 match access-list WEB
!
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum client auto
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
  inspect ip-options
 class SFR
  sfr fail-open
!
service-policy global_policy global
prompt hostname context
no call-home reporting anonymous
!

 

Stay tuned, more is to come…

 

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

7 Responses to Sourcefire Access Control Policies – Part One

  1. Pingback: Sourcefire Access Control Policies – Part Two | popravak

  2. kevin says:

    Amazing post. Thank you for these greats informations. I missed the step where I need to turn on logging on my default policy. It is working now!

  3. Max says:

    Great post! Let’s read till the end )

  4. ppolona says:

    Thank you for super post! My question is: if you configured: class-map SFR
    match any, why do you use access lists: access-group SFR_TEST_OUTSIDE_L2 in interface SFR_TEST_OUTSIDE
    access-group SFR_TEST_OUTSIDE_L3 in interface SFR_TEST_OUTSIDE
    access-group SFR_TEST_INSIDE_L2 in interface SFR_TEST_INSIDE
    access-group SFR_TEST_INSIDE_L3 in interface SFR_TEST_INSIDE

    Or I miss something.

    Thank you.

    • Sasa says:

      Those are for connectivity of this specific deployment. They don’t have to do anything with the SFR. Similar to ordinary ACLs tied to some L3 interface. The class map is the only thing responsible for sending the traffic to the SFR.

      Hope this clarifies it a little bit…

  5. RSS says:

    This is a great blog which is so much clearer and more concise than any “official” documentation I’ve found to date.

    I have an ASA 5506 with FirePOWER managed as a single device; so managed using ASDM and not FireSIGHT. I’ve followed all instructions to the letter, but whilst my access control policy is successfully applied to the device I don’t seem to be able to get the rules working. I’m trying to get URL Filtering working and have configured the service policy rule on the ASA to route ANY traffic to the ASA FirePower for inspection. After that the rules within my ACP should be applied. There’s no “Network Discovery” option as a “Default Action”, so my selection is “Trust All Traffic”.

    One immediate difference in the config is the
    “class-map SFR”
    “match any”
    My entry is
    “class-map inspection_default”
    “match any”
    The SFR option doesn’t exist. Is this something I need to create???

    Looking at the ASA FirePOWER monitoring I can see the web traffic from the initiators thru to target URL and the correctly assigned ACP being applied, but the rules are not working. Can you help???

    Thanks!

  6. RSS says:

    Following on from my earlier entry, see the following lines from my config:
    class-map inspection_default
    match any
    !
    !
    policy-map type inspect dns preset_dns_map
    parameters
    message-length maximum client auto
    message-length maximum 512
    policy-map global_policy
    class inspection_default
    sfr fail-open
    !

    Thanks!

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