cisco's zone based firewall, built into ios

the hook

a lot of people think firewalling means buying another box. if you're running cisco ios on your router, you already own a stateful firewall, you just haven't turned it on. it's called the zone based firewall, zbfw for short, and it's been sitting in ios for years doing nothing while people spend budget on hardware they don't need.

this post walks through how zbfw actually works so you can look at your own router config and understand what's protecting you, or figure out why nothing is.

zones are the whole idea

traditional ios access lists work interface by interface, direction by direction. it gets messy fast. zbfw flips that. instead of thinking "inbound on gi0/0" you think in terms of zones, groups of interfaces that share the same trust level.

you might have a zone called INSIDE for your lan interfaces and a zone called OUTSIDE for your interface facing the internet. traffic moving between zones is what gets inspected. traffic inside the same zone, by default, just flows. this matters for defenders because if you accidentally put two interfaces you didn't mean to trust into the same zone, you've just turned off inspection between them without realizing it.

class maps decide what traffic even matters

a class map is just a matcher. it says "this is what i mean by trusted traffic," usually matching on protocol, access list, or another class map. it doesn't do anything by itself, it just labels traffic so the policy map knows what to act on.

the defensive point here is simple, your class maps are only as good as what you match. a class map matching "any" is basically not doing its job. if you're auditing someone else's config, or your own from six months ago, check what the class maps are actually catching. sloppy matching is the number one way people think they have a firewall rule when they really don't.

policy maps and the inspect action, this is the stateful part

the policy map ties a class map to an action. the action that matters most is inspect. this is what makes zbfw a real stateful firewall instead of a glorified access list.

when you apply inspect to traffic going from INSIDE to OUTSIDE, ios tracks that connection in a state table. when the reply traffic comes back from OUTSIDE, ios checks the state table, sees it matches an established session, and lets it through automatically. you never wrote a rule allowing OUTSIDE to INSIDE traffic, and you don't need to. the router remembers it started that conversation.

flip it around: if someone on the outside tries to initiate a connection inward with no matching session in the state table, it gets dropped. no rule needed for that either, it's dropped by default because there's no policy allowing OUTSIDE to INSIDE traffic to be initiated at all. this is the entire point of a zone based firewall, unsolicited inbound traffic dies, legitimate return traffic lives, and you didn't have to write a rule for every possible reply port.

zone pairs, this is where the policy actually gets applied

a zone pair is the piece that says "apply this policy map to traffic going from this source zone to this destination zone." you'd create a zone pair from INSIDE to OUTSIDE and attach your policy map with the inspect action to it. you generally do not create the reverse zone pair, OUTSIDE to INSIDE, because you don't want to explicitly allow strangers to open connections toward your network. the state table already handles the return traffic for sessions your side started.

if you ever see a config with an OUTSIDE to INSIDE zone pair applying a wide open policy, that's worth stopping and asking why. that's usually someone trying to solve a "this isn't working" problem by punching a hole instead of fixing the actual rule.

the takeaway

zbfw isn't complicated once you see it as four pieces: zones group your interfaces by trust, class maps define what traffic you're talking about, policy maps decide what happens to it, and zone pairs apply that decision in a specific direction. no extra hardware, no separate firewall to patch and maintain, just ios doing what it was built to do.

if you've got a cisco router sitting at your network edge right now, go pull up the running config and check whether zbfw is even configured. if it's not, that unsolicited inbound traffic you assumed was being dropped might just be sailing straight through. know what your router is actually protecting before you assume it's protecting anything.