Zone-Based Policy Firewall

Normally when you think about a router you think about just routing packets and not firewall policies. After all routers route and firewalls block or allow traffic based on policies.  However, routers can also work as stateful firewalls; to accomplish this you can leverage a feature called Zone-Based Policy Firewall (ZBPF) which is available on current versions of IOS and IOS-XE (Check release notes for exact features and caveats). With ZBPF your router can inspect traffic leaving one zone and going to another and allowing the return traffic back in. You can also choose to deny traffic or simply permit it without inspection. Keep in mind though that permitting the traffic instead of inspecting it does not allow the router to add that traffic to its state table and therefore return traffic will need to be explicitly permitted. So how do we configure ZBPF?

First, we have to define the zones that we want to create. For my example I’ll be using two zones, one called INSIDE and the other called OUTSIDE.

Once the zones are created we need to define a zone-pair. Zone-pairs dictate what the source zone and destination zones will be. In our example, there will be two zone-pairs one for traffic coming from INSIDE and going to OUTSIDE, and one for traffic coming from OUTSIDE and going INSIDE.  We’ll also revisit these later when it comes time to apply the service policy.

Now we need to define what type of traffic we want to either permit, drop, or inspect. For this task we’ll use ACLs to define the traffic, class-maps to match off of the ACL and to match on a specific protocol, and lastly, a policy-map to apply an action to take.  For this example, I’ll match telnet traffic from the IP address to as well as all HTTP traffic. Lastly, I’ll create a policy that denies all traffic inbound from the OUTSIDE zone. A couple of things to note here is the keyword match-any on the class-map. This allows the router to match either traffic that matches the ACL, or HTTP traffic. If we used the keyword match-all, then both would have to match for the action in the policy map to take effect.

Once we have the ACLs, class-maps, and policy-maps created we need to apply these to the zone-pairs that we created earlier.

The last thing to do is to assign the interfaces to different zones. I leave this step until last as once an interface has a zone applied it will not pass any traffic that is not explicitly permitted by service policy.

One thing I need to mention here is that there is a default zone created called the self-zone. This zone is used to control traffic to the router itself, such as SSH traffic, EIGRP traffic etc. The policies we applied above will only affect traffic that is transiting through the router. If you don’t do anything with the self-zone then its default behavior is to allow all traffic.

Lastly, I’ll list out the rules for ZBPF that need to be taken into account when setting this up:

  1. A zone must be configured before assigning it to an interface.
  2. An interface can only belong to one security zone.
  3. Traffic to and from an interface assigned to a zone is implicitly blocked unless the interface the destination interface is in the same zone as the source interface or traffic to an interface on the router.
  4. Traffic between interfaces belonging to the same zone is implicitly allowed.
  5. For traffic to be allowed from one interface to another, the traffic must match an “inspect” or a “permit” action in a policy.
  6. Traffic to the self-zone is implicitly allowed until it has been explicitly denied.
  7. Traffic cannot flow between an interface that is a member of a zone and an interface that is not a member of a zone.
  8. Interfaces that do not belong to a zone continue to act as classical router ports.
  9. If an interface that is not a member of a zone needs to send traffic to an interface in a zone, a dummy policy should be created that allows all traffic from the one interface to the other.
  10. For traffic to be able to flow between all of the interfaces on a router, each interface should be a part of a zone with the appropriate policies applied.

By using ZBPF features on a router a small business, or branch office can gain the advantages of a stateful firewall without incurring the costs of one.


First Blog Post and What to Expect Going Forward

I’ve finally gotten around to making my first blog post after having this site for almost two years now, as I’m currently studying for the CCIE Security expect most of my posts to be about the technologies found in this exam, and different lab topologies that I’m using, assuming they are my own content and not from someone else’s workbook. However, as my interests include a lot of different technologies such as routing and switching, data center designs, and network automation. So there will likely be posts about using Python to automate networking changes, or even my latest BGP reconfiguration project.
One question I do want to address as I’m sure it’ll be asked is why go for a CCIE today when SDN or automation are everyone’s favorite buzzwords. First I’m a firm believer in understanding how and why things work fundamentally. This way of thinking was ingrained in me with my first mentor and has stuck with me throughout my career. If you’re going to deploy an SDN solution be it orchestration or automation depending on what your definition of SDN is; you still need to understand how and why things work under the hood. Yes, a GUI will obfuscate a lot of the technical stuff, but when it breaks you will still need to understand the underlying technologies to efficiently troubleshoot the problem. Simply put a CCIE for me is a starting point to a better understanding of the how and why things work. From there I can build on my API and scripting skills to make my life easier and do less work at night.
How am I studying for the CCIE Security? To start I’m working my way through reading any Cisco Press book that relates to a topic covered on the exam, including the evolving technology section. Since I love reading I can read through a book in a few weeks time while still understanding what I’ve read. I’ve also set up the community edition of EVE-NG as a lab and built out small labs for ESA, VPN, IOS Firewall, and Firepower. As I read through the books I do labs to practice with each technology so that I’m applying it as I go through. Now I’m not full-blown lab mode yet as I’m still working towards the written, but once that is completed I’ll move on to workbooks and larger labs that combine technologies. I’ll also be taking the Micronics Security Zero-to-Hero class starting this October. Once I’ve completed this I’m planning on taking the written portion of the exam. Then it’s on to full-time labbing, reading RFC’s and other documentation for a deeper understanding. Also probably re-reading specific chapters or sections from my growing collection of books.
Overall my goal is to have my CCIE  Security written completed in February or March of 2019, with the lab completed by June 2020.