Problem: Enterprise is under Denial Of Service Attack (DDOS) 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 188.8.131.52
PE(config)# ip source-track 184.108.40.206
If you want (and if this is being done by SP they will probably not) you may create log entries:
PE(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 ) :
PE(config)# ip source-track export-interval 60
- And finally , you see the data accumulated so far :
PE#sh ip source-track
Address SrcIF Bytes Pkts Bytes/s Pkts/s 220.127.116.11 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 your 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 the end client would not be affected at all.
Follow me on https://www.linkedin.com/in/yurislobodyanyuk/ not to miss what I publish on Linkedin, Github, blog, and more.