Today’s challenge was to get to grips with Cisco’s ZBFW, there are a few examples out there if you google but this cisco pdf was the best resource I found.
I’m going to share with you my GNS3 config, my first gotcha was getting the “right” IOS version, the latest advanced sec 12.4 image for the 3725 doesn’t cut it, you need to get a copy of c3725-advsecurityk9-mz.124-15.T7.bin.
My plan was simple, I wanted to re-create this following pseudo ASA style configuration:
access-list inside permit icmp any any access-list inside permit tcp any any eq telnet access-list outside permit tcp any host 192.168.10.100 eq telnet access-group inside in interface inside access-group outside in interface outside
What’s funny is that is 5 lines of code for ZBFW it’s more than 20! Yes the IOS FW isn’t a statefull firewall like the ASA but still more than 4 times the work… anyway, moving on…
The ZBFW is broken into four parts:
- Assign Zones to Interfaces
- Create a class-map to define interesting traffic
- Create a policy-map to give your class an action
- Create a zone pair to give you class a direction
As you can see in the picture, I have three routers Inside, Outside & Gateway; we will generate traffic from Inside -> Outside (and vice versa) and Gateway will be our firewall. In this blog post I’ll discuss the inside -> outside policy, read though the attached config to work out how outside->inside works
Creating zones and applying them to interfaces is the easy bit…
! zone security inside description LAN zone security outside description Internet ! interface FastEthernet0/0 ip address 10.10.10.10 255.255.255.0 zone-member security outside ! interface FastEthernet0/1 ip address 192.168.1.1 255.255.255.0 zone-member security inside
ZBFW supports traffic matching by protocol, ACL or both. To start with I need to create a class map equivalent of:
access-list inside permit icmp any any
So that looks like:
class-map type inspect match-any myinspectclass match protocol icmp
Our action to this applied via the policy map will be “inspect” … not “permit” like the access list, what we want to happen is the echo-request (echo) packet passing from the inside interface to the outside to be inspected so that the echo-reply packet is let back in…
policy-map type inspect myinspectpolicy class type inspect myinspectclass inspect
To apply this inside -> outside we create a zone-pair…
zone-pair security in-out source inside destination outside service-policy type inspect myinspectpolicy
Part 1 done. breath, take a break.
We can now ping from inside to outside, but outside to inside fails. Part two is to create a separate “flow” to allow telnet out. Now we could update our existing class-map, but it’s much clearer to create a new one, first we need an access-list…
ip access-list extended telnet_any permit tcp any any eq telnet
This will restrict our TCP protocol inspection to permit only telnet, without this ACL the following class map would permit (inspect) any TCP.
class-map type inspect match-all inspecttelnetclass match access-group name telnet_any match protocol tcp
Now that we have defined our traffic we can using the existing policy that permits the ICMP traffic through to permit this TCP thru, so this is the new policy map that replaces the one above:
policy-map type inspect myinspectpolicy class type inspect myinspectclass inspect class type inspect inspecttelnetclass inspect
The policy map will work top down, permitting ICMP traffic thru flow 1 (rule 1) and telnet through flow 2…. we don’t need to touch the zone pair