> 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 <Jan(a)bytesmiths.com> 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
MediaWiki-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l