Since yesterday, I keep getting automated emails (like, once an hour) with that subject, for both QuickStatementsBot and Reinheitsgebot, two bots of mine.
There are no unusual edits from either bot. I assume it's from the fix for T182722, since the start of the emails and the fixing of the bug coincide.
How can I prevent being flooded by these mails? Can someone else turn them off? One is OK, but not machine-gunning please...
(not sure where this belongs, please fix tags accordingly)
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | None | T14884 Login and account creation should be by secure http. | ||
| Open | None | T11816 Improve security for Special:Userlogin (tracking) | ||
| Invalid | Wikinaut | T3932 [DO NOT USE] ENotif/EConfirm & further enhancements (tracking) [superseded by #MediaWiki-Email] | ||
| Open | None | T125653 Create new types of notifications | ||
| Resolved | demon | T11838 Send notification to account owner on multiple unsuccessful login attempts | ||
| Open | None | T182867 "Login to Wikidata as QuickStatementsBot from a computer you have not recently used" |
I started getting these emails for Legobot today at 3pm PST, so the timing is different than Magnus, but same exact symptoms. Ideally we'd hold bots to higher security standards so I'd hope there's a different solution than just disabling the feature :/
@Niharika and I discussed this in #wikimedia-commtech. She pointed out that LoginNotify will treat an IP as "old" if there is data in CheckUser tables for that address. Data is added to CU upon account creation, edits, and log entries. So if a script logs in and doesn't make any edits, that IP is not considered to be old, and upon the next login will still be seen as new. LoginNotify normally sets a cookie in browsers for this so if the device is trusted it won't warn again, but at least my script doesn't retain any cookies so that feature doesn't work.
@Magnus are your bots using normal password login or OAuth? And have they been making edits or just logging in?
Both bots use the Addwiki lib, not sure if that uses OAuth:
https://phabricator.wikimedia.org/project/profile/1490/
Both bots are making edits:
https://www.wikidata.org/wiki/Special:Contributions/Reinheitsgebot
https://www.wikidata.org/wiki/Special:Contributions/QuickStatementsBot
I also get a few "failed login" message for both.
@Magnus It seems it's only Wikidata you're getting notifications from? Could you turn them off in preferences?
Yes, ListeriaBot (which edits Wikipedia) does not cause those (so far), so only Wikidata.
And I would rather have someone fix this security-relevant feature than turn it off. If your anti-lock brakes make annoying noise, wouldn't you rather have them fixed than removed?
Yes, I would, but given the facts here...
...the probable cause is that your bot is logging in using a new IP address every time which isn't getting logged in CU tables against your bot's account.
Given all that, I'd not say this task is "high priority". We or ToolForge folks would probably get down to the cause and fix it but it won't happen immediately. I suggested you disable the notifications in the meantime if it's a huge problem to you. That's all.
I started getting similar messages at the same time for a bot for which I am the contact on enwiki. I disabled the notification itself in preferences. Possibly default changed? The k8s incident T182722: Ferm changes on the host node break networking for Kubernetes pods seems in no way related to this.
I think https://gerrit.wikimedia.org/r/#/c/398511/ will fix this issue - we need to backport it.
Mentioned in SAL (#wikimedia-operations) [2017-12-16T00:44:58Z] <demon@tin> Synchronized php-1.31.0-wmf.12/extensions/LoginNotify/includes/LoginNotify.php: T182867 (duration: 00m 57s)
@Magnus are you still getting the emails? At least for me they stopped when the above patch was deployed.
If these are logins from tool labs, its odd that LoginNotify::cacheLoginIP() isn't preventing the false positive, since it should always be basically the same IP (or at least in the same subnet)
From the debug logs it seems like no new notifications are being send out for ListeriaBot or QuickStatementsBot. Is that correct, @Magnus?
Same happens with my Irclogbot only at es.wiki (out of the five wiki it operates on). The bot just read abuselog from api without editing, confirming given "diagnosis" above.
@Niharika
Looks like the same happens with my bot user sartle.wiki.bot (doesn't make any edits, only get data) on www.wikidata.org. I had added question about this to the support chart https://www.mediawiki.org/wiki/Topic:U50nm1rlhgajf7wd.
I use https://www.wikidata.org/w/api.php with wikibase-api library (https://github.com/addwiki/wikibase-api) and three servers (prod/stg/dev) with different IPs that logins to the mediawiki through API. The issue is a lot of notifications about logins from an unfamiliar device and IP. Can somebody explain how i can prevent it (except for turn off a notifications)?
But now I'm not sure that the problem is related to different IPs. Probably I'll get the notification even if i will use my bot user only from prod environment
The probable reason is that your bot only logs in and doesn't make any edits. The IP(s) don't get recorded in the CheckUser table that way and every log in is treated as being from a "new" IP. Unfortunately I don't have a solution for you except for either turning off the notifications for this feature (you don't have to turn off notifications for everything) or making a few null edits (on different logins) from the bot on a sandbox page. That'd make sure the few rotating IPs get registered in checkuser and are no longer "new".
There is an ongoing ticket for recording logins in CheckUser and that would probably help with this problem. However, that will take some time to get built.
Using bot passwords seems like the easy way to get around this problem (the AuthManager login hooks don't get invoked that way). Or OAuth, but that needs to be supported by the bot while bot passwords need no special support.
Starting on December 20, I've been getting these emails for MusikBot II several times a day. It uses bot passwords, and logs in the same way as my other bot, MusikBot. In fact they're the same tool account on Toolforge. Both bots run every 5-10 minutes (yes it should probably stay logged in, but that's an aside), and usually do not edit after every login.
So the weird thing here is that only MusikBot II is affected, and that it suddenly started on December 20. Both bots have been running in the same way since LoginNotify was first deployed in 2017.
I can disable notifications, but MusikBot II is an admin and interface-admin account. It'd be much preferred to get the notifications if they are genuine.
Would it make sense to whitelist the Toolforge IP range? Perhaps using a configuration variable, since this is specific to WMF?
Do you actually log in? In theory bot password sessions do not expire.
No. Nothing prevents an attacker from doing login attempts from Toolforge.
Yes, as far as I can tell. The bot has been successfully editing all this time. Nothing relevant in the logs.
Would it make sense to whitelist the Toolforge IP range? Perhaps using a configuration variable, since this is specific to WMF?
No. Nothing prevents an attacker from doing login attempts from Toolforge.
Ah, duh. I was thinking more that I had trust that my Toolforge account is safe, with my credentials visible only to my account. But you're right, if they manage to get the credentials by other means they can just login using a different Toolforge account.
Could it be something to do with the permissions the bot password has? That is seemingly the only difference between my two bots, in practice. Though, I started using the new bot password for MusikBot II in early November, and I didn't get emails until a month afterwards.
I highly doubt it's the culprit, but this change was just before I started getting emails: https://github.com/wikimedia/mediawiki-extensions-LoginNotify/commit/24bb65b54afc8ca4a68f31f72ef870c1c6ca57d9
The immediate cause is rMW0c1b6605eeed: Have BotPassword::login() call AuthManagerLoginAuthenticateAudit which adds the audit hook for bot passwords. I had to re-read the task about CheckUser not logging logins and LoginNotify not recognizing the bot because of that (if it does not handle cookies).
We pass in a parameter telling it's a bot password to the audit hook now, so that could be used to restore the status quo (although not getting notifications about suspicions logins to your bot is not great). Alternatively, add some kind of checkuser data on bot login? Although I would be worried about login spam which is not rare for poorly written bots.
I mean, does the bot log in every day? There shouldn't be any reason to do that.
If the bot does log in every day, does it handle cookies properly?
Could it be something to do with the permissions the bot password has?
Not very likely, the bot user account itself does not do anything during the LoginNotify checks/warnings, why would it be checked for permission?
Presumably one of the bots does CheckUser-logged actions and the other doesn't?
Of course if IP checking did work as expected, LoginNotify would be no help in that scenario...
I guess in some glorious future Toolforge would use IPv6 and have different IPs for each account. Or sign requests with the name of the user who owns the request-making process, and then we could add that to the botpasswords restrictions syntax.
Starting sometime on 2019-02-24, my other bot started getting these emails too. I believe this happened around the same time as me moving the task from Trusty to Stretch.
