I'm sure a similar situation would work here, especially with a decent geoip database. If you get 3 - 5 failed attempts on an account separated by more than a few miles (and not along an interstate :-)) you can probably assume someone is using a botnet to try to break in.
Before I switched my sshd ports a few weeks ago, I often saw break in attempts on my servers that would imply checking only a single username and a single password.
My guess on that is that bruteforcers, rather than testing thousands of usernames with thousand of passwords on a single host will try a single username and single password on thousands of hosts.
http://bsdly.blogspot.no/2013/10/the-hail-mary-cloud-and-les...
I double checked my log archives, it seems not to be exactly the same, though. In what is reported here, a same username will be tried with several password, allowing something like a minute to pass to make a new attempt.
In my logs, this is really just a single attempt. Other break in attempt may happen something like two days after, but with an other IP and username.
It may just be yet an other evolution of the same botnet knowing its previous pattern has been spotted, though.
(and in case you wonder, yes, I always have the nose in my logs, having a dedicated monitor for that :) )
Now that is dumb. I expected more from GitHub.
Looking at the security history page I see a lot of failed login attempts. Makes me glad I enabled 2-factor-authentication!
It's a great way to distribute Open Source software. (Previously Mattt hosted it on a personal Amazon S3 account which he paid out of his own pocket; now bandwidth is generously paid for by Github)
If someone would slip in rogue code - it's quite likely some to many would actually run it and deploy it. Especially if it's a fast moving piece of software - like being so rapidly developed that distribution packages can't keep up for either time or stability reasons, leading people to compiling/deploying from source themselves.
- Of all users, only a small subset would have private repos
- Of those users, only a small subset would have private repos that would be of interest to third parties
- Of those users, only a small subset would have a weak enough password to allow brute force
To reverse it, of these accounts that were hacked, I can't see many of them having private repos that would be of interest.
And if so, then this would seem a bit excessive.
I know that's a lot of ifs, but it seems reasonable. I would be interested to see the number of total accounts vs. the number of accounts w/ private repos.
- That private repos are the only thing worth targeting. What if you could inject a trojan into a popular open source project? You could do a lot of damage that way, probably way more than on private repo, because so many people incorporate them in their products. Imagine they hacked the Rails repo, for example. Worse, some repos host binaries, for which a meddling would be harder to detect (a bad idea, but doesn't mean it doesn't happen).
- That the users being attacked are random and not specifically targeted based on who the user is and what the work on. Not sure if that's the case or not, but I see no reason to assume it.
A good bet to find people with private repositories, would be to aim for all or a subset of those who belong to an Github "organisation".
Likelihood of valuable user greatly increased.
"While we aggressively rate-limit login attempts and passwords are stored properly, this incident has involved the use of nearly 40K unique IP addresses. These addresses were used to slowly brute force weak passwords or passwords used on multiple sites. We are working on additional rate-limiting measures to address this. "