Hitting 100% CPU after restore on Firepower Management Center

I recently purchased a new microserver to reduce my power footprint at home. And I had to move the FMC (Firepower Management Center) from the OpenStack deployment that I previously ran at home. However, I ran into several bugs in OpenStack that were fixed in later versions, but I couldn’t upgrade because of another bug. Essentially I hit a catch-22 and had to deploy a new FMC on that new microserver and use a restore to move the data and policies. In that process I did hit a bug for which I’d like to share some info on. (more…)

FTD access policy behaviour

FTD access policy behaviour

In a previous blog, I’ve written about the differences between Firepower Threat Defense and ASA software. And although the basic OS appears to be ASA with Snort set in between ASA ingress and egress, some basic concepts of the ASA (or actually the PIX) have disappeared in FTD. And it will have an impact once you migrate from ASA (with or without firepower) to FTD devices..
The Cisco ASA firewall has implemented the concept of security levels on interfaces. Each interface must have an interface name and interface level (IP-address is only necessary if you use routed or IRB interfaces). The concept for this is quite easy, let’s take the basic ASA edge deployment into mind.

With interface security levels the ASA keeps two principles into mind when a packet comes into the firewall for a new connection:

  • Traffic is always allowed from a higher security level to a lower security level, unless an access-list prohibts this
  • Traffic is never allowed from a lower security level to a higher security level, unless there is an access-list explicitly permitting the traffic and a static translation is created

So, in this example, the client with internal IP is allowed to go outbound to the webserver on the Internet, but unless you configure a specific access-list, traffic is not allowed from the Internet to the inside mail server.
If you then take into account that IOS/PIX/ASA access-lists always have an implicit deny ip any any statement in the access-list, so even if you configure an access-list (except of course permit ip any any), traffic will be blocked by that implicit match. So it’s relatively easy to tie down the traffic flows, right?

In FTD things are working quite differently.. In FTD there is not really the concept of an access list with an implicitly deny any any. Within FTD, an access policy is used to define the policies that need to be applied to one or more FTD devices. One or more rules, which are run sequentially, combined define the access policy. Each rule in itself contains several elements that can be combined to define the policy rule. Each rule consists following elements:

Element Description
source zone(s) Within FTD it is possible to logically combine different interfaces into a single zone. One or more zones can be used as selection criteria
destination zone(s) Also one or more destination zones can be used as selection criteria, for example the “outside” zone
source network(s) This is the classic selection criteria for a layer3 firewall, based on one or more source IP networks.
destination network(s) This is the classic selection criteria for a layer3 firewall, based on one or more destination IP networks.
VLAN’s It is possible to match traffic based on the vlan tag
Users This is part of the next generation firewall that is inside FTD, per user (or group) policy rules can be matched
Applications Also part of the next generation firewall, in which a lot of applications are already defined. It is also possible to define custom applications using openAppID as well
Source port(s) Classic criteria for the source ports. Within FTD there is a default group called “high ports” that you can use for client connections
Destination port(s) Classic match criteria for the destination ports. It is possible to use one or more ports to match on, or use a port group.It is possible to mix and match UDP, ICMP, ICMP6, TCP, etc in a single match statement
ISE/SGT attributes This is used if you have a pxGrid ISE integration with FirePower and wish to match on scalabale group tags
URL Categories This is also part of the next generation firewall feature set, in which you can use URL categories (like advertisment, Phishing, etc) to match traffic on. It is a recommended from Cisco not to combine these URL categories together with the application matching statement.
File Policy This option (within the rule details) specifies which file detection policy is to be used in AMP for networks.
IPS Policy (with variable set) It is possible to define different Intrusion Policies within FMC. Within a specific rule it is possible to set a custom IPS signature policy.
Action The resulting action that FTD will take when the packet is matching this rule.


FTD Policy actions

There are different actions that FTD can take once a packet has matched the access rule, being

Action Description
Allow This traffic
Trust Trust this traffic and do not send it to Snort for inspection.
Monitor Monitor this traffic, apply inspection, but do not discard packets (drop)
Block Block this packet. Be aware, if used on a TCP connection,  the client will do retries
Block with reset Block this packet and send TCP resets to client and server to reset this packet
Interactive Block This is similar as the block action, but FTD will respond back with a web page that provides feedback to the block
Interactive Block with Reset This is similar as the block with reset action, but FTD will respond back with a web page that provides feedback to the block

For grouping purposes it is possible to group access rules together. Using this approach, it is a very flexible and powerfull mechanism to define the policy. It is a single policy for both ingress and egress traffic, so double access list policies are not required anymore, which is a great benefit. Also, rules are run through sequentially, so after a packet matches the rule, the specific actions are executed.

But what happens if no rule inside the policy is matched? Well, then the default Action comes into play. As soon as you create a new access policy, FMC asks what the default action will be of the new policy

Block all traffic Just block all traffic, similar to the implicit deny any any
Intrusion prevention Allow traffic, but do run it through Snort for inspection
Network discovery Allow traffic for discovery of users, applications and hosts on the network

Within a Firepower on ASA rule, I usually choose the “Intrusion Prevention” or “network discovery” rule, as there is still a firewall outside the FirePower module that has access-lists as well.

But in FTD that is not true!! If you choose “network discovery” or “intrusion prevention“, you will basically allow alltraffic to traverse through the firewall as the interface security levels are in essence equal. So it is then basically a router with some security power! I ran into this issue when I converted a Firepower on ASA device to FTD recently. This is something you have to be aware off.

If you want to change this behaviour in an access policy at a later stage, just go into the access policy and click the pull down menu at the bottom of the policy and select “Access control: Block All Traffic”

So in summary, if you start working with FTD and come from an ASA background, make sure your that you define the access rules both ways and have explicit block rules in your access policy. Either via the default action or per traffic-flow in a category.

Firepower on ASA, Firepower Threat Defense, what is what?

Firepower on ASA, Firepower Threat Defense, what is what?

Yesterday (5 sept) Cisco finally released Firepower Threat Defense 6.2.2 Now is a new update not always a big thing but this specific release had me waiting for quite some time. Key to this release is the support of remote access VPN (e.g. anyconnect) in the FTD image. So FTD was already available on ASA5500-X platform, but if you used anyconnect on your ASA, you just had to wait for this release. But what now is the difference between Firepower on ASA and FTD.. (more…)

DMVPN DualHub EIGRP Traffic Engineering

DMVPN DualHub EIGRP Traffic Engineering

With the advance of vDSL, Fiber, cable Internet and the appropriate SLA’s bussiness Internet connections have become increasingly reliable. By choosing the local ISP’s carefully it is much more interesting for a company to replace the MPLS connections for an Overlay network based on redundant Internet connections. As a result businesses quite often obtain a higher speed connection for much lower rates. One of the business cases I made in 2006/2007 had a 70% decrease in annual costs compared to their European WAN line based on an MPLS service provider including High Availability. (more…)