High-End Resilient Edge Security Design

For the purposes of this book, a high-end resilient edge design is a large network edge with high availability and large throughput capabilities. Because the high-end resilient network edge has greater network throughput and availability requirements, this dramatically changes the requirements for network security. This design is meant to be suitable for the largest edge networks in the world. As connectivity needs change, the design can be extended to support more options with the core design remaining unchanged.

Design Requirements

This design must provide Internet, PSTN, and private WAN connectivity to the outside world. This mirrors the requirements of the medium network. The differences arise with increased throughput requirements and the requirement for high availability. 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 (by PSTN)
• Private WAN connectivity
• High availability

Other key differences from the medium design include dramatically increased management requirements and initial capital outlay.

Design Overview

From a security flow standpoint, the design is very similar to the medium design. The key difference is a completely separate infrastructure for remote access. Separate remote access firewalls, as described in Chapter 10, allow for focused remote access ACLs and tight enforcement of NIDS violations. Other differences include anomaly-based NIDS on the WAN routers, more than one public server segment (to allow for greater segmentation), and routed connections exiting from all modules. These differences are described in more detail later in this section. Figure 13-9 shows the Internet edge. Figure 13-10 shows the remote access edge.

Figure 13-9. High-End Internet Edge Design

Figure 13-10. High-End Remote Access and WAN Edge Design

Figure 13-11 eliminates the redundancy and L2 switching from the design and merges both figures. This should allow you to better visualize the flows through the entire network.

Figure 13-11. Simplified High End Edge Design

Multiple Public Server Segments

The two public server segments in this design can be expanded or contracted as your needs dictate. Having multiple server segments allows you to segment services by several factors: security, trust, criticality, and so on. This design assumes that one segment houses "nonessential" or legacy services. These services are not protected by NIDS, though such protection could be easily added. Remember that private VLANs allow some level of segmentation within a single segment.

Another potential point of segregation is to use the second public server segment as a campus services segment. This segment could house proxy servers, URL filtering devices, and web caches that respond only to requests from the Internal network and are not directly reachable by the Internet.

Routed Connections to the Campus

Previously a design alternative in the medium network design, routed connections to the campus network are now a recommended option. This routing layer, which occurs right before connections are made to the campus, allows for an L3 resiliency between the campus and edge as opposed to using spanning tree at L2. Like the medium design alternative, it also allows for a final filtering point before connecting the campus.

The Price of L2 Resiliency

The high-end design provides L2 resiliency as well as L3. This significantly increases the number of devices needed. To start, the number of L2 switches needed is doubled. On top of that, the number of NIDS devices is doubled as well, unless you span both switches with a single NIDS (discussed later). Because of the increase in the number of devices, the management requirements increase as well.

Some designs opt for only L3 redundancy. Although this is an okay choice, make sure you understand the implications and realize that you will have downtime when a given L2 switch fails or is misconfigured.

NOTE

In these designs, all end hosts are single attached to Ethernet switches. Although you could connect them to both switches, make sure you have the host systems configured to support this so at least the IP address (if not also the MAC address) is consistent after failure.

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 high-end design, multiple WAN routers handle the traffic to and from the two ISPs. These routers handle all routing functions and do some basic security filtering to narrow the field of attack against the firewall.

Some of these security functions can also be 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 These devices should have their 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 in the log.
• Unicast RPF Similar to ingress/egress filtering, uRPF can be implemented on the WAN routers as an alternative to ACL-based ingress filtering where appropriate.
• ICMP best practices ICMP filtering should be implemented on the routers following the guidance in Chapter 6.
• Routing protocol authentication Most Internet WAN routers for networks of this size carry full or partial Border Gateway Protocol (BGP) tables from their upstream ISPs. Using MD5-authenticated BGP is a good idea per Chapter 6.
• 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.
• Anomaly-based NIDS By using technologies such as NetFlow (see Chapter 16), flow information can be sent from these WAN routers, which can be analyzed by a third-party, anomaly-based NIDS.

Stateful Firewall

Perimeter security is centered primarily around a pair of stateful firewalls that can also have other security functions. Because the performance requirements of the firewalls in the high-end design are high, strongly consider the impact before enabling any more advanced functionality in the firewalls. Separation of security function is implemented throughout this design as a deliberate design goal that should allow the firewalls to be relatively focused in their role. This section assumes that only stateful firewall capabilities are available. Chapter 7 discusses basic firewall filtering guidelines.

Resiliency is most easily handled through an "active-standby" high-availability configuration in the firewalls. When one firewall fails, the other assumes the former's MAC address and IP address. Operating in an "active-active" role is also fine, but be aware that this places stringent requirements on the firewalls with regard to the speed that they share state information. Also be sure that a failure in one firewall doesn't overload the capacity of the second firewall. The key security techniques configured on the stateful firewalls are as follows:

• Stateful firewall Stateful access control should be implemented on these devices. This state information must transition between the two firewalls to ensure that most existing sessions stay connected when one of the firewalls fails.
• Network device hardening These devices should have their 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 both the WAN router and firewall and only muddles 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 firewalls per Chapter 6.
• Routing protocol authentication Depending on your stance toward routing on firewalls (discussed in Chapter 7), you can 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. Keep in mind that routing will affect your high availability (HA) design, depending on how it is deployed. Refer to your firewall vendor's HA documentation for more details.
• 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 Internet edge per the recommendations in Chapter 7. First, a pair are deployed on public server segment A to protect the hosts there. The second NIDS pair 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 attack list earlier in this chapter for details and to Chapter 7 for tuning recommendations.

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 pair of switches 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, number of switches, and so on). All of these technologies are discussed more fully in Chapter 6. Most common in these large networks is the merging of all L2 switches to two high-end L3 switches with all sorts of redundancy built into them. Although you learned in Chapter 6 that this can be made secure, the concerns rest mostly in the consistent management of such devices because the chance for configuration error is high. 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 switches 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 networks, it should be enabled. Because the threat of ARP spoofing is low in this area of the network, ARP inspection is by no means a requirement.
• Private VLANs Private VLANs should be configured on the public server switches to separate public servers with no need to communicate directly with one another.

Public Servers

In the high-end design, like all designs in this chapter, 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 the network can provide is significantly weakened. The key security techniques configured on the public servers are as follows:

WARNING

This high-end resilient 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 deployed in the edge.
• 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

The remote access edge, like in the medium design, supports WAN, PSTN, and VPN connectivity. Its design centers around a pair of firewalls configured specifically to the needs of the remote access technologies. The WAN, as in the medium design, is trusted and connects behind the firewall but is still inspected by NIDS.

The remaining technologies each terminate on a dedicated interface on the firewalls. This ensures that each technology type is separate from one another and can be trusted more or less by modifying the configuration of the firewall. For example, if site-to-site VPN is trusted slightly more than remote user, the access control policy on the firewall can reflect that. Using a separate firewall for remote access as opposed to merging with the general Internet access firewall provides three benefits.

First, it splits the traffic load across two sets of firewalls rather than having all traffic to or from the Internet cross the same firewalls. This should allow you to use more of the advanced features on each firewall without worrying that you are creating a performance bottleneck.

Second, by separating remote access traffic to a separate firewall, you implement the operational simplicity axiom discussed in Chapter 1, "Network Security Axioms." When troubleshooting a problem on either firewall pair, the configuration on each is focused on its specific task. Errors are more easily discovered, and policies can be clearly viewed and implemented on both devices. If you are having a problem with remote user VPN traffic, you know that the issue can be addressed on a single dedicated interface with its own access control policy. Furthermore, that policy is implemented on a firewall whose only concern is traffic from the outside coming into the campus network by using some remote access technique.

Third, from a policy standpoint, it is often difficult to implement effective filtering for your remote users. Often full connectivity is required, which limits what you can do on a firewall. Here, the NIDS system behind the remote access firewall really adds value. The firewall can be configured to permit the entire L3 subnet for each technology to have full access to the corporate network. This at least provides an audit point and allows specific filtering when needed. The NIDS behind the firewall can be configured to actively stop attacks by using the shun capability as discussed in Chapter 7. Chapter 7 mentions that most organizations don't implement NIDS attack prevention because they worry about the impact that false-positive alarms would have on paying customers. In a remote access environment, the only risk if a false positive somehow sneaks through your tuning procedures is that you accidentally block a remote access user, not a paying customer. Having the layer of firewalls in the remote access edge allows this filtering to be enforced before the user gains access to the campus network.

VPN

In the high-end design, a dedicated set of VPN devices is used for site-to-site and a separate dedicated set of devices is used for remote user VPN. This design supports very large VPN deployments as discussed in Chapter 10. There is one additional requirement for the VPN systems that should be configured on the Internet WAN routers. Because traffic from these routers to the VPN segments should contain only IPsec traffic, outbound filters should be placed on the Internet WAN routers to ensure that only IPsec traffic can reach the VPN gateways.

Site-to-Site

In the high-end resilient edge design, GRE + IPsec on routers is the most appropriate IPsec technique. For authentication, digital certificates should be used. Routing protocols should be passed across these links using a hub-and-spoke topology that takes advantage of the multicast support GRE + IPsec affords. Moving to a partial mesh is appropriate if your connectivity requirements demand it, but be aware of the issues. Chapter 10 has extensive information on this subject.

The design scales by increasing the number of head-end devices as discussed in Chapter 10. Keep in mind that, by using routing, you have a limited number of peers that can be configured on each device, just like you have a limited number of routed peers in any network design. If you have more than two site-to-site gateways, you can consider a distribution layer of L3 switching between the IPsec gateways and the firewalls to aggregate the routing. The key security techniques configured on the site-to-site VPN gateways are as follows:

• Network device hardening These devices should have their configuration hardened per the best practices in Chapter 5.
• Router with ACL Site-to-site VPN gateways should be configured to filter all non-IPsec traffic inbound on each device. Your IPsec policy should enforce this anyway, but filtering with ACLs provides an additional check.
• Network crypto IPsec VPN tunnels are established to remote sites per the recommendations in Chapter 10.
• Digital certificates Remote sites are authenticated with digital certificates in a closed PKI model discussed in Chapters 4 and 9.

Remote User

Remote user VPN connectivity can be done on a set of load-sharing devices dedicated to remote user connectivity. Group preshared keys for phase 1 Internet Key Exchange (IKE) authentication and OTP as extended user authentication (Xauth) are used to validate user identity. The key security techniques configured on the remote user VPN gateways are as follows:

• Network device hardening These devices should have their configuration hardened per the best practices in Chapter 5.
• Network crypto IPsec VPN tunnels are established to remote users per the recommendations in Chapter 10.
• OTP OTP identity checks occur for all remote user VPN connections.

WAN

The private WAN network is a redundant pair of routers that then connect behind the firewall. WAN traffic is still 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. This will likely impact the performance and manageability of the WAN, so be sure to take that into consideration before making the decision. The key security techniques configured on the WAN routers are as follows:

• Network device hardening These devices should have their configuration hardened per the best practices in Chapter 5.
• Router with ACLs If you must do any basic L3 filtering to limit access to specific networks to or from the WAN, it can be implemented on the WAN router by using 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 pair of NASs are used for dial-up, and then dial-up traffic is routed through the firewall in the same way as VPN traffic. Extensive filtering can occur here, or the firewall can act only as an audit check and NIDS enforcement point. The key security techniques configured on the NASs are as follows:

• Network device hardening These devices should have their 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-4 shows the top 10 threats 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 remains the most important thing you can do to improve security across all three of the designs presented in this chapter. Following that, the various flavors of IDS do a good job detecting many of the top attacks. The notable difference in this design when compared to the medium network design is the addition of anomaly-based NIDS. This catches broader traffic fluctuations, which is important at the data rates commonly experienced in large networks. Perhaps most interestingly, a stateful firewall, typically a mainstay of network security, stops only two out of the top 10 attacks. (This is the same in the previous two designs as well.) 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, 13-3, and 13-4 are nearly identical. You should expect this because small networks don't generally have lower security requirements; it just sometimes doesn't make sense financially to deploy some controls until the network (or more accurately the asset value) increases. The high-end design does offer the ultimate level of flexibility, performance, and availability when compared to the smaller designs.

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 attacks related to VPNs. Both of these are stopped by a combination of network crypto, OTP, and digital certificates. 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 will 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. For the high-end design, any number of options can be considered. The following section outlines some of the major options for the design. Of course, the most important alternative design is your own, developed to meet the needs of your own policy.

Increased Security Alternative

Believe it or not, this design can support even more security capabilities and techniques than currently recommended. Some of these options include the following:

• NIDS on the IPsec network Although this is an expensive control to ensure that you are filtering and encrypting properly, a signature-based NIDS system can be deployed on the segment between the VPN gateways and the Internet WAN router. Because all traffic is encrypted, this device should never alarm. (NIDS can't decrypt the flows.) Any alarm from this sensor likely indicates an access control or VPN configuration failure and requires immediate attention. A simple tcpdump process running on a Linux box using a cron job (time-based script) to page you if it sees non-IPsec traffic does the same thing at significantly less cost.
• WAN link encryption As discussed in Chapter 10, you can elect to encrypt the traffic on your WAN links.
• More NIDS When you refer to Figure 13-11, depending on the asset value of the devices in public server subnet B, you can benefit from adding NIDS there as done on public server subnet A. In addition, for sites with lots of free time to view attacks, you can put NIDS in front of the firewall. As discussed in Chapter 7, you will be inundated with alarms, but a comparative analysis with your interior NIDS devices could be useful.

Decreased Security Alternative

Like the previous three designs, reducing the security is easy. If financial or operational realities prevent you from deploying all the security elements you might like, trim by eliminating the technologies that detect but do not prevent attacks that are one of many that stop a given threat. NIDS is a good candidate to initially reduce, though I would first recommend that you deploy NIDS in a nonredundant mode. As discussed earlier in this chapter, you can acquire NIDS systems that inspect traffic from more than one subnet simultaneously. This implementation is shown in Figure 13-12 specific to the high-end Internet edge, but it applies the same to the high-end remote access edge.

Figure 13-12. Dual-Attached NIDS High-End Internet Edge Design

If a NIDS system fails, you have no backup. But in the redundant design, if the NIDS on the active switch fails, you must manually move the other NIDS to the active switch anyway.

If your throughput needs are limited and you are aware of the operational implications, you can implement this design using a single pair of firewalls by connecting the remote systems in the same way as the medium network edge design. This compressing of function can happen throughout this design if desired, though with each merger of security function, configurations increase in complexity and defense-in-depth suffers slightly.