Games (Building Internet Firewalls, 2nd Edition)

23.2. Games

Internet games are a lot of fun. Unfortunately, game designers are rarely security experts, and many of the same people who attack computer systems are attracted to Internet games. That's not to say that Internet gamers are inherently bad people; most of them are fine upstanding citizens. On the other hand, the primary audience for Internet shoot-em-ups is the same crowd of adolescents with computers and free time that attackers come from, and it would be a miracle if there weren't a lot of overlap between the two cultures. If you take an application that wasn't designed for security, put it on a network, and hand it over to people who like to attack computer systems, the result is predictable and not very pretty.

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.

23.2.1. Quake

Quake, in its many and varied versions, is one of the most popular Internet games. It also has a long and sad history of security problems, particularly in its Unix versions. You should not run any Quake binaries as root, regardless of what the documentation says; Quake servers are susceptible to remote attacks, and Quake clients running as root can be exploited by local users.

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.

23.2.2. Summary of Recommendations for Games

Don't allow games through your firewall if you have a choice. It may seem cruel to block harmless amusements, but they carry real dangers.

If you want to run a game server, use a victim machine with nothing else on it that you care about.

Install games with great care. It is almost never safe to run either servers or clients as a privileged user.