Topic on Project:Support desk

I was attacked quite badly by bots today, over a thousand of new users in fact, 4000 pages. I immediately went into LocalSettings and added this code:

$wgGroupPermissions['*']['createaccount'] = false;

$wgGroupPermissions['user']['edit'] = false;

$wgGroupPermissions['sysop']['edit'] = true;

$wgBlockAllowsUTEdit = false;

$wgGroupPermissions['*']['createpage'] = false;

But it didn't do a thing, they kept creating accounts, editing, and making new pages. I couldn't figure it out and added these lines too:

$wgRevokePermissions['user']['edit'] = true;

$wgRevokePermissions['user']['createpage'] = true;

That seemed to do it, but I couldn't post myself, as the sysop/admin. So I created a new category of user, added myself to that category and added these lines:

$wgRevokePermissions['administrators']['edit'] = false;

$wgGroupPermissions['administrators']['edit'] = true;

Now I am confirmed to be in that group, I am admin in every way, I've checked my user rights. But I still can't post. Anyone know why they could for so long and I still can't? It's bizarre.

If you are using the default $wgGroupPermissions configuration, which MediaWiki comes with, then your users are not in any special user group besides the user group. Maybe they also become member of the autoconfirmed group after time and/or a certain number of edits.

If this is the case for you, these lines should be enough to take edit rights away:

$wgGroupPermissions['*']['createaccount'] = false; $wgGroupPermissions['user']['createaccount'] = false; $wgGroupPermissions['autoconfirmed']['createaccount'] = false; $wgGroupPermissions['*']['edit'] = false; $wgGroupPermissions['user']['edit'] = false; $wgGroupPermissions['autoconfirmed']['edit'] = false; $wgGroupPermissions['*']['createaccount'] = false; $wgGroupPermissions['user']['createaccount'] = false; $wgGroupPermissions['autoconfirmed']['createaccount'] = false;

The name of the administrator group is sysop by the way.

See Manual:$wgGroupPermissions for details!

Right, but none of that was working. Does that mean they were adding pages directly into the database, perhaps hacking into my hosting service? Or is there a way of disabling GroupPermissions from working? I haven't changed anything, but bottom line is that it didn't work. they kept attacking and posting for hours after changing permissions.

The most Robots create normaly user side with content; other Robots login in the next time and change your side content. For a better security create a New Group, in that user must self change to get rights!

No Robot at this time change the usergroup!

cu

Bastor

That is the strange part, and why I posted here. I did create a new group with only myself in it and gave that group permissions. It's not working. I did change everyone else's group permissions and it didn't stop them. I don't understand what's going on because it should work.

> Right, but none of that was working.

Note that permissions are cumulative: If there only is one single group, which does grant a right, then with $wgGroupPermissions there is no way to take it away again.

> Does that mean they were adding pages directly into the database, perhaps hacking into my hosting service?

I still want to figure out, if this maybe is only a configuration problem. What is the URL of the wiki?

Which MediaWiki version are you using?

> Or is there a way of disabling GroupPermissions from working?

There at least should not be one. If there was a way around these permissions, this would be a serious security problem.

www.helpforshepherds.org The revoking of permissions completely seemed to do the trick, but I also had changed all my account and database passwords as well. All I know for sure is that the code for grouppermissions did not stop anyone. I can edit some settings so you can check it out if you want. I've been too nervous to open it up yet until I figure out why they got through in the first place.

You are using MediaWiki 1.26.3, which is good.

Looking at your recent changes, there have been no edits at all since 2013. The Log does not show any entries after June 2013. Since the attack happened today, you obviously have replaced the database with an older backup. Other options are available at combating spam!

With your current settings, according to Special:ListGroupRights, the "*" group still does get edit permission. That is the reason why everyone can edit pages.

Please add

$wgGroupPermissions['*']['edit'] = false;

to the bottom of your LocalSettings.php file and test again. The page Special:ListGroupRights will directly show you, if it worked out.

Ahh, soo the * overrides. I thought star just meant all, and so user would prevent them from editing and still allow me as a sysop. But going * and then adding rights to myself would have worked fine too.

Yeah, I was an idiot and when I did a fresh install of my old site this week with a new copy of mediawiki I assumed "bundled" extensions meant running automatically. So left the entire thing vulnerable as anything because I didn't see the need to install my old extensions for security since they were mostly "bundled." I have since learned otherwise.

Thanks for the help. I'll make sure to use both * and user for each, then allow sysops back.

The group * in fact does mean all users. The group "user" in contrast only affects users, who are logged in (and not also anonymous users). If you give one of these groups a right, no matter which one, it can also be the "user" group, then a user, who is member of both groups (= every user, who is logged in), will have that right. That is what I meant with "user rights are cumulative" above.

It is not true that "*" would overwrite. What one could say is that for each permission, the value "true" overwrites: If a user is member of several groups, then he will effectively have a right, if this right has been granted (= is true) for at least one of his groups.

Yeah, "bundled" does not mean "installed". If you want to use an extension, you still have to install it by adding a line to LocalSettings.php.

Thanks for the clarification, I appreciate it. But then I don't understand how they were still able to make new pages and new accounts with group permissions for all being turned off. Very strange. Oh well, I'm just doing my best to have enough security on that it won't be a problem when I do turn it all back on. Again, I appreciate the information and the help.

For the account creation, the permissions as you have them right now, the user right "createaccount" is only granted to admins (= the sysop group). That is why spammers currently cannot create new accounts. With regards to spammers, your account creation settings are fine.

However, the "edit" right still is granted to all users - that is also why I could do a test edit an hour or so ago. And every spammer can abuse this as well - without having to log in before starting to spam.

With your current settings, anonymous users can edit existing pages and, since the * user group also has the "createtalk" user right, they will also be able to create new talk pages. You should take this right away as well:

$wgGroupPermissions['*']['createtalk'] = false;

Maybe you want to remove those lines, where you revoke the "edit" and "createpage" permissions from the "user" group. If this group should not have this permission, just use $wgGroupPermissions to set it to false.