cpu protection mechanisms

CCIE Security V4 Technology Labs Section 1:System Hardening and Availability

CPU Protection Mechanisms

Last updated: May 3, 2013

Task

Load configurations for this task.

To protect against TTL expiry attacks, which can affect the device CPU, create a policy on R3 that

filters IP packets where the TTL value is less than 5. This should be applied to traffic entering from

R2.

On R3, filter transit traffic that contains any IP options from coming into interface

FastEthernet0/0.23.

Configure R3 so that it will send syslog notifications to the syslog service running on the lab

workstation. The notifications level should be set to level 5.

Configure R1 s0 that 2000 kilobytes of memory is reserved for critical notifications.

Set a threshold of 20000 KB free processor memory before the router issues notifications.

Set a threshold of 20000 KB free I/O memory before the router issues notifications.

Enable CPU rising and falling threshold notifications on R1 as follows: When the total CPU utilization

rises above 80 percent for a period of 5 seconds or longer, a rising threshold notification will be

triggered, and when the total CPU utilization falls below 30 percent for a period of 5 seconds or

longer, a falling threshold notification will be sent. These messages should be sent to the syslog

server on the test PC.

Explanation and Verification

You can use the ACLs for filtering on TTL value. This particular feature was introduced in Cisco IOS

Software Release 12.4(2)T and is implemented in an extended IP access list. The idea is to filter

traffic entering the router where the TTL-value is zero or one, because these can constitute an

attack. You can also use this feature to ensure that the TTL value is not lower that the diameter of

your network. This protects the control plane of downstream infrastructure devices from TTL expiry

attacks.

It's important to understand that some applications and tools use TTL expiry packets for testing and

diagnostic purposes, and some protocols legitimately use a TTL value of one. You'll need to pay

close attention to the traffic that your router is seeing so that you do not to prohibit desired traffic

from entering the router. Let's begin with the configuration on R3.

R3:

We first build a simple ACL to filter any IP packets with a TTL that is less than 5. This is then

applied to the interface facing R2.

R3#conf t

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

R3(config)#ip access-list extended TTY_ACL

R3(config-ext-nacl)# deny ip any any ttl lt 5

R3(config-ext-nacl)# permit ip any any

R3(config-ext-nacl)#

R3(config-ext-nacl)#int FastEthernet0/0.23

R3(config-subif)#ip access-g TTY_ACL in

R3(config-subif)#end

We can now look at the ACL.

R3#sh access-list

Extended IP access list TTY_ACL

10 deny ip any any ttl lt 5 (5 matches)

20 permit ip any any (15 matches)

R3#

Here we see something interesting: Packets are being matched already, and we haven't generated

any specific traffic. We can see what these packets are by enabling logging on the ACL.

R3#conf t



R3(config-ext-nacl)# deny ip any any ttl lt 5 log

It's not long before we see the packets we are dropping. In this case, it's RIP.

*Jan 22 18:40:58.891: %SEC-6-IPACCESSLOGP: list TTY_ACL denied udp 136.1.23.2(0)

-> 224.0.0.9(0), 1

*Jan 22 18:41:03.663: %SEC-6-IPACCESSLOGP: list TTY_ACL denied udp 136.1.23.20(0)

-> 224.0.0.9(0), 1 packet

To see the effect of the ACL, we can look at the routing table. Here we see that our route to R2's

loopback is "possibly down."

R3(config)#do sh ip route

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP

+ - replicated route, % - next hop override

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

C 10.0.0.0/24 is directly connected, FastEthernet0/0.10

L 10.0.0.3/32 is directly connected, FastEthernet0/0.10








R 136.1.99.0/24 [120/1] via 136.1.13.1, 00:00:06, FastEthernet0/0.13

150.1.0.0/24 is subnetted, 2 subnets

R 150.1.1.0 [120/1] via 136.1.13.1, 00:00:06, FastEthernet0/0.13

R 150.1.2.0/24 is possibly down,

routing via 136.1.23.2, FastEt

R3(config)#

Let's now modify the ACL to allow RIP traffic.


R3(config-ext-nacl)#4 permit udp host 136.1.23.2 host 224.0.0.9

R3(config-ext-nacl)#5 permit udp host 136.1.23.20 host 224.0.0.9

R3(config-ext-nacl)#end

R3#

Verify that we are getting hits.

R3#sh access-l

Extended IP access list TTY_ACL

4 permit udp host 136.1.23.2 host 224.0.0.9 (1 match)

5 permit udp host 136.1.23.20 host 224.0.0.9 (2 matches)

10 deny ip any any ttl lt 5 log (23 matches)

20 permit ip any any (15 matches)

R3#

Finally, we should see the route back in the routing table.

R3#sh ip route

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP

+ - replicated route, % - next hop override

Gateway of last resort is not set











R 136.1.99.0/24 [120/1] via 136.1.13.1, 00:00:17, FastEthernet0/0.13

150.1.0.0/24 is subnetted, 2 subnets



R3#

Next we are asked to filter on the presence of IP options. In Cisco IOS Software Release 12.3(4)T

and later, you can use the ACL Support for the Filtering IP Options feature in a named, extended IP

access list. This lets you filter IP packets with IP options present. This will prevent the control plane

of infrastructure devices from having to process these packets at the CPU level. Additionally, the

ACL Support for Filtering IP Options feature can be used only with named, extended ACLs.

Because we are applying this ACL to the same interface as the previous ACL, we just need to

modify what we have. Again on R3...

R3#conf t


R3(config)#ip access-l ext TTY_ACL

R3(config-ext-nacl)#15 deny ip any any option any-options

R3(config-ext-nacl)#

If necessary, you can enhance the level of granularity by filtering on specific options. If you wanted

to filter on packets that contain these options:

0 End of Options List (eool)

7 Record Route (record-route)

68 Time Stamp (timestamp)

131 - Loose Source Route (lsr)

137 - Strict Source Route (ssr)

You could create entries in the ACL such as these:

deny ip any any option eool

deny ip any any option record-route

deny ip any any option timestamp

deny ip any any option lsr

deny ip any any option ssr

permit ip any any

The point is that you can be granular when necessary, but always pay close attention to the lab

requirement.

Next we are asked to send syslog to the test PC at level 5. Configuring syslog should be a natural

task. It's recommended that you spend some extra time understanding how to filter syslog

messages as well. However, this task is very simple. Begin by defining the host to log to, as well as

the level.

R3#conf t


R3(config)#logging host 10.1.0.10

R3(config)#logging trap 5

To test, we can shut down an interface and ensure that it is generating logs to the server.

R3(config)#int f0/1

R3(config-if)#shut

R3(config-if)#no shut

R3(config-if)#

*Jan 23 16:55:06.874: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state t

o administratively downshut

R3(config-if)#

*Jan 23 16:55:11.786: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to

up

On the syslog server, we can see a generated message.

Now we are asked to move to R1 and control the memory. We can do this by enabling CPU and

memory thresholding. This lets us know why something happened and what happened right before

the system gets to the unusable point.

When a router is overloaded by processes, the amount of available memory might fall to levels

insufficient for it to issue critical notifications, so the first step is to reserve some memory for this.

To do so, use the memory reserve critical {kilobytes} command. Next, configure the

amount of free processor memory before the router issues notifications by using the

memory free low-watermark processor {kilobytes} command. Additionally, we should set

the free I/O memory threshold using the memory free low-watermark io {kilobytes}

command.

Begin on R1.

R1:

R1>en

R1#conf t


R1(config)#memory reserve critical 2000

R1(config)#memory free low-watermark processor 20000

R1(config)#memory free low-w io 20000

R1(config)#

Next, enable the CPU rising and ralling threshold notifications.

R1(config)#

R1(config)#process cpu threshold type total rising 80 interval 5 falling 30 inter

val 5

R1(config)#

Jan 23 17:55:14.578: %SYS-4-FREEMEMLOW: Free Memory has dropped below low waterma

rk

Pool: I/O Free: 17885232 Threshold: 20480000

Enable syslog for these messages.

R1(config)#logging trap notifications

R1(config)#logging 10.1.0.10

R1(config)#

The next step takes a little work, but we can test by generating as much traffic as possible to R1.

To do this, we launch a ping from R2, R3, and Sw1, as well as from R1 itself.

R2:

R2>en

R2#ping 136.1.13.1 repeat 100000 size 18024

Type escape sequence to abort.

Sending 100000, 18024-byte ICMP Echos to 136.1.13.1, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

R3:




!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

SW1:

SW1#ping 136.1.13.1 repeat 100000 size 18024



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

R1:

R1#telnet 136.1.13.1

Jan 23 18:21:34.466: %SYS-5-CONFIG_I: Configured from console by console

Trying 136.1.13.1 ... Open

User Access Verification

Password:

Password:

R1>en

Password: cisco




!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Test PC:

When all this traffic is being thrown at R1, you can see the CPU stats rise.

R1:

R1#sh proc cpu | in CPU

CPU utilization for five seconds: 98%/28%; one minute: 76%; five minutes: 37%

R1#

Finally, verify on the syslog server that we are receiving the messages we expect.

cpu protection mechanisms

Documents