Slashdot Mirror
Ubisoft's Authentication Servers Go Down
ZuchinniOne writes "With Ubisoft's fantastically awful new DRM you must be online and logged in to their servers to play the games you buy. Not only was this DRM broken the very first day it was released, but now their authentication servers have failed so absolutely that no-one who legally bought their games can play them. 'At around 8am GMT, people began to complain in the Assassin's Creed 2 forum that they couldn't access the Ubisoft servers and were unable to play their games.' One can only hope that this utter failure will help to stem the tide of bad DRM."
Well, right now it seems only the pirates are still going to play, while those legitimate customers will not. Reminds me of a quote I saw:
The Arch Demon's mantra has always been they will do it The Arch Demon's way once the pain becomes severe enough. However, it absolutely amazes The Arch Demon how much pain the IDOITS [legitimate customers in this case] can endure.
Actually, the proper term is Digital Restrictions Management.
DRM only exists to restrict, period. Any use of "Digital Rights Management" is due to marketing.
Hey, remind me of something: what are you talking about? It's not like network administrators have a magic "prevent DDOS" button.
DDOS's can take a couple hours to be noticed and a couple more to fix, and that's if it's something simple. They come in a variety of shapes and forms. If it's more complex, it won't be as easy as just turning off a port or access to something or IP filtering.
As an example, did you ever think that it's entirely possible that ubisoft DDOS'd themselves with their connection checking?
EA would never do that!
Would it make you happy if someone were to list every possible high-availability best practice we currently know, and make some inferences about the probable architecture and design of the system, applying each best practice to that aspect of the design? It's not like DDoS or high availability is a new thing, it's been around for quite some time. And you likewise contain no counterargument, just pointing out that there is nothing to argue against. You didn't add anything to the conversation, you proved no point, you certainly did not earn your informative moderation. Not that it matters to an AC. Why the hell am I even typing this? Oh well, here we go.
The simplest way to prevent DDoS in a situation like this is to have an front-end server (load balanced/clustered) which routes your request to either the authentication system (if your connection hasn't been authenticated) to validate the installation such as checking the license key and verifying whatever else they verify. Or if authenticated it goes to the "simply reply" server. Both of these servers can dynamically update the firewall rules on the front-end, or even before the front-end, if they have something like IPtables accepting input from a specific set of IPs on the intranet-facing rail. The front-end uses these to block any connections which send garbage data or try to re-authenticate using multiple license keys (brute-forcing) or basically try any type of connection other than the two allowed above - initial auth or continued ping. So you have 3 tiers for your IP addresses - initial (send to authentication), authenticated (send to keep-alive) and "other", which simply force-closes the connection, and the front-end redirects as needed. An expiration time of an hour or two should be sufficient, at which time it gets removed from the list and will go to authentication.
Customer service should be able to manually update the list to unblock you if you have a legitimate key. The only time a person should have to call customer service is if a continued DDoS is going on, and only if the user has a dynamic IP address or the DDoS is using spoofed IP addresses and managed to invalidate your connection. So this isn't an unworkable solution - it's a worst case high-call-volume type scenario, and a company would do everything in its power to keep paying customers working.
The front-end itself can have several IP addresses in the DNS entry, so you can scale up that part as needed.
The front-end deals with IP filtering, the second stage does request routing, and a server farm does either auth or ping. It would be trivial to create a list from the front-end so that the hosting provider can filter out the most egregious of offenders before it even hits the Ubisoft network. This is all pretty basic stuff, and most of it comes directly from reading other reports of DDoS and how it was handled.
At that point the only real problem is IP spoofing from a very large botnet, which would pretty much ruin your day. Even that has its defenses, but much trickier. It's unlikely that they planned for packet-inspection as part of the filtering, but anything that contains unexpected packet contents can be ignored, since you know what the client will be sending. Only a targeted DDoS would be effective then, crafting packets to appear to be legit.
Software could be optimized, for example if it's a simple database contention issue, or move to a RAID type solution allowing for faster access to the validation keys.
It's possible you're saying to yourself "Yes, but that won't prevent a DDoS, just mitigate it." I'll go ahead and address that before you post more rhetoric. "There are various techniques to battle against DDoS even on network level." Poster did not claim to completely prevent DDoS, just work around it.
Having said that, it's impossible to say whether they can use this particular description because we don't know whether they use authentication and keepalive, so the most we can say is either they implemented an unpro
Not mad - but rather, scripted. Deviate from the script = lose your job. It's the script writers that have killed intelligent responsiveness in the "customer interface department". No longer are people employed because of their knowledge of the subject, but because of their ability to "follow the script". Reminds me of a story of contacting BT's Tech Support on behalf of a friend. I told the woman (in India) what steps I'd tried (all the steps anyone which any person with reasonably high levels of IT literacy would try) and she then took me through scripted steps, all of which I'd already tried, all of which I told her I'd tried, and when none of them worked she said "contact your pc vendor" and hung up. She didn't know ANYTHING about computers, just how to follow the script on the screen. Not technical support at all really.