Glorious Alpha Two Testers!
Alpha Two Realms are now unlocked for Phase II testing!
For our initial launch, testing will begin on Friday, December 20, 2024, at 10 AM Pacific and continue uninterrupted until Monday, January 6, 2025, at 10 AM Pacific. After January 6th, we’ll transition to a schedule of five-day-per-week access for the remainder of Phase II.
You can download the game launcher here and we encourage you to join us on our for the most up to date testing news.
Alpha Two Realms are now unlocked for Phase II testing!
For our initial launch, testing will begin on Friday, December 20, 2024, at 10 AM Pacific and continue uninterrupted until Monday, January 6, 2025, at 10 AM Pacific. After January 6th, we’ll transition to a schedule of five-day-per-week access for the remainder of Phase II.
You can download the game launcher here and we encourage you to join us on our for the most up to date testing news.
Suggestion for DDOS Mitigation - for the Network Team
ArchivedUser
Guest
Hi Guys,
Here's a suggestion for Intrepid's Network Engineers:
Denial of Service Attacks can have an tremendous impact on game developers. If the DDOS attack prohibits users from attaching to servers, the players become frustrated, and look for other games to play.
I believe I have a solution that will help.
First, I'd like to describe the core issue of DDOS attacks. Denial of Service attacks focus (primarily) upon attacking the server that all clients must attach to. It could be an IP address or domain name. ALL clients need to know which server to attach to. If an attacker can overwhelm that server with invalid packets, legitimate clients wont be able to connect to it.
If you attempt to connect to "www.whitehouse.gov", and its under a DDOS attack, you wouldn't be able to access the website. It doesn't matter if the administrator changes the IP address of the domain, because the DDOS will still attack the URL (server name), which cannot change. If he attempted to change "www.whitehouse.gov" to "www.somethingelse.gov", who would know where to browse to?
<strong>KEY POINT: </strong>
That's the difference between a DUMB web browser, and a smart game client. A game client can connect to a variety of different URLs to log into a game server. A web browser has to go to "www.whitehouse.gov".
<strong>IMPLEMENTATION:</strong>
With the wonder of the "cloud" the developer can spin up a "Google Compute Engine" instance in seconds (the Devs have hinted at using google cloud resources). This instance, by default has a random IP assigned to it. The administrator can then set a static IP or continue to use the random IP address.
How do you connect to a server that's been assigned a random IP (throw away IP)?
Its not possible with a web browser, because the URL "www.whitehouse.gov" would need to be mapped to it, thereby redirecting the DDOS attack to the new server. But it IS possible with a game client. Here's How...
Program the client with an encrypted list of URLs (domain names). The client randomly selects one of the URLs to connect to. If that URL is unavailable, have the client to fail over to another URL in the list.
<ul>
Here's an example of server names:</ul>
ashes324v23.ashesofcreation.com -> 1.1.1.1 (throw away IP)
ashesacvfe2.ashesofcreation.com -> 2.2.2.2 (throw away IP)
ashes324jky.ashesofcreation.com -> 3.3.3.3 (throw away IP)
ashes9a8d7f.ashesofcreation.com -> 4.4.4.4 (throw away IP)
ashes5464j3.ashesofcreation.com -> 5.5.5.5 (throw away IP)
After a period of time, a hacker would eventually learn the server names. How does a game developer could keep a hacker from learning all the names.
<strong>HERE'S HOW:</strong>
One, have a few static names hard coded in an encrypted table, much like the ones above.
Two, replace those names every time a new revision is released.
Three, develop an algorithm that can compute new names based upon the date. Something that can be computed by the developer, so that the servers exist when the clients compute their names. The algorithm can ALSO be modified with each revision of the client.
<strong>WHAT DOES THIS DO?</strong>
First, there's a list of server names that clients are guaranteed to connect to, even if their PC is set to the wrong date. With each update, those names can change. So there's a small possibility of all of them being attacked by a DDOS at the same time. Then there's the "Random" list of names that are computed by the client and server administrator. This list wouldn't be known until the date at hand. And would exist for a short period as a server name, before a new instance in generated. Once again, to keep the hacker from deducing the algorithm, it could be modified with each update of the client (possibly with a random seed).
Once the client "Logs In" the administrator has the ability to redirect them to whatever IP they want. A hacker "player" may be able to affect a few users by targeting that redirected IP, but the administrator would INSTANTLY know who was performing the attack. They could isolate that user (and ban them), and they could move legitimate players to a different server.
By using "Throw Away" login servers with throw away IP addresses, the issue of a DDOS attack is mitigated.
What do you think?
It's important to note that I'm speaking of "Physical Servers" and "Virtual Servers", and not "Game Servers" or "Game Instances". Most MMOs run on more than one physical server, even though the player sees it as a single "game server".
Here's a suggestion for Intrepid's Network Engineers:
Denial of Service Attacks can have an tremendous impact on game developers. If the DDOS attack prohibits users from attaching to servers, the players become frustrated, and look for other games to play.
I believe I have a solution that will help.
First, I'd like to describe the core issue of DDOS attacks. Denial of Service attacks focus (primarily) upon attacking the server that all clients must attach to. It could be an IP address or domain name. ALL clients need to know which server to attach to. If an attacker can overwhelm that server with invalid packets, legitimate clients wont be able to connect to it.
If you attempt to connect to "www.whitehouse.gov", and its under a DDOS attack, you wouldn't be able to access the website. It doesn't matter if the administrator changes the IP address of the domain, because the DDOS will still attack the URL (server name), which cannot change. If he attempted to change "www.whitehouse.gov" to "www.somethingelse.gov", who would know where to browse to?
<strong>KEY POINT: </strong>
That's the difference between a DUMB web browser, and a smart game client. A game client can connect to a variety of different URLs to log into a game server. A web browser has to go to "www.whitehouse.gov".
<strong>IMPLEMENTATION:</strong>
With the wonder of the "cloud" the developer can spin up a "Google Compute Engine" instance in seconds (the Devs have hinted at using google cloud resources). This instance, by default has a random IP assigned to it. The administrator can then set a static IP or continue to use the random IP address.
How do you connect to a server that's been assigned a random IP (throw away IP)?
Its not possible with a web browser, because the URL "www.whitehouse.gov" would need to be mapped to it, thereby redirecting the DDOS attack to the new server. But it IS possible with a game client. Here's How...
Program the client with an encrypted list of URLs (domain names). The client randomly selects one of the URLs to connect to. If that URL is unavailable, have the client to fail over to another URL in the list.
<ul>
Here's an example of server names:</ul>
ashes324v23.ashesofcreation.com -> 1.1.1.1 (throw away IP)
ashesacvfe2.ashesofcreation.com -> 2.2.2.2 (throw away IP)
ashes324jky.ashesofcreation.com -> 3.3.3.3 (throw away IP)
ashes9a8d7f.ashesofcreation.com -> 4.4.4.4 (throw away IP)
ashes5464j3.ashesofcreation.com -> 5.5.5.5 (throw away IP)
After a period of time, a hacker would eventually learn the server names. How does a game developer could keep a hacker from learning all the names.
<strong>HERE'S HOW:</strong>
One, have a few static names hard coded in an encrypted table, much like the ones above.
Two, replace those names every time a new revision is released.
Three, develop an algorithm that can compute new names based upon the date. Something that can be computed by the developer, so that the servers exist when the clients compute their names. The algorithm can ALSO be modified with each revision of the client.
<strong>WHAT DOES THIS DO?</strong>
First, there's a list of server names that clients are guaranteed to connect to, even if their PC is set to the wrong date. With each update, those names can change. So there's a small possibility of all of them being attacked by a DDOS at the same time. Then there's the "Random" list of names that are computed by the client and server administrator. This list wouldn't be known until the date at hand. And would exist for a short period as a server name, before a new instance in generated. Once again, to keep the hacker from deducing the algorithm, it could be modified with each update of the client (possibly with a random seed).
Once the client "Logs In" the administrator has the ability to redirect them to whatever IP they want. A hacker "player" may be able to affect a few users by targeting that redirected IP, but the administrator would INSTANTLY know who was performing the attack. They could isolate that user (and ban them), and they could move legitimate players to a different server.
By using "Throw Away" login servers with throw away IP addresses, the issue of a DDOS attack is mitigated.
What do you think?
It's important to note that I'm speaking of "Physical Servers" and "Virtual Servers", and not "Game Servers" or "Game Instances". Most MMOs run on more than one physical server, even though the player sees it as a single "game server".
0
Comments
Most volumetric DDoS mitigation strategies today are aimed at offloading traffic to the data center's network through a distributed series of scrubbing centers that remove the offending DDoS traffic before returning the cleaned traffic to the data center. Gaming companies generally can't afford to overbuild their data center infrastructure by 10-100x just to absorb DDoS attacks, and this "cloud scrubbing" approach has proven to be one of, if not the most, effective means to address them.
Except...
In the cloud environment, servers don't have to reside within the same subnet. If you have experience spinning up Amazon EC2 instances, or Google GCE instances, you would see that they could conceivably be in completely separate geographic regions. So, they don't have to reside on the same router or switch. This mitigates network resource overload.
The throw away suggestion still addresses that issue. And a throw away IP address could conceivably be in use for only 48 hours before its given back to Google so it can be reallocated to another Google customer.
Also, once again.. Cloud instances are easy to spin up, and shut down. And you're only billed for when they're running. So, the cost is minimal, and isolated to the servers in use.
However...
In the cloud environment, servers don't have to reside within the same subnet. If you have experience spinning up Amazon EC2 instances, or Google GCE instances, you would see that they could conceivably be in completely separate geographic regions. So, they don't have to reside on the same router or switch. This mitigates network resource overload.
The throw away suggestion still addresses that issue. And a throw away IP address could conceivably be in use for only 48 hours before its given back to Google so it can be reallocated to another Google customer.
Also, once again.. Cloud instances are easy to spin up, and shut down. And you're only billed for when they're running. So, the cost is minimal, and isolated to the servers in use.
Use "Throw Away" servers
Use "Throw Away" server names
Use "Throw Away" IP addresses (not restricted to subnet or infrastructure)
For ALL client facing servers.
If a botnet, attacks any of the above, spin up a new instance and throw the old one away. Heck... Throw them away whenever you like. There's no difference between running 1 server for 30 days, or 30 servers for one day.
That's not something you can do with a web server.
This all breaks down when you're talking about game servers. Clients *must* maintain a persistent connection to the game server in order for the game to function. This is intrinsically tied to the functionality of TCP/IP (predominantly UDP when it comes to games) and cannot absorb a change in IP address without disruption. Were they to attempt an IP rollover as you suggested for a game server, it would disconnect every player who was currently connected, who would then have to restart the client to connect again. This would be more disruptive then most DDoS attacks.
That said, there is probably a means to address this by handing off live connections to alternate servers before taking one out of service. I know this technology was used in World of Warcraft for zone-to-zone travel. However, it will likely be simpler for Intrepid to rely on Google to mitigate DDoS attacks against their cloud computing facilities, as well as having a broader impact to maintaining their service. This only really becomes an issue if Intrepid intended to begin hosting their services in their own data centers.
Exactly! You have the gist of it.
Transition from one server to another would behave just like a player passing from one transparent zone to another.
The problem for me is you have put all your eggs in one basket or gateway funnel if you like.
You have created a whacking great target with bullseye on it that can be targetted in the first place.
Throw up 1000 targets and that DDoS attack has a problem.
The more you fragment their trafffic the less effective the attack is.
It nullifies the distributed part of the denial of service.
Its like the herd vs predator issue.
Safety in numbers.
For me the best solution is a cluster of relay gateways.
If one is targetted and has bad ping the clients simply jump to another.
The relay cluster can even notify each other and the clients of addresses to use.