Friday, November 24, 2017

Adjusting to Firepower Threat Defense

I wanted to do a quick post today about Cisco's Firepower Threat Defense. As I'm sure most of you know, this platform is moving to (eventually) replace the ASA code we all know and love. It's not quite there yet with some features missing that are keeping some from converting. Most notably is AnyConnect for remote access VPN. While true that in FTD 6.2.2 we do finally have support for AnyConnect, it's missing a lot of features (Client-less SSL, Posturing, and custom profiles for AMP and Umbrella deployments to name a few). However; if all you need is a head-end for AnyConnect clients FTD works just fine. In future posts I'll talk about deploying FTD, specific configuration task, and some of the really nice integration we get with Cisco ISE. However this post is going to be geared a little more towards those who currently work with ASA and how day-to-day work with FTD is similar and more importantly where it differs. So let's dive in (obligatory gif coming)!




Configuration Changes

This is by far the biggest difference coming from ASA. In ASA-land, most of us are either making changes line-by-line in the CLI or, if you hate having a clean and legible config, using ASDM. With FTD you have two options for deployment that will directly influence how you interact with your firewall(s). 
  • Option 1 is to use the Firepower Management Center. This comes in both virtual and hardware appliance flavors. The FMC is designed to manage policies across multiple Firepower devices, but can be used to manage a single device. This option provides the most features, and most complete Firepower experience. You'll deploy your management center, and via the management interface on the FTD, register the FTD with the FMC. 
  • Option 2 is to use the onboard Firepower Device Manager (FDM). After giving your FTD a management IP address, you'll connect directly to the management IP via web browser to make all configuration changes. As of 6.2.2, some of the limitations you'll find with FTD are as follows:
    • No dynamic routing
    • Limited Identity policy options (AD integration for identity based access control). Limited in that you can only do active authentication, meaning the user is redirected to a Web Portal and has to sign-on.
    • IPS and AMP policies are static/prebuilt policies that can't be tweaked.
    • No Etherchannel 
I will say this about FDM though, what it lacks in features is makes up for in appearance. See for yourself. 

Firepower Management Console

Firepower Device Manager

So it's from here that you'll configure your access-lists, NAT, Interface addressing, etc, etc. Which brings us to another difference. In Firepower changes are not made in real time (contrary to those of us who use CLI heavily with ASA). Instead, you'll make whatever changes you intend on, then click "Deploy" to actually push/apply those changes to your Firepower device. This CAN be a little slow. If you're practicing with a virtual FTD (which I highly recommend) deployments can take less than a minute. However if you're working with a physical firewall, they may take several minutes to complete. My 5506-X for example, on average, takes ~2 1/2 minutes. 


Packet Processing & ACLs


In ASA we have a concept of security levels. Out of the box behavior is that traffic from higher security levels is allowed to lower security levels, but not vice versa. This concept goes away in FTD. In FTD we have "Security Zones" which are essentially tags we use in policy configuration, and they don't have any other inherent properties that I'm aware of (no more nameif inside = security-level 100). So we need to be explicit about what traffic is allowed from what zone to what destination zone. Which brings me to the next big difference, ACLs. In ASA we have the option of per-interface ACL. You create an access-list specifically for, say, traffic coming from the outside interface inbound. This is another concept that's largely gone in FTD. Instead, we have an ACL applied globally (which you could do in ASA, but would normally be in conjunction with per-Interface ACLs).  This isn't as cumbersome as it sounds though, so long as you're smart about creating your ACEs, we can create rule categories within our access control policies that help us keep things organized. Important to note as well, within the Access Control Policy (ACP), it's processed top to bottom, just like traditional ACLs. So keep that in mind when building out separate rule categories.

ACP Rule Category Example

NAT and ACL; here's where we find some common ground. Just like on ASA 8.3+, ACLs are processed POST NAT. That means, like in the example above, if you have a Web Server being translated through your FTD, access control rules for allowing access to the Web Server need to specify the private/real IP of the server. Not the NAT IP. 


The Command Line

Is. Not. Dead. Rejoice my CLI junkies. Rejoice. While it can't be used for configuration, if you're like me and have honed your troubleshooting skills on the ASA CLI... those skills aren't lost on FTD. Regardless of if you go the FMC or FDT route for deployment, can you can still SSH to the management IP (or console in you like) the Firewall itself and have full access ASA style commands. The shell does look different, but commands do indeed work. For example, lets look at output from a couple troubleshooting commands.

> show version 
-------------------[ LM-HQ-FW1 ]--------------------
Model                     : Cisco Firepower Threat Defense for KVM (75) Version 6.1.0 (Build 330)
UUID                      : 260e3aee-ce59-11e7-a99a-a6e8d2e44557
Rules update version      : 2017-11-20-002-vrt
VDB version               : 270
----------------------------------------------------
> show conn
5 in use, 44 most used

UDP inside  172.16.10.250:123 outside  104.131.139.195:123, idle 0:00:01, bytes 96, flags - N
UDP inside  172.16.10.250:123 outside  38.229.71.1:123, idle 0:01:53, bytes 96, flags - N
> show running-config 
: Saved

: Serial Number: {omitted}
: Hardware:   ASAv, 8192 MB RAM, CPU Pentium II 2660 MHz, 1 CPU (4 cores)
:
NGFW Version 6.1.0 
!
hostname firepower
enable password {omitted} encrypted
names

!
interface GigabitEthernet0/0
 nameif outside
 cts manual
  propagate sgt preserve-untag
  policy static sgt disabled trusted
 security-level 0
 ip address dhcp setroute 
!
interface GigabitEthernet0/1
 nameif inside
 cts manual
  propagate sgt preserve-untag
  policy static sgt disabled trusted
 security-level 0
 ip address 172.16.10.2 255.255.255.0 
!
interface GigabitEthernet0/2
 shutdown
 no nameif
 no security-level
 no ip address
!
interface Management0/0
 management-only
 nameif diagnostic
 cts manual
  propagate sgt preserve-untag
  policy static sgt disabled trusted
 security-level 0
 no ip address
!
ftp mode passive
ngips conn-match vlan-id
dns domain-lookup diagnostic
access-list CSM_FW_ACL_ remark rule-id 9998: PREFILTER POLICY: Default Tunnel and Priority Policy
access-list CSM_FW_ACL_ remark rule-id 9998: RULE: DEFAULT TUNNEL ACTION RULE
access-list CSM_FW_ACL_ advanced permit ipinip any any rule-id 9998 
access-list CSM_FW_ACL_ advanced permit 41 any any rule-id 9998 
access-list CSM_FW_ACL_ advanced permit gre any any rule-id 9998 
access-list CSM_FW_ACL_ advanced permit udp any eq 3544 any range 1025 65535 rule-id 9998 
access-list CSM_FW_ACL_ advanced permit udp any range 1025 65535 any eq 3544 rule-id 9998 
access-list CSM_FW_ACL_ remark rule-id 268434432: ACCESS POLICY: LM_DEFAULT - Default/1
access-list CSM_FW_ACL_ remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268434432 
!
[omitted for brevity]
!
nat (inside,outside) after-auto source dynamic any interface description NERD Default NAT
access-group CSM_FW_ACL_ global
router ospf 1
 network 172.16.0.0 255.240.0.0 area 0.0.0.0
 no nsf cisco helper
 no nsf ietf helper
 no capability opaque
 no capability lls
 log-adj-changes
 default-information originate
> show ospf neighbor 


Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.0.1        1   FULL/BDR        0:00:32    172.16.10.1     inside
> packet-tracer input inside tcp 172.16.32.107 80 8.8.8.8 80

Phase: 1
Type: ACCESS-LIST
Subtype: 
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 172.19.0.1 using egress ifc  outside

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268434432 
access-list CSM_FW_ACL_ remark rule-id 268434432: ACCESS POLICY: LM_DEFAULT - Default/1
access-list CSM_FW_ACL_ remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached

Phase: 4
Type: CONN-SETTINGS
Subtype: 
Result: ALLOW
Config:
class-map class-default
 match any
policy-map global_policy
 class class-default
  set connection advanced-options UM_STATIC_TCP_MAP
service-policy global_policy global
Additional Information:

Phase: 5
Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (inside,outside) after-auto source dynamic any interface description LM Default NAT
Additional Information:
Dynamic translate 172.16.32.107/80 to 172.19.0.160/80

Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) after-auto source dynamic any interface description LM Default NAT
Additional Information:

Phase: 9
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 73360, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow


You get the idea. It's all there. You can look access-list hits, check on IKEv1 or IKEv2 security associations or look at IPsec SAs. Which was welcome news for me, however if you're a GUI user... fear not lol. These tools are indeed available in the Management Center. In 6.1 they're a bit limited and can be accessed from System > Health > Monitor. Then clicking on the firewall you want to execute these commands on, and selecting advanced troubleshooting. In 6.2 they've built these tools up a pretty good deal, and can now be accessed from Devices > Device Management and selecting the icon for Advanced Troubleshooting.

Firepower 6.1 Advanced Troubleshooting

Firepower 6.2 Advanced Troubleshooting



Different, but "good" different?

First off, I want to acknowledge that I didn't cover a lot of things in this post. That was intentional though. Firepower brings to the table some absolutely amazing (and much needed) features. Features like SNORT IPS, Advanced Malware Protection (AMP), URL and Application Filtering. In future posts I'll share my thoughts on these features, but spoiler alert - I love them lol. That said, as an ASA fanboy and CLI junkie I'm surprised how much I like working with FTD. I do leverage my ASA style troubleshooting, which makes the transition significantly easier. All that changes from a troubleshooting perspective with FTD is how your react when you discover configuration issues. Instead of adding/removing some lines from the config, now we're going into our management console (be it FDM or FMC) to make those changes. I thought this would be disruptive to my work flow, or maybe it would fundamentally slow me down... but it doesn't. At least until I click "Deploy" on my changes lol. Well, that's all for this post. Again, in future posts I hope to cover deploying an FTD from scratch and working with some of the NGFW features that set this platform apart. 

Tuesday, May 30, 2017

Protect The LAN: IPv6 RA Guard

So while nerding on YouTube, one of my favorite YouTubers Quidsup did a demonstration of using Kali Linux to perform a pretty nifty denial of service attack against Windows 10. The attack has some minor caveats, but none the less is dangerous and relatively easy to pull off. It works by flooding the connected network segment with IPv6 router advertisements (RA). IPv6 RAs assist in stateless autoconfiguration, so that IPv6 hosts on the network can assign themselves an IP, and can also carry default router information. However, since hosts can have multiple IPv6 addresses, Windows ends up trying to autoconfigure an IPv6 address for every RA is receives. This results in pretty hefty CPU spikes, as well as the NIC being completely unresponsive. However; Cisco has a pretty neat little trick we can implement on our access layer switches to mitigate these types of attacks. Based on the title of this blog, I'm sure you guessed what that feature is; RA Guard.

I like to think of RA Guard as being somewhat akin to DHCP snooping. We build a policy, assign said policy to switch ports, and RA Guard will drop unauthorized RAs. The configuration is fairly straight forward, but seeing the difference it can make when implemented is impressive. See video below :-).



Tuesday, May 2, 2017

CCIE status suspended (but then got it back)

So that happened. Now, I know what some of you are thinking based on the title of this post alone.


That's fair. The truth of the matter is, 2yrs sneaks up on you (or at least snuck up on me) really fast. After I passed the lab in 2015, all I wanted in the world was a break. At that point, not many days had gone by that I hadn't thought of, talked about, or studied for my route switch lab. While I love R/S, and find the technologies incredibly interesting, it just isn't my only interest. Not even within the technology field. There were so many other things I wanted to learn, and to be honest... a lot of video games, TV shows, and general lounging about I felt I had missed out on.

Immediately after passing the lab, I sought to do (2) things. First and foremost, catch up on some seriously overdue slacking off time. I bought video games. So many games. I wanted to watch every TV show I had casually overheard co-workers or friends talking about. Secondly, I wanted to start learning something new. Not necessarily to the degree of a CCIE, but just something different. After a few months went by, I started feeling the itch to start working on something new. At that time I was really struggling to find something to scratch that itch. I felt like I didn't want to recertify in R/S, but if not R/S then what?

Data Center

Data Center... DataCenter... Data Centre? I didn't care, I had deployed a handful of Nexus switches. I thought (and still think) VPC and FabricPath were pretty cool. However after a few months, I started realizing that I was interested quite enough to justify going much further with it. That's not to say I'm ruling out CCNP DC, just I didn't see going after the DC written a path forward.

Service Provider

Oh SP, how much I still wish I could have made this make sense for me. It gets all my nerd juices going. For me studying SP was like all my favorite parts of R/S, but on steroids. MPLS is hands down one of my favorite topics, so from an interest level, this made perfect sense. However, after 6 months or so (yeah... 6 months lol), I started realizing that it didn't make much practical sense. I love the technology, but when would I ever get to use this knowledge? I don't work with ISPs often, and I have zero interest in working full time for one. I do work with large enterprise networks that run MPLS internally on occasion, but the R/S material is more than sufficient to support that. So that left me wondering if I could find something I both found interesting and had practical career applications.

Security

The upsides, I was already pretty versed on the ASA and IOS security measures. The downsides. at this time Security v5 had been announced and I knew that I couldn't wait for v5 to be released (January 31st 2017) because there's no way material for that exam would be out in enough time for me to prepare for the written before my number expired April 1st 2017. That left me with a narrow window to learn v4 of the lab (which had a fair bit of older technology). But I decided to go for it, I'd spend 3-4 months prepping for v4  security written, and make my first attempt in December of 2016. My thinking there, that would give me enough time to reasonably be ready for the test, but also enough time that if I failed I could retake before Cisco retired the exam.

Bad News Bears.

I wasn't ready for the v4 written in December, and I only had enough time for (1) retake before the exam retired. Which I also failed lol. Meaning there was no choice to keep my number in active status aside from taking the written for R/S. However, in February I decided I wouldn't do that. I figured "Who cares, I'll let my number go into suspended status until I can pass the v5 security written." Well, turns out I care. The day I got the email from ccie@cisco.com saying CCIE status was now suspended I instantly freaked out. Really really hard.

Routing & Switching

So after a couple weeks of getting back up to speed on R/S written material (c'mon, like you expect me to work with IS-IS and Multicast routing everyday), I sat for my R/S written last Friday and passed. It was a bitter sweet moment, on the one hand I got my number back in active status, and all the perks that come with that. On the other hand, I felt like I spent my first two years as an IE spinning my tires. So what now? Security, I'm coming for you. As for this blog, I'm back here as well. Focused on R/S, SP, and Security technologies just like before. 





In keeping with my ususal standard of blogging, I'm not proof reading this post until much much later. Have fun grammar Nazis. 

















Wednesday, January 18, 2017

I'm Alive!!

Just thought that'd be worth sharing... I guess. CCIE Security studies have been consuming most of my time. However, I'm just about at the point where I can publish some stuff. I've had drafts for my FlexVPN with dynamic spoke-to-spoke tunnels sitting in draft for months now. So that'll likely come first, after that I may get into some FirePOWER posts.


Monday, August 15, 2016

Dynamic Site-2-Site VPNs with Cisco ASA

So let's take a moment and assume your life is too easy, and you want to punish yourself. But how?! Here's a way, let's use the ASA for sites-2-site VPN. Even better, the spoke sites have be able to have dynamic IPs, and also need connectivity to other spokes. Also, IKEv2. Just because. Everyone ready?! I know I am.




Honestly, it's actually incredibly easy. If you're not familiar with the ASA's ability to form dynamic L2L tunnels this post might be an eye opener. The tricky part is getting spoke to spoke connectivity in a reasonable fashion. However, we'll cross that bridge when we come to it. Let's look at the amazingly complex and overwhelming topology we'll be working with today.


Give yourself a few minutes to study all the minute details. Alright, let's get the hub configured. Luckily this is actually really easy.

crypto ikev2 policy 10
 encryption aes-256
 integrity sha512
 group 2
 prf sha      
 lifetime seconds 28800
!
crypto ikev2 enable OUTSIDE
!
crypto ipsec ikev2 ipsec-proposal AES256
 protocol esp encryption aes-256
 protocol esp integrity sha-512
!
crypto ipsec security-association lifetime seconds 3600
!
crypto dynamic-map DYNAMIC-S2S 1 set pfs 
crypto dynamic-map DYNAMIC-S2S 1 set ikev2 ipsec-proposal AES256
crypto dynamic-map DYNAMIC-S2S 1 set reverse-route
crypto map VPNMAP 65535 ipsec-isakmp dynamic DYNAMIC-S2S
crypto map VPNMAP interface OUTSIDE
!
tunnel-group DefaultL2LGroup ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco123
 ikev2 local-authentication pre-shared-key cisco123

That's about it for the crypto. The tunnel-group name has to be DefaultL2LGroup. One thing of particular note that I do not care for, with this model any dynamic tunnel peers have to share the same PSK. You'll also take notice I didn't specify any interesting traffic, nor did I set any peers. I also really like using reverse-route to inject static routes into the RIB, if you're going to do that on the Hub just keep in mind you have to do this under the dynamic map.

Now on the Hub, let's setup our nat exempt which will look a little different than it does on spoke ASAs.


object-group network ALLSITES
 network-object 192.168.1.0 255.255.255.0
 network-object 192.168.2.0 255.255.255.0
 network-object 192.168.3.0 255.255.255.0
!
nat (any,OUTSIDE) source static ALLSITES ALLSITES destination static ALLSITES ALLSITES
!

So pretty basic, we're just using a single object-group with our subnets included. Then in the actual NAT configuration we're saying the internal nameif is "any". This is because as traffic transits the hub from spoke-2-spoke, we want this policy to pick that up along with traffic from the Hub's inside to Spokes. Alternatively, you could have separate NAT statements. One for (INSIDE,OUTSIDE) and another for (OUTSIDE,OUTSIDE). The later of which being for spoke-2-spoke communication. Alright! Moving along, the config on the spokes looks a little something like this.

crypto ikev2 policy 10
 encryption aes-256
 integrity sha512
 group 2
 prf sha      
 lifetime seconds 28800
!
crypto ikev2 enable OUTSIDE
!
crypto ipsec ikev2 ipsec-proposal AES256
 protocol esp encryption aes-256
 protocol esp integrity sha-512
!
crypto ipsec security-association lifetime seconds 3600
!
object-group network LAN

 network-object 192.168.2.0 255.255.255.0
!
access-list L2LVPN extended permit ip object-group S2 192.168.0.0 255.255.0.0 
!
crypto map VPNMAP 1 match address L2LVPN
crypto map VPNMAP 1 set pfs 
crypto map VPNMAP 1 set peer 200.1.1.1 
crypto map VPNMAP 1 set ikev2 ipsec-proposal AES256

crypto map VPNMAP interface OUTSIDE
!
tunnel-group 200.1.1.1 type ipsec-l2l
tunnel-group 200.1.1.1 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco123

 ikev2 local-authentication pre-shared-key cisco123
!
nat (INSIDE,OUTSIDE) source static ALLSITES ALLSITES destination static ALLSITES ALLSITES
!


That's right, stock standard L2L VPN tunnel back to the hub. The above config is applied to ASAv2, however the only change in the configuration on ASAv3 is in "object-group network LAN", instead of 192.168.2.0, ASAv3 has 192.168.3.0. For our interesting traffic we're saying anything from our local subnet going to 192.168.0.0/16. This is pretty important, in order to have consistent and mostly reliable communication between spokes, we need the SA formed with the hub to also cover traffic to other spokes. I demonstrated why in my video below. The quick and dirty answer is, the Hub doesn't build tunnels outbound. Just by design, it's responder only within the DefaultL2LGroup tunnel. So while ASAv2 will build it's SA for S2>>S3 to the Hub, the Hub can't actually build the second half of that connection. Leaving you seeing a single SA for 192.168.2.0>>192.168.3.0 with the peer being ASAv2. The hub can receive that traffic, but will be unable to build the new SA out to S3 to actually forward it along. Again though, this is a non-issue if your Spokes are building tunnels where the destination covers all remote spoke subnets.


Well I could ramble on a bit longer, but that's the jist of it boys and girls. Linking the video below.


Sunday, July 31, 2016

How to Not Suck at Web Filtering: Cisco's Web Security Appliance Part (1)

So I'll start off by saying, configuring the WSA isn't too terribly hard. What seems to be tricky, is getting all the components working together in a way that provides a seamless experience for users, while providing accurate reporting and filtering. In this two parter, I'm going to attempt to get us from a based environment (Active Directory Domain, (1) DC, (1) Client PC, and an ASA Firewall) all the way to having the following requirements met: 

  • HTTP Filtering
  • HTTPS Filtering/Decrypting
  • Transparent Proxy 
  • AD Integration
  • Single Sign-on

Again, none of this is too difficult, there's just a lot of moving pieces. Sadly, many of those pieces are on the Systems side. So buckle up! In this first part, we're going to kick out all the server side stuff that makes web filtering as transparent and effective as possible. I know, I know "But JJoooooonnnnnnnn, this is a networking blog!! I don't like doing systems work!!"




I don't like it anymore than you. That said, it's important to know all these things so you can accurately make demands of your Server team! Also, if you want a working lab or POC, you'll have to do this stuff anyway. That said, I'm not a fan of text only guides for Windows. They just don't translate well, AND I loathe taking a million screen shots. So, I'll outline the general tasks below and then link to my YouTube video for this 1st part.


Prereqs:
  1. Windows Server 2008 (or newer) Domain Controller
  2. Windows 7 (or newer) client, joined to the domain
  3. Cisco ASA or IOS Router with WCCP support
  4. Cisco Web Security Appliance (using WSAv w/45 day demo license for this post)

Ingredients:
  • Active Directory Certificate Services (Enterprise Root)
    • Web Enrollment supported
  • Root CA certificate for WSA (or any cert with Subject Type=CA)
  • Server Certificate for WSA
  • URL to WSA in Window's "Trusted Sites"
    • Trusted Sites set to "Automatic Logon with Current Username and Password"
    • Can be done with GP, login script, or manually.
  • WSA joined to AD domain
  • Identification Policies for AD Users
    • And whatever access policies based on users/groups.
  • WCCP configured on router/firewall to redirect http/https traffic to WSA.

Video: