Some script kiddie in Delhi, India has been trying to hack our site since last night. He wrote a browser script that makes requests of our server in massive nested loops, trying everything under the sun.

He's not getting anywhere, and isn't getting past even our basic defenses (but he is filling up our log files).

We're sending back a 403 Unauthorized to his requests almost as soon as they come in, but the faster we block his requests, the faster his script runs.

We would like to introduce a "delay" of some sort before sending back the 403 response. The longer, the better.

Question: How can we delay hack attempts without affecting the rest of the site?

  • I assume that a Sleep(15000) on his thread would be bad news for other site visitors.
  • Spinning up a new thread just for him seems like overkill.
  • Is there another way to send a delayed response?
  • How long can we force his browser to wait? I suppose I don't care much if he gets the 403 Unauthorized error or eventually times out, so we could probably even do an indefinite / infinite wait.
  • 36
    Is there a reason you cannot just configure your firewall to drop traffic coming from his IP address? This problem would be better solved at the network level than the application level. Dropping traffic will mean he will have to sit there until the connect request times out. And not responding at all is much more effective than throwing back "unauthorized" responses since it gives him effectively no information to inspect. – cdhowie Dec 6 '10 at 22:21
  • 3
    Why not just block his ip? – Hogan Dec 6 '10 at 22:21
  • 2
    Unplug your server. – Sayed Ibrahim Hashimi Dec 7 '10 at 9:10
  • Look at my answer - this is a standard thing, I am surprised you didn't get an answer that points to some intrusion detection system earlier. – Unreason Dec 7 '10 at 18:27
  • @Sayed, unplugging your server is one of the worst things you can do. Besides DoSing yourself, see also security.stackexchange.com/q/181/33 – AviD Dec 8 '10 at 10:00

10 Answers 10


There should be a separate firewall somewhere in front of your web server. You want to block the requests there from ever reaching your server, such that as far his IP is concerned your server doesn't exist any more.

  • 1
    Hi Joel, this is the "accepted" answer, but since the question was transferred from StackOverflow, it appears that I don't have the authority to actually accepted it. I gave your answer +1. This is just what I will do. – Flipster Dec 6 '10 at 23:03
  • 2
    @flip click on your name and then the 'accounts' link partway down the page on the right. That will let you associate this back to your stack overflow account and regain ownership of the question. – Joel Coel Dec 6 '10 at 23:34
  • 1
    but you also want to do it automatically - no point in dealing with such issues on case by case basis. (see my answer) – Unreason Dec 7 '10 at 9:56

There are actual intrusion detection systems big and small that will do this automatically for you depending on the various filters, honeypots and other mechanisms

For example see fail2ban which can be configured to take actions based on analysis of logs.

This way you can

  • easily filter single IP address from which an attack is coming without influencing other users of your site
  • you can write your own regex to analyze logs
  • you can define your own actions (throttle instead of ban, etc)

There are other and bigger tools, see the see also section on wikipedia.

As your question is marked as asp.net I assume your server platform is windows. Still, if using linux firewall is an option you can try the above

  • put a linux firewall between WAN and your server
  • give access to the firewall machine to your IIS logs
  • write regex to analze it
  • plug it into existing templates for banning

Such firewall can be run on extremely modest hardware - think even something like linksys routers (see here) for very decent link bandwidths.


If they come from a specific IP address or address block, you may want to add a blackhole route to it:

ip ro add blackhole
ip ro flush cache

You can also accomplish this by using an iptables rule, but realize that iptables rules are traversed linearly, so if you start adding iptables rules for every miscreant that comes along, you can start to eat up a lot of CPU. Routing tables are optimized for handling many, many entries. For example, one of my boxes has 350K entries in it's routing table with no problem. But if I had 3K iptables rules the box would almost certainly fall over.

If you try doing something where your application sleeps for many seconds on these connections, you may end up tieing up enough resources that legitimate requests can't get any resources.

  • 1
    +1. I liked your info about the relative efficiency of routing vs netfilter in this situation. iptables on a kernel with ipset capability can very efficiently match huge lists of IP addresses, but it seems none of the major distros enable ipset in their kernels. – Steven Monday Dec 7 '10 at 5:06
  • Good point, ipset is something that seems like it would be useful for these sorts of things, but just isn't readily available. There's another system called nf-hipac that was a more general iptables optimizer, but the last post on the mailing list and last release is from 2005. – Sean Reifschneider Dec 7 '10 at 12:55

You do not want to slow him down because slowing him down incorrectly will take your site down as if it was under a DoS attack because your threads will be 'busy' servicing this person's requests. What you want to do is to block his IP and be done with it. There is no reason to bait the person doing it.


What you're looking for is Apache module mod_evaisve.

On Debian based distros, install it using

apt-get install libapache2-mod-evasive


yum install mod_evasive

mod_evasive keeps a track on the requests coming to Apache and bans IP using iptables that pass the threshold value. It's an ultimate tool against HTTP based DoS attacks and even Distributed DoS attacks when you're targeted by a huge botnet with thousands of different IP.

It runs as a Apache module loaded during runtime and not as a separate daemon.

Although, a smart attacker with control of a huge botnet can still bring down your webserver by timing the requests sent by each zombie in the botnet so that none of the IP ever passes the threshold value.

In that case, you've to use anomaly based IDS and probably train the system yourself. But this is highly unlikely to happen unless you've some real big enemies or someone with a corporate agenda.


If you're using linux, use iptables to limit the guy to like 1 byte/s with big delays and make him take forever to even get one request through. If it's distributed, that won't help much.

I'm not sure how you'd do it on Windows, but you may find some similar options in your router or hardware firewall, if you have one.

EDIT: Agreed with the above, this is more like a server fault question.

  • 2
    This technique is sometimes used in DDoS attacks - by the attacker. Doing this on the server is kind of counterproductive. <_< – p-static Dec 7 '10 at 4:33
  • Is not really right to say that it is used in DDoS attacks - this kind of effect is the goal of DDoS attacks. Doing it on the server/firewall, but only to attacking computers is the only real defense (AFAIK). – Unreason Dec 7 '10 at 10:11

If the IP address of the guy's pretty constant you could create a custom HttpModule, plug it in via a change in the web.config file and have a delay on it when it's recognized as this IP address. Or you can send him back some 404 codes or have him redirected to somewhere else.


You know they're in India. Does your site have significant Indian patrons which would preclude simply blocking their entire IP range at the firewall level in increments until the flow stops? It's certainly not a firm solution but if you're just dealing with a typical 'script kiddie' it should be enough to discourage them and send them to another target.

Even better, if it's from one IP, you could reply with your own denial of service attack :)

  • thats not really a solution, cutting jelly with an axe. And B, DDOS isnt really a good recommendation (though I asume you were kidding), no reason to a) do smth illagel b) put more load on your server! – Trufa Dec 6 '10 at 22:38

In addition to the answer you received, you will want to save your documentation (logs, traces) and supply them to your service provider. This is the most effective during the incident as your provider can witness the incursion. Even though you are successful in your measures, it's important to curtail further attempts and it helps your provider in escalating a request to the attacker's service provider; arguably the most efficient action is for the attacker's provider to refuse service to his customer, the identified attacker.


if your a programmer you could work with the .net Begin_Request event and put your "sleep" in there

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.