2

My coworker and I are developing an authoritative server for an MMO. We can't agree on how to handle "misbehaving" clients. Misbehaving, in this case, means clients who send "odd" requests that might indicate a compromised/altered client, or even a nefarious user injecting data directly into the communication stream.

One of us believes that the offending request should be aborted, the client's data saved, and the client's connection forcibly closed ("killed"). The other believes the request should be aborted and a "failed" response returned to the client.

We're at an impasse because we can't decide which approach is best. We've both generated arguments, but nothing has been sufficient to sway either of us.

For reference, here are some things we've considered:

  • Being disconnected results in an annoyance for legitimate users if we make a mistake coding the "misbehavior detection"
  • Killing the client eliminates the need for "clean up" response code.
  • If we don't kill the client, we might make a mistake and continue processing the bad request.
  • Killing the client prevents a compromised client from sending other potentially bad requests, at least until they log back in.
  • A disconnection may not do much to deter cheaters, whereas a denial response may elicit a "big brother is watching" feeling.

Any feedback on our arguments? Are there any other reasons for choosing one over the other? Is there some industry standard, or even a best practices consensus?

  • This is squarely a security question, definitely not at all SF, not even programmers.se - its not about "how to do it", the question is basically "what do we do with misbehaving users / requests". If this was on programmers.se, it should be migrated here. – AviD Aug 5 '14 at 10:17
2
  • Being disconnected results in an annoyance for legitimate users if we make a mistake coding the "misbehavior detection"

With proper code review, mistakes like these can be avoided.

  • Killing the client eliminates the need for "clean up" response code.

Although it is important to "kill" a malicious client in order to prevent further issues, personally, I would suggest gathering as much information about the malicious source prior to "killing" the client connection.

  • If we don't kill the client, we might make a mistake and continue processing the bad request.

Without shunning the malicious activity, you risk further exploitation.

  • Killing the client prevents a compromised client from sending other potentially bad requests, at least until they log back in.

This would ultimately depend on the architecture and the design of the game, but without knowing much details about the proposed MMO, this action would definitely be an immediate mitigation but it is important to log the source of the attack (date/time/src IP/dst IP/ports/protocols/attack type) for incident response. Although cyber attacks are inevitable, collecting the aforementioned data can help you detect, contain and eradicate any further threats.

  • Let me clarify "clean up response code" to mean the denial response being sent back to the client, as well as properly escaping the handler. We're already collecting a lot of information about the offender. – Xcelled Aug 4 '14 at 21:26
  • @Xcelled194 What are you planning on doing with the collected information about the offender? How will this information be handled? – injector Aug 4 '14 at 21:30
  • Right now, it's just going into an SQL table. Eventually, we might make tools to find patterns and so forth. But for now, we're just storing it. – Xcelled Aug 4 '14 at 21:44
  • Storing the offender information is smart, but I would definitely track behavior. Based on time/location/type of attack/etc I would recommend reporting the offender IP's to spam/blacklist sites. A quick google search can help you find some. Question: Do you have a mitigation plan for DDoS attacks? – injector Aug 4 '14 at 22:01
  • Not at this time, no, but we are bearing it in mind. Also, wouldn't that be the responsibility of the hoster, not so much us (the developers)? – Xcelled Aug 4 '14 at 22:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.