
- •Using Your Sybex Electronic Book
- •Acknowledgments
- •Introduction
- •Assessment Test
- •Answers to Assessment Test
- •Types of Network Security Threats
- •Types of Security Weaknesses
- •Technology Weaknesses
- •Configuration Weaknesses
- •Policy Weaknesses
- •Types of Network Attacks
- •Eavesdropping
- •Denial-of-Service Attacks
- •Unauthorized Access
- •WareZ
- •Masquerade Attack (IP Spoofing)
- •Session Hijacking or Replaying
- •Rerouting
- •Repudiation
- •Smurfing
- •Password Attacks
- •Man-in-the-Middle Attacks
- •Application-Layer Attacks
- •Trojan Horse Programs, Viruses, and Worms
- •HTML Attacks
- •The Corporate Security Policy
- •Summary
- •Exam Essentials
- •Key Terms
- •Written Lab
- •Review Questions
- •Answers to Written Lab
- •Answers to Review Questions
- •Authentication Methods
- •Windows Authentication
- •Security Server Authentication
- •PAP and CHAP Authentication
- •PPP Callback
- •Configuring the NAS for AAA
- •Securing Access to the Exec Mode
- •Enable AAA Locally on the NAS
- •Authentication Configuration on the NAS
- •Authorization Configuration on the NAS
- •Accounting Configuration on the NAS
- •Verifying the NAS Configuration
- •Troubleshooting AAA on the Cisco NAS
- •Summary
- •Exam Essentials
- •Key Terms
- •Commands Used in This Chapter
- •Written Lab
- •Review Questions
- •Hands-On Labs
- •Lab 2.1: Setting the Line Passwords
- •Lab 2.2: Setting the Enable Passwords
- •Lab 2.3: Encrypting your Passwords
- •Lab 2.4: Creating Usernames and Logging In
- •Lab 2.5: Configuring AAA Authentication on the NAS
- •Answers to Written Lab
- •Answers to Review Questions
- •Introduction to the CiscoSecure ACS
- •Using User Databases for Authentication
- •Populating the User Database Population
- •New ACS Features
- •Installing CiscoSecure ACS 3.0
- •Administering CiscoSecure ACS
- •TACACS+ Overview
- •Configuring TACACS+
- •Using RADIUS
- •CiscoSecure User Database NAS Configuration for RADIUS
- •Verifying TACACS+
- •Summary
- •Exam Essentials
- •Key Terms
- •Commands Used in This Chapter
- •Written Lab
- •Review Questions
- •Answers to Written Lab
- •Answers to Review Questions
- •Solving Eavesdropping and Session Replay Problems
- •Fighting Rerouting Attacks
- •Fighting Denial-of-Service Attacks
- •Turning Off and Configuring Network Services
- •Blocking SNMP Packets
- •Disabling Echo
- •Turning Off BOOTP and Auto-Config
- •Disabling the HTTP Interface
- •Disabling IP Source Routing
- •Disabling Proxy ARP
- •Disabling Redirect Messages
- •Disabling the Generation of ICMP Unreachable Messages
- •Disabling Multicast Route Caching
- •Disabling the Maintenance Operation Protocol (MOP)
- •Turning Off the X.25 PAD Service
- •Enabling the Nagle TCP Congestion Algorithm
- •Logging Every Event
- •Disabling Cisco Discovery Protocol
- •Disabling the Default Forwarded UDP Protocols
- •Summary
- •Exam Essentials
- •Key Terms
- •Commands Used in This Chapter
- •Written Lab
- •Review Questions
- •Hands-On Lab
- •Lab 4.1: Controlling TCP/IP Services
- •Answers to Written Lab
- •Answers to Review Questions
- •Understanding the Cisco IOS Firewall
- •Authentication Proxy and IDS
- •Context-Based Access Control
- •CBAC Compared to ACLs
- •CBAC-Supported Protocols
- •Introduction to CBAC Configuration
- •Using Audit Trails and Alerts
- •Configuring Global Timeouts and Thresholds
- •Configuring PAM
- •Defining Inspection Rules
- •Applying Inspection Rules and ACLs to Router Interfaces
- •Configuring IP ACLs at the Interface
- •Testing and Verifying CBAC
- •Summary
- •Exam Essentials
- •Key Terms
- •Commands Used in This Chapter
- •Written Lab
- •Review Questions
- •Hands-On Labs
- •Lab 5.1: Configure Logging and Audit Trails
- •Lab 5.2: Define and Apply Inspection Rules and ACLs
- •Lab 5.3: Test and Verify CBAC
- •Answers to Written Lab
- •Answers to Review Questions
- •Introduction to the Cisco IOS Firewall Authentication Proxy
- •Configuring the AAA Server
- •Configuring AAA
- •Configuring the Authentication Proxy
- •Testing and Verifying Your Configuration
- •show Commands
- •Clearing the Cache
- •Introduction to the Cisco IOS Firewall IDS
- •Initializing Cisco IOS Firewall IDS
- •Configuring, Disabling, and Excluding Signatures
- •Creating and Applying Audit Rules
- •Setting Default Actions
- •Creating an Audit Rule
- •Applying the Audit Rule
- •Verifying the Configuration
- •Stopping the IOS Firewall IDS
- •Summary
- •Exam Essentials
- •Key Terms
- •Commands Used in This Chapter
- •Written Lab
- •Review Questions
- •Hands-On Labs
- •Lab 6.1: Enabling the IOS Firewall Authentication Proxy
- •Lab 6.2: Enabling the IOS Firewall IDS
- •Answers to Written Lab
- •Answers to Review Questions
- •What is a Virtual Private Network?
- •Introduction to Cisco IOS IPSec
- •IPSec Transforms
- •IPSec Operation
- •The Components of IPSec
- •IPSec Encapsulation
- •Internet Key Exchange (IKE)
- •Summary
- •Exam Essentials
- •Key Terms
- •Written Lab
- •Review Questions
- •Answers to Written Lab
- •Answers to Review Questions
- •Configuring Cisco IOS IPSec for Pre-Shared Keys Site-to-Site
- •Preparing for IKE and IPSec
- •Configuring IKE
- •Configuring IPSec
- •Testing and Verifying IPSec
- •Configuring IPSec Manually
- •Configuring IPSec for RSA-Encrypted Nonces
- •Configuring Cisco IOS IPSec Certificate Authority Support Site-to-Site
- •Configuring CA Support Tasks
- •Preparing for IKE and IPSec
- •Configuring CA Support
- •Configuring IKE Using CA
- •Configuring IPSec for CA
- •Testing and Verifying IPSec for CA
- •Summary
- •Exam Essentials
- •Key Terms
- •Commands Used in This Chapter
- •Written Lab
- •Review Questions
- •Hands-On Labs
- •Lab 8.1: Configure IKE on Lab_A and Lab_B
- •Lab 8.2: Configure IPSec on Lab_A and Lab_B
- •Answers to Written Lab
- •Answers to Review Questions
- •Answers to Hands-On Labs
- •Answer to Lab 8.1
- •Answer to Lab 8.2
- •Introduction to Cisco Easy VPN
- •The Easy VPN Server
- •Introduction to the Cisco VPN 3.5 Client
- •Easy VPN Server Configuration Tasks
- •Pre-Configuring the Cisco VPN 3.5 Client
- •Summary
- •Exam Essentials
- •Key Terms
- •Written Lab
- •Review Questions
- •Hands-On Lab
- •Lab 9.1: Installing the Cisco VPN 3.5 Client Software on Windows
- •Answers to Written Lab
- •Answers to Review Questions
- •Network Separation
- •Three Ways through a PIX Firewall
- •PIX Firewall Configuration Basics
- •Configuring Interfaces
- •Saving Your Configuration
- •Configuring Access through the PIX Firewall
- •Configuring Outbound Access
- •Configuring Inbound Access
- •Configuring Multiple Interfaces and AAA on the PIX Firewall
- •Configuring Multiple Interfaces
- •Implementing AAA on the PIX Firewall
- •Configuring Advanced PIX Firewall Features
- •Failover
- •Outbound Access Control
- •Logging
- •SNMP Support
- •Java Applet Blocking
- •URL Filtering
- •Password Recovery
- •Glossary

Solving Eavesdropping and Session Replay Problems |
119 |
Solving Eavesdropping and Session
Replay Problems
Remember, eavesdropping is when a hacker is listening in and reading your data. Session replay happens when a sequence of packets or application commands are captured, manipulated, and replayed by bad guys with the intent of causing harm. You obviously need a solution for these ugly problems, but first let’s use the corporate network example in this book, illustrated in the following graphic, as an example of how eavesdropping and session replay can be a problem.
Lab_A |
HostA HostB
172.16.2.0/24
|
Perimeter |
WWW Server |
DNS Server |
|
10.1.1.0/24 |
Router |
172.16.1.2/24 |
172.16.1.3/24 |
|
Internet |
|
|
|
|
|
Lab_B |
|
|
|
|
|
|
172.16.1.0/24 |
|
|
F0/0 |
"Dirty DMZ" |
|
|
172.16.1.254/24 |
|
|||
|
|
|
||
Protected DMZ |
|
|
|
|
|
PIX |
|
Bastion Host |
|
|
|
|
F0/0 |
|
|
|
192.168.254.254/24 |
|
|
Bastion Host |
|
|
|
|
NAS |
|
|
|
|
|
F0/0 |
|
|
|
192.168.254.252/24 |
|
|
|
|
|
CiscoSecure ACS 3.0 |
Management Station |
||
|
192.168.254.253/24 |
192.168.254.251/24 |
HostA needs to communicate to the bastion host in the dirty DMZ. (Recall that a dirty DMZ is defined as the part of a network that’s using real Internet IP addresses.)
Copyright ©2003 SYBEX Inc., 1151 Marina Village Parkway, Alameda, CA 94501. |
www.sybex.com |

120 Chapter 4 Cisco Perimeter Router Problems and Solutions
Okay, you have a client machine that must cross an unknown network to reach the bastion host. As you learned in Chapter 1, it’s possible for someone in this unknown network who’s using a protocol analyzer to capture the conversation between the client and server by eavesdropping. If successful, your data can be compromised and the session can be replayed back to the server. Your problem is that you have unencrypted data crossing an unknown network— not good. Hmm…unencrypted data—any guesses as what the solution to this problem could be?
Yes—encryption. Of course you’ll use encryption to protect that data. In our corporate network example, you can configure the Lab_A router at the remote site to encrypt the data traveling between the client and the bastion host. The perimeter router at the corporate site would also be configured for this same operation. Those two routers will then encrypt all data passing between these two hosts. Any intermediate routers between them can still route the traffic (network headers are not encrypted). Traffic between the client and the bastion host doesn’t need to be encrypted unless you really want it to be. You can control the encryption based on network, subnet, port, or protocol.
The best solution for eavesdropping and session replay is IPSec. IPSec is an open standards framework that ensures private communications over an IP network, and it is used and recommended by Cisco as a tool for encryption. Most of the time, the best place to use IPSec is across a public IP network. This not only ensures confidentiality, it also ensures data integrity and authenticity. IPSec is configured between two routers, and it does its work at the Network layer.
Before IPSec was introduced, lots of people used the Secure Socket Layer (SSL) to provide application encryption for web browsers and other applications. The problem with SSL is that the configuration is on an application-by-application basis, so only applications configured to use SSL were encrypted. By using IPSec, all data at the Network layer is encrypted.
Cisco suggests that IPSec encryption, VPN, and digital certificates are all viable solutions to eavesdropping and session replay problems. Chapter 7, “Understanding Cisco IOS IPSec Support,” and Chapter 8, “Cisco IOS IPSec Pre-Shared Keys and Certificate Authority Support,” look more closely at IPSec.
Defending Against Unauthorized Access,
Data Manipulation, and Malicious
Destruction
Think back and picture the perimeter router in the corporate network firewall example illustrated earlier in this chapter. It connects the DMZ to the Internet, which as you recall, is a potential source of problems. Assuming that this connection is necessary for business purposes, how can you ensure that traffic to and from the Internet is good and legitimate and not the communications equivalent of Stephen King’s evil Christine?
Copyright ©2003 SYBEX Inc., 1151 Marina Village Parkway, Alameda, CA 94501. |
www.sybex.com |

Defending Against Unauthorized Access |
121 |
Honestly, you can’t always be sure, but you can certainly stop most of the nasty stuff using a simple tool—access control lists (ACLs). No doubt you’ve used these in the past, but there are a number of tasks ACLs can do for you at the perimeter to significantly beef up your security.
With your perimeter router in mind, here’s a list of various packets you probably don’t want to allow into your network from the Internet:
Private address as the source IP address
One of your internal IP addresses as the source IP address
BOOTP, TFTP, and traceroute packets
TCP connections to servers not in the DMZ
DHCP reserved range
Loopback addresses
All of these packets can be stopped with inbound ACLs on a perimeter router. Here’s an example of an access list on the perimeter router stopping the dirty DMZ IP addresses from being used as source addresses from an outside intruder:
Lab_B(config)#access-list 110 deny ip 172.16.1.0 0.0.0.255 any
Lab_B(config)#interface s0/0
Lab_B(config-if)#access-group 110 in
Do you remember from your ACL studies that you also need to have a permit statement included in your list to make it work? It’s the same here—this is just an example.
Here’s another example of using a simple ACL to implement network security. These commands prevent a SYN packet from coming into the inside network from the outside network:
Lab_B(config)#access-list 110 deny tcp any any established
Lab_B(config)#access-list 110 permit tcp any any
Lab_B(config)#interface s0/0
Lab_B(config-if)#access-group 110 in
Doing this allows a SYN packet out, but it won’t let anyone “SYN” in. No one from the outside network can create a session to a host on the inside network. A host on the inside network can both send out and receive an ACK so those packets are allowed to enter the DMZ.
These are two types of packets you don’t want leaving your network:
Source address not in your internal IP address space
Source address of any machine that is not allowed Internet access by policy
And again, you can prevent that from happening by using fairly simple ACLs.
These simple examples demonstrate just how efficient ACLs can be for preventing inappropriate access. If you make the functions we’ve discussed off-limits to bad guys, you’ve denied them access to some of the most common techniques that they use to exploit networks.
ACLs are a great weapon for guarding your network against unauthorized access, data manipulation, and malicious destruction.
Copyright ©2003 SYBEX Inc., 1151 Marina Village Parkway, Alameda, CA 94501. |
www.sybex.com |

122 Chapter 4 Cisco Perimeter Router Problems and Solutions
Solving Lack of Legal IP Addresses
Problems
Let’s say you have 500 machines to connect to the Internet, and you have 254 legal IP addresses. This could definitely be a problem, but if you use Network Address Translation (NAT), you can use a pool of IP addresses to meet the needs of a large number of clients. Even better, NAT gives you some additional security benefits beyond extending IP address space.
NAT hides your internal addressing scheme from the external network. The only device that the external network will be able to see is your NAT device; everything behind it is essentially invisible. So, if you configure NAT on your perimeter router, you get to hide all of your addressing!
There’s a subset of NAT called Port Address Translation (PAT) that extends NAT functionality by using TCP and UDP ports for address translation. Doing this allows a single Internet IP address to support up to 64,000 hosts, but Cisco recommends that you don’t support more than 4,000 per address. Even so, that’s still pretty impressive!
When your problem is the lack of legal IP addresses, your solution is to use NAT.
Fighting Rerouting Attacks
Let’s suppose a bad guy could modify your routing table. Would that make you nervous? It should! The best-case scenario is that the attacker simply breaks into your network. The worstcase scenario is, well, destruction, corruption, and malfunction—Hell as your uninvited guest. Breaking your routing can cause all kinds of security problems, and there are a number of ways for the bad guys to do it. The most obvious way is to somehow gain access to a router, but that’s not always necessary.
Let’s take a look at the corporate network illustrated earlier in this chapter and use routers Lab_A and Lab_B, which are connected on the same network, for an example. And let’s also assume that they’re communicating using some routing protocol—say EIGRP. Okay, you know that if router Lab_A learns about a new path to a network, it’ll dutifully inform router Lab_B using EIGRP.
Router Lab_B may change its routing table to take advantage of this new information. Router Lab_A doesn’t “log in” to router Lab_B, but it is able to change router Lab_B’s routing table by just sending an EIGRP update to Lab_B. This is a simple example of dynamic routing, but look again. It also demonstrates how a network can be exposed to a potential security attack.
How? Suppose you have a bad guy between routers Lab_A and Lab_B, listening to their conversations. What if that bad guy builds an EIGRP update and sends it to router Lab_B, claiming that it’s from router Lab_A? Router Lab_B gets the update, processes it, and maybe even changes
Copyright ©2003 SYBEX Inc., 1151 Marina Village Parkway, Alameda, CA 94501. |
www.sybex.com |

Fighting Rerouting Attacks |
123 |
its routing table. This really does work sometimes—an attacker can introduce a routing update to the network that the receiving router acts upon because it has no way of knowing that the update isn’t valid. This is a prime example of what’s known as a rerouting attack.
The fundamental problem here is that the receiving router couldn’t verify that the update was truly sent by the sending router. You can solve this problem by giving the receiving router the ability to verify that the source of the updates it’s getting is in fact the router that the updates are supposed to be coming from. You can make this happen by enabling MD5 authentication on both routers.
It’s possible to also use distribution lists to address the rerouting problem.
With MD5 authentication enabled, the routers receive a common key that’s configured by the administrator. The routers then use that key to sign the routing updates they send and to verify the updates they receive. Any updates without matching keys won’t be considered valid updates and therefore will not be acted upon. And since invaders can’t extract the key from the update, they can’t reproduce it to fake an update.
The following routing protocols can use MD5 authentication:
RIPv2 (Routing Information Protocol version 2)
OSPF (Open Shortest Path First)
BGP (Border Gateway Protocol)
EIGRP (Enhanced Internet Gateway Routing Protocol)
It’s a good idea to deny routing protocol packets at your network’s entry points because you really shouldn’t see any routing protocols coming in, except for BGP. And if you’re not using BGP, it’s another good reason to just use static routes to and from the Internet.
Let’s take a look at a configuration example of some of these technologies at work. IPSec is covered in Chapter 7 and NAT configuration isn’t part of the SECUR exam, so I’m not including them here. Instead, this example focuses on enabling MD5 authentication and adding it into your routing process on the Lab_B router, whose EIGRP neighbor is out S0/0:
Lab_B#conf t
Lab_B(config)#router eigrp 100
Lab_B(config-router)#network 10.0.0.0
Lab_B(config-router)#network 172.16.0.0
Lab_B(config)#exit
Lab_B(config)#int s0/0
Lab_B(config-if)#ip authentication mode eigrp 100 md5
Lab_B(config-if)#ip authentication key-chain eigrp 100 toddkey
Lab_B(config-if)#exit
Lab_B(config)#key chain toddkey
Copyright ©2003 SYBEX Inc., 1151 Marina Village Parkway, Alameda, CA 94501. |
www.sybex.com |