GitHub was down(status.github.com)
status.github.com
GitHub was down
https://status.github.com/messages?cache=burst
35 comments
Since this has been more frequent as of late, can anyone shine some light on who might DDOS someone like github? Is there anything to gain or is this just sadism?
I imagine that there's plenty of groups from third world countries who would be more than glad to take advantage of a cheap botnet to hold a website at gunpoint in exchange for protection money.
Probably cyber-terrorism, along the lines of "pay us $500,000 to stop this attack before hit hits," to blackmail startups like Github into paying.
That's what I originally assumed, but is this actually ever successful with companies like that?
I honestly doubt it's successful for anyone. No matter the size of the site, the amount of money you would pay a DDoS mitigation provider, either on a full-time basis or just to stop a current attack, would generally be considerably less than the ransom asked for, with the bonus of having your site be available much more often.
Sounds like that's successful for the DDoS mitigation provider.
does github really count as a startup still? they're not inducted into programmatic canon yet?
I suppose they're past the startup phase; you're right - I just never noticed the transition from 'startup' to 'company,' because the culture has stayed the same (as well as development pace, and quality).
does every downtime have to be submitted? it happens every other day and interested parties already know that and the status page.
Anyone know who they're getting hit by yet?
Maybe someone from GitHub can tell us.
I'm having a difficult time reasoning as to the motivation behind all the DDOS attacks. Why would anyone want to disrupt a tool for open, public collaboration used by many free and open-source technologies.
Anyone have any insight?
I'm having a difficult time reasoning as to the motivation behind all the DDOS attacks. Why would anyone want to disrupt a tool for open, public collaboration used by many free and open-source technologies.
Anyone have any insight?
Github.com is a profitable entity that makes a fairly large amount of money. Additionally, Github.com hosts a lot of content. Content that other people may not like.
Possibilities are: 1) Extortion of some sort i.e. We want your money, or we'll DDoS you every week 2) Content i.e. Remove repositories a, b, and c with content we don't like, or we'll DDoS you every week 3) Weapons demonstration i.e. We want to show off what l33t hax0rs we are, so we'll DDoS Github.com every week
Possibilities are: 1) Extortion of some sort i.e. We want your money, or we'll DDoS you every week 2) Content i.e. Remove repositories a, b, and c with content we don't like, or we'll DDoS you every week 3) Weapons demonstration i.e. We want to show off what l33t hax0rs we are, so we'll DDoS Github.com every week
Do they not have the bandwidth or resources to stop or mitigate something like this from happening? I would've thought they'd have better resources in place in case of something like this.
Just a theory, but perhaps some hackers trying to flex their muscles and stroke their ego's by taking down GitHub.
Would make sense. Saw a bunch of that at the Rio during defcon. Print my boarding pass? Nope. Somebody broke all of the machines. Order a movie or checkout on the TV from my room? Nope. Someone broke the outdated system.
Tools gonna tool.
Tools gonna tool.
To a degree this is pretty funny. Are you sure the hotel didn't do it on purpose just to remove the opportunity for hackers to get over on the hotel?
Yes. These systems weren't disabled, they were broken.
Not trying to be a buzkill, but I fail to see how it's funny. So you can break an old - undoubtedly unpatched - win xp box that people use to print boarding passes. Congrats.
Not trying to be a buzkill, but I fail to see how it's funny. So you can break an old - undoubtedly unpatched - win xp box that people use to print boarding passes. Congrats.
> Why would anyone want to disrupt a tool for open, public collaboration used by many free and open-source technologies
and a lot of closed source commercial projects.
and a lot of closed source commercial projects.
Nope.
Anyone thinking about hosting locally should check out Git and Gitolite. I've created a screencast about them @ http://sysadmincasts.com/episodes/11-internal-git-server-wit...
[deleted]
Do you know how it compares to GitLab? I've been thinking of deploying it when I have a spare weekend.
http://gitlab.org/
http://gitlab.org/
Git and Gitolite are command lines tools only. So, you basically install git-daemon, which allows you to run a central git server, and then you have gitolite, which allows you to do user management.
GitLab is basically a GUI that fronts this (I'm not sure about their user access implementation though; doubt it is gitolite). There are other tools like Gerrit [1], Gitweb [2], and cgit [3], that you can use to front your git repos though. GitLab is just a really slick one!
[1] http://code.google.com/p/gerrit/
[2] https://git.wiki.kernel.org/index.php/Gitweb
[3] http://git.zx2c4.com/cgit/
GitLab is basically a GUI that fronts this (I'm not sure about their user access implementation though; doubt it is gitolite). There are other tools like Gerrit [1], Gitweb [2], and cgit [3], that you can use to front your git repos though. GitLab is just a really slick one!
[1] http://code.google.com/p/gerrit/
[2] https://git.wiki.kernel.org/index.php/Gitweb
[3] http://git.zx2c4.com/cgit/
> you basically install git-daemon, which allows you to run a central git server
AFAIK, git-daemon is to allow the specific use case of anonymous, public access to git repositories [1].
You don't need it to have a "central git server", though: If you have an ssh account on yourhost.com and a git repo in /home/you/yourproject on that machine, you can simply git clone git+ssh://yourhost.com/home/you/yourproject. Give out multiple ssh keys to that account, and it's a minimal but functional "central git server"!
Of course, doing the above the easiest, quickest way, with a single UNIX user account, results in (A) giving git client users access to a shell and (B) giving git client users read/write access to each others' repos. Gitolite uses authorized_keys restrictions to avoid (A) and a clever SSH_ORIGINAL_COMMAND hack to avoid (B).
> doubt it is gitolite
Gitlab in fact did use Gitolite for actually serving the git client until quite recently. The largest change in 5.0 was reimplementing a subset of Gitolite's functionality and losing the dependency [2]; the project's major version number is still at 5, although 6.0 is promised soon [3].
[1] http://git-scm.com/book/en/Git-on-the-Server-Git-Daemon
[2] http://blog.gitlab.org/gitlab-5-dot-0-has-been-released/
[3] http://blog.gitlab.org/gitlab-5-dot-4-released/
AFAIK, git-daemon is to allow the specific use case of anonymous, public access to git repositories [1].
You don't need it to have a "central git server", though: If you have an ssh account on yourhost.com and a git repo in /home/you/yourproject on that machine, you can simply git clone git+ssh://yourhost.com/home/you/yourproject. Give out multiple ssh keys to that account, and it's a minimal but functional "central git server"!
Of course, doing the above the easiest, quickest way, with a single UNIX user account, results in (A) giving git client users access to a shell and (B) giving git client users read/write access to each others' repos. Gitolite uses authorized_keys restrictions to avoid (A) and a clever SSH_ORIGINAL_COMMAND hack to avoid (B).
> doubt it is gitolite
Gitlab in fact did use Gitolite for actually serving the git client until quite recently. The largest change in 5.0 was reimplementing a subset of Gitolite's functionality and losing the dependency [2]; the project's major version number is still at 5, although 6.0 is promised soon [3].
[1] http://git-scm.com/book/en/Git-on-the-Server-Git-Daemon
[2] http://blog.gitlab.org/gitlab-5-dot-0-has-been-released/
[3] http://blog.gitlab.org/gitlab-5-dot-4-released/
Oh I see. I didn't realize how many different tools are available for Git. Thanks!
I've had experience maintaining a private Gitolite installation; we ended up migrating to Gitlab.
Managing SSH keys and repo permissions from the command line was just enough of a learning curve for users (internal developers) that they really didn't like it and tended not to use it unless forced. Gitlab has had much less pushback.
Really, it depends on whether your users are more comfortable with the command line or web interface.
Also, I found Gitolite to be a bit easier to administer than Gitlab. Gitlab is a Rails web app, with lots of moving parts. Gitolite is essentially a bunch of Perl scripts which use authorized_keys and SSH_ORIGINAL_COMMAND hackery to convince ssh to do the actual authenticating.
If you already know and love deploying Rails web apps (I don't), then you might find Gitlab easier.
Managing SSH keys and repo permissions from the command line was just enough of a learning curve for users (internal developers) that they really didn't like it and tended not to use it unless forced. Gitlab has had much less pushback.
Really, it depends on whether your users are more comfortable with the command line or web interface.
Also, I found Gitolite to be a bit easier to administer than Gitlab. Gitlab is a Rails web app, with lots of moving parts. Gitolite is essentially a bunch of Perl scripts which use authorized_keys and SSH_ORIGINAL_COMMAND hackery to convince ssh to do the actual authenticating.
If you already know and love deploying Rails web apps (I don't), then you might find Gitlab easier.
Anyone know what the motivation of these attacks might be? I can't imagine anything to gain from DOSing Github and I certainly can't imagine any of their direct competition doing it.
Possible motivation: Someone just finished their hack at the facebook hackathon (going on right now), and is DDOSing github to stop everyone else in their tracks :)
It is up right now.
https://status.github.com/
Bitbucket is also down for the count.
[deleted]
Seems to be working for the moment for me.
Sounds like they need to be talking to Prolexic...
> Attacks