Congratulations, you've purchased one of Cisco's shiny new Next-Generation Firewalls. It's going inspect more packets, push bits at blazing speed, and finally lockdown your disgraceful network. You've built your access control policy and added a ton of rules allowing traffic outside to your inside zone. Maybe you even took this opportunity to build out that DMZ you've always been talking about. Good for you, I'm happy for you. But, uh, did you restrict which ports were open inside to outside? Did you use AVC to restrict which applications were allowed on the ports you opened or did you just open port 80 and 443 like a child?!
Well, that's why we're here, Derek, to talk about both this underused feature and also about some of the new features in Firepower Device Manager (standalone manager for non-FMC deployments). Time for us all to start firewalling better, all of us... Derek. To start things off, let's look aoutt our starting environment. Built-in GNS3, I'll be using FTDv for KVM running 6.2.3 and a layer3 switch running whocare.png. Honestly, the L3 switch is just so I have another OSPF speaker on net, use whatever you like.
 |
| Super Complex Topology |
All I've done on the FTD is assign a management IP on the same subnet as FDM-Client and FDM-Server. GigabitEthernet 0/1, which will be my inside interface, connected to SW1 on a separate routed link.
> show network
===============[ System Information ]===============
Hostname : FTDv
DNS Servers : 208.67.222.222
208.67.220.220
Management port : 8305
IPv4 Default route
Gateway : 172.31.45.1
======================[ br1 ]=======================
State : Enabled
Channels : Management & Events
Mode : Non-Autonegotiation
MDI/MDIX : Auto/MDIX
MTU : 1500
MAC Address : 0C:ED:AF:17:A6:01
----------------------[ IPv4 ]----------------------
Configuration : Manual
Address : 172.31.45.45
Netmask : 255.255.255.0
Broadcast : 172.31.45.255
----------------------[ IPv6 ]----------------------
Configuration : Disabled
> show managers
Managed locally.
>
So from here, before diving into AVC, I'm just going to get basic addressing knocked out then get connectivity to the outside setup. Along the way, I'll show off using SmartCLI to configure OSPF.
FDM - Basic Setup and Addressing
Of note, I did have some initial issues getting into FDM on this GNS3 appliance. When trying to access the WebUI I was receiving 503 Service Unavailable. To resolve this, I went to the CLI and issued 'configure manager delete' followed by 'configure manager local'.
When you first log into FDM, you're prompted to complete Device Setup which configures the outside interface, a default policy rule, DNS servers for your management interface, and also gives you the option to change your hostname. The next two pages you can configure time settings, and add Smart Licensing. This is a lab, so I'm just going to use a 90-day trial. Once complete you'll arrive at a page that looks similar to below.
 |
| FDM Quick Setup complete |
Next, we're going to configure our inside interface with an IP address 172.31.99.1/29. To do that I'll click on "3 Enabled" under Interfaces. Then select edit for interface GigabitEthernet0/1. From here I'll need to both change the IP address as well as delete the DHCP configurations to successfully modify this interface. After clicking OK, I'll then deploy my changes (top right, the icon with an 🠟, second from the left).
 |
| Change inside IP and delete associated DHCP scope |
SmartCLI - Configuring OSPF in FDM
I know, I know... that was really boring. Thanks for hanging in there, Derek, I promise we're going to start getting into the meat and potatoes of this post now. Also, sorry for making you hungry. First up, to finish establishing connectivity, let's configure OSPF on our Firepower device. Super basic, we're going to drop Gig0/1 (inside) into area 0.0.0.0 and have it originate a default route. The L3 switch behind the firewall also has a basic OSPF configuration looking for a neighbor on this subnet. From the Device tab in FDM, in the bottom right you'll see 'Advanced Configuration', and that's where we're headed.
 |
| FDM Advanced Config - SmartCLI and FlexConfig |
At present, SmartCLI serves a single purpose, which is configuring OSPF and OSPF alone (what no ODR?! #ObscureRoutingReference). From the OSPF template, the initial view leaves much to be desired. So we're going to click on 'Show Disabled' and then change enable 'setup ospf advanced'. From here you'll have a ton of OSPF options to configure, however, I'm going to disable most of them by clicking on the + to the left of each option I want to disable. Then I'll fill out all my relevant information.
 |
| SmartCLI - Advanced options hidden |
 |
| SmartCLI - Advanced OSPF enabled |
Additionally, there's a SmartCLI template called "Interface" that allows you to configure interface-specific OSPF options such as authentication, cost, and network type. After deploying, we can go to the CLI to confirm everything is working as expected.
> show ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.122.22 1 FULL/BDR 0:00:34 172.31.99.2 inside
> show route ospf | begin ^Gateway
Gateway of last resort is 192.168.122.1 to network 0.0.0.0
O 172.31.45.0 255.255.255.0 [110/20] via 172.31.99.2, 00:41:15, inside
>
Application Visibility & Control (AVC)
Now onto the main event, AVC. I'll demo this out using FDM, but the concept is exactly the same in Cisco's full-blown Firepower Management Center. This is a feature I don't see implemented near often enough, and when I do see it deployed typically not in a way that maximizes its potential (looking at you again Derek). Let's start with a very basic objective and we'll work outwards from there. You've deployed this firewall, and you only want to allow the following egress traffic from your users.
- Web browsing over HTTP and HTTPS (foreboding-music.mp3)
- ICMP echo
- DNS to OpenDNS
Everything else should be dropped. Additionally, you want to block URLs for online gaming sites. So you build out a couple ACEs in your policy, click deploy and call it a day. Tell me I'm wrong Derek. Let's first take a quick look at what our policy looks like, before talking about how AVC can help us.
 |
| Derek's super secure bulletproof ACP |
Then we'll go to our client machine and make sure everything is working as expected.
 |
| DNS and ICMP work |
 |
| HTTPS works |
 |
| URL Filtering works |
So that's it, right? Right?...Right? What's guaranteeing that the ports we've opened are going to used by the applications we intend? Of course, there are obvious things like SSLVPN and proxies to worry about - but then also less obvious concerns. There's an open-source, easily deployed, VPN client now that allows tunneling over ICMP and DNS. You read that right.
**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.
 |
| Common Web Browsing |
With this deployed, let's go back to our test machine. I'll try to connect to VPN first, then browse to a couple websites.
 |
| No Luck connecting to SSLVPN |
 |
| 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.
Not really, but now we have a custom application detector to add to our ACP that should work as a catch all for all HTTPS browsing (in addition to the previous rules implemented based on application type/risk level). After adding that to my INSIDE-to-WEB rule, browsing works flawlessly and SSLVPN is still implicitly blocked. So, a couple more screen shots then I'm call this post from hell done.
 |
| Adding HTTPoverSSL to ACE |
 |
| Web Browsing Working |
 |
| SSTP Still Dead |
Alright. Well... I need a drink.
