The only computer at risk when it comes to net games is the server unless you''re handing out IP addresses to everyone from everyone which really defeats the purpose of a server.

To keep it secure run a port scanner on the server computer to see which ones are open and then check those ports from a remote location. The only ports that should be remotely accessible are the ones you wanted open.

Check for viruses and trojans on a regular basis. Use a firewall.

Don''t put messages in the server program that could be used maliciously like a "Delete map" message. Come up with a way to verify authenticity of messages as well.

The client can only do what you tell it to do. Just opening a port doesn''t magically give you the ability to run amok. You have to use whatever program is using that port to run amok. So unless your client has malicious code that can be remotly triggered there''s no worry.

Ben

[The Rabbit Hole | The Labyrinth | Programming | Gang Wars | The Wall]

I feel one should emphasize the buffer overrun thing more. If there is any local buffer that a client can overrun (e.g. in calls to functions like sprintf or strcpy), they might be able to execute arbitrary code on the server by overwriting the return EIP address and inserting the code on the stack, or by manipulating the return address so that it jumps into a library function.

Of course, actually executing code is made nearly impossible when the source code or the server executable aren''t available for the public, or if the position of the stack is variable, which is the case for threaded applications. However, you can still crash the server using buffer overruns.

It''s not too difficult to write secure code though. Use snprintf and vsnprintf instead of sprintf/vsprintf (on Windows, use _(v)snprintf). Use a buffer overrun-safe strcpy. strncpy is _not_ a good choice, since the destination string won''t be null-terminated in the case of an overrun.
And (obviously) never trust any size information sent by a client.

cu,
Prefect