CCNA Security Certification Tutorial:
The Cisco IOS Firewall Set (Part 2)
(And An Illustrated CCNA Access List Review, Too!)
Chris Bryant, CCIE #12933
In the first part of this CCNA Security and ISCW exam tutorial, we spent quite a bit of time going over the differences between stateful and stateless filtering.
We ended that section with an introduction to the actual components of the Cisco IOS Firewall Set, and we'll start this section with details of those components.
Before we get started, I want to remind you that not every IOS version will allow the configuration of a Cisco router to act as a firewall. When purchasing new routers, be sure to purchase this particular feature set if you plan to use the router as a firewall.
There are three major components to the IOS Firewall feature set - the IOS Firewall itself, the Intrusion Prevention System (IPS), and the Authentication Proxy. We'll look at IPS in a future CCNA Security tutorial and concern ourselves strictly with the IOS Firewall and AP here.
The IOS Firewall is a stateful firewall, so we know it keeps a session table. Other features include:
The ability to filter traffic on a per-application basis for both TCP and UDP, plus the ability to perform generic inspection for all TCP and/or all UDP traffic (more about generic inspection later in this section).
Defense against external attacks such as TCP SYN attacks and IP Spoofing while allowing certain packets to enter the network if they're part of an already-existing connection.
The ability to go beyond the "permit/deny" choice with ip inspection rules , which permit the router to monitor the actual content of the packets.
The Authentication Proxy allows us to create security profiles that will be applied on a per-user basis, rather than a per-subnet or per-address basis. These profiles can be kept on either of the following:
-
RADIUS server
-
TACACS+ server
Upon successful authentication, that particular user's security policy is downloaded from the RADIUS or TACACS+ server and applied by the IOS Firewall router.
Configuration of the AP is beyond the scope of the both the CCNA Security and ISCW exams. As always, if you're planning to introduce AP to your network, be sure to visit Cisco's website for prerequisites and sample configurations.
AP is compatible with VPN client software, IPSec, and NAT, but it does take a little extra configuration!
We'll continue the tutorial after this brief and important message!
I'm Paying It Forward Bigger Than Ever.
My Famous CCNA Study Package Is Now $25.
 
Planning For Success With The Cisco IOS Firewall
We need to do more than a little planning before we implement the IOS Firewall. The obvious first decision is deciding what traffic we want to inspect, and for that we just need to answer two simple questions:
Which interface(s) are handling traffic that should be inspected?
In which directions(s) is the traffic heading that needs to be inspected?
Once those questions are answered, we'll use a combination of extended ACLs and inspection rules to put this inspection into effect.
It might have been a while you studied extended ACLs, so here's a quick review from my CCNA Study Guide. I've also included a review of using host and any in ACLs, since both of those options are common in extended ACLs.
Using “Host” and “Any” for Wildcard Masks
It is acceptable to configure a wildcard mask of all ones or all zeroes -- and it can save you a lot of typing, which some of you will truly appreciate!
A wildcard mask of 0.0.0.0 means the address specified in the ACL line must be matched exactly; a wildcard mask of 255.255.255.255 means that all addresses will match the line. We have the option of using the word host to represent a wildcard mask of 0.0.0.0. Consider a configuration where only packets from IP source 10.1.1.1 should be allowed and all other packets denied. The following ACLs both do that.
R3#conf t
R3(config)# access-list 6 permit 10.1.1.1 0.0.0.0
R3(config)#conf t
R3(config)# access-list 7 permit host 10.1.1.1
The keyword any can be used to represent a wildcard mask of 255.255.255.255. Both of the following lines permit all traffic.
R3(config)#access-list 15 permit any
R3(config)#access-list 15 permit 0.0.0.0 255.255.255.255
There's no "right" or "wrong" decision to make when you're configuring ACLs in the real world. For your exam, though, I'd be very familiar with the proper use of host and any.
Extended Access Control Lists
Extended ACLs allow both the IP source and destination address to be matched. Actually, they require it. Even if you don't want to use either of those two criteria for matching, you still have to put any for the one you don't want to use.
In this example, we'll write an ACL that blocks traffic sourced from 172.50.50.0 /24 that is intended for 172.50.100.0 /24. 
The source port, destination port, and protocol type can also be matched. These are optional - you don't have to specify a value for any of those options if you're not using them to filter traffic.
Extended ACLs give us quite a few options where standard ACLs really don't give us any. Let's use IOS Help to take a look at these options in the access-list command.
R1(config)#access-list 150 ?
deny Specify packets to reject
dynamic Specify a DYNAMIC list of PERMITs or DENYs
permit Specify packets to forward
remark Access list entry comment
R1(config)#access-list 150 deny ?
<0-255> An IP protocol number
ahp Authentication Header Protocol
eigrp Cisco's EIGRP routing protocol
esp Encapsulation Security Payload
gre Cisco's GRE tunneling
icmp Internet Control Message Protocol
igmp Internet Gateway Message Protocol
igrp Cisco's IGRP routing protocol
ip Any Internet Protocol
ipinip IP in IP tunneling
nos KA9Q NOS compatible IP over IP tunneling
ospf OSPF routing protocol
pcp Payload Compression Protocol
pim Protocol Independent Multicast
tcp Transmission Control Protocol
udp User Datagram Protocol
We can match by protocol name or by number. We'll keep it simple here and select ip. If we planned to use port numbers for matching, we'd need to specify tcp or udp.
R1(config)#access-list 150 deny ip ?
A.B.C.D Source address
any Any source host
host A single source host
We're going to specify the 172.50.50.0 /24 network as the source. If we wanted any source IP address to match on this line, we could use the any option. If we wanted to specify one and only one source IP address, we could use the host option followed by that one IP address.
R1(config)#access-list 150 deny ip 172.50.50.0 ?
A.B.C.D Source wildcard bits
R1(config)#access-list 150 deny ip 172.50.50.0 0.0.0.255
Just a reminder -- ACLs use wildcard bits!
R1(config)#access-list 150 deny ip 172.50.50.0 0.0.0.255 ?
A.B.C.D Destination address
any Any destination host
host A single destination host
Now we'll define the destination address. We have the same any and host options here, but we'll define the 172.50.100.0 /24 network.
R1(config )#$ 150 deny ip 172.50.50.0 0.0.0.255 172.50.100.0 0.0.0.255
Notice the dollar sign next to the pound sign prompt? That's what you see when your command runs too long to be shown in its entirety on the screen!
The next and final line of the ACL will negate the implicit deny. Since this is an extended ACL, we have to enter any twice - once for the source and the second time for the destination. This line allows all traffic.
R1(config)#access-list 150 permit ip any any
To verify your ACLs and the order of the lines, run show access-list .
R1#show access-list
Extended IP access list 150
deny ip 172.50.50.0 0.0.0.255 172.50.100.0 0.0.0.255
permit ip any any
Another rule of extended ACLs - both the source and destination must match the line for the action to be carried out.
In this case, a packet sourced from 172.50.50.0 /24 is only denied IF the destination is on the 172.50.100.0 /24 subnet. If either the source or destination IP address does not match the line, there is no match. Both standard and extended ACLs are applied to the interface with the ip access-group command, and the direction of the packets to be filtered with the ACL must be indicated at the end of that command.
R1(config)#int e0
R1(config-if)#ip access-group 150
% Incomplete command.
R1(config-if)#ip access-group 150 in Now that we've refreshed our ACL skills a bit, we'll dive in to CBAC and the ip inspect command.
What's CBAC, you ask? Let's go to the next installment of this CCNA Security tutorial, and all will be revealed!
No Gimmicks -- Just Results.
Get CCNA Security Certified Today For $20.
I'm Paying It Forward Bigger Than Ever.
My Famous CCNA Study Package Is Now $25.
Chris Bryant
CCIE #12999
"The Computer Certification Bulldog"
chris@thebryantadvantage.com
 
|
