Small Network Edge Security Design

The small network edge design is not a throwaway design as the industry's lack of focus on small network security might have you believe. Oftentimes, designs for small networks are more challenging because there are fewer options for the security designer and often fewer resources are available (financial and operational). The security needs, however, are usually the same as for larger networks. This is because the security requirements for a network are mostly independent of size. Your security policy defines your requirements. Although it is often the case that a small coffee shop with an Internet connection available for its patrons has fewer security requirements than a Fortune 500 company, a small research think tank might be more security conscious than a larger network with less-sensitive data to protect.

Design Requirements

The small network design assumes that a single Internet connection is the only means of communicating with the outside world. Given that, 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)

These requirements should be implemented in a way that is cost effective to install and to maintain. This translates into the design by favoring easy-to-manage technologies and not requiring threat mitigation techniques when a given threat is low on the list.

Design Overview

Figure 13-1 shows the basic design for the small network edge that supports the preceding requirements.

Figure 13-1. Small Network Edge Design

As you can see, the small network edge compresses the essential network security elements into a single security gateway. Dividing functionality into different devices doesn't make financial sense in a network of this size. As a result, careful attention must be paid to the integrity of the gateway's configuration. Manageable systems are a key element in this design because, with as many functions as you will configure on this one device, mistakes are likely.

Edge Devices and Security Roles

This section outlines the devices present in the small network edge design and outlines the security roles each device plays as listed in Table 6-1.

Router/Security Gateway

Perimeter security is centered primarily around a dedicated security gateway that can also act as a router. This depends on the requirements for WAN connectivity and other router services such as quality of service (QoS). The integration of routing and security only changes the complexity of the configurations as discussed in Chapter 7, "Network Security Platform Options and Best Deployment Practices," but not their effectiveness. Integration is the default option in this design. The key security techniques configured on this device are as follows:

• Stateful firewall Stateful and stateless filtering should be implemented on this device.
• Signature-based NIDS NIDS signatures should be matched and enforced on this device. As of this writing, more complete signature NIDS functionality is available on dedicated security appliances than on routers with security features.
• Network device hardening This device should have its configuration hardened per the best practices in Chapter 5, "Device Hardening."
• Ingress/egress filtering RFC 2827, RFC 1918, and bogon filtering should be implemented here per Chapter 6.
• Unicast RPF uRPF filtering, where available, can be used as an implementation method for some of the ingress/egress filtering. RFC 2827 filtering is particularly suited to uRPF. Because this network is small, this might be the only place in the broader security system where either ingress/egress or unicast RPF is done in the entire design.
• ICMP best practices ICMP filtering should be done on this security gateway per Chapter 6.
• Routing protocol authentication In a small network, routing protocols might not even be required, but if they are necessary, authenticated routing protocols should be easy to configure and manage in a network of this size.
• DDoS best practices Although your ISP occupies the pivotal role in DDoS threat mitigation, technologies such as committed access rate (CAR) can still be optionally implemented at your location. Keep in mind that these best practices (BPs) primarily are useful for mitigating attacks originating from your network.
• TCP SYN best practices Mitigating the effects of TCP SYN floods can be done at several points in the design. On your security gateway, technologies such as TCP Intercept (Chapter 6) can be used to minimize the impact on hosts. If you can run SYN cookies on all your publicly accessible TCP hosts, TCP Intercept is not necessary.

Optional WAN Router

There are two main reasons in this network design for you to use both a WAN router and a security gateway (as opposed to integrating the two). First, the security gateway might not support the WAN interface necessary for connectivity to your ISP. In most cases, however, small networks are taking advantage of broadband connections, which often terminate at an Ethernet port on the ISP customer premise equipment (CPE). The second reason, and the most common, is that the set of features required for the network in general and for security are not available on a single device. For example, your network might need to support voice, advanced QoS, and other specialized router features. In this case, you may have difficulty finding a single device that does all those things and also provides all the security functions defined during the design of your security system.

In either case, a dedicated WAN router can be configured on your Internet edge to provide the necessary network functionality. This opens more options in security device selection to ensure that you get the capabilities required.

WARNING

In branch deployments, try whenever possible to limit the number of devices in each branch. Combining the WAN router and security gateway functionality should be a deliberate design goal in these environments to limit the management requirements from the central site.

When using a dedicated WAN router, the functions provided by the security gateway should generally stay the same as previously listed because it is useful to have a single audit point in smaller networks with limited IT staff. Exceptions to this are noted later in this section.

The WAN router, at a minimum, must be hardened, but it can also have basic security functions implemented on it. Remember that, in this case, the defense-in-depth benefit is minimal because both your router and your security device are offering the same kind of security. The main difference is that a router without dedicated and advanced security features usually does a worse job of it. Still, if you have the resources to implement some of these basic configurations, it is worthwhile. Some cases are more useful than others and are called out. The key security techniques configured on this device 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 can be implemented here in addition to, or instead of, filtering at the firewall. If implemented here, you reduce the amount of data generated daily by your firewall log. This makes it easier to detect more advanced attacks. The ingress filtering can still be configured on the security gateway, but any hits on these access control list (ACL) entries would indicate a security failure on the WAN router.
• Unicast RPF Similarly to ingress/egress filtering, uRPF can be implemented on the WAN router in addition to, or instead of, the security gateway.
• ICMP best practices For the same reasons as for the previous two technologies, ICMP filtering can be implemented on the router as a means of eliminating basic security events from attracting the attention of the security gateway.
• Routing protocol authentication In a small network, routing protocols might not even be required. If they are necessary, authenticated routing protocols should be easy to configure and manage in a network of this size.
• 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. If implemented on the WAN router and if an arrangement is made with your ISP regarding DDoS attack response, also implementing CAR on your security gateway certainly is overkill.

NOTE

In some areas, any ISP-provided leased line comes with a router under the control of the ISP. Although this device is the closest ISP-connected device to you, DDoS and other threat mitigation should occur at the other end of the WAN link, not at this local router.

Ethernet Switch

The key security techniques configured on this device are as follows:

• Network device hardening This device should have its configuration hardened per the best practices in Chapter 5.
• L2 control protocol best practices All Ethernet switches in these designs should account for the Layer 2 (L2) control protocol best practices discussed in Chapter 6.
• Port security Even though users are not connected to this switch directly, an attack that successfully compromises a host on this network could use Media Access Control (MAC) flooding to gain access to data on other ports of the switch. If your switch supports port security, the configuration is not complex and does not require ongoing maintenance. See Chapter 6 for more details.
• VLAN hopping best practices Although VLANs are not needed on this switch to support production traffic, they are very likely needed to support secure management of the device.
• ARP best practices If ARP inspection is available on the switch used in this area of the network, it should be configured for ARP inspection per Chapter 6. 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 to separate public servers with no need to communicate directly with one another. Private VLANs are explored fully in Chapter 6.

Public Servers

In a small network edge design, protecting the public servers adequately can take a significant percentage of available resources. Instead, you can consider outsourcing your public servers to hosting facilities where the cost of such management can be shared among several clients. Hosting your e-mail, HTTP, DNS, and other public services at external facilities on shared servers can save you significantly in both initial capital outlay and ongoing management expense. The remainder of this subsection assumes you wish to host such services locally at your organization. The servers are deployed off a perimeter interface on your security gateway. The key security techniques configured on the public servers are as follows:

WARNING

This small 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 (have you checked the list of root CAs on your browser lately?), 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 operating system (OS) and any applications as identified in Chapter 5.
• File system integrity check This should be done on every server because the cost involved should be manageable even in a small network.
• Host antivirus/host IDS Both technologies should ideally be deployed, but host antivirus (AV) might be the only one affordable for smaller networks. As discussed in Chapter 4, the lines between these technologies and other host controls are blurring. Be sure to evaluate the technology options available to you before deploying because they will have changed since this book was written.

VPN

Now that you have seen the security roles on the devices in the small network edge design, this section presents the VPN elements. Figure 13-2 shows the termination points for site-to-site and remote user VPNs. In this design, both terminate on the security gateway directly.

Figure 13-2. Small Network Edge VPN Design

Site-to-Site

In a site-to-site VPN of the size generally common in small networks, preshared keys are probably sufficient, as is basic IPsec without generic route encapsulation (GRE) tunnels. As always, your own network requirements trump these recommendations. See Chapter 10 for more information.

Remote User

Remote user VPN connectivity can be implemented on the same device using group preshared keys for phase 1 and OTP as extended user authentication (Xauth). If the number of remote users is very small and they can be trusted to practice proper password procedures, you can use local usernames and passwords without OTP to save money. This decision is not without risk. Be sure you are familiar with the general identity considerations discussed in Chapters 4, 9, and 10. At a minimum, be sure to configure individual accounts to temporarily disable on the AAA server after a fixed number of incorrect logins.

NOTE

Providing OTP logins for remote user VPN requires a AAA/OTP server in your campus design.

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, "Designing Your Security System," 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-2 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.

To focus on only the top 10 attacks is not to say that the remaining ones are unimportant. It is just meant as a rough cut of the things you should pay special attention to. The remaining attacks can be evaluated by cross-referencing the technology recommended in this chapter with the chart in Table 6-1.

As you can see by reviewing the preceding table, hardening devices is easily the most important thing you can do to improve security. After hardening your devices, 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 threat.

VPN Evaluation

The VPN design evaluation is done separately because the threats related to VPN are slightly different than those against basic Internet connectivity. 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.

Design Alternatives

Any design has several alternatives. The following section outlines some of the major options for the small network edge design. Of course, the most important alternative design is your own, developed to meet the needs of your own policy.

Outsourced Applications Alternative

As discussed earlier, if you decide to outsource your public servers, you will save costs and suffer a slight loss of control. This choice reduces the security requirements of your design significantly. Without public servers, there are no hosts to attack from the outside. You still must adequately protect your internal systems, but this can probably be done without IDS or having to deal with DDoS attacks. Understand, however, that new security considerations arise when outsourcing applications. The principal concern is ensuring that you have a secure means of doing content modification on these servers and that the service provider (SP) has procedures in place to ensure that the servers are appropriately monitored and hardened.

Increased Security Alternative

If you want to add to the strength of your security system in the small network edge design, the operative word is more. One option would be to implement more, rather than less, of the host security controls already outlined. For example, make sure you have host AV and host IDS on your public servers. Another option is to add e-mail filtering for viruses. This gives you a centralized place to perform such filtering as discussed in Chapter 8. Without such filtering, mitigating viruses is left to the end systems that receive the virus-infected mail message. A third option is to move your VPN functions to a separate system, routing the decrypted traffic into the main security gateway as shown in Figure 13-3.

Figure 13-3. Small Network Edge with Dedicated VPN

A final option concerning the network infrastructure is to set up a dedicated NIDS system on your public segment. Figure 13-4 shows all these alternatives applied to the small network design.

Figure 13-4. Increased Security Small Network Design

Note that this design starts to function more like the medium network design described in the next section.

Decreased Security Alternative

Hopefully you won't need to select this design, but it would be irresponsible not to present it. Some networks, because of many circumstances (not the least of which are financial), are unable to deploy the designs presented so far in this section. If dollars are currently unavailable for security or you are trying to do your best with an existing topology that can't be significantly changed, the design in Figure 13-5 might be necessary.

Figure 13-5. Decreased Security Small Network Design

In this design, the key to remember is sacrifice at the network first, not the applications. Since the number of hosts is small, hardening these systems should be a top priority. For the absolute bare minimum, deploy the design in Figure 13-5 using only application and OS hardening on the hosts. The lone router should be configured with stateless ACLs defining the traffic needed in each direction. For VPN, you might need to resort to older technologies for site-to-site. GRE tunnels (without encryption) might be your only option. (Be sure to secure any critical information at the application level.) For remote users, use Secure Shell (SSH) port forwarding configured on one of your hosts. Certainly, this design is less secure, but it is far better than no security system at all.