DDOS attack report of Elite & Alliance Mir 2

Join Discord

Far

tsniffer
Developer
May 19, 2003
19,801
29
2,203
400
Doesn't protect u from DDoS, you need external protection for that. But this protects the server against packet flooding.
This doesn't protect you from packet flooding. Just protects against connection floods.
 

Valhalla

Nexus Mir Developer
Dedicated Member
Nexus
Game Master
May 29, 2015
1,278
2
221
110
127.0.0.1
This doesn't protect you from packet flooding. Just protects against connection floods.
guessing it just limits how many sockets can be created per IP? havent looked into it yet as im at work
 

Far

tsniffer
Developer
May 19, 2003
19,801
29
2,203
400
guessing it just limits how many sockets can be created per IP? havent looked into it yet as im at work

Theres already a max connection per IP restriction in the files. But this changes means you're limited to 1 connection every 5 seconds (instead of just spamming to the max straight away).
 

Win

Elite Mir 2
Elite Mir
Game Master
Aug 13, 2020
239
1
114
45
Theres already a max connection per IP restriction in the files. But this changes means you're limited to 1 connection every 5 seconds (instead of just spamming to the max straight away).
"max connection per IP restriction in the files"

Isn't this flawed though that it still (previously) accepts the connection and doesn't return the method and previously only refused login? You can limit it to 10 per IP, doesn't stop someone from spamming 1000 connections at the server and crashing the server.exe as it shits itself.

If someone was to edit a client and copy paste Network.Connect(); a thousand times, your servers gonna go bang without this, which the max connection per IP doesn't work for previously.
 

Far

tsniffer
Developer
May 19, 2003
19,801
29
2,203
400
"max connection per IP restriction in the files"

Isn't this flawed though that it still (previously) accepts the connection and doesn't return the method and previously only refused login? You can limit it to 10 per IP, doesn't stop someone from spamming 1000 connections at the server and crashing the server.exe as it shits itself.

If someone was to edit a client and copy paste Network.Connect(); a thousand times, your servers gonna go bang without this, which the max connection per IP doesn't work for previously.

Yeah it wasn't written to stop connection spams - simply to prevent people from legit opening too many clients. If people were to just open 1000's of requests the max IP block wouldn't have been much use.

My point was that with the change you've put in above (which limits 1 connection per 5 seconds) the "Max IP" system already in the files will now mean connections are also limited.
 

Chriz

Captain Lurker
VIP
Mar 24, 2003
1,103
201
265
LOMCN
This doesn't protect you from packet flooding. Just protects against connection floods.
I dont think it would fully protect against connection floods either; inorder to determine the initiators IP the TCPClients RemoteEndPoint is used, which is possibly the only way to do it from .NET - but to get that information the socket must already be connected, atleast thats my understanding? Meaning you could in theory 'open' enough connections in a small amount of time and saturate the available listen sockets to prevent new connections establishing..

Its a step in the right direction though Win and will probably provide a level of protection - its good to cover as many bases as possible however Firewalls and DDOS protection services are probably better equipt for handling these senarios where you can limit the number of new connections for X IP within a certain threshold.

A good DDOS provider is: www.x4b.net - we used these guys when we banned a group of players from Artificial who then subsequently raised a very large DDOS on us for about two weeks - with enough traffic, it is extremely difficult to fully mitigate against these attacks through code alone.

Also using reverse proxys such as HAProxy with rate limiting abilities and also to 'hide' the real IP of the server can be another tactic, this allows you to have multiple endpoints for connections.

In terms of pack flooding, Heres a couple ideas - I'm not sure what is in place for Crystal, but on Artificial we limit the number of packets that can be processed within a loop cycle per player- (this should be set high enough that normal operations should never cause it to hit the limit)
1669740639328.png

Also have a hard limit of how many queued packets a player can send before they are forcefully disconnected:
1669740576896.png
 

Win

Elite Mir 2
Elite Mir
Game Master
Aug 13, 2020
239
1
114
45
I dont think it would fully protect against connection floods either; inorder to determine the initiators IP the TCPClients RemoteEndPoint is used, which is possibly the only way to do it from .NET - but to get that information the socket must already be connected, atleast thats my understanding? Meaning you could in theory 'open' enough connections in a small amount of time and saturate the available listen sockets to prevent new connections establishing..

Its a step in the right direction though Win and will probably provide a level of protection - its good to cover as many bases as possible however Firewalls and DDOS protection services are probably better equipt for handling these senarios where you can limit the number of new connections for X IP within a certain threshold.

A good DDOS provider is: www.x4b.net - we used these guys when we banned a group of players from Artificial who then subsequently raised a very large DDOS on us for about two weeks - with enough traffic, it is extremely difficult to fully mitigate against these attacks through code alone.

Also using reverse proxys such as HAProxy with rate limiting abilities and also to 'hide' the real IP of the server can be another tactic, this allows you to have multiple endpoints for connections.

In terms of pack flooding, Heres a couple ideas - I'm not sure what is in place for Crystal, but on Artificial we limit the number of packets that can be processed within a loop cycle per player- (this should be set high enough that normal operations should never cause it to hit the limit)
View attachment 29649

Also have a hard limit of how many queued packets a player can send before they are forcefully disconnected:
View attachment 29648
I think @Far is working on some packet flood protection, so this might be something relevant to his work.

The attacks we saw weren't smashing our network really, bandwidth wise it was easily handling it. The issue was purely the server.exe dying, I had absolutely no issues with the server itself. Basically 5 seconds and boom the server.exe will self-destruct from the incoming connections, as the application cannot handle it.

x4b is good to keep in mind though for an actual DDoS thanks, but I think the main work needs to be on the crystal files being able to process or discard the packets and connections.. or so that's been the issue over the past weeks.
 

Chriz

Captain Lurker
VIP
Mar 24, 2003
1,103
201
265
LOMCN
I think @Far is working on some packet flood protection, so this might be something relevant to his work.

The attacks we saw weren't smashing our network really, bandwidth wise it was easily handling it. The issue was purely the server.exe dying, I had absolutely no issues with the server itself. Basically 5 seconds and boom the server.exe will self-destruct from the incoming connections, as the application cannot handle it.

x4b is good to keep in mind though for an actual DDoS thanks, but I think the main work needs to be on the crystal files being able to process or discard the packets and connections.. or so that's been the issue over the past weeks.
Ah I see, I guess there could be somthing more specific at play then; Did you manage to capture logs or traffic data when it was occuring? Somthing like a wireshark trace might be useful if it happens again - to get an idea of what packet(s) are potentially problematic..

Or was it just the sheer number of connection requests?
 

Jev

When I'm Gone
Staff member
Moderator
Jul 21, 2020
1,575
7
653
135
Worthing, West Sussex
Ah I see, I guess there could be somthing more specific at play then; Did you manage to capture logs or traffic data when it was occuring? Somthing like a wireshark trace might be useful if it happens again - to get an idea of what packet(s) are potentially problematic..

Or was it just the sheer number of connection requests?
We did better, I managed to get ahold of the source code of the software being used to attack.
 
  • Wow
Reactions: zedina