GitHub: About This Week's Availability
github.com
github.com
Although github is sort of an odd target for them to be going after. Maybe their hired geeks are just testing their own software - github seems like the sort of place that would figure out how to defeat a DDoS attack, and by learning how, the black hats could improve their tools.
The youngster ends up in basically a run-down warehouse full of other kids each taught how to look for basic exploits like mysql injection or use root kits, and they sit around and do this all day.
This is why some countries are typically COEs for hacking, such as Russia with crimeware kits, and until recently Brazil for bank hacking.
This is also why you need coordinated efforts of special agents armed with assault rifles to clean out some spam-mills sometimes (they're taking them away from some mob).
What I've described is a bit outmoded, typically this behavior is turning into other things such as this: http://abh-news.com/cybercrime-china-hackers-training-camp-c... as well as the makers of exploit scripts are just getting better and recruiting these kids doesn't make sense any more... you can intelligently scan for millions of sites using phpmyadmin and automatically run your exploit with it.
As with any crime you find the trends all over the map: not all robberies are mob related, not all of them aren't, some of them are more elaborate than others, etc.
Your best bet is to move to a protected hosting provider (dragonara or ddoshostingsolutions are quite good for Europe / US). Failing that you can purchase a bunch of VPS servers, round-robin DNS to them and reverse proxy to your actual server (and keep that IP off the DNS system entirely). This way only the proxy servers will go down if you are attacked.
Edit: If they are not spoofing they sender address, you can achieve some success by mailing the hosting provider of the IP performing the attack. In 90% of cases the server has been hijacked and they will shut it down, this only works for US / European companies though since Chinese / Russian hosting providers never ever reply in my experience. For maximum success you can attach a tcpdump of the attack traffic.
Most of the cases though it's as simple as attack is 200 mbit and connection is 100mbit -> no amount of dropping packets once they reach the server will do anything, as the connection is entirely saturated.
I'm sure it was tempting more than a few people with the resources.
Edit: just to be clear I meant any reader of signal vs. noise could have seen that (and Jesse's #1 comment and the jokes about DDOS in the comments) and decided to pull a prank. 37signals would never do that to anybody.
There's a growing band of pirates (the web kind) who hold sites to ransom via their massive botnets, in exchange for payment -- 'protection money'.
- Github are obviously very successful and may have money - their clients are reacting quickly on twitter so attackers might think they have an edge in terms of pressuring
Especially depending on the sum of money demanded, I can imagine it being cheaper to either spin up more servers to handle the load, or hire a DDoS specialist to help you out, or make it someone else's problem by moving behind a thirdparty CDN.
Your logic is sound - why trust a criminal?
But it's not like there's a better business bureau from organized crime.
The rich and weak Frank empire, a bad combination, resorted to the disastrous policy of bribing the invaders to leave. It only served to mark the Franks as a good target and emptying the treasury. The Vikings would leave, plunder some other place and come back for more.
In the end, the Franks ended up giving part of their land on the coast : Normandy. This served to settle the invaders down while making THEM have to protect their newly acquired territory against other vikings.
Though it's easy to imagine that those guys think differently than I do.
Dear GitHub,
Although your product may sound boring to laymen, you provide a good service to a very important industry. Your "boring" day job reflects nothing on your personal and very exciting lives. Your customers, however, like you for what you provide them with, not for your companionship, and I'm sure your friends like you for the opposite reasons, as they very well should. In fact, everybody loves you for many reasons, and you are all very lovable. So please, keep your extra-curricular activities to your friends, and your work activities to your customers. You can call your friends "awesome" if that's your kind of thing, but for various reasons it is better to treat your customers with proper decorum. If you're unable to keep the two separate, you're in for some bitter disappointment later in life.
Love, everyone.
If you have known (and proven) legitimate traffic, give it a high QoS.
For never-been-seen IPs, provide a limited initial rate, with training based on experience.
Use tools such as the ASN Routeviews project to identify contiguous blocks of IP space (or any other source of BGP routing data, but the RV data are queryable via DNS and downloadable as zonefiles).
ID bad actors and either block or severely limit them.
Train up or down other traffic as appropriate.
This leaves you tracking large amounts of IP space. Doable in IPv4, somewhat more difficult under IPv6, though you're still probably going to be able to do something reasonable.
I'd like to see more of this pushed into the routing/networking layer, automatically, based on application-layer-based feedback. Maybe someday.
Indeed, why _would_ anyone want to DDoS github? How can we believe Github that the outages were due to a DDoS? They're smart people, aren't they using solid load balancesrs that can mitigate DDoS attacks? Why haven't they issued an actual statement describing the supposed attacks in better detail?
Which is why effective anti-DDoS means working with your upstream provider to figure out how to differentiate between real traffic and fake traffic. The best solution to a DDoS is the phone # of a tech that can implement firewall rules upstream and a good traffic analyzer to tell them exactly how to filter it.
Fortunately bots are usually pretty stupid. If you can outrun them on bandwidth, then change /victimpage.html to 302 to /victimpage-new.html. The web server or load balancer can send those redirects really fast and it doesn't take much bandwidth either. I have never seen a bot chase that redirect.
After a particularly nasty DDOS attack (where our upstream provider just shrugged their shoulders) I wrote an F5 iRule:
1. Check for the IAMNOTABOT cookie 2. If not there, redirect to /cookie-me?oldpage=the_page_you_were_trying_to_access 3. Set IAMNOTABOT=true cookie 4. Redirect to the old page
This requires the bot to interpret javascript, and it can easily be configured in nginx and other load balancers.
The way you deal with a DDoS is hard: you can try to identify distinguishing characteristics of the attack so traffic can be blocked as far out as possible and you try to figure out who's behind the attack so you can get law-enforcement involved. Otherwise you're just playing whack-a-mole with compromised home computers all around the globe…
"Some people just want to watch the world burn."
Organized crime extorting sites with DDoSes is certainly not unheard of, either.
Unless your regular traffic pattern has 10000x increases built into it, why would you spend all the extra expense to be able to handle that level of load?