Telnet Flooding with CoPP
Numerous alternatives exist to protect against attacks on the management plane.
One option is to ensure that only traffic from prevalidated IP addresses is allowed (only allow packets from the management network).
A second option is to implement a CoPP policy to protect the services on the management plane.
In this example, a simple CoPP policy is created to protect Telnet (TCP port 23) and SSH (TCP port 22).
First, create an access list that specifies the traffic we want to inspect:
access-list 170 permit tcp any any eq 22 access-list 170 permit tcp any any eq telnet
Then, create a class map for this traffic:
class-map match-all Mgmt match access-group 170
Then, create a policy map that specifies you want to rate-limit all traffic that matches class map Mgmt to 32,000 bits per second (bps):
policy-map CoPP class Mgmt police cir 32000 bc 1500 be 1500 conform-action transmit exceed-action drop class class-default
In this example, you do not specify any rate limit for other traffic (class-default), which actually leaves openings for other attacks against the control plane/management plane. Using the methodology explained earlier, you need to classify everything you know about and then rate-limit what you don't know about to safe values.
Then, attach the policy map to the control plane:
control-plane service-policy input CoPP
To test this, start your Telnet flooding attack again. After a short while, the CPU load goes from 0 percent to 79 percent!
c6500#sh proc cpu
CPU utilization for five seconds: 79%/73%; one minute: 56%; five minutes: 18%
Chances are, however, that you are no longer seeing any OSPF flapping, but this is not the result you might have expected. Looking at the statistics for the policy map on the control plane interface, you see the following output (see Example 13-11).
Example 13-11 Displaying the Status of CoPP
c6500#sh policy-map control-plane control plane Interface
Service-policy input: CoPP
Hardware Counters:
class-map: Mgmt (match-all) Match: access-group 170 police :
32000 bps 1000 limit 1000 extended limit
Software Counters:
Class-map: Mgmt (match-all)
1502937 packets, 96187968 bytes
5 minute offered rate 2375000 bps, drop rate 2256000 bps
Match: access-group 170
police:
cir 32000 bps, bc 1500 bytes conformed 4347 packets, 278208 bytes; action: transmit exceeded packets, 95912448 bytes; action: drop conformed 14000 bps, exceed 2370000 bps
Looking at the software counters, chances are that you see high values for the Mgmt class map and lots of drops. However, the values for the hardware counters are not displayed. Why not?
As previously explained, it is required to activate MLS QoS before any hardware acceleration takes place:
c6500(config)#mls qos
Looking at the CPU load, you see that it has now gone down to its normal idle load:
c6500#sh proc cpu
CPU utilization for five seconds: 0%/0%; one minute: 1%; five minutes: 2%
Looking at the policy-map statistics for the control plane, you see that the hardware CoPP is now active, as Example 13-12 shows.
Example 13-12 Displaying CoPP Status c6500#sh policy-map control-plane control plane Interface
Service-policy input: CoPP
Hardware Counters:
class-map: Mgmt (match-all) Match: access-group 170 police :
32000 bps 1000 limit 1000 extended limit Earl in slot 5 : 1245535600 bytes
5 minute offered rate 11173896 bps aggregate-forwarded 3368992 bytes action: transmit exceeded 1242166608 bytes action: drop aggregate-forward 32040 bps exceed 11881608 bps
Software Counters:
Class-map: Mgmt (match-all) 49751 packets, 3184064 bytes
5 minute offered rate 30000 bps, drop rate 0 bps
Match: access-group 170
police:
cir 32000 bps, bc 1500 bytes conformed 49783 packets, 3186112 bytes; action: transmit exceeded 0 packets, 0 bytes; action: drop conformed 30000 bps, exceed 0 bps
Class-map: class-default (match-any) 1199 packets, 161889 bytes
5 minute offered rate 1000 bps, drop rate 0 bps Match: any
On line card 5, which is the supervisor line card, there has been many drops, but the traffic forwarded to the central CPU is 32,040 bps, which is close to the value of 32,000, which you already configured.
Looking at the software counters, you see that no packets have been dropped. This is correct behavior if all the attack traffic comes through one line card.
If two attackers had been connected to two line cards, each line card would have rate-limited the attack on each card down to 32,000 bps. However, the sum of the traffic hitting the software CoPP would have been around 64,000 bps. This would have been rate-limited to 32,000 bps using software CoPP (which is done by the central CPU), but the CPU impact would have been minimal.
Continue reading here: TTL Expiry Attack
Was this article helpful?