Vous êtes sur la page 1sur 68

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Copyright Information

Copyright © 2009 Internetwork Expert, Inc. All rights reserved.

The following publication, CCIE Security Lab Workbook Volume I Version 5.0, was developed by Internetwork Expert, Inc. All rights reserved. No part of this publication may be reproduced or distributed in any form or by any means without the prior written permission of Internetwork Expert, Inc.

Cisco®, Cisco® Systems, CCIE, and Cisco Certified Internetwork Expert, are registered trademarks of Cisco® Systems, Inc. and/or its affiliates in the U.S. and certain countries.

All other products and company names are the trademarks, registered trademarks, and service marks of the respective owners. Throughout this manual, Internetwork Expert, Inc. has used its best efforts to distinguish proprietary trademarks from descriptive names by following the capitalization styles used by the manufacturer.

the capitalization styles used by the manufacturer. Accessed by rohitpardasani@hotmail.com from 115.240.81.217

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

i

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Disclaimer

The following publication, CCIE Security Lab Workbook Volume I Version 5.0, is designed to assist candidates in the preparation for Cisco Systems’ CCIE Security Lab Exam. While every effort has been made to ensure that all material is as complete and accurate as possible, the enclosed material is presented on an “as is” basis. Neither the authors nor Internetwork Expert, Inc. assume any liability or responsibility to any person or entity with respect to loss or damages incurred from the information contained in this workbook.

This workbook was developed by Internetwork Expert, Inc. and is an original work of the aforementioned authors. Any similarities between material presented in this workbook and actual CCIE lab material is completely coincidental.

and actual CCIE lab material is completely co incidental. Accessed by rohitpardasani@hotmail.com from 115.240.81.217

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

ii

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Table of Contents

Control/Management Plane Security

4

6.1 Control Plane Protection (CPPr)

4

6.2 BGP Generic TTL Security Mechanism

5

6.3 BGP

Prefix Limit

5

6.4 Selective Packet Discard

5

6.5 Terminal Lines Security

5

6.6 TCP Keepalives

 

6

6.7 SNMPv2 Server

6

6.8 SNMPv2c Access Control

6

6.9 SNMP Traps and Informs

6

6.10 CPU and Memory Thresholds

6

6.11 SNMPv3

 

7

6.12 RMON Alarms

7

6.13 Role Based Access Control

8

6.14 IP Source Tracker

 

8

6.15 ICMP Rate Limiting

8

6.16 IOS Login Enhancements

8

Control/Management Plane Security Solutions 6.1 Control Plane Pr otection (CPPr) 6.2 BGP Generic TTL Se

Control/Management Plane Security Solutions

6.1 Control Plane Protection (CPPr)

6.2 BGP Generic TTL Security Mechanism

9

9

20

6.3 BGP

Prefix Limit

22

6.4 Selective Packet Discard

25

6.5 Terminal Lines Security

29

6.6 TCP Keepalives

 

34

6.7 SNMPv2 Server

36

6.8 SNMPv2c Access Control

38

6.9 SNMP Traps and Informs

40

6.10 CPU and Memory Thresholds

42

6.11 SNMPv3

 

45

6.12 RMON Alarms

52

6.13 Role-Based Access Control

56

6.14 IP Source Tracker

 

60

6.15 ICMP Rate Limiting

62

6.16 IOS Login Enhancements

64

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

iii

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Control/Management Plane Security

Note

Load the IOS Firewall initial configuration prior to starting with the following tasks. Use the diagram as your reference:

RIPv2 136.X.23.0/24 VLAN23 Fa0/0 Fa0/1.23 Fa0/0 Fa0/0 R3 Fa0/1.100 136.X.13.0/24 VLAN 13 10.0.0.0/24 VLAN 100
RIPv2
136.X.23.0/24 VLAN23
Fa0/0
Fa0/1.23
Fa0/0
Fa0/0
R3
Fa0/1.100
136.X.13.0/24 VLAN 13
10.0.0.0/24 VLAN 100
AAA/CA
Server
Lo0: 150.X.2.2/24 R2
Lo0: 150.X.2.2/24
R2

Lo0: 150.X.1.1/24Fa0/0 Fa0/0 R3 Fa0/1.100 136.X.13.0/24 VLAN 13 10.0.0.0/24 VLAN 100 AAA/CA Server Lo0: 150.X.2.2/24 R2 R1

R1
R1

6.1 Control Plane Protection (CPPr)

Enhance R3 protection by dropping packets going to all closed ports.

Ensure this does not affect connections made on ports 3020 and 4040.

To reduce the effect of broadcast storms, limit the rate of input non-IP packets to 100 per second

Set the queue-limit for input HTTP packets to 100 packets and limit the packet rate to 10 per second.

Ensure that all fragmented packets transiting the router are limited to 1 Mpps.

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

4

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

6.2 BGP Generic TTL Security Mechanism

Configure eBGP session between R1 and R2 and make both routers accept the peer if it’s no more than one hop away.

Use AS numbers 100 and 200 for R1 and R2 respectively.

6.3 BGP Prefix Limit

Configure R1 so that it does not accept more than ten prefixes from R2.

A warning message should be generated once 6 prefixes have been received.

When the maximum limit is exceeded, drop the session and restart it in 5 minutes.

6.4 Selective Packet Discard

Enable Selective Packet Discard on R1 in aggressive mode.

Increase R1’s input queue size on its link to VLAN 13 to twice the default.

Increase the amount of the memory headroom for IGP packets to 150 buffers.

The headroom for BGP packets should be set to 120 packets.

Start dropping low-priority packets randomly when the input queue is 50% full.

packets randomly when the input queue is 50% full. 6.5 Terminal Lines Security • Configure R3

6.5 Terminal Lines Security

Configure R3 to allow only telnet connections to VTY lines 0 through 4 without using an access-list.

When a user is telnetted into R3 and mistypes a command in exec mode, R3 should not try to open a telnet session to the command as if it was a hostname.

Configure VTY line 0 to listen for telnet at port 3001.

When the virtual terminal line is busy issue the output “Sorry, the line is already in use” to the connecting user.

Exec sessions on a VTY line should timeout after 2 minutes of inactivity; additionally a user should not be able to hold the line busy for more than 5 minutes.

Sessions initiated from a VTY line should time out in 1 minute.

When the console line is idle the user should see the output “Welcome to IOS”

Allow no more than 1 session to be initiated from the console line.

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

5

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Allow a user to lock VTY terminal lines.

6.6 TCP Keepalives

Configure R1 so that it’s capable of detecting dead TCP connections and closing them prematurely.

6.7 SNMPv2 Server

Configure SNMP on R3 with the SNMP contact set to “Default Contact” and the SNMP Location to “Default Location”.

Enable the SNMP server service using the community string value of CISCO so that remote hosts can modify the local MIB database.

Allow the system to be reloaded via SNMP.

Ensure that interface index numbers persist between reloads.

Only allow configuration transfers via TFTP to/from the host 10.0.0.100.

6.8 SNMPv2c Access Control

Configure R3 to restrict read-write access to only hosts in VLAN 13.

R3 to restrict read-writ e access to only hosts in VLAN 13. • Log any other

Log any other SNMP access attempts using the community string “CISCO”.

Allow any host to access R3’s MIBs in read-only mode using the community string “PUBLIC”.

Read-only access should be permitted to the “cisco” MIB subtree only.

6.9 SNMP Traps and Informs

Configure R3 to send SNMP traps to the management host 10.0.0100 and informs to the host 10.0.0.200.

Only send notifications about interfaces going up or down.

Ensure no informs are being sent about FastEthernet interface changing status.

Use the community value of “CISCO” with the above traps and informs.

6.10 CPU and Memory Thresholds

Configure R3 to monitor CPU usage every 5 seconds using the process cpu command, and to generate a rising threshold event every time the CPU usage hits 50%.

Set up the free memory low threshold to 1000Kbytes, and reserve 512Kbytes of memory for the notification process using the memory command.

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

6

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

6.11 SNMPv3

Create two SNMP views named NORMAL and RESTRICTED on R2.

The NORMAL view should include the branch “iso”.

The RESTRICTED view should include the branch “ifEntry.*.n”, where n is the ifIndex of R2’s FastEthernet interface.

Create an SNMP group named NORMAL with the read/write view assigned to NORMAL, and a security model of “priv”.

Assign the user named NORMAL to this group, set the SHA1 password to CISCO, and the encryption key to CISCO.

Create an SNMP group named RESTRICTED with the read view assigned to RESTRICTED, and a security model of “auth”.

Only users in VLAN 23 should be allowed in the SNMP group RESTRICTED.

Assign the user named RESTRICTED to this group using the security model which only requires authentication using the password CISCO.

Create an SNMP group named TRAP with the security model “priv”.

Assign the user named TRAP to this group using the password and encryption key CISCO.

Enable SNMP traps for LinkUp and LinkDown events only, and send them to the destination host 10.0.0.100 using the security model “priv” and the username TRAP.

using the security model “priv” and the username TRAP. 6.12 RMON Alarms • Configure R1 to

6.12 RMON Alarms

Configure R1 to monitor the rate of packets entering its interface connecting to VLAN 13 based on the total input packet counter

(ifEntry.11).

If the rate is above 100 packets per minute generate the log message “VLAN13 Interface Congested” and send a trap to the management host at 10.0.0.100.

Use the SNMP community string CISCO.

When the packet rate falls below 50 packets per minute, generate another log message “VLAN13 Interface UnCongested” and send a corresponding trap.

The owner of events should be set to “CISCO”.

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

7

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

6.13 Role Based Access Control

Create the following roles in R3: “SUPER”, “DEBUG”, “INTERFACE1” and

“INTERFACE2”.

The role “INTERFACE1” should have access to all IP configuration commands of interface Fa0/0 only. For “INTERFACE2” do the same with the exception that it applies to interface Fa0/1.

The role “DEBUG” should be able to use any debug and undebug commands, and it should be able to inspect the running configuration.

The last role name “SUPER” should be a sum of all the other roles.

Use the password of “CISCO” to authenticate all roles.

6.14 IP Source Tracker

You suspect that R1 is under a distributed DoS attack from unidentified sources.

Configure R3 to collect attack information for the IP address of R1.

Export the statistics via syslog messages every 5 minutes.

Export the statistics via syslog messages every 5 minutes. 6.15 ICMP Rate Limiting • In the

6.15 ICMP Rate Limiting

In the future, you plan to apply an input traffic filter on R3’s VLAN 23 interface.

Configure this interface not to respond with an ICMP message when the filter drops a packet.

The rate of these messages sent out of all other interfaces should not exceed 100 per second.

In order to ensure that PMTUD works correctly, increase the rate of ICMP messages used by this feature to 1000 per second on R3.

6.16 IOS Login Enhancements

After 3 unsuccessful attempts to log into R2 in 30 seconds, block all further attempts for 40 seconds.

Ensure that sessions sourced from the R3 Loopback0 are exempted from this restriction.

Log every successful login attempt and every 3 rd unsuccessful attempt.

Enforce a delay of 2 seconds between successive login attempts.

Create a local username “TEST” with the password of “TEST” for this task.

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

8

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Control/Management Plane Security Solutions

6.1 Control Plane Protection (CPPr)

Enhance R3 protection by dropping packets going to all closed ports.

Ensure this does not affect connections made on ports 3020 and 4040.

To reduce the effect of broadcast storms, limit the rate of input non-IP packets to 100 per second

Set the queue-limit for input HTTP packets to 100 packets and limit the packet rate to 10 per second.

Ensure that all fragmented packets transiting the router are limited to 1 Mpps.

Configuration

Note

Note Control Plane Protection (CPPr) is Ci sco IOS feature aimed at preventing infrastructure attacks, i.e.

Control Plane Protection (CPPr) is Cisco IOS feature aimed at preventing infrastructure attacks, i.e. attacks targeting at the router itself. Control Plane implements routing and management protocols, such as OSPF, BGP, RIP, SNMP, SSH, Telnet and so on. The most typical attacks against control plane are of resource exhaustion type, i.e. they target at depleting router’s resources and causing service denial. On most IOS platforms, control plane applications run on central Route Processor (or CPU) in parallel with asynchronous packet switching. Packet routing is commonly implemented using CEF switching path, during hardware interrupt processing task. All packets directed to the control plane (e.g. routing updates, keepalives, SSH/SNMP sessions) are handled using process-switching, which is most CPU intensive.

Since IOS 12.3T a feature known as Control Plane Policing allows for applying traffic policing for packets not handled during interrupt processing (fast/CEF paths). This feature permit basic protection against DoS attacks targeted at the router’s CPU, such as fragmented ping flooding. A sample control plane policing configuration would look similar to the following example:

ip access-list extended BGP permit tcp any any eq bgp

!

ip access-list extended OSPF

permit ospf any any

!

class-map BGP match access-group name BGP

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

9

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

!

class-map OSPF match access-group name OSPF

!

policy-map CONTROL_PLANE_POLICY class BGP police rate 2000 pps burst 100 packets class OSPF police rate 10 pps burst 3 class class-default police rate 5000 pps burst 100 packets

!

control-plane service-policy input CONTROL_PLANE_POLICY

Notice that in the above configuration the police command specifies rate in packets per second and the burst size in packets. This type of the police command is only applicable to the control-plane policy. In addition to the input policy, you can configure output policing as well, and limit the rate of the packets produced by the router’s control plane.

te of the packets produced by the router’s control plane. Using just the demonstrated aggregate form

Using just the demonstrated aggregate form of policing along, you may already increase the level of your router’s protections. However, CPPr extended CPP and made it even more granular. CPPr treat the Route Processor (RP) as a virtual interface attached to the router. All packets redirected to the RP for some reason are classified into three categories corresponding to three subinterfaces of the virtual interface:

Control-plane host subinterface. This interface receives all control- plane TCP/UDP traffic that is directly destined for one of the router interfaces. Examples of control-plane host traffic include management traffic or routing protocols. Notice that non TCP/UDP control traffic will end up on the CEF- exception sub-interface. Most control plane protection features operate on this subinterface and thus this sub-interface provides most features, such as policing, port filtering and per-protocol queue thresholds.

Port-filtering allows for automatically dropping of packets destined for the TCP/UDP ports not currently open in the router. The operating system automatically detects all open ports, and you can manually configure some exceptions. The net effect is reduced load on router’s CPU during the times of flooding attacks.

Per-protocol queue thresholds allow you setting selective queue limits for packets of different type, for example BGP, OSPF, FTP, DNS, HTTP, IGMP, SNMP etc.

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

10

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Control-plane transit subinterface. This subinterface is intended to handle transit IP packets not handled via CEF mechanism and needed to be switching in the processor context. This might happen, for instance, when a packet mast be routed out of Ethernet interface and no ARP lookup has been made yet for the next-hop, making the CEF adjacency incomplete.

Control-plane CEF exception subinterface. This is where packets causing an exception in CEF switching path land. So far, those include non-IP router-destined traffic, such as CDP, L2 keepalive messages (e.g. Frame-Relay LMI keepalives) or ARP packets and IP packets with options or TTL <=1. Additionally, non-UDP local multicast traffic destined to the router (e.g. OSPF updates) fall into this category as well.

You may apply a separate rate-limiting policy to any of the sub-interface or have a single aggregate policy embracing all subinterfaces (classic control plane policing). It is possible to configure both the subinterface and aggregate policy, but this feature appears to work unstable in many 12.4T images. So far, it seems to be better configuring either aggregate or subinterface specific policies.

Before any packet reaches any specific control plane subinterface, it is first processed via a series of ingress features including input access-list, uRP checks, aggregate control-plane policy. After passing the subinterface-specific policy, the packet is then being enqueued onto the respective interface input queue and handled via SPD (selective packet discard) policy. Here is a visual outline of the process:

discard) policy. Here is a visual outline of the process: Let’s go and look into CPPr
discard) policy. Here is a visual outline of the process: Let’s go and look into CPPr

Let’s go and look into CPPr configuration steps. You start by defining class-maps to select control-plane traffic. Those are regular L3/L4 class-maps, matching access-lists/DSCP values etc. You cannot use NBAR for control-plane traffic classification. After this, you define a regular policy map and assign classes to it, applying the desired actions. The policing command is the same as described

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

11

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

above, based on packet rate per second. However, after this the things start to differ. You may attach the new policy map to any of the control plane sub- interfaces, like this:

policy-map CPP_HOST_POLICY class BGP police rate 256000

!

control-plane host service-policy input CPP_HOST_POLICY

You may use the command control-plane {host| cef-exception| transit} to select any of the control-plane subinterfaces. Notice that you cannot configure egress policing for any of the host subinterfaces. Now, the most important host subinterface also supports the port-filtering feature. To configure this one, you first need to create a class-map defining ports to be filtered. The command is class-map type port-filter [match-all | match-any] <NAME>. For example

class-map type port-filter match-any CLOSED_PORTS match closed-ports match port TCP 1024 match port UDP 2048

match closed-ports match port TCP 1024 match port UDP 2048 The first match command auto-detects all

The first match command auto-detects all open ports in the system and select all other ports as “closed”. To check the ports currently detected as “open” use the command show control-plane host open ports. As you can see, you may add your own ports using the match port statement. You can also use the match not port command to unblock a port that is not automatically detected by the system as open. For example, if you have a rotary-group 30 configured on a VTY line, you may want to make sure that TCP port 3030 is not blocked. You can use the following configuration:

class-map type port-filter match-all CLOSED_PORTS match closed-ports match not port 3020

To apply the port filtering settings, create a port-filtering policy-map and apply it to the host control-plane subinterface:

policy-map type port-filter FILTER_CLOSED_PORTS class CLOSED_PORTS drop

!

control-plane host

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

12

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

service-policy type port-filter input FILTER_CLOSED_PORTS

This configuration will effectively drop all packets destined to closed ports before affecting router’s CPU. The last feature to discuss is per-protocol input queue thresholds. As mentioned, those allow for differentiated per-protocol services on the control-plane host interface. In order to define a queue threshold, create a special queue-threshold class-map first. This class-map should match one or many of the supported protocols:

class-map type queue-threshold [match-all | match-any] <CLASS> match protocol [bgp | dns | ftp | http | igmp | snmp | ssh | syslog | telnet | tftp]

As you can see, the list is pretty extensive. You can use the special command match host-protocols to select ALL TCP/UDP based protocol running on the router and set a queue threshold for those. Packets are classified when they enter the router and are redirected to the host subinterface. Afte you have the special class-map defined you may configure a special queue-threshold policy- map and apply it to the host subinterface:

policy- map and apply it to the host subinterface: class-map type queue-threshold CMAP_BGP match protocol bgp

class-map type queue-threshold CMAP_BGP match protocol bgp

!

policy-map type queue-threshold BGP_THRESHOLD

class CMAP_BGP queue-limit 50

!

control-plane host service-policy type queue-threshold input BGP_THRESHOLD

The queue limit is set in packets. This is the separate limit enforced for this particular protocol in the common input queue. There could be only one input queue-threshold policy-map, but you can configure every class with a separate limit.

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

13

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

R3:

!

!

ACL to select fragmented IP packets

!

ip access-list extended FRAGMENTS

permit ip any any fragment

!

class-map FRAGMENTS match access-group name FRAGMENTS

!

!

HTTP traffic

!

ip access-list extended HTTP permit tcp any any eq www

!

class-map HTTP match access-group name HTTP

!

!

Class-map to select closed ports. Notice that we

!

need to unblock the RIP port explicitly.

!

class-map type port-filter match-all CLOSED_PORTS match closed-ports match not port TCP 3020 match not port TCP 3040 match not port UDP 520

!

TCP 3020 match not port TCP 3040 match not port UDP 520 ! policy-map type port-filter

policy-map type port-filter HOST_PORT_FILTER class CLOSED_PORTS drop

!

!

To set the queue thresholds for HTTP

!

class-map type queue-threshold QUEUE_HTTP match protocol http

!

policy-map type queue-threshold HOST_QUEUE_THRESHOLD class QUEUE_HTTP queue-limit 100

!

!

Control plane rate-limit policies

!

policy-map HOST_RATE_LIMIT class HTTP police rate 10 pps burst 2 packets

!

policy-map CEF_EXCEPTION_RATE_LIMIT class class-default police rate 100 pps burst 20 packets

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

14

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

!

policy-map TRANSIT_RATE_LIMIT class FRAGMENTS police rate 1000000 pps burst 200000 packets

!

! Applying the policies together

!

control-plane host service-policy input HOST_RATE_LIMIT service-policy type queue-threshold input HOST_QUEUE_THRESHOLD service-policy type port-filter input HOST_PORT_FILTER

!

control-plane transit service-policy input TRANSIT_RATE_LIMIT

!

control-plane cef-exception service-policy input CEF_EXCEPTION_RATE_LIMIT

cef-exception service-policy input CEF_EXCEPTION_RATE_LIMIT Accessed by rohitpardasani@hotmail.com from 115.240.81.217

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

15

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Verification

Note

Configure an HTTP server in R3 and simulate an HTTP connection from R1 to

R3.

Rack1R1#telnet 136.1.13.3 80

Trying 136.1.13.3, 80 GET /

Open

WWW-Authenticate: Basic realm="level_15_access"

401 Unauthorized

[Connection to 136.1.13.3 closed by foreign host]

Rack1R1#

Note

Check the policy-map statistics for the host subinterface.

Check the policy-map statisti cs for the host subinterface. Rack1R3#show policy-map control-plane host Control Plane

Rack1R3#show policy-map control-plane host

Control Plane Host

Service-policy input: HOST_RATE_LIMIT

Class-map: HTTP (match-all) 12 packets, 720 bytes

5 minute offered rate 0 bps, drop rate 0 bps Match: access-group name HTTP police:

rate 10 pps, burst 2 packets conformed 8 packets; actions:

transmit exceeded 4 packets; actions:

drop conformed 0 pps, exceed 0 pps

Class-map: class-default (match-any)

5 packets, 338 bytes

5 minute offered rate 0 bps, drop rate 0 bps Match: any

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

16

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Note

Now check the port-filter policy map applied to the host subinterface. Configure R3 to listen on port 3020 by setting up a rotary group numer on any VTY line. Notice that the list of auto-detected open ports does not include the ports manually added to the policy-map.

Rack1R3#show policy-map type port-filter control-plane host

Control Plane Host

Service-policy port-filter input: HOST_PORT_FILTER

Class-map: CLOSED_PORTS (match-all)

4 packets, 543 bytes

5 minute offered rate 0 bps, drop rate 0 bps Match: closed-ports Match: not port tcp 3020 Match: not port tcp 3040

Match: not

port udp 520

drop

Match: not port tcp 3040 Match: not port udp 520 drop Class-map: class-default (match-any) 12 packets,

Class-map: class-default (match-any) 12 packets, 816 bytes

minute offered rate 0 bps, drop rate 0 bps Match: any

5

R3:

line vty 0 rotary 20

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

17

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Rack1R3#show control-plane host open-ports

Active internet connections (servers and established)

Prot

Local Address

Foreign Address

Service

State

tcp

*:23

*:0

Telnet

LISTEN

tcp

*:80

*:0

HTTP CORE

LISTEN

udp

*:67

*:0

DHCPD Receive

LISTEN

udp

*:68

*:0

BootP client

LISTEN

Rack1R1#telnet 136.1.13.3 3020

Trying 136.1.13.3, 3020

Open

User Access Verification

Password:

Note

Note Check the queue thresholds for HTTP traffic class next. Notice that there are matches because

Check the queue thresholds for HTTP traffic class next. Notice that there are matches because we connected to the router using HTTP.

Rack1R3#show policy-map type queue-threshold control-plane host

queue-limit 100 queue-count 0 Control Plane Host

packets allowed/dropped 0/0

Service-policy queue-threshold input: HOST_QUEUE_THRESHOLD

Class-map: QUEUE_HTTP (match-all)

8 packets, 480 bytes

5 minute offered rate 0 bps, drop rate 0 bps Match: protocol http

Class-map: class-default (match-any) 18 packets, 1224 bytes

5 minute offered rate 0 bps, drop rate 0 bps Match: any

Note

Next, check the CEF-exceptions subinterface statistics. There is a lot of packets matching this sub-interface as all non-IP keepalives, CDP packets, non-IP multicast hit this interface.

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

18

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Rack1R3#show policy-map control-plane cef-exception

Control Plane Cef-exception

Service-policy input: CEF_EXCEPTION_RATE_LIMIT

Class-map: class-default (match-any)

537 packets, 38156 bytes

5 minute offered rate 0 bps, drop rate 0 bps Match: any police:

rate 100 pps, burst 20 packets conformed 537 packets; actions:

transmit exceeded 0 packets; actions:

drop conformed 1 pps, exceed 0 pps

Note

There is just one packet recorded for the transit control-plane subinterface. This packet was generated when we were pinging off R1 across R3 and the firewall attempted to resolve the IP to MAC mapping for R2.

firewall attempted to resolve the IP to MAC mapping for R2. Rack1R3#show policy-map control-plane transit Control

Rack1R3#show policy-map control-plane transit

Control Plane Transit

Service-policy input: TRANSIT_RATE_LIMIT

Class-map: FRAGMENTS (match-all)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps Match: access-group name FRAGMENTS police:

rate 1000000 pps, burst 200000 packets conformed 0 packets; actions:

transmit exceeded 0 packets; actions:

drop conformed 0 pps, exceed 0 pps

Class-map: class-default (match-any)

1 packets, 114 bytes

5 minute offered rate 0 bps, drop rate 0 bps Match: any

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

19

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

6.2 BGP Generic TTL Security Mechanism

Configure eBGP session between R1 and R2 and make both routers accept the peer if it’s no more than one hop away.

Use the AS numbers 100 and 200 for R1 and R2 respectively.

Configuration

Note

General TTL Security Mechanism (GTSM) defined in RFC 3682 specifies a protection method against BGP session hijacking and resource exhaustion attacks. Generally, BGP process listens on the TCP port 139 and accepts all TCP SYN packets destined to this port, unless they are filtered by an ACL. It is possible to generate a barrage of spoofed packets imitating a valid BGP session and inject false information (if the session is unauthenticated) or generate a TCP SYN-flooding attack.

GTSM utilizes the simple fact that every router on the path to the BGP speaker decrements the TTL field in IP packets by one. Based on this, it is possible to identify potentially spoofed packets by looking at their TTL field – the packets send from “afar” will have the TTL field below some threshold. It is possible to define a “secure radius” in the number of hop counts to accept the incoming IP packets. For example, if all BGP peers are within 10 hops away from the local BGP speaker, then all incoming IP packets will have their TTL field set to at no less than 245. This is because all IP packets start with TTL=255 and the field is decremented by every hop on the path. Thus, by accepting the IP packets with TTL greater than or equal to 245 it is possible to minimize the risk of spoofed packets reaching the BGP process. Notice that the usefulness of GTSM feature decreases as the diameter of eBGP Multihop session grows.

decreases as the diameter of eBGP Multihop session grows. In order to configure the TTL securi

In order to configure the TTL security checks for a BGP peer use the command neighbor <IP> ttl-security hops <hop-count>. This command applies to eBGP peering sessions only (either directly-connected or multihop) and specifies the number of hops the remote peer could be away from the local speaker. Keep in mind the internal BGP sessions are not protected, and therefore the internal network assumed to be “trusted”. All packets incoming TCP packets targeted at BGP port with the IP TTL value below (255 - <hop-count>) are silently discarded by the router. In addition, the feature sets TTL value for outgoing TCP/IP packets to 255-<hop-count> to make sure the remote peer will accept the local packets. The GTSM feature is mutually exclusive with the ebgp- multihop BGP feature. This is because the eBGP session by default sets TTL=1 in the outgoing IP packets and with the multihop <n> session

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

20

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

parameter, the TTL value is set to <n>, which is not compatible with GTSM Therefore, make sure you configured GTSM feature on both sides of the peering link.

R1:

router bgp 100 neighbor 136.1.23.2 remote-as 200 neighbor 136.1.23.2 ttl-security hops 2

R2:

router bgp 200 neighbor 136.1.13.1 remote-as 100 neighbor 136.1.13.1 ttl-security hops 2

Verification

Note

Check the TTL settings for every peer. Notice the minimum incoming TTL of 253 in the peer properties.

the minimum incoming TTL of 253 in the peer properties. Rack1R2# show ip bgp neighbors 136.1.13.1

Rack1R2#show ip bgp neighbors 136.1.13.1 | inc TTL

Connection is ECN Disabled, Mininum incoming TTL 253, Outgoing TTL 255

Rack1R1#show ip bgp neighbors 136.1.23.2 | include TTL

Connection is ECN Disabled, Mininum incoming TTL 253, Outgoing TTL 255

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

21

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

6.3 BGP Prefix Limit

Configure R1 so that it does not accept more than ten prefixes from R2.

A warning message should be generated once 6 prefixes have been received.

When the maximum limit is exceeded, do not tear down the connection, just generate a warning message.

Configuration

Note

Filtering based on maximum-prefix number is an important BGP security feature. The number of BGP prefixes in the Internet is many hundred of thousands. It’s is possible to overwhelm a BGP speaker’s table by injecting too many prefixes and putting too much stress on router’s CPU or memory. Cisco IOS supports special feature that limits the maximum number of prefix received over a BGP session. The command is neighbor <IP> maximum-prefix <Number> [<Threshold%>] [warning-only]|[restart <minutes>].

[warning-only]|[restart <minutes>] . The router by default permanently shut s down the session

The router by default permanently shuts down the session that exceeds the maximum-prefix limit specified by the <Number> parameter. The <Threshold%> value specifies the percent value applied to <Number> to generate a warning syslog message. The default threshold is 75%. For example if the prefix limit is 1000 then warning message is generated once 750 prefixes have been learned from this neighbor.

If you don’t want the session to be shut-down once the maximum prefix number has reached, you can specify the warning-only keyword. This instruct the router to generate two warning messages: once for 75%*<Maximum> number of prefixes and once the <Maximum> has been crossed. Another option is using the restart <minutes> parameter. With this option set, the router will tear down the session once it reaches the maximum threshold, but will restore it after the number of <minutes> has passed.

R1:

router bgp 100 neighbor 136.1.23.2 maximum-prefix 10 50 restart 5

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

22

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Verification

Note

Start verifications by checking the maximum number of prefixes configured for R2 in R1.

Rack1R1#show ip bgp neighbors 136.1.23.2 | beg Maximum

Maximum prefixes allowed 10 Threshold for warning message 50%, restart interval 5 min

Note

Now configure R2 with new Loopback addresses (10 in total) and advertise all R2 subnets into BGP.

R2:

interface Loopback101 ip address 10.1.101.1 255.255.255.0

!

interface Loopback102 ip address 10.1.102.1 255.255.255.0

!

interface Loopback102 ip address 10.1.102.1 255.255.255.0 ! interface Loopback103 ip address 10.1.103.1 255.255.255.0 !

interface Loopback103 ip address 10.1.103.1 255.255.255.0

!

interface Loopback104 ip address 10.1.104.1 255.255.255.0

!

interface Loopback105 ip address 10.1.105.1 255.255.255.0

!

interface Loopback106 ip address 10.1.106.1 255.255.255.0

!

interface Loopback106 ip address 10.1.106.1 255.255.255.0

!

interface Loopback107 ip address 10.1.107.1 255.255.255.0

!

interface Loopback108 ip address 10.1.108.1 255.255.255.0

!

interface Loopback109 ip address 10.1.109.1 255.255.255.0

!

interface Loopback110 ip address 10.1.110.1 255.255.255.0

!

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

23

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

router bgp 200 redistribute connected

Note

Check the messages that appear on R1’s console. First, there is a warning message generated when the warning threshold is crossed. Next, when there is 11 prefixes received, the peering session is torn down with a notification message.

%BGP-4-MAXPFX: No. of prefix received from 136.1.23.2 (afi 0) reaches 6, max 10 %BGP-3-MAXPFXEXCEED: No. of prefix received from 136.1.23.2 (afi 0): 11 exceed limit 10

%BGP-5-ADJCHANGE: neighbor 136.1.23.2 Down BGP Notification sent %BGP-3-NOTIFICATION: sent to neighbor 136.1.23.2 3/1 (update malformed)

0 bytes

0101 0240 0204 0201 00C8 4003 0488 0117 0280 0404 0000 0000 1896 0102 180A 0165 180A 0166 180A 0167 180A 016C 180A 016D 180A 016E 180A 0168 180A 0169 180A 016A 180A 016B 1888 0117

FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0060 0200 0000 1940

FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0060 0200 0000 1940 Accessed by rohitpardasani@hotmail.com from

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

24

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

6.4 Selective Packet Discard

Enable Selective Packet Discard on R1 in aggressive mode.

Increase R1’s input queue size on its link to VLAN 13 to twice the default.

Increase the amount of the memory headroom for IGP packets to 150 buffers.

The headroom for BGP packets should be set to 120 packets.

Start dropping low-priority packets randomly when the input queue is 50% full.

Configuration

Note

Selective Packet Discard is the queue management technique for interface input queueing. The SPD commands are hidden in the IOS parser, but you can see them in the running configuration once you enter them. By default SPD is enabled in Normal mode. The following is the list of SPD commands:

in Normal mode. The following is the list of SPD commands: spd enable spd headroom <N>

spd enable spd headroom <N> spd extended-headroom <N> ip spd mode aggressive ip spd queue max-threshold <N> ip spd queue min-threshold <N>

Every physical interface has an input FIFO queue. The router uses this queue to buffer packets going to the route processor. Usually these packets include control plane packets, such as Layer 2 Keepalives (e.g. HDLC/PPP keepalives), IGP packets (OSPF, ISIS, etc.) and BGP packets. The routing protocol packets are classified based on their default IP precedence of 6 or higher. In addition to control plane packets, the input queue holds other packets destined to the route processor, such as packets with an expired TTL, wrong header length, wrong checksum, or non-existent local UDP port numbers. The latter packets are malformed, in the sense that they require the router to generate an ICMP error message in response. Lastly the input queue holds packets that are to be process-switched, which is uncommon on modern CEF-based systems.

SPD input queueing is desirable for a number of reasons. The first is for control plane security. It’s possible to block the router’s input queue with a high rate of malformed packets, which effectively blocks legitimate routing traffic. The result is a control plane DoS against the router. The next reason is for layer 2 keepalive, IGP, and BGP traffic separation.

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

25

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Large BGP tables generate considerably large updates. These updates could potentially block the input queue for some time, preventing the router from receiving keepalive packets or IGP updates. This may result in IGP adjacency flapping or layer 2 link loss reports. The third reason is due to issues with process switching.

If for some reason CEF is disabled, the IP INPUT process can result in regular IP traffic blocking the input queues, causing a loss of the control plane. SPD prevents this through input drops.

So how does SPD work? First, the input queue consists of two parts. One part is the regular hold queue, which is visible through show interface command, and the other part is the priority queue, which stores routing updates and keepalives. The processor serves the priority queue first until it is empty, and then switches to the regular hold-queue. Additionally, the priority queue consists of two parts, the SPD Headroom and the SPD Extended Headroom. The Extended Headroom queue is emptied before the SPD Headroom in a priority manner. Specifically input packets are queued as follows.

Layer 2 keepalives and IGP packets go to the SPD Extended Headroom. If there is no space available in the SPD Extended Headroom, packets go to the SPD Headroom. As a last resort, if both the Extended Headroom and Headroom are full, these packets go to the regular Hold Queue. BGP updates go directly to SPD Headroom. If the SPD Headroom is full, BGP packets hit the Hold Queue. All other IP packets (malformed or process-switched) go to the Hold Queue. The result is that L2 Keepalive/IGP packets are serviced first, BGP next, and other packets last.

are serviced first, BGP next, and other packets last. Although the Hold Queue is FIFO, it

Although the Hold Queue is FIFO, it uses the RED drop procedure. Two thresholds (Minimum and Maximum) set for hold queue define the random drop behavior. If the current hold queue length is less than the Minimum Threshold, packets are never dropped. If the queue length grows beyond Minimum, but is less than Maximum, every new packet is randomly dropped with the probability proportional to queue depth:

Prob = (QueueDepth MinimumThresh)/(MaximumThresh-MinimumThresh)

If the queue depth is above Maximum Threshold, SPD drops every new incoming packet. See the figure below for an illustration using the SPD default values:

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

26

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Note the important fact that SPD thre sholds are global for all queues. SPD computes
Note the important fact that SPD thre sholds are global for all queues. SPD computes
Note the important fact that SPD thre sholds are global for all queues. SPD computes
Note the important fact that SPD thre sholds are global for all queues. SPD computes

Note the important fact that SPD thresholds are global for all queues. SPD computes Min and Max thresholds based on the lowest hold-queue size in the system. Therefore if you set the hold queue size lower on some interfaces, you will affect all other interface drop thresholds.

you will affect all other interface drop thresholds. Lastly, SPD has two modes of operati on,
you will affect all other interface drop thresholds. Lastly, SPD has two modes of operati on,

Lastly, SPD has two modes of operation, normal and aggressive. They differ in their treatment of malformed packets (packets that require the router to generate ICMP responses). When SPD is set for normal mode (the default) it treats malformed packets as it would all regular IP packets. It places them in the hold queue, subject to random drop. However, in aggressive mode, the malformed packets are dropped as soon as the hold queue grows above the minimum threshold. Effectively, SPD Aggressive mode replaces the random drop for malformed packets with an unconditional drop. SPD configuration can be verified as follows.

R1:

spd extended-headroom 150 spd headroom 120 ip spd mode aggressive

ip spd queue max-threshold 150 ip spd queue min-threshold 75

!

interface FastEthernet 0/0

hold-queue 150 in

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

27

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Verification

Note

Check the input queue size and the SPD settings using the following show commands:

Rack1R1#show interface fastEthernet 0/0

FastEthernet0/0 is up, line protocol is up Hardware is AmdFE, address is 000d.659b.9140 (bia 000d.659b.9140) Internet address is 136.1.13.1/24 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never

Last clearing of "show interface" counters never Input queue: 3/150/0/0 (size/max/drops/flushes); Total

Input queue: 3/150/0/0 (size/max/drops/flushes); Total output drops:

0

Queueing strategy: fifo Output queue: 0/40 (size/max) <snip>

Rack1R1#show ip spd

Current mode: normal.

<snip> Rack1R1#show ip spd Current mode: normal. Queue min/max thresholds: 75/150, Headroom: 120, Extended

Queue min/max thresholds: 75/150,

Headroom: 120, Extended Headroom: 150

IP normal queue: 2, priority queue: 0.

SPD special drop mode:

aggressively drop bad packets

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

28

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

6.5 Terminal Lines Security

Configure R3 to allow only telnet connections to VTY lines 0 through 4 without using an access-list.

When a user is telnetted into R3 and mistypes a command in exec mode, R3 should not try to open a telnet session to the command as if it was a hostname.

Configure VTY line 0 to listen for telnet at port 3001.

When the virtual terminal line is busy issue the output “Sorry, the line is already in use” to the connecting user.

Exec sessions on a VTY line should timeout after 2 minutes of inactivity; additionally a user should not be able to hold the line busy for more than 5 minutes.

Sessions initiated from a VTY line should time out in 1 minute.

When the console line is idle the user should see the output “Welcome to IOS”

Allow no more than 1 session to be initiated from the console line.

Allow a user to lock VTY terminal lines.

console line. • Allow a user to lock VTY terminal lines. Configuration Note IOS supports multiple

Configuration

Note

IOS supports multiple timeout settings for terminal sessions, which can be divided as follows. Absolute – limits the maximum amount of time the user could spend on the line. Exec – limits the time an exec shell can be idle. Session – the maximum amount of time a session opened from terminal (e.g. telnet to other router) could be idle.

A

refuse message is displayed when someone tries to connect to a line already

in

use. The vacant message is displayed when the current line is idle (not in use,

e.g. no exec shell started).

The transport input/output option specifies which protocols can be used to connect to/from the terminal line. The preferred transport protocol is used when no session protocol is specified at exec prompt and a station name is typed. By default the preferred transport is telnet, which is why the router tries to telnet when a command is mistyped.

The lock feature allows a user to lock the current terminal session and require a password to unlock it.

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

29

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

R3:

line vty 0 4 session-timeout 1 exec-timeout 2 0 lockable absolute-timeout 5 refuse-message # Sorry, the line is already in use

#

length 20 transport preferred none transport input telnet

!

line vty 0 rotary 1

!

line console 0 session-limit 1

vacant-message # Welcome to IOS

#

console 0 session-limit 1 vacant-message # Welcome to IOS # Accessed by rohitpardasani@hotmail.com from 115.240.81.217

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

30

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Verification

Note

Check the terminal line settings using the following “show” command.

Rack1R3#show line vty 0

Tty Typ

130 VTY

Tx/Rx

A Modem Roty AccO AccI -

-

-

-

-

Uses

10

Noise Overruns

0

0/0

Int

Line 130, Location: "", Type: ""

0 0/0 Int Line 130, Location: "", Type: "" Length: 20 lines, Width: 80 columns Baud

Length: 20 lines, Width: 80 columns

Baud rate (TX/RX) is 9600/9600 Status: Ready, No Exit Banner

Capabilities: Lockable

Modem state: Ready Group codes: 0 Special Chars: Escape Hold Stop Start Disconnect Activation -

- Timeouts: Idle EXEC Idle Session Modem Answer Session Dispatch

^^x

none

none

00:02:00

00:01:00

00:05:00

not set

-

Idle Session Disconnect Warning never Login-sequence User Response

00:00:30

Warning never Login-sequence User Response 00:00:30 Autoselect Initial Wait not set Modem type is unknown.

Autoselect Initial Wait not set

Modem type is unknown. Session limit is not set. Time since activation: never Editing is enabled. History is enabled, history size is 20. DNS resolution in show commands is enabled Full user help is disabled

Allowed input transports are telnet.

 

Allowed output transports are lat pad v120 lapb-ta mop telnet rlogin ssh.

Preferred transport is none.

 

No output characters are padded No special data dispatching characters

Rotary groups allow bundling multiple lines into a pool and to give the option to access the pool using the dedicated TCP port number 3000+N, where N is the rotary group number. Those special port numbers can also be used as “backdoors” for telnet access. Note that the refuse message is displayed when a user attempts to connect to the busy line.

Rack1R3#telnet 150.1.3.3 3001

Trying 150.1.3.3, 3001

Open

User Access Verification

Password: cisco

Rack1R3>telnet 150.1.3.3 3001

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

31

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Trying 150.1.3.3, 3001

Open

Sorry the line is already in use

[Connection to 150.1.3.3 closed by foreign host]

The console session limit can be verified as follows.

Rack1R3#telnet 150.1.2.2

Trying 150.1.2.2

Open

User Access Verification

Password: cisco

Rack1R2>Ctrl-Shift-6-x

Rack1R3#telnet 150.1.5.5

Session limit exceeded

Rack1R3#w

 

Conn Host

Address

Byte Idle Conn Name

*

1 150.1.2.2

150.1.2.2

0

0 150.1.2.2

Name * 1 150.1.2.2 150.1.2.2 0 0 150.1.2.2 To verify session locking login in via telnet

To verify session locking login in via telnet and issuing the lock command.

Rack1R3#telnet 150.1.3.3

Trying 150.1.3.3

Open

User Access Verification

Password: cisco

Rack1R3>lock

Password: cisco Again: cisco

<snip>

Locked
Locked

Rack1R3#telnet 150.1.3.3

Trying 150.1.3.3

Open

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

32

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Verify that setting the preferred transport to “none” disables automatic telnet sessions opening for hostnames entered in the CLI as follows.

User Access Verification

Password: cisco

Rack1R3>hostname

^

% Invalid input detected at '^' marker.

Check the vacant message for the console line as follows.

Rack1R3#exit

<snip>

Welcome to IOS

line as follows. Rack1R3#exit <snip> Welcome to IOS Accessed by rohitpardasani@hotmail.com from 115.240.81.217

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

33

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

6.6 TCP Keepalives

Configure R1 so that it’s capable of detecting dead TCP connections and closing them prematurely.

Configuration

Note

The TCP keepalive feature is useful for probing idle connection to see if they are still active. In some cases, such as when the exec-timeout feature is disabled on VTY lines, this helps to prevent resources starvation by freeing connections that are not active anymore.

R1:

service tcp-keepalives-out service tcp-keepalive-in

Verification

tcp-keepalives-out service tcp-keepalive-in Verification Note To test this scenario, initiate a connection from R3

Note

To test this scenario, initiate a connection from R3 to R1 and verify its parameters. Note the keepalive fields in the TCP Connection Block output.

Rack1R6#telnet 136.1.13.1

Trying 136.1.13.1

Open

User Access Verification

Password:

Rack1R1>

Rack1R1#show tcp brief all

TCB

Local Address

849905B4 136.1.13.1.23

8551BA24 *.80

Foreign Address

136.1.13.3.17316

*.*

(state)

ESTAB

LISTEN

Rack1R1#show tcp tcb 849905B4

Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255 Local host: 136.1.13.1, Local port: 23 Foreign host: 136.1.13.3, Foreign port: 17316

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

34

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Event Timers (current time is 0x1BE3ED2):

Timer

Starts

Wakeups

Next

Retrans

4

0

0x0

TimeWait

0

0

0x0

AckHold

5

2

0x0

SendWnd

0

0

0x0

KeepAlive

7

0

0x1BECF6D

GiveUp

0

0

0x0

PmtuAger

0

0

0x0

DeadWait

0

0

0x0

iss: 3817118842 snduna: 3817118922 sndnxt: 3817118922 sndwnd:

4049

irs: 2400837743 rcvnxt: 2400837781 rcvwnd: 4091 delrcvwnd:

37

SRTT: 124 ms, RTTO: 1405 ms, RTV: 1281 ms, KRTT: 0 ms minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 200 ms Flags: passive open, active open, retransmission timeout,

keepalive running

IP Precedence value : 0

Datagrams (max data segment is 1460 bytes):

Rcvd: 11 (out of order: 0), with data: 7, total data bytes: 37 Sent: 10 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 7, total data bytes: 79

Rack1R1#

Congestion: 0), with data: 7, total data bytes: 79 Rack1R1# Debug TCP transactions on R1 and

Debug TCP transactions on R1 and then shut down the switch-port connected to R6 to simulate a dead connection. Note that after four keepalives have been missed R1 forcefully closes the idle connection.

Rack1R1#debug ip tcp transactions

Rack1SW2#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Rack1SW2(config)#int fastEthernet 0/3

Rack1SW2(config-if)#shutdown

Rack1R1#

TCP66: keepalive timeout (0/4)

Rack1R1#

TCP66: keepalive timeout (1/4)

Rack1R1#

TCP66: keepalive timeout (2/4)

Rack1R1#

TCP66: keepalive timeout (3/4)

Rack1R1#

TCP66: keepalive timeout (4/4)

 

TCP66: state was ESTAB -> CLOSED [23 -> 136.1.13.3(17316)]

TCB 0x849905B4 destroyed

 

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

35

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

6.7 SNMPv2 Server

Configure SNMP on R3 with the SNMP contact set to “Default Contact” and the SNMP Location to “Default Location”.

Enable the SNMP server service using the community string value of CISCO so that remote hosts can modify the local MIB database.

Allow the system to be reloaded via SNMP.

Ensure that interface index numbers persist between reloads.

Only allow configuration transfers via TFTP to/from the host 10.0.0.100.

Configuration

Note

By default when you configure the SNMP agent with a community string, SNMPv2c is used. This version uses only the community string for authentication. Issuing the snmp-server community command is the minimal configuration needed to enable the devices to be polled via SNMP. The read- write string allows the management station to make changes to the managed device, as opposed to the read-only string.

to the managed device, as opposed to the read-only string. SNMP interface index (IfIndex) values are

SNMP interface index (IfIndex) values are not being the same between reloads by default. This may confuse some network management systems (NMS), as interfaces are identified by the IfIndex value in the SNMP Management Information Base (MIB). To resolve this the SNMP IfIndex persistence feature may be helpful.

To allow the NMS to reload the managed device, read-write access must be allowed, and the snmp-server system-shutdown feature must be enabled.

The TFTP server list specifies the acceptable addresses to download/upload the router’s configuration when instructed via SNMP. In recent IOS versions, the command has been replaced with the command snmp-server file- transfer access-group. The IOS still accepts the old command though, but converts it to the new format.

R3:

snmp-server community CISCO RW snmp-server location Default Location snmp-server contact Default Contact snmp-server ifindex persist snmp-server system-shutdown

!

access-list 98 permit 155.1.146.100 snmp-server tftp-server-list 98

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

36

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Verification

Note

Use the following show commands to verify your configuration for this scenario:

Rack1R3#show snmp

Chassis: 26388555

Contact: Default Contact

Contact: Default Contact Location: Default Location
Location: Default Location

Location: Default Location

0

SNMP packets input

 

0

Bad SNMP version errors

0

Unknown community name

0

Illegal operation for community name supplied

0

Encoding errors

0

Number of requested variables

0

Number of altered variables

0

Get-request PDUs

0

Get-next PDUs

0

Set-request PDUs

0

Input queue packet drops (Maximum queue size 1000)

0

SNMP packets output

0

Too big errors (Maximum packet size 1500)

0

No such name errors

0 No such name errors

0

Bad values errors

0

General errors

0

Response PDUs

0

Trap PDUs

SNMP logging: disabled

Rack1R3#show snmp community

Community name: ILMI Community Index: cisco0 Community SecurityName: ILMI storage-type: read-only active

Community name: CISCO

 

Community Index: cisco3

 

Community SecurityName: CISCO

storage-type: nonvolatile

active

Rack1R3#show snmp mib ifmib ifindex

Ethernet0/0: Ifindex = 1 Loopback0: Ifindex = 7 Null0: Ifindex = 6 Serial0/0: Ifindex = 3 VoIP-Null0: Ifindex = 5 Ethernet0/1: Ifindex = 2 Serial0/1: Ifindex = 4

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

37

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

6.8 SNMPv2c Access Control

Configure R3 to restrict read-write access to only hosts in VLAN 13.

Log any other SNMP access attempts using the community string “CISCO”.

Allow any host to access R3’s MIBs in read-only mode using the community string “PUBLIC”.

Read-only access should be permitted to the “cisco” MIB subtree only.

Configuration

Note

It is highly advisable to limit access to managed SNMP devices by associating an access-list with the SNMP server community. By using the log keyword it is possible to expose other hosts that attempt to access the router via SNMP.

Additionally SNMPv2 allows the restricting of access to certain MIB values using the concept of views. A view is partition of the whole MIB tree built by including or excluding various subtrees. Note that view definition may have multiple include/exclude statement, and the latter ones take preference.

subtrees. Note that view definition may have multiple include/exclude statement, and the latter ones take preference.

R3:

access-list 99 permit 136.1.13.0 0.0.0.255 access-list 99 deny any log

!

snmp-server view ROVIEW cisco included snmp-server community CISCO RW 99 snmp-server community PUBLIC view ROVIEW ro

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

38

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Verification

Note

Use the following show commands to verify this scenario:

Rack1R3#show snmp community

Community name: ILMI Community Index: cisco0 Community SecurityName: ILMI storage-type: read-only active

Community name: CISCO Community Index: cisco4 Community SecurityName: CISCO

storage-type: nonvolatile

active

access-list: 99

Community name: PUBLIC Community Index: cisco5 Community SecurityName: PUBLIC storage-type: nonvolatile active
Community name: PUBLIC
Community Index: cisco5
Community SecurityName: PUBLIC
storage-type: nonvolatile
active
Rack1R3#show snmp view

*ilmi system - included permanent active *ilmi atmForumUni - included permanent active

ROVIEW cisco - included nonvolatile active

v1default iso - included permanent active v1default internet.6.3.15 - excluded permanent active v1default internet.6.3.16 - excluded permanent active v1default internet.6.3.18 - excluded permanent active v1default ciscoMgmt.394 - excluded permanent active v1default ciscoMgmt.395 - excluded permanent active v1default ciscoMgmt.399 - excluded permanent active v1default ciscoMgmt.400 - excluded permanent active

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

39

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

6.9 SNMP Traps and Informs

Configure R3 to send SNMP traps to the management host 10.0.0100 and informs to the host 10.0.0.200.

Only send notifications about interfaces going up or down.

Ensure no informs are being sent about FastEthernet interface changing status.

Use the community value of “CISCO” with the above traps and informs.

Configuration

Note

SNMP traps are part of SNMPv1 and SNMPv2 specifications. Additionally SNMPv2 allows sending notifications as informs, which differ from traps in that they require acknowledgement from the NMS. Informs are kept in router local queue until they are acknowledged or timeout has expired. Informs make SNMP reliable even though the transport protocol is still UDP.

reliable even though the transpor t protocol is still UDP. The traps which are to be

The traps which are to be sent can be configured either globally or on a per-host basis. In the latter case the host settings override the global settings. Some traps however can only enabled globally, such as link up and down notifications.

If the single command snmp-server enable traps is entered, all traps will

be sent to all configured destinations, unless they are overridden on a per-host basis. Note that it is required to configure both the snmp-server enable traps and the snmp-server host commands in order to send notifications to

a particular host.

Informs sending is enabled by default, and the same notifications configured with the global snmp-server enable traps command are sent to NMS hosts, provided that they are configured for informs. The same host may receive informs and traps in parallel, though this configuration is uncommon.

R3:

snmp-server enable traps snmp linkdown linkup snmp-server host 10.0.0.200 inform version 2c CISCO snmp-server host 10.0.0.100 CISCO

!

interface FastEthernet0/0 no snmp trap link-status

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

40

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Verification

Note

Check the SNMP traps destinations:

Rack1R3#show snmp host

Notification host: 10.0.0.200 udp-port: 162

type: inform

user: CISCO security model: v2c

 

Notification host: 10.0.0.100 udp-port: 162

type: trap

 

user: CISCO security model: v1

 

To verify SNMP trapping, enable SNMP packet debugging and create a link down event.

Rack1R3#debug snmp packet

SNMP packet debugging is on

Rack1R3#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Rack1R3(config)#interface FastEthernet 0/0

End with CNTL/Z. Rack1R3(config)#interface FastEthernet 0/0 Rack1R3(config-if)#shutdown Rack1R4(config-if)# SNMP: Inform

Rack1R3(config-if)#shutdown

Rack1R4(config-if)#

SNMP: Inform request, reqid 17, errstat 0, erridx 0

sysUpTime.0 = 2019043 snmpTrapOID.0 = snmpTraps.3 ifIndex.1 = 1 ifDescr.1 = Ethernet0/0 ifType.1 = 6

lifEntry.20.1 = administratively down

lifEntry.20.1 = administratively down

lifEntry.20.1 = administratively down 155.1.146.101.162
lifEntry.20.1 = administratively down 155.1.146.101.162
155.1.146.101.162

155.1.146.101.162

Packet sent via UDP to

SNMP: Queuing packet to 155.1.146.100

SNMP: V1 Trap, ent snmpTraps, addr 155.1.146.4, gentrap 2, spectrap 0

ifIndex.1 = 1 ifDescr.1 = Ethernet0/0 ifType.1 = 6

lifEntry.20.1 = administratively down

Jul 18 02:24:36.590: SNMP: Packet sent via UDP to

155.1.146.100

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

41

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

6.10 CPU and Memory Thresholds

Configure R3 to monitor CPU usage every 5 seconds using the process cpu command, and to generate a rising threshold event every time the CPU usage hits 50%.

Set up the free memory low threshold to 1000Kbytes, and reserve 512Kbytes of memory for the notification process using the memory command.

Configuration

Note

CPU threshold notification allows sending SNMP traps and/or informs when the CPU usage crosses defined boundaries. A trap could be generated on the CPU value crossing the rising threshold (going above) or the falling threshold (going below). Additionally the memory threshold notification feature will post a syslog message when the amount of free memory shrinks below a defined limit.

To verify CPU threshold tracking enable SNMP packet debugging and set the CPU rising threshold to a very low value. After that, execute the show run command to cause a CPU spike.

that, execute the show run command to cause a CPU spike. R3: snmp-server enable traps cpu

R3:

snmp-server enable traps cpu threshold

!

memory free low-watermark processor 1000 process cpu threshold type total rising 50 interval 5 memory reserve critical 512

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

42

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Verification

Note

Enable SNMP packets debugging and generate some load on the CPU, e.g. by executing the “show run” command. Notice the inform generated by R3.

Rack1R3#debug snmp packet Rack1R3#conf t Rack1R3(config)#process cpu threshold type total rising 5 interval 5

Rack1R3(config)#^Z

Rack1R3#sh run

Building configuration

Current configuration : 2493 bytes

%SYS-1-CPURISINGTHRESHOLD: Threshold: Total CPU

 

Utilization(Total/Intr): 32%/0%, Top 3 processes(Pid/Util): 3/31%,

91/0%, 2/0%

 
Top 3 processes(Pid/Util): 3/31%, 91/0%, 2/0%   SNMP: Inform request, reqid 21, errstat 0, erridx 0

SNMP: Inform request, reqid 21, errstat 0, erridx 0

sysUpTime.0 = 2146590 snmpTrapOID.0 = ciscoProcessMIB.2.0.1 cpmCPUThresholdTable.1.2.1.1 = 5 cpmCPUTotalTable.1.10.1 = 32 cpmCPUTotalTable.1.11.1 = 0 ciscoProcessMIB.1.2.3.1.5.1.3 = 31 cpmProcessTable.1.5.1.3 = 2146497

SNMP: Packet sent via UDP to 155.1.146.101.162

 

SNMP: Queuing packet to 155.1.146.100

 

SNMP: V1 Trap, ent ciscoProcessMIB.2, addr 155.1.146.4, gentrap 6,

spectrap 1

 

cpmCPUThresholdTable.1.2.1.1 = 5 cpmCPUTotalTable.1.10.1 = 32 cpmCPUTotalTable.1.11.1 = 0 ciscoProcessMIB.1.2.3.1.5.1.3 = 31

Rack1R4#

cpmProcessTable.1.5.1.3 = 2146497

SNMP: Packet sent via UDP to 155.1.146.100

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

43

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

To verify free memory threshold notifications find out the current amount of free processor memory, set the threshold to a high value, and then again to a lower value.

Rack1R3(config)#do show memory summmary

 

Head

Total(b)

Used(b)

Free(b)

Lowest(b) Largest(b)

Processor

6420A860

59725728

14638656

45087072
45087072

44403156

43632028

I/O

7B00000

5242880

1743784

3499096

3499096

3499068

Critical

650EDF74

481976

52

481924

481924

481924

Critical

7C9F640

42312

52

42260

42260

42260

Rack1R3(config)#memory free low-watermark processor 50000

%SYS-4-FREEMEMLOW: Free Memory has dropped below low watermark

%SYS-4-FREEMEMLOW: Free Memory has dropped below low watermark

Pool: Processor Free: 45087396 Threshold: 51200000

%SYS-4-FREEMEMLOW: Free Memory has dropped below low watermark Pool: Processor Free: 45087396 Threshold: 51200000

Rack1R3(config)#memory free low-watermark processor 5000

%SYS-5-FREEMEMRECOVER: Free Memory has recovered above low watermark

%SYS-5-FREEMEMRECOVER: Free Memory has recovered above low watermark

Pool: Processor Free: 45087660 Threshold: 5120000

%SYS-5-FREEMEMRECOVER: Free Memory has recovered above low watermark Pool: Processor Free: 45087660 Threshold: 5120000
Pool: Processor Free: 45087660 Threshold: 5120000 Accessed by rohitpardasani@hotmail.com from 115.240.81.217

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

44

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

6.11 SNMPv3

Create two SNMP views named NORMAL and RESTRICTED on R2.

The NORMAL view should include the branch “iso”.

The RESTRICTED view should include the branch “ifEntry.*.n”, where n is the ifIndex of R2’s FastEthernet interface.

Create an SNMP group named NORMAL with the read/write view assigned to NORMAL, and a security model of “priv”.

Assign the user named NORMAL to this group, set the SHA1 password to CISCO, and the encryption key to CISCO.

Create an SNMP group named RESTRICTED with the read view assigned to RESTRICTED, and a security model of “auth”.

Only users in VLAN 23 should be allowed in the SNMP group RESTRICTED.

Assign the user named RESTRICTED to this group using the security model which only requires authentication using the password CISCO.

Create an SNMP group named TRAP with the security model “priv”.

Assign the user named TRAP to this group using the password and encryption key CISCO.

Enable SNMP traps for LinkUp and LinkDown events only, and send them to the destination host 10.0.0.100 using the security model “priv” and the username TRAP.

using the security model “priv” and the username TRAP. Configuration Note SNMPv3 extends the previous versions

Configuration

Note

SNMPv3 extends the previous versions of SNMP by introducing a new security model that replaces the old community-based authentication system. SMNPv3 also provides for communication privacy by means of encryption. The new concepts for SNMPv3 are the user, group, and security level.

A group defines what access rights a set of users have. This access policy

controls which SNMP objects (MIBs) can be accessed for reading and writing, or which SNMP objects can generate notifications to the members of a group. The policy is defined by associating a read, write, or notify view with the group. By using a notify view, a group determines the list of notifications its users can receive. The group also defines the security model (SNMP version) and the security level (authentication and/or encryption) for its users.

If a group is defined without a read view, all objects are available to be read

(implicit permit). Contrary to that, if a write or notify view is not defined, no write access is granted, and no objects can send notifications to members of the group

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

45

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

(implicit deny). The notify view is usually not configured manually, and is auto- generated by the snmp-server host command when users in a group are bound to a notification target host.

The security models are defined as SNMPv1, SNMPv2, SNMPv3, while the security levels are defined as noAuthNoPriv, AuthNoPriv, and AuthPriv. noAuthNoPriv, the noauth keyword in the IOS, means no authentication and no encryption. AuthNoPriv, the auth keyword in the IOS, means authentication but no encryption. AuthPriv, the priv keyword in IOS, means authentication and encryption.

SNMPv3 can implement any of the three above security levels. SNMPv1 and SNMPv2 only support noAuthNoPriv. In the case that SNMPv3 uses noAuthNoPriv, the username serves as a replacement for the community string. All users sharing a group utilize the same security model, however the specific model settings (password and encryption key) are set per-user. Note that SNMPv3 does not send passwords in clear-text, but instead uses MD5 or SHA1 hash-based authentication. For encryption, statically configured keys are used along with a single-DES (56-bit) symmetric cipher (3DES/AES supported in the latest IOS releases). This means that the same key should be configured on NMS for the particular user. Note that SNMPv3 users do not appear in the running configuration for security reasons.

appear in the running configuration for security reasons. Accessed by rohitpardasani@hotmail.com from 115.240.81.217

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

46

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

R2:

Note

Use the command show snmp mib ifmib ifindex fastEthernet 0/0 to learn the ifIndex of the respective interace. Use the command snmp-server ifindex persist in global configuration mode to preserve the interface indexes between reboots.

access-list 99 permit 136.1.23 0.0.0.255

!

snmp-server ifindex persist snmp-server view NORMAL iso included

snmp-server view RESTRICTED ifEntry.*.1 included

!

snmp-server group NORMAL v3 priv read NORMAL write NORMAL

snmp-server group RESTRICTED v3 auth read RESTRICTED access 99 snmp-server group TRAP v3 priv

!

snmp-server user NORMAL NORMAL v3 auth sha CISCO priv des56 CISCO

snmp-server user RESTRICTED RESTRICTED v3 auth sha CISCO

snmp-server user TRAP TRAP v3 auth sha CISCO priv des56 CISCO

user TRAP TRAP v3 auth sha CISCO priv des56 CISCO ! snmp-server enable traps snmp linkup

!

snmp-server enable traps snmp linkup linkdown snmp-server host 10.0.0.100 traps version 3 priv TRAP

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

47

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Verification

Note

Start verification by checking the SNMPv3 users created in the router.

Rack1R2#show snmp user

User name: TRAP

Engine ID: 80000009030000119221DA80

storage-type: nonvolatile

active

Authentication Protocol: SHA

Privacy Protocol: DES

 

Group-name: TRAP

 

User name: NORMAL

Engine ID: 80000009030000119221DA80

storage-type: nonvolatile

active

Authentication Protocol: SHA

Privacy Protocol: DES

 

Group-name: NORMAL

 

User name: RESTRICTED

active
active

Engine ID: 80000009030000119221DA80

storage-type: nonvolatile

Authentication Protocol: SHA

Authentication Protocol: SHA

Privacy Protocol: None Group-name: RESTRICTED

Authentication Protocol: SHA Privacy Protocol: None Group-name: RESTRICTED

For the TRAP group the notify view is auto-generated by the snmp-server host command, which bound the user (TRAP) and the group it belongs to (TRAP) to the list of notifications which are to be sent to the host.

Rack1R2#show snmp group

groupname: ILMI readview : *ilmi notifyview: <no notifyview specified> row status: active

groupname: ILMI readview : *ilmi notifyview: <no notifyview specified> row status: active

security model:v1 writeview: *ilmi

security model:v2c writeview: *ilmi

groupname: TRAP

security model:v3 noauth

readview : <no readview specified> specified>

writeview: <no writeview

notifyview: *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F

row status: active

groupname: TRAP

security model:v3 priv

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

48

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

readview : v1default specified> notifyview: <no notifyview specified> row status: active

groupname: NORMAL readview : NORMAL notifyview: <no notifyview specified> row status: active

groupname: RESTRICTED readview : RESTRICTED

specified> notifyview: <no notifyview specified>

row status: active

access-list: 99

Rack1R2#show snmp view

writeview: <no writeview

security model:v3 priv writeview: NORMAL

security model:v3 auth writeview: <no writeview

*ilmi system - included permanent active *ilmi atmForumUni - included permanent active

NORMAL iso - included nonvolatile active

v1default iso - included permanent active v1default internet.6.3.15 - excluded permanent active v1default internet.6.3.16 - excluded permanent active v1default internet.6.3.18 - excluded permanent active v1default ciscoMgmt.394 - excluded permanent active v1default ciscoMgmt.395 - excluded permanent active v1default ciscoMgmt.399 - excluded permanent active v1default ciscoMgmt.400 - excluded permanent active

active v1default ciscoMgmt.400 - excluded permanent active RESTRICTED ifEntry.0.3 FF:EF included nonvolatile active

RESTRICTED ifEntry.0.3 FF:EF included nonvolatile active

 

*tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F iso.2.840.10036 - included volatile

active

 

*tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F internet - included volatile active

To ensure that SNMP traps are being sent in encrypted and authenticated, enable SNMP packet debugging along with a low-level packet dump for outgoing SNMP traps as follows.

Rack1R2(config)#access-list 100 permit udp any any eq 162 Rack1R2#debug ip packet detail 100 dump

IP packet debugging is on (detailed) (dump) for access list 100

Rack1R2#debug snmp packet

SNMP packet debugging is on

Rack1R2#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Rack1R2(config)#interface loopback 0

Rack1R2(config-if)#shutdown

Rack1R2(config-if)#

SNMP Queuing packet to 10.0.0.100:

SNMP: V2 Trap, reqid 23, errstat 0, erridx 0

sysUpTime.0 = 2893642

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

49

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

snmpTrapOID.0 = snmpTraps.3 ifIndex.11 = 11 ifDescr.11 = Loopback0 ifType.11 = 24

lifEntry.20.11 = administratively down

SNMP: Packet sent via UDP to 10.0.0.100

IP: tableid=0, s=136.1.23.2 (local), d=10.0.0.100 (FastEthernet0/0), routed via RIB

IP: s=136.1.23.2 (local), d=10.0.0.100 (FastEthernet0/0), len 283,

sending

UDP src=58135, dst=162

07802010:

4500011B 00060000

}.0.|

E

0

07802020: FF11605E 9B019206 9B019264 E31700A2 07802030: 01077D80 3081FC02 0103300D 02011202

" dc `^

07802040: 0205DC04 01030201 03043530 33040C80

\

503

07802050: 00000903 00001192 21DA8002 01180202

 

!Z

07802060: 190C0404 54524150 040C3972 C05E1654

TRAP
TRAP

9r@^.T

qx.M

0!3rF.9K.h.}5#

07802090: 584291FA 887D96B8 6894CCE6 58AAD5DD XB.z.}.8h.LfX*U] 078020A0: 5F4EACE4 4B30FB5C 25B58A78 09A78EF0 _N,dK0{\%5.x.'.p

078020B0: 863CEE49 3745902A FEE6530C BAD247DC .<nI7E.*~fS.:RG\

07802070: 7D2249D0 11F10408 00000018 F1F81DCD }"IP.q

07802080: 0481B021 3372C60A 394B07E8 93FD35A3

078020C0: DF94530F E5ED993C FC955C8C 3B42FC15

078020D0: D4C2B05B 8CF2869A FED2EC8E 38570FBB TB0[.r ~Rl.8W.;

S.em.<|.\.;B|.

FED2EC8E 38570FBB TB0[.r ~Rl.8W.; S.em.<|.\.;B|. & 078020F0: EF4CBD1F 34B5E63A 0C05AA56 385B32D2 oL=.45f:

&

078020F0: EF4CBD1F 34B5E63A 0C05AA56 385B32D2 oL=.45f: *V8[2R

078020E0: C1454016 599591C2 D3FA07B1 0D048B26 AE@.Y BSz.1

07802100: E5AB5AB6 F9F722F2 13C5610E 4ADE3FC3 e+Z6yw"r.Ea.J^?C

Ki

07802110: 73F78791 74AED319 5F86D648 74A04BE9

sw

t.S

VHt

07802120: 1CCDAB2E 0D022589 6BFBE813 E613B58C .M+

07802130: 739C66

IP: s=136.1.23.2 (local), d=10.0.0.100 (FastEthernet0/0), len 283, encapsulation failed UDP src=58135, dst=162

07802010:

07802020: FF11605E 9B019206 9B019264 E31700A2 07802030: 01077D80 3081FC02 0103300D 02011202 07802040: 0205DC04 01030201 03043530 33040C80 07802050: 00000903 00001192 21DA8002 01180202 07802060: 190C0404 54524150 040C3972 C05E1654

4500011B 00060000

s.f

E " dc `^

0 }.0.|

\

503

!Z

9r@^.T TRAP

07802070: 7D2249D0 11F10408 00000018 F1F81DCD }"IP.q qx.M

0!3rF.9K.h.}5#

07802090: 584291FA 887D96B8 6894CCE6 58AAD5DD XB.z.}.8h.LfX*U] 078020A0: 5F4EACE4 4B30FB5C 25B58A78 09A78EF0 _N,dK0{\%5.x.'.p 078020B0: 863CEE49 3745902A FEE6530C BAD247DC .<nI7E.*~fS.:RG\

078020C0: DF94530F E5ED993C FC955C8C 3B42FC15

078020D0: D4C2B05B 8CF2869A FED2EC8E 38570FBB TB0[.r ~Rl.8W.;

&

078020E0: C1454016 599591C2 D3FA07B1 0D048B26 AE@.Y BSz.1

07802080: 0481B021 3372C60A 394B07E8 93FD35A3

S.em.<|.\.;B|.

078020F0: EF4CBD1F 34B5E63A 0C05AA56 385B32D2 oL=.45f: *V8[2R 07802100: E5AB5AB6 F9F722F2 13C5610E 4ADE3FC3 e+Z6yw"r.Ea.J^?C

Ki

07802110: 73F78791 74AED319 5F86D648 74A04BE9

07802120: 1CCDAB2E 0D022589 6BFBE813 E613B58C .M+

07802130: 739C66

sw

s.f

t.S

VHt

-if)#

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

50

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Change the security model for the destination host to “noAuth” and generate a trap message again. Note that now the message is not encrypted.

Rack1R2# snmp-server host 10.0.0.100 version 3 noauth TRAP

Rack1R2(config)#interface Loopback 0 Rack1R2(config-if)#no shut

Rack1R2(config-if)#

SNMP: Queuing packet to 10.0.0.100 SNMP: V2 Trap, reqid 24, errstat 0, erridx 0 sysUpTime.0 = 2928473 snmpTrapOID.0 = snmpTraps.4 ifIndex.11 = 11 ifDescr.11 = Loopback0 ifType.11 = 24 lifEntry.20.11 = up

SNMP: Packet sent via UDP to 10.0.0.100

IP: tableid=0, s=136.1.23.2 (local), d=10.0.0.100 (FastEthernet0/0),

routed via RIB

IP: s=136.1.23.2 (local), d=10.0.0.100 (FastEthernet0/0), len 238,

sending

UDP src=58135, dst=162

079D76B0:

079D76C0: FF11608A 9B019206 9B019264 E31700A2

450000EE 00070000

FF11608A 9B019206 9B019264 E31700A2 450000EE 00070000 E n " dc ` 0 079D76D0: 00DA3F33 3081CF02 0103300D

E n " dc `

0

079D76D0: 00DA3F33 3081CF02 0103300D 02011302 .Z?30.O

079D76E0: 0205DC04 01000201 03042130 1F040C80 079D76F0: 00000903 00001192 21DA8002 01180202 079D7700: 1A680404 54524150 04000400 30819704 .h 079D7710: 0C800000 09030000 119221DA 800400A7 079D7720: 81840201 18020100 02010030 79300F06 079D7730: 082B0601 02010103 0043032C AF593017 .+ 079D7740: 060A2B06 01060301 01040100 06092B06 079D7750: 01060301 01050430 0F060A2B 06010201 079D7760: 02020101 0B02010B 3017060A 2B060102 079D7770: 01020201 020B0409 4C6F6F70 6261636B 079D7780: 30300F06 0A2B0601 02010202 01030B02 00 079D7790: 01183012 060C2B06 01040109 02020101 079D77A0: 140B0402 7570 <snip>

!0 \

!Z

TRAP 0 ' !Z 0y0 +. + + 0 + 0 Loopback
TRAP
0
' !Z
0y0
+. +
+ 0
+ 0
Loopback

+

+ 0

up

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

51

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

6.12 RMON Alarms

Configure R1 to monitor the rate of packets entering its interface connecting to VLAN 13 based on the total input packet counter

(ifEntry.11).

If the rate is above 100 packets per minute generate the log message “VLAN13 Interface Congested” and send a trap to the management host at 10.0.0.100.

Use the SNMP community string CISCO.

When the packet rate falls below 50 packets per minute, generate another log message “VLAN13 Interface UnCongested” and send a corresponding trap.

The owner of events should be set to “CISCO”.

Configuration

Note

The Remote Monitoring (RMON) feature is used to monitor specified SNMP MIB variables and generate events (syslog messages or SNMP traps) when a threshold or change threshold is crossed. The common misconception about the RMON feature is the difference between an absolute sampling and a delta sampling.

between an absolute sampling and a delta sampling. An absolute sampling threshold is used fo r

An absolute sampling threshold is used for variables that increase or decrease over time, and have an upper or lower bound for when a log should be generated. Examples of absolute samplings would be CPU utilization, memory utilization, interface queue depth, etc. A delta sampling threshold is used for variables that either constantly increase (most common) or constantly decrease. Examples of delta samplings would be for interface errors, input packets, output bytes, etc.

For example if the CPU utilization is at 60% at interval 1, and increases to 90% at interval 2, it makes more sense to want to know that the CPU utilization is exactly 90% (absolute) versus it having changed 30% (delta) over the interval. On the other hand if we find that at interval 1 the total number of bytes received inbound on an interface is 1000, and at interval 2 the total bytes increases to 10000, it makes more sense to want to know that the inbound link utilization was 9000 bytes per interval (delta) versus having increased to 10000 bytes (absolute). The problem with the absolute sampling in this second case is that there’s no way to tell if those 10000 bytes were received in the last minute or the last month.

RMON configuration consists of defining events and creating an alarm on a known MIB variable. In the presented case, the variable given is a an interface

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

52

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

counter (lifEntry.11) and therefore to get rate from it the delta sampling method is applied. Note that the variable name is based on interface index, so additional steps are needed to discover the interface index and ensure that the indexes are persistent across reboots.

R1:

snmp-server host 10.0.0.100 CISCO snmp-server ifindex persist

!

rmon event 1 log trap CISCO description "VLAN13 Interface Congested" owner CISCO

rmon event 2 log trap CISCO description "VLAN13 Interface UnCongested" owner CISCO

!

rmon alarm 1 ifEntry.11.1 60 delta rising-threshold 100 1 falling- threshold 50 2 owner CISCO

rising-threshold 100 1 falling- threshold 50 2 owner CISCO Accessed by rohitpardasani@hotmail.com from 115.240.81.217

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

53

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

Verification

Note

To verify the configuration enable SNMP packet debugging and generate traffic across VLAN 13 to make sure the counter increases by more than 100 packets.

Rack1R1#debug snmp packet Rack1R1#ping 136.1.13.3 repeat 150

Type escape sequence to abort. Sending 150, 100-byte ICMP Echos to 136.1.13.3, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! <snip> Success rate is 100 percent (150/150), round-trip min/avg/max = 1/2/4 ms

%RMON-5-RISINGTRAP: Rising trap is generated because the value of

%RMON-5-RISINGTRAP: Rising trap is generated because the value of

ifInUcastPkts.1 exceeded the rising-threshold value 100

%RMON-5-RISINGTRAP: Rising trap is generated because the value of ifInUcastPkts.1 exceeded the rising-threshold value 100

Rack1R1#

SNMP: Queuing packet to 10.0.0.100

SNMP: V1 Trap, ent rmon, addr 136.1.13.1, gentrap 6, spectrap 1 alarmEntry.1.1 = 1 alarmEntry.3.1 = ifInUcastPkts.1 alarmEntry.4.1 = 2 alarmEntry.5.1 = 150 alarmEntry.7.1 = 100 SNMP: Packet sent via UDP to 10.0.0.100

alarmEntry.7.1 = 100 SNMP: Packet sent via UDP to 10.0.0.100 Do not send any packets after

Do not send any packets after that, and wait for a minute.

%RMON-5-FALLINGTRAP: Falling trap is generated because the value of

ifInUcastPkts.1 has fallen below the falling-threshold value 50

 

SNMP: Queuing packet to 10.0.0.100

 

SNMP: V1 Trap, ent rmon, addr 136.1.13.1, gentrap 6, spectrap 2 alarmEntry.1.1 = 1 alarmEntry.3.1 = ifInUcastPkts.1 alarmEntry.4.1 = 2 alarmEntry.5.1 = 0 alarmEntry.8.1 = 50 SNMP: Packet sent via UDP to 10.0.0.100

Display the RMON event and alarms configuration information and statistics as follows.

Rack1R1#show rmon events

Event 1 is active, owned by CISCO

Description is VLAN13 Interface Congested Event firing causes log and trap to community CISCO,

last event fired at 0y0w0d,09:39:11,

Current uptime Current log entries:

index uptime

0y0w0d,09:51:22

description

Accessed by rohitpardasani@hotmail.com from 115.240.81.217 at 20:27:21 Nov 23,2009

Copyright © 2009 Internetwork Expert

54

www.INE.com

CCIE Security Lab Workbook Volume I Version 5.0

Ctrl Plane Security

1 0y0w0d,09:39:11

VLAN13 Interface Congested

Event 2 is active, owned by CISCO

Description is VLAN146 Interface UnCongested Event firing causes log and trap to community CISCO, last event fired at 0y0w0d,09:40:12,

Current uptime Current log entries:

0y0w0d,09:51:22

index uptime

description

1 0y0w0d,03:59:10

2 0y0w0d,09:38:11

3 0y0w0d,09:40:12

VLAN13 Interface UnCongested