How can I protect my server/client of DoS or hacker attacks (also cheating)? Can you block IP addresses already in hardware, so that DoS attacks of specific addresses are blocked before they reached the app? If this is not possible, how to handle them the best way? Is there something to prevent cheating (authentification) for each message? Something like PGP? Thanx for answers! -Nitro

As for the DoS attacks, those are pretty tough to deal with. Any worthwhile response here would just duplicate the volumes of articles already available by searching google.

As for the hacking, you can look into signing your network messages to ensure that they''re not tampered with between the client and your server, but if the person who controls the client wants to forge messages, that''s virtually impossible to prevent since they''d need access to the signing key for normal operation.

JonStelly is correct... it seems that you can’t answer a question these days without some form of debate erupting... as long as its constructive I suppose we all can learn something from the discussion.

With that, here we go... It’s my understanding that under Winsock 2 the use of AcceptEx() provides the server developer the ability to reduce the possibility of DoS attacks.

quote:

---

From Network Programming for Microsoft Windows, Second Edition, Chapter 6, pg 177
Another point to be aware of, which we mentioned in Chapter 5, is that if a receive buffer is specified to AcceptEx (for example, dwRecievedDataLength is greater than zero), then the overlapped operation wil not complete until at least one byte of data has been received on the connection. So a malicious client could post many connections but never send any data. Chapter 5 discusses methods to prevent this by using the SO_CONNECT_TIME socket option. The AcceptEx function is available on Windows NT 4.0 and later versions.

---

OK, I scoured Chapter 5 and did not find the discussion that was referred to in the above paragraph. Chapter 7 discusses Socket Options and Ioctls and the following is the description of SO_CONNECT_TIME.

quote:

---

From Network Programming for Microsoft Windows, Second Edition, Chapter 7, pg 205
SO_CONNECT_TIME is a Microsoft-specific option that returns the number of seconds a connection has been established. The most frequent use of this option is with the AcceptEx function. AcceptEx requires that a valid socket handle be passed for the incoming client connection. This option can be called on the client’s SOCKET handle to determine whether the connection has been made and how long it has been established. If the socket is not currently connected, the value returned is 0xFFFFFFFF.

This option is especially relevant in the case of AcceptEx . If an application posts an AcceptEx with a receive buffer, then the AcceptEx will not complete until data is received on the client connection. A malicious application could perform denial of service attack by making many connections without sending data. To prevent this, the server should cycle through all client sockets outstanding in AcceptEx calls to see if they have been connected but the accept has not completed. Refer to Chapter 6 for more details.

---

Those two paragraphs seem to have been thrown together as on refers to missing information in Chapter 5 and Chapter 7 refers back to Chapter 6... But, the point here is that it is possible to code a server such that it can defend itself against a DoS attack.

Anyone have more information regarding this? I’d really welcome a discussion of this topic...






Dave "Dak Lozar" Loeser

In his article on network programming, Dan Royer suggests that UDP OOB (out-of-band datagrams) may be used in server-client login communication. As he puts it, once a certain amount of data has been put in the OOB queue, no additional login requests would be permitted, thus "naturally" negating a DoS attack. Interestingly, he mentions this as the technique employed by the guys at id Software in Quake. I suppose that''s why you never hear of a Quake server being brought down by such an attack.

Find the article in flipcode''s Network Programming column and scroll to "Preventing DoS/Spamming attacks."

RapscallionGL - arriving soon.

Dan Royer states that it meight be the best to accept incoming login requests as fast as possible. Wouldn''t it be better to let one client per second (or other timeperiod) in so that you don''t have to bother with the load of logins? Of course this has the disadvantage, that non-hacker clients couldn''t log in anymore.

-Nitro

weird double post (I am sure I pushed just once)

[edited by - Nitrogenycs on January 7, 2003 9:08:02 PM]

I''ve been looking at the quake source. The OOB datagrams aren''t like TCP OOB data. They are just regular UDP packets that are sent outside of the regular reliable stream packets. The reliable stream packets also piggy back unreliable messages. Using the out of stream packets probably just lets you save memory and CPU time by not started a stream for people that aren''t connected yet. I haven''t looked at the connection code yet so I don''t know exactly how they are used yet.

So don''t go crazy looking for a way to send UDP OOB data like I did.

You can get a cleaned up version of the quake source code from
http://www.quakeforge.net/

Nitrogenycs, the last idea you had would just make it easier for someone to DoS you. A DoS is using up the resources for real players with fake data. Lowering the amount of resources for real players just makes this easier. You can keep track of ip addresses that appear to be sending fake data and give them less resources or no resources at all.

Secure programming is the most important thing. You can read more about it here.
http://community.corest.com/~juliano/secprog.html

You can''t trust input that you don''t control. If someone can send you data that will cause your program to crash or get caught in a loop they can DoS you easily. Stopping someone from using up all your bandwidth is almost impossible. You can block the DoS data at a point earlier in the network if you have that ability.

Encryption can help discourage cheating but will not solve the problem. Anybody good with a debugger can learn how your client works and insert bad data before it is encrypted. Encryption mostly is just useful to keep data safe between the client and the server.

The AcceptEx function sort of sounds like the OOB UDP data or syn cookies in that you aren''t starting up a full connection immediately.
http://cr.yp.to/syncookies.html

kdIXfA.gamedev.10.coreyh@xoxy.net
www.ipeg.com/~rlfc

Note that AFAIK all those methods involving cookies are targetted against IP spoofing connection saturating attacks.
If you have a server with a limited number of player slots (which is common in FPS games), an attacker could still occupy all slots and prevent other players from joining the server without forging her IP address. Maybe you should also disallow more than a certain number of connections (potentially per time) from a single IP address. IRC networks usually prevent more than 4 clients joining from the same IP address, for example. Note that multiple connections from the same host should be allowed because of NAT setups.

To prevent exploits that result in system compromises, you should follow the usual guidelines for writing secure software. Never trust user-(client)-supplied data, etc..

Cheat prevention is mostly a completely different topic. I like to classify cheats into three categories: Rulebreaking cheats (e.g. invincibility, more money/resources), Knowledge cheats (e.g. wallhacks or reveal map) and Doping (usually reflex augmentation cheats, e.g. aimbots).
The short answer is:
1. You can make rulebreaking impossible in a client-server architecture iff the server is trusted: simply eliminate all bugs and always treat client packets as change requests and not authoritative information. In a peer-to-peer architecture, you can ensure that rulebreaking results in a desync: make sure all peers verify the actions performed by all other peers. However, it will be difficult to judge who the guilty party is (which is a problem if you''ve got a global ranking system or similar).
2. There is nothing you can do to prevent doping.
3. Knowledge cheats can in theory be eliminated in a client-server architecture, although that is usually impractible because of bandwidth and latency limitations. In a peer-to-peer architecture, you can do nothing against knowledge cheats if you want to make rulebreaking impossible, and vice versa (personally, I''d make rulebreaking impossible and live with the knowledge cheats).

Note that this assumes that the potential cheater knows everything about at least the client software. You could always try security through obscurity of course.

Depending on your gamedesign, you might want to look into cheat _detection_ (and subsequent punishment) in addition to cheat prevention. If you''ve got a nicely hidden cheat detector that silently reports modifications to the program you might be able to increase the risk for potential cheaters so much that most of them won''t cheat.

cu,
Prefect

The best way to avoid cheating/hacking is to encrypt your data. For example xbox live uses Secure IP to ensure the integrity of the data and to foil proxy/listen type cheats.

To avoid DoS attacks, it depends on the attack. If they are spamming your router or network layer, there''s nothing you can do in code.

If they are targeting your application then its a design issue to help avoid/reduce the problem. You have to review all your code and think about what happens when you get malformed or corrupted data. Any place in your code where you crash, or spend too much CPU time processing bad data is a prime target. Make sure you have error handling, and make sure it is fast.

Encryption is great for the xbox where most people won''t be able to get the encryption key being used, but for PCs where the user can just run another program that looks through the memory of your application, any sort of encryption is eventually crackable if there''s enough desire and enough demand.

Encryption only protects from endpoint to endpoint. If one of those endpoints is compromised then encryption is easily defeated.