Network Design Considerations

Later in the chapter, specific designs and considerations for specific edge designs are presented. However, there are some considerations that apply to all designs. This section contains discussions of relevance to all sizes and types of edge design.

ISP Router

Throughout each of the edge designs presented later, your Internet service provider (ISP) will have a router under its control that can implement security functions for you as your policy requires. As discussed in Chapter 6, "General Design Considerations," be sure to work out this arrangement prior to signing up with your ISP and expect to pay more for the added security it provides. There are a number of functions this ISP router can do to improve the security of your network. They are as follows:

• Ingress/egress filtering Your ISP should be able to provide you bogon, RFC 1918, and RFC 2827 filtering at some point in its network. The closer it is to the router that handles your connection, the better.
• Unicast RPF Unicast reverse path forwarding (uRPF) is another mechanism to help your ISP implement ingress/egress filtering.
• Routing protocol authentication If you are passing routing protocols between you and your provider, using authentication is a good idea. Many ISPs are reluctant to implement this because managing keys for all of their customers is very time consuming.
• DDoS best practices This is the principal function your ISP must assist you with. Chapter 6 goes into detail on the various mitigation options your ISP has for distributed denial of service (DDoS) attacks directed against your network. Most ISPs prefer to turn on the mitigating technology at your request rather than leave it on all the time. Be sure to work this out with your ISP in advance. Remember that the best security on your end can't help you if your WAN link is filled with bogus traffic.

Number of Public Servers

As a rule, the greater the number of public servers, the greater your ability to segment the provided services, which increases security. This is because the compromise of one service does not automatically translate into the compromise of other services. This segmentation increases upfront and ongoing costs, however, since multiple servers must be provisioned, hardened, and monitored. For all but the smallest networks, which might be better off using an external hosting provider anyway, the DNS, HTTP, and SMTP servers should each live on separate devices because they generally make up the "triple crown" of public services commonly attacked. Of course, your own policies might differ from these, in which case your own decisions easily take precedence.

Branch Versus Head-End Design Considerations

If you have two or more locations for your organization, each will have a network edge at the point of connection between them. Often the extent of the security required at remote locations varies with their connectivity choices. The designs presented later in this chapter assume that the location is a head end (also called a central site) with full services required because these are generally more complex designs. The next four sections highlight specific design considerations around branch networks that provide fewer services than a central site.

NOTE

One of the principal considerations in remote site security deployments is management. If your IT staff is centralized, you must provide some mechanism to remotely manage these systems, which can prove very difficult. See Chapter 16, "Secure Network Management and Network Security Management," for more details.

 

WAN Only

Some remote sites have connectivity only to a central site by a private WAN. These networks have many of the same characteristics as an extension to your campus network. Often firewalling, intrusion detection, and encryption are not performed. (See Chapter 10, "IPsec VPN Design Considerations," for a discussion on encrypting private WAN links.) Assuming the physical security of the remote location is sound, a WAN router with some basic RFC 2827 filtering should be sufficient. If the remote site must be restricted from accessing certain central resources, this filtering can be done at the remote site first and then again at the central-site router, which should be under closer watch.

WAN-only designs typically utilize the central site for Internet connectivity. If your design has Internet connectivity at some of your remote sites, these Internet connections should be treated much like the Internet connections described in the remaining three subsections of this portion of the chapter. For example, if your remote site has a WAN link and an Internet connection used only for outbound access, the security requirements are much like the Internet VPN (No Services) branch design described in the following section.

Internet VPN (No Services)

Oftentimes, a branch location has only a single Internet connection as its means of connectivity outside its own network. Connection to the central site is provided by a VPN connection over the public Internet. The requirements for additional security are based on the decision you make regarding split tunneling. (See the section titled "Split Tunneling" in Chapter 10.) If split tunneling is allowed, most commonly an IPsec router is used with a stateful firewall to increase security. The firewall provides security for the branch users when accessing the Internet. Additional security mechanisms (IDS, proxies, and so on) often are not justified by the expense for all but the largest branches.

Internet (Limited Services)

On some occasions, a remote site has some services it wishes to provide to outside users. E-mail, for example, can be provided locally to reduce the strain on the central system (particularly in globally diverse organizations). In addition, web servers for the particular business functions that operate from the remote location can be appropriate.

In these cases, the design of the remote site generally mirrors a sparse design for a central site. All the same conventions are applied as usual (perimeter firewall interfaces, proper filtering, and other best practices). Be sure to implement this design in as efficient a manner as possible to minimize the management burden.

This efficiency must be tempered with the realization that your entire network is only as secure as the least secure Internet connection and user population. If a remote site is compromised, often the attacker can access the central site with few restrictions.

Internet (Full Services)

A remote site providing all the major Internet services might as well be considered a head-end location in terms of its security requirements. Such locations might require local IT support.

Remote Access Alternatives

In the edge designs in this chapter, there can be a wide range of external connectivity options: WAN, Internet, PSTN, VPN. Although Internet connectivity is probably essential for most organizations, the rest are not. The implicit assumption in the design of these connectivity options is that you might trust different technologies (or parties using these technologies) more or less. This generally means that most remote access connections pass through a layer of access control before connecting to the campus. Feel free to modify these designs as your own policy dictates. This can include connecting remote users directly to the campus without extensive security controls, or going in the opposite direction by tightly controlling each of these access methods.

An unintended byproduct of loosening security controls with remote access connectivity is that you have fewer options when it comes to mitigating the effects of an active attack. During the Code Red worm infestation, for example, many organizations had to limit remote access to the network since the systems using these remote connections were not as tightly controlled as the ones at the central site. This lack of control lead to reinfestations over these remote networks, which would be hard to stop without some choke points from your remote networks to the central site. Even if you must have the default policy of permitting all traffic, a choke point can be quite helpful during abnormal conditions on your network.

NOTE

Throughout this chapter, to allow this material to be later referenced, some of the text is repeated in places. This ensures that each design can be read without requiring an understanding of the other designs. Although I would certainly prefer that you familiarize yourself with each design, this isn't strictly necessary. If you decide to read these next few sections from start to finish, you might find yourself skimming sections, but beware that some distinctions between the designs are subtle, yet no less significant.