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

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CPU Protection Mechanisms

Загружено:

Авторское право:

Доступные форматы

CCIE Security V4 Technology Labs Section 1:

System Hardening and Availability

applied to the interface facing R2.

Вам также может понравиться