Medium Network Edge Security Design

The medium network edge is designed to support greater throughput, security, and connectivity options as compared to the small network design.

Design Requirements

This design must provide Internet, PSTN, and private WAN connectivity to the outside world. Depending on the network service needed, one or more of these connections can be used. The requirements of the design are as follows:

• Internet connectivity
• Public servers (e-mail, WWW, etc.)
• Site-to-site VPN (to branch locations)
• Remote user VPN tunnels (for remote or traveling workers)
• Remote user dial-up (through PSTN)
• Private WAN connectivity

When compared to the small design, the medium design makes many of the previously optional functions defaults. It is expected that an organization using a network of this size has greater resources to allocate to security. This allows for separating security functions as a deliberate design goal as well. Management requirements for this design are also increased.

Design Overview

This might be the design most similar to many readers' current networks. It applies many of the best practices discussed throughout this book in a way that balances both security and performance. If you aren't sure which of this chapter's three designs to use as a base for your own security design, start here.

The Internet portion of the connectivity looks much like the high-security alternative of the small design. Added to this is PSTN dial-up and private WAN connectivity. See the following alternatives section for options on this. Figure 13-6 shows an overview of this design.

Figure 13-6. Medium Network Edge Design

Internet Edge

This section outlines specific design considerations and deployment recommendations for each element deployed in the design. Table 6-1 lists all the technologies and best practices from which these design-specific lists were drawn.

Internet WAN Router

In the medium design, a dedicated WAN router is used to handle all routing functions and does some basic security filtering to narrow the field of attack for the firewall.

Some of these security functions are also implemented at the firewall for added protection, but the filtering is expected to be done on the WAN device. This keeps your firewall logs more focused on valid attacks rather than "noise." The key security techniques configured on the Internet WAN router are as follows:

• Network device hardening This device should have its configuration hardened per the best practices in Chapter 5.
• Ingress/egress filtering RFC 2827, RFC 1918, and bogon filtering should be implemented here. This reduces the amount of data generated daily by your firewall log, making it easier for a firewall administrator to notice advanced attacks.
• Unicast RPF Similar to ingress/egress filtering, uRPF can be implemented on the WAN router as an alternative to ACL-based ingress filtering where appropriate.
• ICMP best practices ICMP filtering should be implemented on the router following the guidance in Chapter 6.
• Routing protocol authentication Most Internet WAN routers for networks of this size use static routes only. If you are using routing protocols, authentication is almost always a good idea.
• DDoS best practices Although your ISP occupies the pivotal role in DDoS threat mitigation, technologies such as CAR can still be optionally implemented at your location. This becomes "good neighbor" filtering, preventing your network from sourcing certain types of DDoS attacks.

Stateful Firewall

Perimeter security is centered primarily around a stateful firewall that can also have other security functions. This depends on the performance requirements of the device, the capabilities of the firewall you are deploying, and the management infrastructure you set up. This section assumes that only stateful firewall capabilities are available, in keeping with the separation-of-security-function design goal stated earlier in this section. Chapter 7 discusses basic firewall filtering guidelines. The key security techniques configured on the stateful firewall are as follows:

• Stateful FW Stateful access control should be implemented on this device.
• Network device hardening This device should have its configuration hardened per the best practices in Chapter 5.
• Ingress/egress/uRPF filtering RFC 2827, RFC 1918, and bogon filtering can be implemented here per Chapter 6. Depending on the extent to which you treat your WAN router as a security device, you can avoid doing this filtering on the firewall as a backup. Certainly, implementing the entire bogon filtering range isn't necessary at two devices and will only muddle the firewall's configuration. Specific ingress/egress filtering related to the interfaces directly connected to the firewall should still be done.
• ICMP best practices ICMP filtering should be done on the firewall per Chapter 6.
• Routing protocol authentication Depending on your stance toward routing on firewalls, you might have the firewall participating in your internal routing protocols. If so, routing protocol authentication should be required because of the security risks of false routing being introduced to the firewall.
• TCP SYN best practices Mitigating the effects of TCP SYN floods should be done on the firewall for hosts that don't have their own robust TCP SYN flood defenses.

NIDS

Dedicated signature-based NIDS devices are deployed at two points in the network per the recommendations in Chapter 7. First, one is deployed on the public server segment to protect the hosts there. The second NIDS is deployed behind the main firewall to act as a check of traffic to and from the campus network. The key security techniques configured on the NIDS are as follows:

• Network device hardening These devices should have their configuration hardened per the best practices in Chapter 5.
• Signature-based NIDS These devices should be tuned to detect the attacks most prevalent in the area of the network where they are deployed. Refer to the threat list earlier in this chapter for the key threats and to Chapter 7 for information on NIDS tuning.

Ethernet Switch

There are numerous Ethernet switches in this design. Recommendations that are specific to a given switch are called out as such. Although these multiple switches could be combined to a single switch using VLANs, be sure to familiarize yourself with the VLAN issues discussed in Chapter 6. I would not recommend that it be done, although there are reasons beyond just security that can make this a requirement (financial, rack space, and so on). All of these technologies are discussed more fully in Chapter 6. The key security techniques configured on the Ethernet switches are as follows:

• Network device hardening These devices should have their configuration hardened per the best practices in Chapter 5.
• L2 control protocol best practices All Ethernet switches in these designs should account for the L2 control protocol best practices discussed in Chapter 6.
• Port security Port security should be configured on the public server switch only because an attack that successfully compromises a host on this network could use MAC flooding to gain access to data on other ports of the switch.
• VLAN hopping best practices Although VLANs are not needed on these switches to support production traffic (assuming you don't combine security zones on a single switch), they are needed to support secure management of the device.
• ARP best practices If ARP inspection is available on the switch used in the public server network, it should be enabled. Because the threat of ARP spoofing is low in this area of the network, ARP inspection is not a requirement.
• Private VLANs Private VLANs should be configured on the public server switch to separate public servers with no need to communicate directly with one another.

Public Servers

In the medium network design, fairly strong host security controls are recommended at the edge. This should be the first requirement in your design. If you don't have control over your hosts, the security benefit that the network can provide is significantly weakened. The key security techniques configured on the public servers are as follows:

WARNING

The medium network edge topology should not be used for e-commerce, which has unique requirements and is further discussed later in this chapter.

• Reusable passwords Despite their general weakness, when providing public services to the Internet at large, you cannot expect anyone to use more advanced identity functions. In extranet environments, described later, such controls are possible.
• PKI/sessionapp crypto If any of your public servers are providing HTTPS connections to clients, you will want a certificate from a trusted root on the Internet. Despite the specious amount of assurance digital certificates provide in this role you don't want your users to have the dialog box in their browser informing them of a certification failure.
• OS/application hardening This is by far the most important step to securely deploying any public server. Be sure to properly harden the OS and any applications as identified in Chapter 5.
• File system integrity check This should be done on every server in your edge network.
• Host antivirus/host IDS Both technologies should be deployed before deploying network IDS or other exotic network functions.
• E-mail filtering On your public mail server, e-mail virus scanning should be configured to act as a first line of defense for your internal users. See Chapter 8 for more information.

Remote Access Edge

This section highlights the various ways remote users and sites can access the medium network edge to reach services there or inside the campus. As a general rule, access to the organization over private infrastructure is considered trusted and does not receive the same security attention as access to the organization over a public infrastructure.

Both VPN and PSTN dial-up are considered public, which means each has similar security mechanisms applied. If, from a policy standpoint, you trust the VPN and dial-up connections the same as you might trust internal users or a private WAN, feel free to bring these connections straight into your campus network. Make sure this is an informed decision, though, based on the content discussed so far in this book. Most prefer some security for these connections, and the designs presented here reflect that.

VPN

In the medium network design, a dedicated VPN device is used for site-to-site and remote user VPN. The implicit assumption in this design is that the number of remote users is moderate and the number of remote sites is small (<10). As soon as the number of remote sites and users increases, it might be more cost effective and easier to manage to use a dedicated remote user VPN gateway and a GRE + IPsec VPN router for site-to-site. (This alternative is described at the end of this section.) As still another alternative, site-to-site VPN can be done on the firewall (if supported), leaving the dedicated VPN gateway just to handle remote users. See Chapter 10 for more information on IPsec design considerations. The key security techniques configured on the VPN gateway are as follows:

• Network device hardening This device should have its configuration hardened per the best practices in Chapter 5.
• Router with ACL The Internet WAN router should be configured with outbound ACLs blocking non-VPN traffic to the VPN gateway.
• Network crypto IPsec VPN tunnels are established to remote users and remote sites per the recommendations in Chapter 10.
• OTP OTP identity checks occur for all remote user VPN connections.

Site-to-Site

Preshared keys are used for all peers (assuming a small VPN). As mentioned in Chapter 10, once you exceed 25 sites, digital certificates should be used. Basic IPsec is probably sufficient, although if you have any of the requirements that point to GRE + IPsec (routing, multicast, and so on), it is appropriate to deploy here.

Remote User

Remote user VPN connectivity can be done on the same device using group preshared keys for phase 1 and OTP as extended user authentication (Xauth).

WAN

The private WAN network is very simple in this design, consisting of a single router. This design assumes the private WAN is considered trusted. As such, it is routed behind the firewall. Even still, WAN traffic is subject to the NIDS behind the firewall as a check. If the WAN is not trusted, some combination of firewalls on your WAN routers and IPsec encryption for the links should be considered. The key security techniques configured on the WAN router are as follows:

• Network device hardening This device should have its configuration hardened per the best practices in Chapter 5.
• Router with ACLs If you have need to do any basic Layer 3 (L3) filtering to limit access to specific networks to or from the WAN, it can be implemented on the WAN router with basic ACLs. Most networks don't need filtering here except for RFC 2827, which is most easily implemented with uRPF.
• Unicast RPF uRPF should be implemented on this router to enforce RFC 2827 filtering in either direction.
• Routing protocol authentication Because private WANs generally use routing protocols, routing authentication is almost always a good idea.

PSTN Dial-Up

Although certainly not a requirement, in most networks of this size there is some form of legacy dial-up access to the organization. More and more, networks are outsourcing this function to nationwide ISPs and using VPN from there.

Because most networks still have this function, it is included in the edge design. A dedicated network access server (NAS) is used for dial-up and then is routed through the firewall in the same way as VPN traffic. Extensive filtering on the firewall can occur, or the firewall can act only as an audit check and NIDS enforcement point. The key security techniques configured on the NAS are as follows:

• Network device hardening This device should have its configuration hardened per the best practices in Chapter 5.
• Router with ACL Basic filtering can occur on the NAS if needed. Filtering is also available on the main firewall.
• OTP OTP identity checks occur for all dial-in users.

Design Evaluation

You can now evaluate the success of this design against the edge-focused threat list in Table 13-1. If you recall Chapter 12, this step appears a bit out of order because threat evaluation should also occur during the design of the network, not just after. It is presented in this form to ease understanding of the designs and threats.

Table 13-3 shows the top 10 attacks from Table 13-1 and shows the security elements used in this design that mitigate these threats as they pertain to general Internet connectivity and public server access.

As you can see by reviewing the preceding table, hardening devices is easily the most important thing you can do to improve security. Following that, the various flavors of IDS do a good job detecting many of the top attacks. Perhaps most interestingly, a stateful firewall, typically a mainstay of network security, stops only two out of the top 10 attacks. A number of functions that the firewall provides aren't fully represented in the table, though, and I'm certainly not suggesting that firewalls not be used. By evaluating the types of technologies that detect or stop the different attacks, you can gauge the level of defense-in-depth you have achieved for a given attack.

It is also worth noting that Tables 13-2 and 13-3 are nearly identical to one another. However, for the medium network design, technologies are distributed among more devices, which isn't represented in the table. Since the functions of those devices can be more tuned than in the small design, the level of security you can achieve should be higher. Also remember that by separating the functions you generally achieve faster performance and more scalability.

Remote Access Design Evaluation

The threats related to the remote access edge are slightly different than the Internet edge as a whole. Direct access and identity spoofing are the principal threats to VPNs. Both of these threats are stopped by a combination of network crypto and OTP identity mechanisms. For PSTN dial-up access, the threats are the same. Because there is a direct connection from the user to the organization, OTP is generally used without any network crypto. WAN access is generally considered trusted. Even if it were untrusted, most attacks transit the WAN to targets in the campus or Internet perimeter, leaving the WAN unaffected. As discussed in the WAN section, the routers should be hardened, and minimal ACLs can be applied as needed.

Design Alternatives

Any design has several alternatives. As the design increases in size, so do the options for modifying it. The following section outlines some of the major options for the medium network edge design. Of course, the most important alternative design is your own, developed to meet the needs of your own policy.

Increased VPN Requirements

One of the more common alternatives in this design is an increased requirement for VPN access. This can be met in two ways. Most easily, remote user and site-to-site VPN can be separated into two or more devices connected in the same manner as the single device. This option is shown in Figure 13-7.

Figure 13-7. Increased Medium Network VPN Requirements

Still another option is to go with a completely separate VPN infrastructure, as outlined in the high-end design covered later in this chapter.

Increased Security Alternative

There aren't a lot of obvious ways to increase the security of this design dramatically. The hosts are already well secured and protected (both on the hosts and from the surrounding infrastructure). Web filtering could be deployed on the public server segment or another dedicated firewall interface if your policy dictated its use. Additionally, anomaly NIDS could be deployed on the Internet WAN router by offloading usage data to an anomaly detection tool to watch for abnormal patterns.

Another option is to put a router of some variety as the final device all edge traffic crosses before entering the campus. This allows for routing protocol termination from the campus (if desired) and could act as a final filtering point for all edge traffic.

Decreased Security Alternative

Although it is tough to make this design more secure, it is easy to make it less secure. If you have to start cutting corners, the following list shows which technologies and devices you can consider eliminating first:

1. NIDS behind the firewall
2. NIDS on the public server segment
3. E-mail filtering

The resulting design is shown in Figure 13-8. Like the small network design, application controls are not affected and the core network design stays the same, just without as many control points. Any further reductions or integrations will result in the design closely resembling the small network edge. Integrating firewalling and VPN into a single VPN gateway, for example, would virtually mirror the small network design.

Figure 13-8. Decreased Security Medium Network Edge Design