Introduction

The Cisco VIP (Versatile Interface Processor) is a "router on a card." It contains a CPU, memory, an IOS image, and all of the necessary structures to perform packet switching. Often used in the Cisco 7513 router, the VIP improves performance by removing the burden of packet processing, in many cases, from the RSP (Route Switch Processor). Because the VIP is a "router on a card" that runs an IOS image, it also has many of the same commands and data structures as the RSP.

NetFlow is a data collection method in Cisco routers that allows router support personnel to trace the flows that pass through the router. NetFlow is often used for performance and trend analysis as well as billing.

Through the use of the undocumented VIP console and NetFlow, a DoS attack may be closely monitored and analyzed. The VIP console can also be used to perform the more routine and mundane router performance checks, such as show proc cpu.

This method has been tested, in the lab and in production (during actual DoS attacks), on a Cisco 7513 router with the VIP2-50 line card.

Note that methods exist to secure a border router prior to an attack. DoS mitigation methods and NetFlow configuration can be reviewed in the Secure IOS Template.   If BGP is used, there are additional defense methods available as documented in the Secure BGP Template.
 
 

Caveat

The if-con command used to access the VIP console is UNDOCUMENTED and UNSUPPORTED by Cisco. Cisco will not assist anyone with the use (or misuse) of this command. While this methodology has been fully "battle tested" on both lab and production equipment, and has been successfully utilized during several DoS attacks, your mileage may vary.  The author is not responsible for any damage caused by the use of this command.  The author also won't take undue credit for any benefit derived from the use of this command.  ;-)

Credits

• Angelito Basa
• David Bergum
• Ton Schoenmakers

The VIP Console

Once in the VIP console, many of the RSP CLI commands will work as expected. This, combined with NetFlow, is what makes DoS monitoring possible.
 
 

Monitoring a DoS Attack

The show proc cpu command can be used to determine if the VIP is still heavily utilized by the attacking packets. To wit:

The individual flows provide the granular detail necessary for proper analysis. Note that the listed IP addresses are directing a high rate of packets to the host 1.1.1.1. The entries indicate that the flows are entering the site through the HSSI 9/1/0 interface ("SrcIf"). None of the flows are entering through the HSSI9/0/0 interface. Due to ACL 105, the flows are sent to the Null interface ("DstIf"). The destination address is the target host, 1.1.1.1 ("DstIPaddress").

The next three columns are all in hexidecimal. The protocol ("Pr") is 11, which equates to decimal 17 – UDP. The source ports ("SrcP") are varied. The destination port ("DstP") is a consistent 17, which equates to decimal 23. UDP port 23 is an unused port on this (and most) system. Finally we know the number of packets ("Pkts") each host has generated in the poll interval. These are quite high.

So what have we learned? We know that this attack is UDP based. We know that the packets are not fragments, nor do they claim to be fragments. We know that the majority of the packets are 64 bytes in length. We know of several source addresses used in the attack, and these are likely spoofed based on the address type (RFC 1918). These can be used in an effort to trace the source (see the Tracking Spoofed IP Addresses article). We know the source interface (HSSI9/1/0), which can be traced to an upstream router or provider. This greatly narrows the field when attempting to uncover the source of the attack. Since the attacks are all coming from the same interface, it is thus possible that the sources aren’t so very disparate after all. Perhaps they are even in the same netblock or company! We know the intensity of the attack based on the packet counts. We can now monitor the duration and intensity of the attack.

In short, we have collected enough data to pursue the sources of the attack, involve the upstream ISPs in the pursuit, and possibly modify our ACL to accommodate the specific target ports.
 
 

Conclusion