HB auth servers are hosted on a redundant dedicated connection. Even given that, there isn't much you can do against a 3TB/sec synflood that lasts hours.
There are three options:
1. IP block entire address ranges of botnets. Can't do this because then you block customers.
2. Put up firewalls that will autoban addresses who try to connect too many times. Can't do this because then you inevitably block customers.
3. Try to mitigate the damage while unfortunately dealing with the 2-3 hour outages once a week. This is the best current option.
(in before wired420 posts something I dont understand that would help

)
1.) First off. Most attacks are syn attacks with spoofed ips. So banning the ips do no good as these ips aren't even real that are being tagged on the syn packet. Your banning people that have never connected to your server and probably never will, which junks up the firewall and slows down system response time. You have to filter them, change some options and recompile your kernel. Also a lot of the filtering has to be done data center side. This data center seems lazy and would just rather ban everyone that connects for a while. Extremely bad business practice. A Data Center couldn't survive hosting large business sites using these practices.
2.) Putting up firewalls that auto ban address will not cause un-needed bans. If you have a user connecting to the auth servers more than 125 times in a min, this would be considered abusive anyways. In no shape or form should this bot have 125 socket connections open to server unless your running 125 bots really.
3.) The data center didn't try to mitigate. They were lazy and banned every ip that connected to server for hours. If you continue down this route your users will have to give you their ip's every time there is an attack and you'll spend hours reallowing them on phone and through emails with the data center.
All in all from as crappy as the attacks have seemed, with a couple of well place scripts, a cron job or two, some kernel modifications, to the auth server. I'm pretty sure I could've stopped the recent attack. When you pay for managed services from a data center they think they can do what ever because you'll think they are doing their best. Its usually much better to hire a volunteer or a true system admin to deal with such out side of just plain huge spoofed syn attacks, as they must be filtered and spread at the router. Theres also some tricks you can do with having multiple connection interfaces and shipping a batch script with the bot but I won't go into that publically.
I know you don't really want anyone messing with the servers cause its managed, but I can say in 14 almost 15 years of hosting, in multiple countries, I've never seen a data center respond as poorly, and slowly, to an attack thats as simple as this one. Some simple firewall rules and an open socket checker should've been able to stop this one. Honestly I believe I could kill the server with my home cable modem. Though I'm not going to try I've checked into your data centers network topology and its a mess to say the least.
Anyways. If you ever decide you've had enough of the attacks and want to attempt to stop them. You know where I can be found.
Also if you would like me to talk you though setting some basic stuff up or do it temporarily on volunteer status while I have free time I'd be glad to do so seeing as all my WoW accounts have been switched to perma ban from temporary. So I've just been sitting around playing a 20 year old text based mmo of sorts called a MUD lol.
PS) Let me reiterate again... SYN ATTACKS COME FROM FAKE IPS. Banning IP's does nothing but cause trouble you have to undo later, while the person can continue to syn attack you forever. It HAS to be filtered, or you have to attempt to make your kernel handle the large load caused by it by changing some options. All these ip bans were useless.
Syn flood's are an inherent flaw with the IPv4 Internet Protocol. Theres nothing you can do to fix them besides rewrite the entire internet. The only things you can do is filter it router side and disperse it over a large server farm, as I mentioned theres a few tricks you can do with multiple uplink interfaces to different ips, or set some settings in your kernel to handle it as best as possible. Banning block of ips is looked upon as a bad practice.