Network Testing

[Phantom139]

One of the first to-do items upon getting the engine to a usable state is to stress-test the networking system to actually pin down the proper limits on standard systems running the server.

This should also be a means to ensuring the networking system is properly implemented and that transmissions between the server and client and running as expected with no errors.

The system should also be fully tested for "hostile" packets such as Christmas Tree & DoS packet type attacks and proper countermeasures should be installed in the engine to prevent these packets from affecting gameplay, perhaps a lovely little ban on the sending client will do nicely.

[Phantom139]

With the recent DoS attacks on Xbox/PSN, I think it may be worthwhile to invest some research into preventative measures that could be incorporated onto the G2D server section of the engine. Some of the preliminary ideas that I had follow:

• Add a system to the engine with "ranges" of acceptable packet sizes, discard any that are outside of the range (block standard DoS attacks with large packet sizes)
• Add special packet flags to indicate the packet originates from a G2D/GS source (This restricts some online capabilities, unless they are "trusted" to hold the info)
• Block all requests outside of specified port ranges (Prevents Port Light Up Attacks over UPnP)

There may be more, but this is a topic open to discussion.

[Ragora]

The only real way to defend from one as far as my understanding goes is to have load balancing networks in front of your servers. Remember it's more of a network thing than it is code, though not to say maxing out your CPU and potentially memory bandwidth isn't a big part of it.

While you do have mitigation measures in place on the software, it won't be terribly difficult to produce a specialized attack for the engine due to the open source nature. Simply blasting your server with fake client connections (as per the fake T2 client you can find in Linker's gift), even if they don't auth correctly might be all they need. It's even worse if they can perform all of the authentication (if there is any) as then they don't even really need to blast the server with data to DoS your game as they can simply repeat this process to fill up the client slots.

All I can really see being done is the aforementioned steps along with trying to minimize the amount of data the server will process from unauthenticated clients. That is, minimize the amount of packet types that can be sent without properly authenticating first. So ideally you might have a handshake and some packet containing authentication information being transmitted at max where anything else will cause an immediate disconnect. This is assuming you're in a system where unique client keys can only be obtained by purchasing them so that not only do you need the time to write fake clients you'd also need the financial will to buy the keys to do it (and by doing so you give an easy method of getting yourself identified anyway).

You may be interested into developing systems that utilize operating system features such as the iptables on *nix boxes to perform more effective IP bans at the kernel level. Software such as Fail2ban does this, so you might want to look into writing rules for that, provided your software has enough log output to determine ban conditions.