Firepower Threat Defense AVC and SmartCLI

**Full disclosure, this was actually kind of a pain in the ass. While specifically blacklisting applications works perfectly well, that’s not what I wanted to show off in this post. I wanted to show how we can not just open ports in our ACEs, but also specifically dictate which applications can use those ports. With respect to DNS and ICMP, that worked fine, but trying to write a rule that basically said ‘allow tcp/80 and tcp/443 only for web browsing traffic’ ended up being a huge undertaking that set me back on this post, and forced me to drop the FDM entirely in favor of a full-blown FMC. Cisco… this shouldn’t be as hard as it was, fix it.**


There are a couple different ways to approach this problem, and normally what people do is opt to create a separate ACE that just blocks undesirable application types. That works fine, but I’d argue that implicitly dropping traffic is much more effective than explicitly blocking in this case. With our DNS and ICMP rules, this is easy from the FDM. Web traffic, on the other hand, requires a little more horsepower and granularity, so I’m going to forklift my configs into a Firepower Management Center. So let’s tackle the easy tasks first. Within our access control entries for DNS and ICMP, I’m just going to drop into the applications tab and specify those applications respectfully. Additionally, I’ll add a catchall rule that blocks w/reset so we don’t have to wait for dropped traffic to timeout.

ICMP/DNS Matching Application

Now web browsing traffic, this is where things get a little tricky. Before we dive into how to build our HTTP/HTTPS rule to only allow Web Browsing traffic, let’s look and see why you might want to do this. Eyes up Derek, no sleeping in class today. Remember our URL filter blocking access to online games? What happens to it if we tunnel all our traffic over an SSL VPN? On my test machine, I have both SoftEther and Window’s native SSTP client setup, so let’s get on our dodgy VPN and subvert security policies!

Connected to SSLVPN

Game On

This may seem like a silly example, but start thinking about how easily this could be exploited. Simply tunneling your traffic over port 443 suddenly bypasses DLP policies. Just opening the port to allow web browsing becomes a means of establishing a covert channel. This doesn’t have to be over a VPN either, by default TOR will connect to relays over tcp/443 if it’s default port (tcp/9001) is closed. So how to address this issue? The easy task is allowing the majority of expected applications for web browsing allowed, then we’ll come back to the hard part. So to start, let’s get some client-side applications added in (common browsers like Chrome and FireFox) as well as some well-known web-based applications (i.e. Google, Bing, Cisco, Facebook). The web-based applications become important because with HTTPS traffic Firepower can’t determine the client-side application in use. To make things easier on ourselves, I’m going to allow any Web Application with a risk of Medium or Less. Now, logically, one would think you could select Risk “Very Low”, “Low”, and “Medium” and Web Application as a single filter. At the time of this writing, that does not seem to work. So instead we need three separate filters pairing Web Application with each Risk. 

Cisco page loads

AVC vs. Unclassified Web Sites

So if you’ve caught yourself thinking “Now we’re done.” You wouldn’t be wrong, but user’s experiences on the Internet would be mixed at best. The issue you’ll often run into is, “what happens when a user browses to a site that isn’t well-known?”, that is, a site that Firepower doesn’t have a defined Web Application for. Well to answer that, let’s first see what happens when we browse to a little known, seldom visited site like networkknerd.com.

Congratulations! You’ve played yourself.

So now we’re in a pickle. We could try creating web applications for every website Firepower doesn’t have a canned definition for, but that seems like an administrative nightmare. So instead, I’m going to write a different sort of rule to get around this problem. Essentially, we need to write an application definition that can apply to browsing any HTTPS website (not already defined). To do this, I ran wireshark while trying to browse to my website, so I could poke around the TLS client/server messages. Doing so, I found a field in the client hello that I could match on.

We Got a Match

When we’re writing our rules, we’ll have the option to match on ASCII string or Hex. While I could just match on http/1.1, I decided to match the entire field with Hex 68 74 74 70 2f 31 2e 31. So, let’s move over to our FMC, under Policies -> Application Detectors. Click on ‘Create Custom Detector’. I’ll leave Detector Type as ‘Basic’, and I’ll Add to add an Application Protocol. From the Application Editor I’ll create a protocol like this:

Custom Application Protocol

Click ‘OK’ to return to the Create A Custom Application Detector dialog. Set the Application Protocol to be “HTTPoverSSL”, add a description then click “OK”. Now we need to tell Firepower what pattern we’ll be detecting to classify this traffic. Since I’m going with a field in the client hello field, I’ll set the direction to be client, protocol tcp, and add my hex value from above. To test, we can actually upload a pcap file and click ‘test’ (script with gear icon to the left of the trash can). Got all that?! Derek?! Don’t worry, accompanying screen shots below.

Custom Application Detector

Traffic Pattern to Match

Successful Test

Well that was easy.

Adding HTTPoverSSL to ACE

Web Browsing Working