>> I feel your pain. Don't bother guessing intentions. Don't take it personally. It's most likely just a bot, following some algorithm. (Well, unless you've done something to piss someone off, or if your wiki is highly controversial.) Yea, you got it, its a wiki that some people don't like. So I'm very sure this is an intentional attack. But you're right, the intentions don't matter in this case. I would still have to find a solution whether its a misbehaving bot, a malicious script, a search engine spider, or a big surge in traffic. No its a not a virtual server although I've thought about that upgrade for the future. Right now its a shared server.
>> Ugh. Not the best way to do it, as they've already caused significant CPU usage before you even figure out the IP. I could probably detect an attack in 15 minutes or less, as the same IP makes 2 or 3 requests per second. I would say it would be unusual for a genuine visitor to make that many requests: 15 x 60 x 2 = 1800 pages in 15 minutes. So yea I could probably detect an attack pretty quickly like this if its coming from just one IP. After the detection comes enforcement, and seeing how quick it can stop it. I would ideally do it the way you suggested and slow the attacker if possible. I could refuse further processing from within MW (block of code in an extension) and that wouldn't be as fast the firewall or Htacess. I could use PHP to edit the Htaccess - then detection would be slow, which is fine and enforcement would be quick. When I manually blocked that IP in htaccess, CPU usage went back to normal right away. Or I would ask for advice from server experts on how to block effectively and they could give advice along the lines you gave. I would see if I can do that on a shared server. I bet I wont be able to do the ipfw you mentioned, but I will look for the best solution and work with server support to see if its possible. Yea we're english and non-global but the site is accessed/linked from all over including by people speaking/writing in foreign languages. Last time the attacker had an IP address from one continent and this time he had an IP from another continent so I'm not able to know where it will come from the next time. Anyway, thanks for your advice! I have to learn a lot, will take the information you gave and will also be looking at other sites/forums for advice. I know as time goes and our site's traffic increases even more, the chances of better quality and more frequent attacks will increase so the sooner I can make this (if at all), the better. Dan On Mon, Aug 13, 2012 at 8:20 AM, Jan Steinman <[email protected]> wrote: > > Like for many of us, my wiki is hosted on a shared server so I have to be > > careful about CPU usage. There's a hacker/attacker who has been recently > > flooding my wiki with malicious requests. His intentions may be... > > I feel your pain. Don't bother guessing intentions. Don't take it > personally. It's most likely just a bot, following some algorithm. (Well, > unless you've done something to piss someone off, or if your wiki is highly > controversial.) > > > ... somehow block the attacker's IP address. I'm doing this manually > right > > now in the HTACCESS file, by monitoring CPU usage, checking the IP in the > > log and blocking it in htaccess. > > Ugh. Not the best way to do it, as they've already caused significant CPU > usage before you even figure out the IP. > > Is this a virtual server? If so, where you need to block it is in the > firewall, using ipfw(8). You can make it work so that there is no reply to > packets at all, which has the significant advantage that you actually slow > down the attacker, since they have to wait for a TCP lost packet timeout. > > Anything else you do slows you down while your defensive measures are > executing. > > This is probably not the best place to get advice on ipfw(8), but take my > word for it, that's the place to do it, at the TCP/UDP level. I'd google > around for things like "ipfw denial of service attack" and such. > > I've had great (but temporary) success blocking spam that way, buy using > ipfw(8) to block port 25 access from huge address ranges from sections of > the globe where I don't expect email from -- like China. If your wiki is > English-oriented and non-global in nature, perhaps you can stop access to > big foreign address ranges to ease the problem. > > Good luck! > > ---------------- > :::: Entirely new ways of living are necessary, and if we don't adobt them > voluntarily, we or our children will eventually adopt them involuntarily, > and probably with great pain and difficulty in the process. -- Thom Hartmann > :::: Jan Steinman, EcoReality Co-op :::: > > > > > > _______________________________________________ > MediaWiki-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > _______________________________________________ MediaWiki-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
