CCNA Security 14

When you don't have access to true hardware firewalls like the PIX or ASA, we would have to rely on software implementations like the IOS Firewall (previously known as CBAC) or ZPF (Zone-Based Policy Firewall).
We'll first look at doing IOS Firewall in this topology:


Here are the interfaces for the perimeter router:
S0/0 - OUTSIDE - 4.4.4.1/24
F0/0 - DMZ - 1.1.1.1/24
F0/1 - INSIDE - 2.2.2.1/24

The hosts are:
You - 4.4.4.150/24
WebServer - 1.1.1.2/24
Office - 2.2.2.2/24

Now, assuming that all connectivity is set up, we'll now set up CBAC. Before we begin, we'll write out the policies we want:
-HTTP/S traffic from OUTSIDE to DMZ
-Telnet and HTTP/S traffic from INSIDE to DMZ
-Any traffic from INSIDE to OUTSIDE

Here's a general rule: The access-lists are typically only to permit traffic originating FROM the interface's subnet. Traffic meant to be initiated from other subnets should be denied, then statefully inspected from the originating interface.

Let's start creating the access-list for OUTSIDE. We want to apply a list inbound that only allows HTTP/S traffic to flow from OUTSIDE to DMZ. To do this, we'll make the following list:
ip access-l ext INOUTSIDE
permit tcp any 1.1.1.0 0.0.0.255 eq 80
permit tcp any 1.1.1.0 0.0.0.255 eq 443

Next, we'll cut off all communications from DMZ since it does not initiate any traffic. This effectively introduces a hindrance to hackers who leverage on DMZs to hack internal computers. If you use a database server somewhere, you would need to permit it here, though, then statefully inspect it through some commands we'll go through later. But this is what we have right now:
ip access-l ext INDMZ
deny ip any any

Finally we'll allow INSIDE to only Telnet and HTTP/S to DMZ, but allow any other traffic:
ip access-l ext ININSIDE
permit tcp 1.1.1.0 0.0.0.255 2.2.2.0 0.0.0.255 eq 80
permit tcp 1.1.1.0 0.0.0.255 2.2.2.0 0.0.0.255 eq 443
permit tcp 1.1.1.0 0.0.0.255 2.2.2.0 0.0.0.255 eq 23
deny ip any 2.2.2.0 0.0.0.255
permit ip any any

We'll now apply the lists to the interfaces:
in s0/0
ip access-g INOUTSIDE in
in f0/0
ip access-g INDMZ in
in f0/1
ip access-g ININSIDE in

Right now at this point, INSIDE would still not be able to Telnet/HTTP/S to DMZ because the traffic is not allowed back. INSIDE would also not be able to access anything OUTSIDE. This is when CBAC comes in handy. What CBAC does is that it statefully inspects traffic based on the protocol (TCP, UDP, ICMP, and many other groups) and dynamically opens a return path back to the system. This is to make sure that traffic is INITIATED FROM INSIDE. Hackers would not be able to bypass the firewall through simple protocol tunneling without a host inside first communicating outwards. What we can do here is to first create a inspect list for INSIDE like this:
ip inspect name INSPECTINSIDE tcp
ip inspect name INSPECTINSIDE udp
ip inspect name INSPECTINSIDE icmp

Then we'll apply this list to the interface like this:
in f0/1
ip inspect INSPECTINSIDE in

Similarly, we'll inspect traffic from OUTSIDE:
ip inspect INSPECTOUTSIDE tcp
in s0/0
ip inspect INSPECTOUTSIDE in

Now your DMZ is truly a DMZ. No traffic can flow out of a DMZ unless initiated from either an INSIDE host (through Telnet/HTTP/S) or an OUTSIDE host (through HTTP/S). However, note the amount of work required just to get this scenario working. This is extremely troublesome if you have many interfaces to deal with. If you wish to implement NAT, you would have to change the addresses to match the INSIDE/OUTSIDE GLOBAL address.

Next we'll look at Zone-Based Policy Firewall which simplifies configuration through C3PL.