GitHub under DDoS attack right now (again...)(status.github.com)
status.github.com
GitHub under DDoS attack right now (again...)
https://status.github.com
72 comments
There are groups of people blackmailing companies for money, threatening with DDoS attacks if they do not comply. A client of mine, a European company gets these occasionally. The bigger the company/service, the bolder are the requirements.
Crime, unfortunately, doesn't have feelings for such a great services as GitHub is.
I hope GH will be able to mitigate the attack fast.
To be fair to crime (... Heh), we're not doing ourselves any favors by putting all our eggs in one basket.
How long until they graduate to exploiting GitHub and securing proprietary code from private source repositories, or forging commits to critical repositories (how often do you verify that every commit in the repo with your name on it is definitively yours?)
How long until they graduate to exploiting GitHub and securing proprietary code from private source repositories, or forging commits to critical repositories (how often do you verify that every commit in the repo with your name on it is definitively yours?)
True, but these people usually want money - fast. The process you describe takes time and with time the risk of being caught expands. So I guess "real criminals" would opt for fast money rather than long term possibilities.
The option you're describing seems more likely for various "agencies" and the likes...
Spot on. I have a number of clients who are EU gambling sites. They can count on an email or phone call about 10 minutes before the start of any and every big Football/Rugby/Cricket match to the effect "pay us X euros or we'll take your site off line". Since the betting activity is greatest right before the start, this could represent millions in lost revenue. These clients are very good at DDoS mitigation, but I also suspect they pay a lot of folks off as a cost of doing business. I also suspect that many of the attacks are set up by competitors, because it's pretty easy for a user to say "can't place my bet here, I'll go next door".
Honestly if I had the eleventy squillion bytes/s bandwidth of a large DDoS behind me and I wanted to DDoS GitHub ... I'd DDoS the status page too (just for shits and giggs).
But on a serious note, is DDoS'ing a server that serves mostly static content way too hard? I imagine taking out one of GitHub's ways of communicating what's going on is appealing.
But on a serious note, is DDoS'ing a server that serves mostly static content way too hard? I imagine taking out one of GitHub's ways of communicating what's going on is appealing.
There are two types of DDoS attacks, which Github actually wrote about last week (thereabouts[1]), although you'll be unable to read the blog post until the site is back (unfortunately).
But I can outline the two they discussed. The first is a "complex attack", which basically consists of doing things that make the server overload itself (repeatedly handshaking SSL, etc.), and that would be mitigated to some extent by reducing the complexity of the site (i.e. you can't SSL handshake with a server that only knows HTTP). Similarly, dynamic content could be an attack surface, so static content would make it more difficult to use such a complexity attack.
The other type of attack, a simple bandwidth attack, doesn't care if your server is a top-of-the-line quad-chip Xeon server or an RPi in your basement, because all it does is exploit the bottleneck that is bandwidth. This attack just pumps packets like mad in your direction, and your network will likely become congested (and eventually fail) at some level other than your server (i.e. router level, firewall can't handle 100 Gb/s so the packets never even make it to your server).
So, in light of the second there, DDoS'ing static content is just as easy as DDoS'ing dynamic content sites, as long as you're using a bandwidth type attack.
I encourage you to read the blog post when the site is back up, it's definitely worth a read!
[1] https://github.com/blog/1796-denial-of-service-attacks
But I can outline the two they discussed. The first is a "complex attack", which basically consists of doing things that make the server overload itself (repeatedly handshaking SSL, etc.), and that would be mitigated to some extent by reducing the complexity of the site (i.e. you can't SSL handshake with a server that only knows HTTP). Similarly, dynamic content could be an attack surface, so static content would make it more difficult to use such a complexity attack.
The other type of attack, a simple bandwidth attack, doesn't care if your server is a top-of-the-line quad-chip Xeon server or an RPi in your basement, because all it does is exploit the bottleneck that is bandwidth. This attack just pumps packets like mad in your direction, and your network will likely become congested (and eventually fail) at some level other than your server (i.e. router level, firewall can't handle 100 Gb/s so the packets never even make it to your server).
So, in light of the second there, DDoS'ing static content is just as easy as DDoS'ing dynamic content sites, as long as you're using a bandwidth type attack.
I encourage you to read the blog post when the site is back up, it's definitely worth a read!
[1] https://github.com/blog/1796-denial-of-service-attacks
It seems back now, but in case anyone finds this comment the next time GitHub is under DDoS:
http://webcache.googleusercontent.com/search?q=cache:KNnwGeD...
http://webcache.googleusercontent.com/search?q=cache:KNnwGeD...
In my teenage years I don't think anyone with access to a few servers hooked to T1 lines had to have any excuse to use that to DoS anyone. I always assumed they had some sense of fun (whatever that is) or were compensating for something else in their life.
Anyway, I don't think we ugly bags of water have changed much in the last 20 or so years. I wouldn't read too much into this GitHub DDoS event.
Anyway, I don't think we ugly bags of water have changed much in the last 20 or so years. I wouldn't read too much into this GitHub DDoS event.
Of all the sites I frequently visit/use, GitHub is by far the one to get DDoS the most often. Anyone has any insights on why?
I'm not prone to violence but if I met someone who I was certain DDOS'd Github I'd certainly immediately punch them hard in the face.
Github is a noble company with noble end-goals, and collaborative open-source is a revolutionary "work" idea. To see someone smash a bottle on the counter and threaten the nicest guy in the room gives me rage.
Github is a noble company with noble end-goals, and collaborative open-source is a revolutionary "work" idea. To see someone smash a bottle on the counter and threaten the nicest guy in the room gives me rage.
> I'd certainly immediately punch them hard in the face
Looks to me you are prone to violence.
Looks to me you are prone to violence.
Hard to specifically pinpoint, but clearly someone or a group of individuals that don't want to see GitHub succeed.
(black hat) hackers like to get people's attention, gain notoriety. Especially of their peers.
I'm gonna guess people are just assholes. It's quite the target, considering the number of companies that rely on them for their day to day operations. They can do a lot of disruption/damage with it.
Normally I'd say extorsion, but I don't see why the attackers would keep it up for so long.
maybe credibility, of all things. if they can prove they've been able to successfully ddos github, they can be expected to flood pretty much any target.
What happened to the Hubot command to redirect the attack to the contracted provider? Surely they can handle it.
This isn't as simple as it sounds; they'd need to identify DDoS traffic and reroute, while still allowing "legitimate" users through.
But this may not be the sort of brute-force bandwidth DDoS that this was designed to handle either -- it could be a more targeted attack to existing bottlenecks in GitHub's architecture.
But this may not be the sort of brute-force bandwidth DDoS that this was designed to handle either -- it could be a more targeted attack to existing bottlenecks in GitHub's architecture.
They made praising comments about the service last time.
This is getting ridiculous. There are so many sites to attack, why Github?
Well if your competitor used GitHub for (source control|issue tracking|deploying from a GitHub repository) you could DDoS GitHub (bit of colatoral here and there) for some illegitimate advantage.
A competitor could also face charges for this sort of activity, couldn't they?
Law enforcement would have to work up the caring to actual track you down. There are hundreds/thousands/tons of [D]DoSs launched everyday from 10MB/s to colossal 400Gbps attacks. 99+% of attacks aren't going to be investigated.
Maybe some "corporations" are getting "harmed" because there is so much free code around, and they don't like that. I don't know...
If you have a DDoS network, taking down something large like Github is a good way to display your power to any potential customer.
Maybe there's a perception that since Github is mostly "free", there's less likelihood of prosecution? Maybe Github is most visible site that isn't heavily fortified against DDoS? Is there a common DDoS toolkit out there, and Github is in the example.conf?
Could this be in any way related to Julie Ann Horvath's treatment at the company?
I didn't know the story. From http://thinkprogress.org/economy/2014/03/19/3416013/github-j... :
"The sight of her male coworkers leering at a group of women in the office was the last straw for Github’s first female hire."
Take a workplace with all-men, and due to sheer probability you're going to get a lot of leerers when any number of women walk in. That's really a bit unfair of an assessment. I'd like to see what happens when an attractive man walks into a workplace that is all-women.
"The sight of her male coworkers leering at a group of women in the office was the last straw for Github’s first female hire."
Take a workplace with all-men, and due to sheer probability you're going to get a lot of leerers when any number of women walk in. That's really a bit unfair of an assessment. I'd like to see what happens when an attractive man walks into a workplace that is all-women.
I'd like to see what happens when an attractive man walks into a workplace that is all-women
I've been in this situation a few times and it makes me feel incredibly terrified.
I've been in this situation a few times and it makes me feel incredibly terrified.
It can be for a number of reasons, but I doubt script kiddies are champions of feminism. If it's professional criminals, they won't care one way or another.
I'm not commenting on the situation at all. Just speculating.
I wouldn't have made that comment had I known that DDoSes on GitHub were not uncommon.
I wouldn't have made that comment had I known that DDoSes on GitHub were not uncommon.
> That's really a bit unfair of an assessment.
The point is that it should be acceptable in either circumstance, not that you shouldn't complain about what happens in an majority male environment because something analogous might happen in a majority female environment.
The point is that it should be acceptable in either circumstance, not that you shouldn't complain about what happens in an majority male environment because something analogous might happen in a majority female environment.
I don't know, it's happened frequently in the past as well.
What makes you think other sites aren't being attacked as well?
They have had some bad press lately....
These days when I see a GitHub post that they are experiencing a DDoS attack I have a slightly cynical reaction to it. I was at a software conference where we had thousands of people hitting GitHub to clone projects for workshops all that same time. They shut us down and said they were experiencing a DDoS... We were lucky that a couple of GitHub employees were at the conference and were able to contact the main office to get things straightened out.
Message about DDoS attack could cause another wave of DDoS performed by thousands of users continuously refreshing a website to see if it's up.
My company is in the process of moving from our own SVN server to using GitHub. Is this a bad idea in light of all these DDoS attacks recently?
Github still holds quite a lot of nines in terms of uptime. It's just that it's extra visible when something big like Github goes down.
The important part you should consider is to switch go git. I'd recommend starting to use Github, and if you find that it's down too much, look at alternatives or at hosting a solution yourself.
The important part you should consider is to switch go git. I'd recommend starting to use Github, and if you find that it's down too much, look at alternatives or at hosting a solution yourself.
No they don't now. Because of the recent DDoSes, they're at 99.93%.
It took about a day of mucking around, but we got a VPS up and running and we're using gitlab. (the software github is based on)
It works well for us. We just have to pay the price of a VPS and updating the system occasionally.
It works well for us. We just have to pay the price of a VPS and updating the system occasionally.
I've found that Github makes it so easy to work with clients of mine that the positives still outweigh the negatives.
That said, I have two pushes for two clients this morning that may not make it through in time for the status meetings.
If you have a company full of people, it may still be worthwhile to have a couple of them really learn git, and setup a git server internally.
[Edit: And my pushes made it through anyway. Still happy w/ github]
That said, I have two pushes for two clients this morning that may not make it through in time for the status meetings.
If you have a company full of people, it may still be worthwhile to have a couple of them really learn git, and setup a git server internally.
[Edit: And my pushes made it through anyway. Still happy w/ github]
When moving from svn to GitHub what you're actually doing is moving from a centralized svn system to a centralized git system.
The big difference is that in the second case you can keep working on your local repo without touching the central repo, at any time add new remotes to your local repo and pull and push from your peers.
If GitHub is down, you just keep working. If your svn server is down, you just pile your local work waiting for it to come back up, the tool will not help you in that case.
Moving from svn to git is a no brainer, even if you keep using it as if it were svn most of the time.
The big difference is that in the second case you can keep working on your local repo without touching the central repo, at any time add new remotes to your local repo and pull and push from your peers.
If GitHub is down, you just keep working. If your svn server is down, you just pile your local work waiting for it to come back up, the tool will not help you in that case.
Moving from svn to git is a no brainer, even if you keep using it as if it were svn most of the time.
If Github would only host git repositories, you'd be right. But people use Github for the issue tracker, source browser, code review system. Those are just as centralized as the svn server. And in my opinion, they are at least as important as a source control server to get things done.
Apparently they have been ddos'ed multiple times recently. I wouldn't have noticed, if it didn't appear on HN though. My impression is that they have people who are quite capable of dealing with these issues. I would rather have a provider that gets under attack, but has the resources to mitigate it, than one that is rarely attacked, but would be destroyed by it.
Well if you're only using GitHub for hosting the repo then you can still work with your copy of the repository while GitHub is offline (since you're in distributed not centralise version control territory).
Git has a file protocol so you can also just sync your changes between one another via a network share of your repo. Or SSH or email each other pull requests.
Git has a file protocol so you can also just sync your changes between one another via a network share of your repo. Or SSH or email each other pull requests.
Right, just communicate directly with your colleagues when GitHub is down. This is exact workflow Git was designed to work with.
Upside > Downside. I'll take 15 minutes of DDOS outage / month over hosting my own stuff anytime.
If you're too concerned, there is a self-hosted option, GitHub Enterprise.
Git works pretty damn good offline as well, sure you can't push to the server but its not going to be a show stopper if GitHub goes down for an hour.
I don't think so. I am still able to do all work through the command line (merge, commit) etc.
If anything this is just a minor annoyance to users. If whoever is responsible gets a kick out of DDoS'ing a site like GitHub for no rhyme or reason they really should find better things to do with their time, i.e. they are losers.
This is Chris Dodd and his new friends.
http://www.webupd8.org/2014/03/how-to-install-popcorn-time-f...
http://www.webupd8.org/2014/03/how-to-install-popcorn-time-f...
Let's look on the bright side... At least 2048 is up! ;-) http://gabrielecirulli.github.io/2048/
No. No! Nononononononooooooooo
...and let me help by trying to load the site. /dumbmonkey
GitHub's website loads pretty fine for now. The team is working on the traffic filtering now, the status page said.
[deleted]
The pinnacle of asshattery... This is why we can't have nice things...
Can this be a part of the story?
http://thinkprogress.org/economy/2014/03/19/3416013/github-j...
http://thinkprogress.org/economy/2014/03/19/3416013/github-j...
Wondering who is continuously DDoSign GitHub last time...
Seems like a waste of time for however is DDoSign.
Waste of time? Not really. Think of all the projects that rely on it for package management, plugins, etc. Think of all the companies using private Github. Lots of lost productivity.
Not really, you won't deploy live code from github and if you are it's decentralised anyway so you just use your latest private clones and it's exactly the same.
Everyone can keep working happily even using other syncing methods to collaborate.
At worst it messes with the issue queues and integration services.
Everyone can keep working happily even using other syncing methods to collaborate.
At worst it messes with the issue queues and integration services.
+1, As stated, this isn't affecting the git repos themselves. :)
Its back for me in Baltimore, MD