-3

One of our MediaWiki - based projects seems under DoS attack - unusual number of anonymous users try to edit pages and view or edit history requests. While anonymous editing is disabled on that project and these anonymous users (I assume, bots) cannot actually change the pages, the load is serious enough to slow the server significantly.

One of the ideas seem to alter the MediaWiki PHP code to reject anoymous requests faster. Anonymous visitors only need to view pages; they are not supposed to edit, view page sources or view history. It would be even more interesting to use something like IPTables for shielding following this criteria. We have root access to the server.

Is it possible to alter PHP or to employ some external tool for efficient blocking of all anonymous MediaWiki requests apart from viewing the article content?

I have read, and keep watching, the more general question about DoS protection here and here. The reason of posting this separately is maybe we could do something MediaWiki specific.

Community
  • 1
  • 1
Audrius Meškauskas
  • 20,936
  • 12
  • 75
  • 93
  • 2
    That's really unfortunate, but it's not really on-topic for this site. Maybe it would be more appropriate over at [SuperUser](http://www.superuser.com) or even [ServerFault](http://www.serverfault.com)? – LittleBobbyTables - Au Revoir Jan 29 '13 at 19:23
  • The reason I am posting here, we are developers and ready to alter the source code of MediaWiki to cope with our problems. Please not post general user friendly solutions for the end users also we have already tried the most of such approaches. It is very easy to disable anonymous editing through web GUI but seems not dropping requests early enough. – Audrius Meškauskas Jan 29 '13 at 19:25
  • @Leigh I wonder why are you going so drastic here? There are multiple other questions on how to write and configure DoS resistant applications. – Audrius Meškauskas Feb 05 '13 at 10:19

1 Answers1

1

Have you tried changing the UserRights? The MediaWiki docs show how to edit LocalSettings.php to set rights.

As with a firewall, you should start by disallowing all edit privs, then add it back in for groups you want to allow (like registered users).

From their manual, http://www.mediawiki.org/wiki/Manual:User_rights

This example will disable editing of all pages, then re-enable for 
users with confirmed e-mail addresses only:


 # Disable for everyone.
 $wgGroupPermissions['*']['edit']              = false;
 # Disable for users, too: by default 'user' is allowed to edit, even if '*' is not. 
 $wgGroupPermissions['user']['edit']           = false;
 # Make it so users with confirmed e-mail addresses are in the group.
 $wgAutopromote['emailconfirmed'] = APCOND_EMAILCONFIRMED;
 # Hide group from user list. 
 $wgImplicitGroups[] = 'emailconfirmed';
 # Finally, set it to true for the desired group.
 $wgGroupPermissions['emailconfirmed']['edit'] = true;
Shannon Russell
  • 36
  • 1
  • Is this different from just configuring to disable anonymous editing through web user interface? We have done this long time ago – Audrius Meškauskas Jan 29 '13 at 19:30
  • 1
    No, that's probably the same. Have you checked your http logs? even if there is a DDOS, sometimes they do something simple wrong, like using a user-agent that you can block in Apache. Blocking before PHP spins up would be better than any in-php solution. You can could also through a reverse proxy like pound in front of the server to reduce load, but it might be tough to do properly on a single box. – Shannon Russell Jan 29 '13 at 19:46