Tracking the source of DOS attack with Cisco IOS

Problem: Enterprise is under Denial Of Service Attack that brings down key elements of the business or the whole network at all.
To track the attacker is the first step in handling the attack and unless the flood is coming from inside (most probably not in a well managed LAN) you will need help of your Service Provider to find out the origin. Unfortunately Service Provider’s (SP) backbone is not well suited for such forensics, as its business role is
to provide uninterrupted connectivity to ALL the clients , not only you, so SP will not enable ACLs/ip accounting/Netflow on their backbone to identify where the attack is coming from . And if source Ip of the attack is spoofed you can’t do much .

For such cases Cisco came with the nice feature called
ip source tracking that will gather flow statistics for specific destination
IPs (of victim) and periodically will export them for viewing, and will do all this without overloading the backbone router it is enabled on (Of course relevant if your SP is using Cisco gear) . Here are details:

– Enable it globally for the victim IP , here IP being attacked is 63.45.33.22

Edge(config)#ip source-track 63.45.33.22

- If you want (and if this is being done by SP they will not) you may create log entries:
Edge1(config)#ip source-track syslog-interval 2
Then you will see in logs (good for reminding to disable this afterwards) :
May 28 10:55:47.105: %DOS_TRACK-5-CFG: IP Source Tracker configured for 1 hosts

- Also you may define how often to export gathered info to be viewed (seems to depend on the platform ) :

Edge(config)#ip source-track export-interval 60

- And finally , you see the data accumulated so far :

Edge#sh ip source-track
Address SrcIF Bytes Pkts Bytes/s Pkts/s
63.45.33.22 Fa0/0 141G 485M 8244 141

Most important here will be the Source interface (in this router there is only 1 ingress interface , in real backbone you will have few feeds) where you see most of the incoming traffic for this destination IP. Then you (SP) would go to the upstream router connected to this local interface, enable the same source tracking and so on. Up to the last point in the backbone where the attacking traffic enters
the backbone of SP out of some upstream SP . Then SP would have option to contact the abuse of this upstream provider for them to investigate the issue further, or at least divert the attack to the black hole at the entry point, so end client would not be affected at all.