3 ms·

First off, as others have said, disabling port 80 is a great way to handle this, I don't really care that much if I can see/use github the website for a few hou

by zheng 14y ago

First off, as others have said, disabling port 80 is a great way to handle this, I don't really care that much if I can see/use github the website for a few hours, but I'd be much more upset if I couldn't pull my code. Secondly, I kind of like when big sites go down when I'm not in desperate need because it means a really nice aftermath write up is on the way. Can't wait to hear more about this one.

adambard 14y ago
They didn't even disable https, so the site was still fully usable.
mst 14y ago
> "disabling port 80 is a great way to handle this" It's been a disaster for a bunch of people I know. git is distributed by nature so they all had extra remotes they could use. github's issues and other project metadata wasn't distributed, since that's github's alone. So all of the friends of mine who are corporate github users who were using git in a distributed style (a minority of their overall customer base, I would suspect) are more screwed by the web app's absence than they would have been by a repository problem. I suspect github made the right choice for their customer base overall, but I still find the anecdata interesting.
- kijin 14y ago
  The web app is also available on port 443, which every "corporate github user" should have been using anyway.
  - wfarr 14y ago
    In fact, all HTTP access redirects to HTTPS for just about everything. And most modern browsers (recent versions of Chrome and Safari) that have accessed a website over HTTPS once happen to _prefer_ HTTPS by default for that site.
huhtenberg 14y ago
> disabling port 80 is a great way to handle this They got lucky. What would be a great way to handle it if next time it's port 21 or 443?
- zheng 14y ago
  Like I said, disabling port 80 is a great way to handle this kind of attack. Those would obviously be trickier. I'm no network security expert, but I would assume that they are much more resilient to other attacks, as most protocols aren't as network intensive as TCP.

by zheng 14y ago

adambard 14y ago

They didn't even disable https, so the site was still fully usable.

mst 14y ago

> "disabling port 80 is a great way to handle this" It's been a disaster for a bunch of people I know. git is distributed by nature so they all had extra remotes they could use. github's issues and other project metadata wasn't distributed, since that's github's alone. So all of the friends of mine who are corporate github users who were using git in a distributed style (a minority of their overall customer base, I would suspect) are more screwed by the web app's absence than they would have been by a repository problem. I suspect github made the right choice for their customer base overall, but I still find the anecdata interesting.

kijin 14y ago
The web app is also available on port 443, which every "corporate github user" should have been using anyway.
- wfarr 14y ago
  In fact, all HTTP access redirects to HTTPS for just about everything. And most modern browsers (recent versions of Chrome and Safari) that have accessed a website over HTTPS once happen to _prefer_ HTTPS by default for that site.

huhtenberg 14y ago

> disabling port 80 is a great way to handle this They got lucky. What would be a great way to handle it if next time it's port 21 or 443?

zheng 14y ago
Like I said, disabling port 80 is a great way to handle this kind of attack. Those would obviously be trickier. I'm no network security expert, but I would assume that they are much more resilient to other attacks, as most protocols aren't as network intensive as TCP.