Furthermore, the design constraints for Internet games in general make easy-to-secure connections undesirable. Persistent TCP connections to known ports are just not suitable for most game-playing situations. Well-documented protocols are easier for players to interfere with, which game manufacturers rarely want, and in any case, game manufacturers are generally busy turning out documentation for users who just bought their first computer, and the manufacturers don't have much time to spare to document technical details so people can configure firewalls. (The most common firewall advice in game documentation is "You must not be behind a firewall.")
It is impossible to document the firewall characteristics of games in any detail. Games go in and out of favor rapidly, and even those that are persistent favorites change frequently. For instance, knowing that you want to play Quake doesn't predict what ports or even what protocols you will need; some versions of Quake require both TCP and UDP, while others use only one or the other.
A networked game is always a client, usually of a protocol with unknown features and security implications. One that can be a controller for a multiplayer game is a server of some sort as well. any games always provide both client and server features when they are running in a multiplayer mode. This means that running networked games may create vulnerabilities even if you do not connect to external players (if the game brings up a server, that server may be vulnerable to attack even if you don't initiate connections). achines that run networked games should be protected from incoming Internet connections.
Running plug-ins and extensions to games may change their security characteristics by adding new capabilities. If you have a game that you trust, don't upgrade it or change it without re-evaluating its security.
When Quake was originally written, the game developer, ID, put in a special feature allowing the developer to run commands on all Quake servers. These commands are not logged, and they don't have to be normal Quake commands (Quake can run external programs). On all platforms, you should be careful to run an up-to-date Quake server and/or to refuse packets from ID's corporate network (192.246.40.0/24) because the back door will allow attackers who forge packets from that network to run arbitrary (and unlogged) commands with the permissions of the Quake server.