As you may or may not be aware, the network -- my network -- serving the Aural Moon web site has been unwittingly solicited as a participant in a more likely than not BotNet DDoS (Distributed Denial of Service) amplification attack. Be it known, it is not
my network, nor is it the Aural Moon web site, that is the target of these attacks. My network's DNSs (Domain Name Servers) are being used -- or there's been an attempt to use them -- to facilitate a flood of requests to the intended
targets. This is done by faking the source address in the IP packet such that when the unwitting DNS responds, it sends the response to the target victim. By using unwitting DNS participants around the 'net, they can amplify the attack's effect and essentially drown
the target victim with too much traffic; hence, a denial of service.
I have taken steps to mitigate this but there's really no defense of this action because there's no way to trace the source of these feigned DNS requests. I have been able to identify a number of the targets and I have enabled an input filter on my network's routers to simply deny these request into/onto my network and, subsequently, to the DNSs. This is an ongoing battle. I have a packet sniffer running on the connection between the ISP's interface and the routing interface of the router. I've implemented some filter rules which quickly identify these feigned DNS requests. When I have the source IP address(es), I add them to an ACL (Access Control List) on the router to simply drop them. Note, however, that this doesn't STOP these attacks, it merely mitigates their effectiveness by keeping them from passing onto my network. These attacks are still consuming a vast chunk of my bandwidth.
Cisco871W#show access-list Deny-DDoS-ACL
Extended IP access list Deny-DDoS-ACL
10 deny udp 126.96.36.199 0.15.255.255 any eq domain
20 deny udp 188.8.131.52 0.1.255.255 any eq domain (85 matches)
30 deny udp 184.108.40.206 0.0.31.255 any eq domain
40 deny udp 220.127.116.11 0.0.127.255 any eq domain (65 matches)
50 deny udp 18.104.22.168 0.0.31.255 any eq domain (5580 matches)
60 deny udp 22.214.171.124 0.0.15.255 any eq domain
70 deny udp 126.96.36.199 0.0.63.255 any eq domain
80 deny udp 188.8.131.52 0.0.31.255 any eq domain
90 deny udp 184.108.40.206 0.0.63.255 any eq domain (520922 matches)
100 deny udp 220.127.116.11 0.0.63.255 any eq domain (19 matches)
110 deny udp 18.104.22.168 0.0.63.255 any eq domain (537785 matches)
120 deny udp 22.214.171.124 0.0.31.255 any eq domain (90 matches)
130 deny udp 126.96.36.199 0.255.255.255 any eq domain (10344 matches)
140 deny udp 188.8.131.52 0.0.0.31 any eq domain
150 deny udp 184.108.40.206 0.0.0.63 any eq domain
160 deny udp 220.127.116.11 0.0.0.255 any eq domain
170 deny udp 18.104.22.168 0.0.7.255 any eq domain
180 deny udp 22.214.171.124 0.0.1.255 any eq domain (582 matches)
190 deny udp 126.96.36.199 0.0.0.255 any eq domain
200 deny udp 188.8.131.52 0.0.7.255 any eq domain
210 deny udp 184.108.40.206 0.0.0.7 any eq domain (114439 matches)
230 deny udp 220.127.116.11 0.0.15.255 any eq domain (358260 matches)
250 deny udp 18.104.22.168 0.0.0.255 any eq domain (1074545 matches)
290 deny udp 22.214.171.124 0.0.1.255 any eq domain (313799 matches)
300 permit ip any any (2646852 matches)
As you can see, these are unrelenting attacks as is indicated by the matches counts. That number is the count of how many times (since my router's last reload) that the particular listed network has been targeted through my network.
I totaled the matches counts for the 'deny' clauses and that number is 2,936,515. The total count of packets that were permitted onto the network is 2,646,852. Some quick math shows that that is about 52% of the traffic currently hitting my router's interface. So, if things seems slow, you know know why.
How to stop this? Good question. The Bots in the BotNet are, more likely than not, WEENDOZE boxes. STOP USING WEENDOZE. Also, the ISPs of the world are culpable too. A responsible ISP would/should not route ANY packets that do not maintain source IP addresses within their network.
Because I've never had to contend with this before, I'm learning some more Cisco IOS. IOS has "policing" policies that can throttle certain protocols, networks, etc. As soon as I can get my head wrapped around how to properly implement them, I will put in a throttle for DNS requests that should mitigate these attacks without having to constantly monitor and modify the Cisco's ACLs.