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.
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.
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.
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.
The following are the security considerations in the campus network:
The following are the security considerations in the edge network:
The following are the security considerations related to network management:
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.
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:
- 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).
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.
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:
The most pressing need is to protect the edge servers, so that should happen first. Add the outbound filtering to the edge router to protect the game servers (starting with the test server) and move the public services to an isolated firewall interface. (You must switch to the new firewall at the same time.)
Once you are sure the filtering is working properly, one of the game servers should get the second network interface card (NIC) card and be a test case for management from the firewall interface. Assuming this works well, all the servers can be migrated.
Add the second Internet connection and harden the new router the same as the first.
Configure private VLANs (PVLANs) on the edge switch.
Enable NetFlow and Syslog management to the management system in the internal network.
Configure the VPN functionality on the firewall for remote workers.
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.
Here are some attacks that would be likely against this network and how they might fare:
Part I. Network Security Foundations
Network Security Axioms
Security Policy and Operations Life Cycle
Secure Networking Threats
Network Security Technologies
Part II. Designing Secure Networks
General Design Considerations
Network Security Platform Options and Best Deployment Practices
Common Application Design Considerations
Identity Design Considerations
IPsec VPN Design Considerations
Supporting-Technology Design Considerations
Designing Your Security System
Part III. Secure Network Designs
Edge Security Design
Campus Security Design
Teleworker Security Design
Part IV. Network Management, Case Studies, and Conclusions
Secure Network Management and Network Security Management
Appendix A. Glossary of Terms
Appendix B. Answers to Applied Knowledge Questions
Appendix C. Sample Security Policies
INFOSEC Acceptable Use Policy
Guidelines on Antivirus Process