Sorry to hear that.

DDoS is seen at the server level. What we usually see at the account level is a botnet & difficult to block because of infected IPs, but making sure your 403 page has a small footprint helps.

I also was once an advocate for blocking all China ranges. Hundreds of CIDR amounting to 30kb of additional htaccess bloat. Many of the larger Chinanet ranges also include South Korea, Philippines, Japan, Australia and other collateral damage.

However I no longer block by region. I treat China like anywhere else and filter by a comprehensive method of header, UA, range & behavior. If my defenses are not strong enough then they are not strong enough for China or anywhere else.

FYI - My refrigerator has been trying to get me for years.

I do block a variety of bots directly but I just haven't had the time to really refine my efforts. As for China, it would take a pretty good argument to convince me that I have any need at all for Chinese traffic on a locally oriented U.S. Small Business directory site. Have never seen an ad click from China but I have seen loads of bandwidth sucking from that part of the world.

I will be the first to say that CIDR Blocking isn't idea for entire countries the size of China but with a filtered query and some fast range comparisons it's working pretty well for now. I've followed this thread for several years now and wish I could find some concise information on behavior analysis. I don't use .htaccess due the OS I'm on but I sure I could figure out how to the same things in web.config. I'd wind up with the same bloat if I did though. I have trackers set up for anything that doesn't pass my block list and another for hits that seem ok. I use a whitelist to let acceptable bots through without any further check. So, it's more than nothing. Would love to take this system to the next level.
As always, I appreciate the feedback.

it would take a pretty good argument to convince me that I have any need at all for Chinese traffic on a locally oriented U.S. Small Business directory site

But closing that door and not allowing it to grow may limit your choices in the future. You may not always wish to target only local traffic, and who knows what tomorrow may bring?

Have never seen an ad click from China but I have seen loads of bandwidth sucking from that part of the world

Is this "bandwidth sucking" costing you additional fees? There are many hosts that offer unlimited bandwidth (just say'n.)

Basically, no matter what host OS you're using, the general idea is to use an "if this exists, then do this." It can be implemented in a variety of ways, but it all depends on what you consider to be beneficial/detrimental. Each site is a little different.

Coming soon to a theater near you! Appliancegedon!

@webcentric

The trick here is to use self maintaining list of IPs. With web.config You could use

<rewrite>
 <rewriteMaps configSource="webrwmaps.config"></rewriteMaps> 
 <rules configSource="webrwrules.config"></rules> 
 </rewrite>

Then in "webrwmaps.config:

<rewriteMaps>
 <rewriteMap name="BlockAccess">
  <!-- This one will use wildcards -->
  <add key="88.198.212.*" value="1" />
  <!-- This one wil use static IP -->
  <add key="8.1.22.13" value="1" />
 </rewriteMap>
</rewriteMaps>

and in webrwrules.config

<!-- This is where the rules start, this one will block EVERYTHING on your site with the <match url=".*" /> -->

<rules>
<rule name="Blocked Users" stopProcessing="true">
<match url=".*" />
<conditions>
<!-- This will just go to the 'Bad Ips' rewriteMap below and compare it to the REMOTE_ADDR which is the requesting IP -->
<add input="{BlockAccess:{REMOTE_ADDR}}" pattern="1" />
</conditions>
<!-- This one will rewrite url to specified file -->
<action type="Rewrite" url="FILE-THAT-MANIPULATES-rewriteMaps-FILE.aspx" appendQueryString="false" />
</rule>
</rules>

You then write your code in what ever LANG(c# or vb) and place it in FILE-THAT-MANIPULATES-rewriteMaps-FILE.aspx << your detection rules and add/remove entries to webrwmaps.config

Hope this helps.

added:
just make sure to re-save web.config file itself, sometimes the map file gets cached by IIS.

FYI - My refrigerator has been trying to get me for years.

What was the UA for that fringe? :)

@blend27 I'm down with the self configured part of this. I almost have it down but I'm actually using a database to block ranges, IPs and other stuff. It's a bit of overhead right now (more of a catcher really) but I could see how the db could be used to generate a section in a.config file on a regular basis. Keeping the actual detail out of the web.config file should keep the site from recompiling every time something is added. That's slicker than snot on a refrigerator door handle.

BTW, my host isn't sharing weblog data from their server with me. We'll just have to speculate that it's not a Coleman ice chest. ;)

Whether your attack was a real DDoS or (more likely) a botnet, the IP addresses used are most often infected accounts that will never be used again, so writing these addresses to a block list (of any type) may not accomplish the defense you want.

IMO it's best to block hosting ranges and block malicious user accounts by a comprehensive method using header info, UA, range & behavior.

Well this discussion started with DDOS but @blend27 turned into something far more interesting which is a bit off topic so I'll invite the mod to move this line of thought to another, more appropriate forum/thread with my blessing (as if it's needed).

So, while looking into the techniques mentioned above (which appear to be URLRewrite specific), I got into the concept of Request Filtering (also doable through the web.config file). Apparently, request filtering takes place earlier in the pipeline and is less resource intensive, It works great with user-agent and query strings but doesn't appear to work with remote-host. I haven't tried to move the rules to a separate file yet but I'm guessing it should work about the same as described above. So far, I've added 5 bots to this (based on user-agent). It works like a charm (stopping the bots from ever reaching the application) so, they aren't bogging me down with database calls, page loads or anything like that. Great! For the time being, I can back that up with URLRewrite rules and probably ad IP block lists through request filtering as well.

So in keeping with rule #1 (don't talk about Fight Club), I'll try to keep the details sketchy as this line of thought progresses. Still, there is a ton of info around here related to various .htaccess techniques and I think we could use a bit more on the .NET side of things so I'm happy to add to that. Again, this train of thought probably needs to get moved as it will get well off topic I suppose. I searched the site specifically on request filtering but most of what I found is closed to comments. A shame because I would have added this in one of those.

These posts can remain here, but if we want to continue discussing code, probably better to start a new topic in the Microsoft IIS Web Server forum (or whatever) to get better input from other members.

@keyplyr Will do.

Just to finish off the sub topic. In my case the caching is really sticky and if you haven't actually made a change to the web.config file, republishing it doesn't seem to help I completely republished the site, no luck, republished just the web.config and the external config. No luck. Restarting the server did the trick and for the few changes I need to make, it's acceptable for me. I'm primarily getting this external config file process figured out for rewriting at the moment we'll see how it goes and then move back to request filtering. The caching was really messing with me.

In my case the caching is really sticky and if you haven't actually made a change to the web.config file..

can't you just make a simple change to web.config file and re-save it programmatically? Something like Add a extra space at the and of it, on a next iteration add another space, on the next Trim both, and so on?

Let your router do the fighting, they make routers now that will actively fight a DDoS attack for you.

server level IP blocking is like playing wack a mole...

also.......DNS amplification attacks

I've fought many DDoS attacks in real time, sometimes the best thing you can do is to turn it off...and switch IP addresses, let the horde descend on a node that no longer exists.. most of the time they aren't checking DNS for IPs they are just blasting an IP...so when it goes dead....they are blasting at nothing and you are live and full speed.

also if you are US based

REPORT EVERYTHING to [us-cert.gov...] they go after stuff like this.. I even report phishing emails to them and they take them down with a quickness!

[us-cert.gov...]

here is the general report form... scroll to the very bottom of the main site to find links to report each type of threat.

everyone should bookmark this and any kind of online fkery they find should be reported to them ASAP. Don't just say, oh wow a trap and run away.. KILL THE TRAP!

Once a DDOS attack hits your server, all you can do are stopgap measueres trying to use the least cpu cycles possible. The real defense must happen at the router level, both within the hosting company and further upstream in the backbone. The closer to the source a request is dropped, the better.

If the bad traffic comes in from IoT type consumer hardware, then "blocking china" seems rather pointless. Those devices are rapidly growing in numbers all over the world, and most of them are embarrassingly vulnerable.

I wanted to add as this is an important topic.

@J_RaD : I've fought many DDoS attacks in real time, sometimes the best thing you can do is to turn it off...and switch IP addresses, let the horde descend on a node that no longer exists.. most of the time they aren't checking DNS for IPs they are just blasting an IP...so when it goes dead....they are blasting at nothing and you are live and full speed.

What J_RaD said is very important. If it is a large scale DDoS, you won't be able to block it at the server. Your server will simply die from the amount of flooded requests, including non-http. And block attackers IPs is useless , they change them 1000 times a day and will come from all over the world (mobile is a bitch).

What you do to protect your important site is you keep a list of open IP addresses at your hosting company. You let hosting worry about blocking DDOS atack as far away from their network as possible (they are equipped and will block all traffic to your IP). And then you switch IP.

In our experience , if it is a kiddie hacker wannabe, he will run out of money paying for DDoS (ddos-ing each IP is an incremental cost to them) before you'll run out of IPs.

Regarding the very large DDOS attacks we've been seeing since October, they can largely be attributed to the IoT (internet of things). For those not aware of the discussion, see this thread....

DDoS Attack Brings Down Sites, Including Twitter, Github, Reddit
https://www.webmasterworld.com/foo/4823071.htm [webmasterworld.com]