Medium Network Campus Security Design

The medium network design can support most organizations with a collapsed backbone design, as discussed in Chapter 12. The design uses both L2 and L3 switching to provide services to users and security to the network as a whole. This design can have hundreds of users and a diverse set of applications in use. There are likely several different trust domains within the design.

Design Requirements

The medium network design must provide connectivity for a moderate number of servers and clients and allow them to be separated from one another when necessary. Mitigating the top campus attacks is highly desired because this network might span multiple buildings within a single location. The tight physical controls possible in the small network campus are likely no longer reasonable.

Design Overview

Figure 14-3 shows the basic design for the medium network campus that supports the preceding requirements.

Figure 14-3. Medium Network Campus Design

The core of this design is a single L3 Ethernet switch that provides L2 and L3 services to critical devices. It can have as many subnets as necessary to support the traffic separation required. At a minimum: server, client, wireless, and management subnets should be created. Because most campus traffic must flow through this switch, an NIDS can be used to monitor traffic on this switch. Be sure not to oversubscribe the NIDS device or you will likely lose alarm data. See Chapter 7, "Network Security Platform Options and Best Deployment Practices," for more information on NIDS deployment best practices. This switch acts as both core and distribution layer as defined in Chapter 12. The access layer for users is handled by a set of L2 switches. These switches can make use of VLANs to support different domains of trust at the user level. Be sure to implement VLAN hopping best practices on all switches in this design. In addition, the WLAN APs can be connected through these same access switches if your physical cable plant provides no other options. Be sure to use a separate VLAN for the WLAN traffic.

A AAA server is required here to support the identity needs of the edge, campus WLAN identity, and any management access to different devices. If 802.1x is desired (Chapter 9), this server can provide authentication for it as well.

Campus Devices and Security Roles

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

Ethernet Switches (All)

The following capabilities should be enabled on all Ethernet switches in the campus:

• 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. This includes, at a minimum, setting STP BPDU Guard on all PC ports to prevent accidental or deliberate spanning tree problems.
• Port security Limiting the number of Media Access Control (MAC) addresses per port on a switch (Chapter 6) that uses port security prevents Content Addressable Memory (CAM) table flooding and the VLAN-wide sniffing this flooding enables.
• VLAN hopping best practices Because VLANs can be used for both user and management traffic, configuring these switches to use the appropriate VLAN hopping best practices (Chapter 6) is required.
• ARP best practices If ARP inspection is available on the switch used in this area of the network, it should be enabled per Chapter 6. The decision on whether to seek out a switch specifically that supports this feature should be based on the cost/benefit analysis discussed in Chapter 2.
• Private VLANs Private VLANs can be used here to partition systems from one another per the recommendations in Chapter 6.
• DHCP best practices VLAN ACLs at a minimum should be deployed here to prevent inadvertent, or deliberate, rogue DHCP servers. DHCP snooping can be used instead if available.

Ethernet Switches (L3 Distribution/Core)

The following additional capabilities should be enabled on the core.

• Ingress/egress/uRPF filtering RFC 2827 filtering should be implemented here using unicast reverse path forwarding (uRPF) if available or ACLs if necessary.
• Router with ACL This switch can be configured to block traffic flows at L3/L4 as dictated by your trust domains and security policies.
• Role-based subnetting If your policy defines multiple user roles and you are able to segment these roles by subnet, role-based subnets allow you to implement this filtering. As discussed in Chapter 6, this filtering is best done at L3, where it is easiest to implement and manage.
• Routing protocol authentication If you are exchanging routing information with other campus devices or the edge, authentication should be used.

Internal Servers

Internal servers should be hardened and protected much like any edge server, just with slightly less emphasis and vigilance. You probably have many internal servers, some of which are in your control and others of which are not. It might not be operationally or financially possible to implement all of the following controls, but at a minimum, harden your systems and design a process to test new security fixes and deploy them to your production systems as soon as possible. Again, your own policies easily trump these recommendations. The key security techniques configured on the internal servers are as follows:

• Reusable passwords Username/password pairs will likely make up the bulk of your identity information.
• Sessionapp crypto Any communications from the client to a server deemed sensitive (based on your policy) should be cryptographically protected with sessionapp crypto. Self-signed certificates are probably sufficient here, though you can consider a modest PKI for critical HR and accounting systems.
• OS/application hardening This is by far the most important step to securely deploying any internal server. Be sure to harden the OS properly and any applications as discussed in Chapter 5. Don't just deploy every patch as it is released, though. You need some mechanism to do at least basic testing on updates before applying them to production systems.
• File system integrity check This should be done on every critical production server.
• Host antivirus Host AV is the minimum add-on host security control that should be deployed on every system in your campus (server or client).
• Host IDS Critical internal servers (and others if you are able) should have host IDS deployed to help mitigate local attacks.
• E-mail filtering Depending on how you set up your e-mail system based on the recommendations in Chapter 8, "Common Application Design Considerations," you probably want to filter e-mail messages for viruses internally as well as on the edge. This prevents mail from one user to another within the same campus from passing a known virus.

User Hosts

Most commonly, if there is an attack on your internal systems, it will be through an attacker somehow gaining access to your user PCs. An e-mail virus/worm or other nefarious application can gain remote control of your user PCs and cause them to attack your own network or other networks. In addition, portable computers spend a good deal of time outside the protective confines of your local campus network. While teleworkers travel or work from home, these systems can be compromised, which can then lead to further attacks when they return to your network. The key security techniques configured on user hosts are as follows:

• Reusable passwords Users will authenticate to their systems with usernames and passwords.
• OS/application hardening Modern OSs have mechanisms to patch user systems automatically as security fixes are released for the OS and its core applications. Although these patches can be used if no other option exists, with potentially hundreds of internal systems affected, you should first test fixes before deploying them to the end systems.
• Host antivirus Host AV is the minimum host security control that should be deployed on every system in your campus (server or client).
• Host firewall Host firewalls can optionally be deployed on user workstations, but keep in mind the concerns raised in Chapter 4 regarding their use. This should not be done as a substitute for host hardening.
• File system crypto If your OSs support it, file system crypto is a good measure for portable computers that might be outside your organization's domain of control for extended periods of time.

NIDS

A signature-based NIDS device is deployed off of the core L3 switch. This allows the NIDS to monitor any interdomain campus traffic deemed necessary (since all choke points are on the switch). As mentioned earlier, beware of oversubscribing the NIDS. (Chapter 7 provides more details on NIDS deployment options.) Because the system is deployed for internal systems only, once properly tuned, it can be used actively to stop some attacks. The key security techniques configured on the NIDS are as follows:

• Network device hardening This device should have its configuration hardened per the best practices in Chapter 5.
• Signature-based NIDS This device should be tuned to detect the attacks most prevalent in the area of the network in which it is deployed. Refer to the attack list earlier in this chapter for more details.

AAA Server

This server can supply your edge and campus with a centralized identity store for systems that can take advantage of it (WLAN, management, VPN, and so on). (AAA deployments are covered in more detail in Chapter 9.) Any AAA deployment should follow the best practices of any other internal server as previously described. The one key additional security technique configured on the AAA server is as follows:

• RADIUS/TACACS+ This server provides a central place to store user credentials for use in edge VPN, campus WLAN, network management, and other application functions.

WLAN AP

The WLAN APs should be hardened and deployed as described in Chapter 11. Make sure they are deployed on a VLAN separate from the other user traffic as an additional security measure and physically back haul the uplinks directly to the L3 switch if possible, as shown in Figure 14-3. Chapter 11 describes WLAN deployments in more detail, including the IPsec option.

Design Evaluation

You can now evaluate the success of this design against the campus-focused attack list in Table 14-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 14-3 shows the top 10 attacks from Table 14-1 and the security elements used in this design that mitigate these threats as they pertain to campus assets. As in previous chapters, items that can stop an attack often can also detect it and, as such, aren't listed in both columns.

Table 14-3. Medium Network Campus Design Attack Mitigation

Attack	Detect	Stop
Identity spoofing	Reusable passwords, RADIUS/TACACS+	Sessionapp crypto, file system crypto
Virus/worm/Trojan horse	FS check, signature NIDS	Host AV, e-mail filtering
Rogue devices		Rogue device detection BPs, routing protocol BPs
Sniffer		Sessionapp crypto, L2 control BPs, port security, ARP BPs, DHCP BPs, private VLANs
Man-in-the-middle (MITM)		Sessionapp crypto, rogue device detection BPs, ARP BPs, DHCP BPs
War dialing/driving		Rogue device detection BPs
Direct access	Host IDS, signature NIDS	Reusable passwords, RADIUS/TACACS+, host firewalls, sessionapp crypto, network/OS/application hardening, PVLANs, file system crypto, router with ACL, routing protocol BPs, role-based subnetting
ARP redirection/spoofing	Signature NIDS	ARP BPs, private VLANs
Remote control software	Host IDS, signature NIDS	Host AV, host firewalls, OS/application hardening, file system crypto, e-mail filtering
Buffer overflow	FS check, host IDS, signature NIDS	OS/application hardening

In this table, some of the top mitigation techniques are hardening (all types), rogue device detection, and cryptographic protection for the session or application layer of key applications. All these protections are also in the small network design. What the medium network adds is the various detection capabilities of IDS. In addition, the L3 capabilities of the switch provide more filtering granularity. The extent of defense-in-depth is superior in this design when compared to the small design, though there are still areas where protection is thin (war dialing/driving). To a certain extent, these situations have more to do with the difficulty of the threat than the lack of design options. There aren't a lot of things you can do to stop some attacks if you look back at Table 6-1. The level of security provided in this design is certainly superior to almost every campus network I've evaluated over the years. Even more significant, the security design doesn't impact the core topology in any meaningful way.

Design Alternatives

There are fewer options to modify the internal design than existed in edge designs discussed in Chapter 13. The core differences come down to doing more or less of the recommended functions outlined in this section.

Increased Security Alternative

The most significant addition you can make to this design is to protect certain key server resources with a stateful firewall instead of basic ACLs. This topology, shown in Figure 14-4, allows these key resources to have an added layer of protection. Determining which systems to protect in this manner goes back to the information in Chapter 2. The decision has as much to do with the value of an asset as it does the likelihood that it will be attacked. Examples of systems you can protect with the firewall include insecure proprietary applications, high-value targets (HR, accounting), systems with a high susceptibility to attack, and so on. Your policies and the decisions you make in Chapter 12 should help you make these choices.

Figure 14-4. Medium Network Campus Design (with Firewall)

This concept could be further extended by using NIDS on the protected segment. Other ways to increase security include emphasizing host hardening and other host security controls.

Decreased Security Alternative

Certainly, going to an L2 switch in the core decreases the security level and gives you a design closely mimicking the small network campus design. In addition, having fewer host controls implemented saves costs at the price of reduced security. If you must save money in this design, eliminate the NIDS first and the host add-on security second. Make sure host and application hardening is the last thing you consider eliminating.