How to Configure URL filtering on FirePower

Welcome to Tor Network’s technical tutorials where we demonstrate how to configure URL filtering on Cisco’s Next Generation FirePower devices, so lets dive in.

Prerequisites for URL Filtering on FirePower

To begin with, let us see what are the prerequisites for the configuration of URL filtering on Firepower.

There are two points to consider; first the device should have valid URL filtering license, and second the URL database cloud should be updated. One other thing that needs to kept in mind is that we should have connectivity to the BrightCloud Services as well.

To check whether the Cisco Firewall device has a valid license in management center version 5.4, you go to Devices and then Overview. It is there where we can see if the device has a valid URL filtering license or not.

Go to the Devices > Device Management page, and verify if the URL Filtering license is applied on the device that monitors the traffic. Here is a Screenshot:

To check the connectivity part you need to have the management center ready and then ssh into it. Then we need to check whether we are able to telnet into the bright cloud services with the commands:

telnet database.brightcloud.com 443

&

telnet service.brightcloud.com 80.

A successful test would let you in and confirm that it is working fine.

The next step is to check whether the cloud database is updated. For that you need to go to System > Local > Configuration and then click on Cloud Services.

Make sure that Enable URL filtering, Enable Automatic Updates, and Query Cloud for unknown URLs is selected. Then click on the button Update Now. On successful update you should be able to see the most recent update date and time.

Check if the URL Filtering license is installed on the FireSIGHT Management Center. Go to the System > Licenses page in order to find a list of licenses.

And if you want to see the same information from the CLI then we can check it through the following commands:

 

 

root@Sourcefire3D:/volume/home/admin# cd /var/sf

root@Sourcefire3D:/var/sf# cd cloud_download

root@Sourcefire3D:/var/sf/cloud_download# ls -alrt | grep bcdb

 

As you can see that we have a big size BrightCloud database file in this cloud download directory, which tells us that it has successfully downloaded the database from the cloud. To check on the sensor or the FirePower module that you are managing that the Defense Center has actually pushed this update to the sensor or not, here is what you will need to do:

Here if you see the size of the file is also the same on both the management center and the sensor. This was about the URL database updates from the Cloud. And since in this example we were using FirePower version 5.4 and if you’re running version 6.0 which is a more recent one, you can see the same option but in a different place:

In the GUI go to System > Integration > Cisco CSI tab. So that is the only change from the configuration point of view.

Configuring URL Filtering

There are three steps you should follow for the configuration of URL filtering:

1. Configure URL objects/group under Object management
2. Create rule under Access control policy calling the URL object created
3. Deploy the policy to the target device

(The above steps will work for both version 5.4 and 6.0 and any device managed via ASDM as well)

Firstly you have to configure the object/s or group under Object Management, secondly you have to call that object group in the access control policy and lastly you have to apply or deploy the target policy on to the target device.

As an example to block Twitter we can create a URL filtering policy. To do that lets go to Objects > Objects Management then to the URL tab and here you have a choice between Individual Objects or Object Group. Individual objects is used when you have a single URL entry that you want to call in your policy.

An Object Group will come into picture when you have multiple URLs for the same category and you want to combine them into one particular group. Lets add twitter.com to Individual Objects as seen in the screenshot:

The next step is to create a policy that will utilize the above URL object. For that lets go to Policies > Access Control > Default Access Control. We already have the Default Access Control policy in which we have to create a rule for twitter.com

After providing a name and action go to URL tab and call the object created and add to Rule with the action set to block. Also click on the logging tab and enable logging as well so that you can see the corresponding events on the Defense Center.

As a general rule, whenever you are adding a rule make sure that the specific rules are added above the general rules because if you create specific rules below any allow or trust rules which is by default allowing all traffic then your new rule will not be hit.

The next step is to apply the changes to the target device. With that we have covered the configuration part and the configuration of the the FirePower module will be the same if you’re managing the device via ASDM as not all users will be using the FirePower Management Center.

URL Selection Matrix

Selected Reputation Level	Selected Rule Action
	High Risk	Suspicious Site	Benign Site with Security Risk	Benign Site	Well Known
1 – High Risk	Block, Allow	Allow	Allow	Allow	Allow
2 – Suspicious Sites	Block	Block, Allow	Allow	Allow	Allow
3 – Benign Sites with Security Risk	Block	Block	Block, Allow	Allow	Allow
4 – Benign Sites	Block	Block	Block	Block, Allow	Allow
5 – Well Known	Block	Block	Block	Block	Block, Allow

Problem: Wildcard Does not Work in the Access Control Rule

FireSIGHT System does not support specification of a wildcard in a URL condition. This condition might fail to alert on cisco.com.


*twitter*.com

Troubleshooting URL Filtering

So now let’s check how we can verify that whatever URl filtering that we have created is actually being used. We have two ways to identify if rule we created is correct. First is on the Defense Center or from the FirePower Management Center (FMC), we can check from the connection events if the rule is correctly hit and the URL is properly blocked or allowed.

And the second way is to do it from the CLI of the FirePower device; so that we can see whether it is hitting the correct rule. After initiating some traffic from the test machine for twitter.com we can see that we are getting the right policy and twitter.com has been blocked.

And if we check the corresponding events on the GUI we can see that twitter.com has the action of  blocked and it is also hitting the right policy. You can check the details by clicking on the “Table view of Connection events”, which basically show us the exact policy which was engaged by the access control rules.

We can also use the CLI to check  if we are getting the right policy or not. We have to initiate some traffic again so if we see here it starts with matching the rules from top to bottom and it first checks the Facebook block rule and then goes to the Block Twitter rule and takes action depending upon the rules set in the policy.

So this confirms that we are matching the right policy and hence the URL filtering is working as expected.

Please join us for more useful tutorials and guides. Or you can browse our Cisco CCNA training course.

Please Join Save