NetGamesRUs.com

NetGamesRUs is a sample company I have used in the past in talks I have given. It is a small organization with a midsize network and some specific needs.

Organization Overview

NetGamesRUs (NGRU) is an upstart gaming company in the world of massively multiplayer (MM) games. These games allow thousands of users from around the world to connect to the same server to take part in a game. MM games attract a devoted following that doesn't take too kindly to downtime and is even less tolerant of game bugs or cheats that allow a certain player to gain an unfair advantage over others.

After finishing the beta phase for its first game, NGRU quickly realized that it had a hit on its hands. The buzz on the Internet was that this game could sell over 100,000 copies in its first month of release. During peak times, the company estimates that as many as 10,000 people can be logged on to its servers.

Unfortunately, NGRU designed the infrastructure for the game back when it thought it would be lucky to sell 10,000 copies in the first 3 months. As such, NGRU needs an improved design that allows a high rate of throughput. Security wasn't top of mind during the game's development, but after seeing a competitor's customer database get hacked and the bad PR this caused, NGRU decided to hire a security professional, you, to come in and help improve its security in the 30 days leading up to the commercial release of the game.

NGRU has a staff of 30 in one location, mostly developers, some of whom work remotely. It has one dedicated IT staffer for both security and networking.

Current Design

The NGRU network is shown in Figure 17-1.

Figure 17-1. NetGamesRUs Current Network Design

The NRGU network is currently a flat internal network with a firewall between the internal network and the Internet. As you can see, all public services are in front of the firewall. This was done because NGRU didn't spend the money on a three-interface firewall when it built out the network originally. All public servers, including the gaming servers, are UNIX based.

All internal systems are unprotected beyond application security. Each game developer has a UNIX box for development, e-mail, and other work-related tasks. They also have a Microsoft Windows box that they use for game testing because Windows is the dominant MM gaming platform.

Security Requirements

The following are the basic network-relevant decisions related to the security improvements NGRU wishes to make. Some of the requirements are found in the security policy; others are derived from the policy's mandates.

Campus Security

The following are the security considerations in the campus network:

• Internal employees are trusted, in addition to being a very small group. Policies were written to encourage strong password selection, antivirus, host patching, and basic hardening, but internal security is left intentionally weak.
• All devices are stationary, so there is no wireless LAN (WLAN).
• Physical access to the building is basic lock and key.
• No inbound access to the campus network should be allowed as a default. (Exceptions are noted in the following sections.)

Edge Security

The following are the security considerations in the edge network:

• The public services (DNS, SMTP, HTTP) should be separated from the game servers, and both collections of hosts should be protected from attack.
• The game servers listen on User Datagram Protocol (UDP) port 4432.
• Remote workers should have a secure channel to access the internal network and the game servers.
• The availability of the game servers is of paramount concern.
• The customer database should be protected against direct attack from the Internet because it contains credit cards and other sensitive information.

Management

The following are the security considerations related to network management:

• Devices on the edge network should be managed securely when possible. Systems on the internal network can be managed using any available method.
• The game servers should not be managed over the same links that route the production traffic.

WARNING

At this point, you have enough information to design the network on your own. After you have tried your hand at the design, turn the page to compare your design to those in the book. Be sure also to consider how the network will migrate to the more secure design.

Design Choices

A number of factors drive the design. First, it appears that there isn't a lot of concern with internal security. With only 30 employees in one main location, user education and compliance with policies should be fairly straightforward. This allows the nontechnical compliance checks discussed in Chapter 2, "Security Policy and Operations Life Cycle," to mitigate the need for technical controls. For example, deploying a set of controls to mitigate DHCP attacks is overkill for 30 trusted employees.

Therefore, the focus of the changes needed to improve the security of the design is on the edge. Some sort of secure remote connectivity option is necessary; in this design IPsec is used. Because the edge servers must be better protected, a firewall with multiple interfaces is used to partition the traffic. Because high availability is a concern, multiple Internet connections are necessary.

The primary limiting factor from a security standpoint is that there is only one IT person for the entire network. As a result, the design must be easy to manage on a limited time budget and straightforward to troubleshoot.

The design that seems to meet the requirements best is shown in Figure 17-2.

Figure 17-2. NetGamesRUs Proposed Network Design

Here are some of the key elements of the design:

• High availability The high availability (HA) capability is primarily for the game servers, though it benefits the employees as well. Redundancy could have also been added at Layer 2 (L2) for the gaming servers, but because they are single homed on the Internet side, any failure will have a short period of downtime anyway. Using multiple switches could limit the failure to 50 percent of the servers, but at an increased capital cost for both the router interfaces and the extra switch. These edge routers are configured with standard hardening guidelines and edge best practices (Chapters 5, 6, and 13). They also send NetFlow and Syslog data to the management system in the internal network.
• Game servers The game servers are connected directly off of the edge routers rather than behind a firewall. Because the traffic is UDP based and nonstandard, a commercial firewall is not going to be able to do anything special with the traffic anyway. Instead, outbound access control lists (ACLs) are configured on the routers' Ethernet interfaces that allow connections to the game servers from the Internet to occur only on UDP port 4432. Although protecting the game servers with a firewall can provide some limited benefit, to realize the HA requirements for the game servers, two firewalls would need to be deployed, which increases the administrative load on the already-overworked lone IT engineer. Because the policy specified that management should occur over a separate interface, each production game server is dual homed to a separate subnet. This traffic passes through the firewall and is used only for content changes and general management. The game servers are hardened appropriately as discussed in Chapter 5, "Device Hardening." Although additional host controls can be deployed on these servers, exhaustive testing should occur to ensure compatibility with the game code. Checks such as file system integrity checkers will be easier to deploy than more complicated controls.
• Game server L2 switch The L2 switch that connects the game servers, Internet edge routers, and the firewall is using private VLANs (Chapter 6, "General Design Considerations") as a method of separating access on the different servers. Because the test server is likely less stable and more prone to security issues, it is set up as an isolated port separate from the other game servers (which could themselves be isolated or used on community ports, depending on how the game works).
• Corporate firewall The main firewall was replaced with one that supports four interfaces and has virtual private networking capability. Because the number of remote workers is very low, there is no need to deploy a dedicated VPN device. The firewall is configured to allow everything out and nothing in with the following exceptions:

  - Traffic between the HTTP server and the customer database server is permitted on the specific port used by the database server.

  - NetFlow and Syslog data is permitted from the edge routers to the management system.

  - Syslog is permitted from the game servers to the internal network.

  - Return traffic is allowed when initiated from the inside (such as basic Internet browsing, or management traffic from the edge routers or game servers initiated from the inside).

• Network management Besides the NetFlow and Syslog data from the edge routers and Syslog data from the game servers, Secure Shell (SSH) is allowed from the internal network to the game servers and edge routers. All internal management is in the clear unless the means with which to secure the communications are available for free (such as SSH on a UNIX system).
• Internal network The internal network is unchanged from the original design.

Notably absent from this design is any form of IDS. In reality, with the limited IT resources, an IDS could not be properly managed and would not add enough value to deploy. This is particularly true because the main asset, the game servers, is running a proprietary protocol and nothing else on the production side of the network. An IDS could not inspect that data properly anyway without a large amount of work building custom signatures.

Somewhat unusual for a design of this size is NetFlow analysis. Because of the concern about distributed denial of service (DDoS) and other improper uses of bandwidth, NetFlow gives NGRU a decent ability to detect anomalies in the traffic flows.

Migration Strategy

Because the network is relatively small and the game is not yet in full production, changes can be made fairly easily. The following broad steps present a plan to migrate to the design in Figure 17-2:

Because these changes are relatively contained and the network is fairly small, this entire migration could be completed quickly once adequate testing had been done.

Attack Example

Here are some attacks that would be likely against this network and how they might fare:

• DDoS This low-tech attack could certainly cause problems with this network, even with dual Internet connections. NetGamesRUs needs clear policies with its upstream Internet service providers (ISPs) to ensure that any attack is quickly dealt with. The NetFlow data it is analyzing will provide good visibility into these kinds of attacks.
• Game server attack Any successful attack is going to have to happen over the protocol on which the game runs. This means that the security of the game is up to the skill of the game developers.
• Public server attack The public servers are the easiest attack profile for an outside attacker. The lone IT staffer must ensure that the systems are adequately hardened, kept up-to-date, and properly monitored through system logs.