Senior Acquisitions Editor: Kenyon Brown Development Editor: Kim Wimpsett

To find up-to-the-minute updates for this chapter,

please see

www.lammle.com/ccna

or the book’s web page

at

www.sybex.com/go/ccna

.

Mitigating Threats at the Access Layer

The Cisco hierarchical model can help you design, implement, and

maintain a scalable, reliable, cost-effective hierarchical internetwork.

The access layer controls user and workgroup access to internetwork

resources and is also sometimes referred to as the desktop layer. The

network resources most users need at this layer will be available locally

because the distribution layer handles any traffic for remote services.

The following are some of the functions to be included at the access layer:

Continued (from the distribution layer) use of access control and

policies

Creation of separate collision domains (microsegmentation/switches)

Workgroup connectivity into the distribution layer

Device connectivity

Resiliency and security services

Advanced technology capabilities (voice/video, PoE, port-security,

etc.)

Interfaces like Gigabit or FastEthernet switching frequently seen in

the access layer

Since the access layer is both the point at which user devices connect to

the network and the connection point between the network and client

device, protecting it plays an important role in protecting other users,

applications, and the network itself from attacks.

Here are some of the ways to protect the access layer (also shown in

Figure 16.1

):

Figure 16.1

Mitigating threats at the access layer

Port security You’re already very familiar with port security (or you

should be!), but restricting a port to a specific set of MAC addresses is the

most common way to defend the access layer.

DHCP snooping DHCP snooping is a layer 2 security feature that

validates DHCP messages by acting like a firewall between untrusted

hosts and trusted DHCP servers.

In order to stop rogue DHCP servers in the network, switch interfaces are

configured as trusted or untrusted, where trusted interfaces allow all

types of DHCP messages and untrusted interfaces allow only requests.

Trusted interfaces are interfaces that connect to a DHCP server or are an

uplink toward the DHCP server, as shown in

Figure 16.2

.

Figure 16.2

DHCP snooping and DAI

With DHCP snooping enabled, a switch also builds a DHCP snooping

binding database, where each entry includes the MAC and IP address of

the host as well as the DHCP lease time, binding type, VLAN, and

interface. Dynamic ARP inspection also uses this DHCP snooping binding

database.

Dynamic ARP inspection (DAI) DAI, used with DHCP snooping,

tracks IP-to-MAC bindings from DHCP transactions to protect against

ARP poisoning (which is an attacker trying to have your traffic be sent to

him instead of to your valid destination). DHCP snooping is required in

order to build the MAC-to-IP bindings for DAI validation.

Identity-based networking Identity-based networking is a concept

that ties together several authentication, access control, and user policy

components in order to provide users with the network services you want

them to have.

In the past, for a user to connect to the Finance services, for example, a

user had to be plugged into the Finance LAN or VLAN. However, with

user mobility as one of the core requirements of modern networks, this is

no longer practical, nor does it provide sufficient security.

Identity-based networking allows you to verify users when they connect

to a switch port by authenticating them and placing them in the right

VLAN based on their identity. Should any users fail to pass the

authentication process, their access can be rejected, or they might be

simply put in a guest VLAN.

Figure 16.3

shows this process.

Figure 16.3

Identity-based networking

The IEEE 802.1x standard allows you to implement identity-based

networking on wired and wireless hosts by using client/server access

control. There are three roles:

Client Also referred to as a supplicant, this software runs on a client

that is 802.1x compliant.

Authenticator Typically a switch, this controls physical access to the

network and is a proxy between the client and the authentication

server.

Authentication server (RADIUS) This is a server that

authenticates each client before making available any services.

External Authentication Options

Of course we only want authorized IT folks to have administrative access

to our network devices such as routers and switches, and in a small to

medium-sized network, just using local authentication is sufficient.

However, if you have hundreds of devices, managing administrative

connectivity would be nearly impossible since you’d have to configure

local authentication on each device by hand, and if you changed just one

password, it can take hours to update your network.

Since maintaining the local database for each network device for the size

of the network is usually not feasible, you can use an external AAA server

that will manage all user and administrative access needs for an entire

network.

The two most popular options for external AAA are RADIUS and

TACACS+, both covered next.

RADIUS

Remote Authentication Dial-In User Service, or RADIUS, was developed

by the Internet Engineering Task Force—the IETF—and is basically a

security system that works to guard the network against unauthorized

access. RADIUS, which uses only UDP, is an open standard implemented

by most major vendors, and it’s one of the most popular types of security

servers around because it combines authentication and authorization

services into a single process. So after users are authenticated, they are

then authorized for network services.

RADIUS implements a client/server architecture, where the typical client

is a router, switch, or AP and the typical server is a Windows or Unix

device that’s running RADIUS software.

The authentication process has three distinct stages:

1.  The user is prompted for a username and password.

2.  The username and encrypted password are sent over the network to

the RADIUS server.

3.  The RADIUS server replies with one of the following:

Response

Meaning

Accept

The user has been successfully authenticated.

Reject

The username and password are not valid.

Challenge

The RADIUS server requests additional information.

Change Password The user should select a new password.

It’s important to remember that RADIUS encrypts only the password in

the access-request packet from the client to the server. The remainder of

the packet is unencrypted.

Configuring RADIUS

To configure a RADIUS server for console and VTY access, first you need

to enable AAA services in order to configure all the AAA commands.

Configure the

aaa new-model

command in the global configuration mode.

Router(config)#

aaa new-model

The

aaa new-model

command immediately applies local authentication to

all lines and interfaces (except

line con 0

). So, to avoid being locked out

of the router or switch, you should define a local username and password

before starting the AAA configuration.

Now, configure a local user:

Router(config)#

username Todd password Lammle

Creating this user is super important because you can then use this same

locally created user if the external authentication server fails! If you don’t

create this and you can’t get to the server, you’re going to end up doing a

password recovery.

Next, configure a RADIUS server using any name and the RADIUS key

that is configured on the server.

Router(config)#

radius server SecureLogin

Router(config-radius-server)#

address ipv4 10.10.10.254

Router(config-radius-server)#

key MyRadiusPassword

Now, add your newly created RADIUS server to an AAA group of any

name.

Router(config)#

aaa group server radius MyRadiusGroup

Router(config-sg-radius)#

server name SecureLogin

Last, configure this newly created group to be used for AAA login

authentication. If the RADIUS server fails, the fallback to local

authentication should be set.

Router(config)#

aaa authentication login default group

MyRadiusGroup local

TACACS+

Terminal Access Controller Access Control System (TACACS+) is also a

security server that’s Cisco proprietary and uses TCP. It’s really similar in

many ways to RADIUS; however, it does all that RADIUS does and more,

including multiprotocol support.

TACACS+ was developed by Cisco Systems, so it’s specifically designed to

interact with Cisco’s AAA services. If you’re using TACACS+, you have the

entire menu of AAA features available to you—and it handles each

security aspect separately, unlike RADIUS:

Authentication includes messaging support in addition to login and

password functions.

Authorization enables explicit control over user capabilities.

Accounting supplies detailed information about user activities.

Configuring TACACS+

This is pretty much identical to the RADIUS configuration.

To configure a TACACS+ server for console and VTY access, first you

need to enable AAA services in order to configure all the AAA commands.

Configure the

aaa new-model

command in the global configuration mode

(if it isn’t already enabled).

Router(config)#

aaa new-model

Now, configure a local user if you haven’t already.

Router(config)#

username Todd password Lammle

Next, configure a TACACS+ server using any name and the key that is

configured on the server.

Router(config)#

radius server SecureLoginTACACS+

Router(config-radius-server)#

address ipv4 10.10.10.254

Router(config-radius-server)#

key MyTACACS+Password

Now, add your newly created TACACS+ server to a AAA group of any

name.

Router(config)#

aaa group server radius MyTACACS+Group

Router(config-sg-radius)#

server name SecureLoginTACACS+

Last configure this newly created group to be used for AAA login

authentication. If the TACACS+ server fails, the fallback to local

authentication should be set.

Router(config)#

aaa authentication login default group

MyTACACS+Group local

SNMP

Although Simple Network Management Protocol (SNMP) certainly isn’t

the oldest protocol ever, it’s still pretty old, considering it was created way

back in 1988 (RFC 1065)!

SNMP is an Application layer protocol that provides a message format for

agents on a variety of devices to communicate with network management

stations (NMSs)—for example, Cisco Prime or HP Openview. These

agents send messages to the NMS station, which then either reads or

writes information in the database that’s stored on the NMS and called a

management information base (MIB).

The NMS periodically queries or polls the SNMP agent on a device to

gather and analyze statistics via GET messages. End devices running

SNMP agents would send an SNMP trap to the NMS if a problem occurs.

This is demonstrated in

Figure 16.4

.

Figure 16.4

SNMP GET and TRAP messages

Admins can also use SNMP to provide some configurations to agents as

well, called SET messages. In addition to polling to obtain statistics,

SNMP can be used for analyzing information and compiling the results in

a report or even a graph. Thresholds can be used to trigger a notification

process when exceeded. Graphing tools are used to monitor the CPU

statistics of Cisco devices like a core router. The CPU should be

monitored continuously and the NMS can graph the statistics.

Notification will be sent when any threshold you’ve set has been

exceeded.

SNMP has three versions, with version 1 being rarely, if ever,

implemented today. Here’s a summary of these three versions:

SNMPv1 Supports plaintext authentication with community strings and

uses only UDP.

SNMPv2c Supports plaintext authentication with community strings

with no encryption but provides GET BULK, which is a way to gather

many types of information at once and minimize the number of GET

requests. It offers a more detailed error message reporting method called

INFORM, but it’s not more secure than v1. It uses UDP even though it

can be configured to use TCP.

SNMPv3 Supports strong authentication with MD5 or SHA, providing

confidentiality (encryption) and data integrity of messages via DES or

DES-256 encryption between agents and managers. GET BULK is a

supported feature of SNMPv3, and this version also uses TCP.

Management Information Base (MIB)

With so many kinds of devices and so much data that can be accessed,

there needed to be a standard way to organize this plethora of data, so

MIB to the rescue! A management information base (MIB) is a collection

of information that’s organized hierarchically and can be accessed by

protocols like SNMP. RFCs define some common public variables, but

most organizations define their own private branches along with basic

SNMP standards. Organizational IDs (OIDs) are laid out as a tree with

different levels assigned by different organizations, with top-level MIB

OIDs belonging to various standards organizations.

Vendors assign private branches in their own products. Let’s take a look

at Cisco’s OIDs, which are described in words or numbers to locate a

particular variable in the tree, as shown in

Figure 16.5

.

Figure 16.5

Cisco’s MIB OIDs

Luckily, you don’t need to memorize the OIDs in

Figure 16.5

for the Cisco

exams!

To obtain information from the MIB on the SNMP agent, you can use

several different operations:

GET: This operation is used to get information from the MIB to an

SNMP agent.

SET: This operation is used to get information to the MIB from an

SNMP manager.

WALK: This operation is used to list information from successive MIB

objects within a specified MIB.

TRAP: This operation is used by the SNMP agent to send a triggered

piece of information to the SNMP manager.

INFORM: This operation is the same as a trap, but it adds an

acknowledgment that a trap does not provide.

Configuring SNMP

Configuring SNMP is a pretty straightforward process for which you only

need a few commands. These five steps are all you need to run through to

configure a Cisco device for SNMP access:

1.  Configure where the traps are to be sent.

2.  Enable SNMP read-write access to the router.

3.  Configure SNMP contact information.

4.  Configure SNMP location.

5.  Configure an ACL to restrict SNMP access to the NMS hosts.

The only required configuration is the IP address of the NMS station and

the community string (which acts as a password or authentication string)

because the other three are optional. Here’s an example of a typical

SNMP router configuration:

Router(config)#

snmp-server host 1.2.3.4

Router(config)#

snmp-server community ?

WORD SNMP community string

Router(config)#

snmp-server community Todd ?

<1-99>

Std IP accesslist allowing access with this

community string

<1300-1999>

Expanded IP accesslist allowing access with this

community string

WORD

Access-list name

ipv6

Specify IPv6 Named Access-List

ro

Read-only access with this community string

rw

Read-write access with this community string

view

Restrict this community to a named MIB view

Router(config)#

snmp-server community Todd rw

Router(config)#

snmp-server location Boulder

Router(config)#

snmp-server contact Todd Lammle

Router(config)#

ip access-list standard Protect_NMS_Station

Router(config-std-nacl)#

permit host 192.168.10.254

Entering the

snmp-server

command enables SNMPv1 on the Cisco device.

You can enter the ACL directly in the SNMP configuration to provide

security, using either a number or a name. Here is an example:

Router(config)#

snmp-server community Todd Protect_NMS_Station rw

Notice that even though there’s a boatload of configuration options under

SNMP, you only really need to work with a few of them to configure a

basic SNMP trap setup on a router. First, I set the IP address of the NMS

station where the router will send the traps; then I chose the community

name of

Todd

with RW access (read-write), which means the NMS will be

able to retrieve and modify MIB objects from the router. Location and

contact information comes in really handy for troubleshooting the

configuration. Make sure you understand that the ACL protects the NMS

from access, not the devices with the agents!

Let’s define the SNMP read and write options.

Read-only Gives authorized management stations read access to all

objects in the MIB except the community strings and doesn’t allow write

access

Read-write Gives authorized management stations read and write

access to all objects in the MIB but doesn’t allow access to the community

strings

Next we’ll explore a Cisco proprietary method of configuring redundant

default gateways for hosts.

Client Redundancy Issues

If you’re wondering how you can possibly configure a client to send data

off its local link when its default gateway router has gone down, you’ve

targeted a key issue because the answer is that, usually, you can’t! Most

host operating systems just don’t allow you to change data routing. Sure,

if a host’s default gateway router goes down, the rest of the network will

still converge, but it won’t share that information with the hosts. Take a

look at

Figure 16.6

to see what I am talking about. There are actually two

routers available to forward data for the local subnet, but the hosts know

about only one of them. They learn about this router when you provide

them with the default gateway either statically or through DHCP.

Figure 16.6

Default gateway

This begs the question: Is there another way to use the second active

router? The answer is a bit complicated, but bear with me. There is a

feature that’s enabled by default on Cisco routers called Proxy Address

Resolution Protocol (Proxy ARP). Proxy ARP enables hosts, which have

no knowledge of routing options, to obtain the MAC address of a gateway

router that can forward packets for them.

You can see how this happens in

Figure 16.7

. If a Proxy ARP–enabled

router receives an ARP request for an IP address that it knows isn’t on the

same subnet as the requesting host, it will respond with an ARP reply

packet to the host. The router will give its own local MAC address—the

MAC address of its interface on the host’s subnet—as the destination

MAC address for the IP address that the host is seeking to be resolved.

After receiving the destination MAC address, the host will then send all

the packets to the router, not knowing that what it sees as the destination

host is really a router. The router will then forward the packets toward

the intended host.

Figure 16.7

Proxy ARP

So with Proxy ARP, the host device sends traffic as if the destination

device were located on its own network segment. If the router that

responded to the ARP request fails, the source host continues to send

packets for that destination to the same MAC address. But because

they’re being sent to a failed router, the packets will be sent to the other

router on the network that is also responding to ARP requests for remote

hosts.

After the time-out period on the host, the proxy ARP MAC address ages

out of the ARP cache. The host can then make a new ARP request for the

destination and get the address of another proxy ARP router. Still, keep

in mind that the host cannot send packets off of its subnet during the

failover time. This isn’t exactly a perfect situation, so there has to be a

better way, right? Well, there is, and that’s precisely where redundancy

protocols come to the rescue!

Introducing First Hop Redundancy Protocols

(FHRPs)

First hop redundancy protocols (FHRPs) work by giving you a way to

configure more than one physical router to appear as if they were only a

single logical one. This makes client configuration and communication

easier because you can simply configure a single default gateway and the

host machine can use its standard protocols to communicate. First hop is

a reference to the default router being the first router, or first router hop,

through which a packet must pass.

So how does a redundancy protocol accomplish this? The protocols I’m

going to describe to you do this basically by presenting a virtual router to

all of the clients. The virtual router has its own IP and MAC addresses.

The virtual IP address is the address that’s configured on each of the host

machines as the default gateway. The virtual MAC address is the address

that will be returned when an ARP request is sent by a host. The hosts

don’t know or care which physical router is actually forwarding the

traffic, as you can see in

Figure 16.8

.