Small Network Campus Security Design

There isn't much to design in the small network campus. Here, a single switch (likely L2) is used to connect both server and host resources to one another. Because the network is small, operational practices can mitigate the need for strong network controls. For example, a campus network with a single L2 switch can probably easily determine whether a rogue AP or other device is connected. Still, the design in this chapter assumes you want to implement some controls in your L2 environment. If you don't, there isn't much point to reading the rest of this section. Just plug your switch into your edge router and be done!

Design Requirements

The small network design must provide connectivity for a small number of servers and clients in a cost-effective way. Mitigating the top campus attacks is certainly useful, but it is viewed as a best-effort process within the cost constraints of most small networks.

Design Overview

Figure 14-1 shows the basic design for the small network campus that supports the preceding requirements.

Figure 14-1. Small Network Campus Design

A single L2 switch provides connectivity between all campus resources and the edge. A WLAN AP is attached to the same network as the wired clients using 802.11 security enhancements. Internal servers and user PCs are connected to one another by the single switch. Private VLANs can be used to limited effect in controlling traffic flows.

Campus Devices and Security Roles

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

Ethernet Switch

The key security techniques configured on the Ethernet switch 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 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. Simply disabling spanning tree can work, but if the attacker (or a user through a mistake) introduces a loop, you can have a large broadcast storm.
• Port security Limiting the number of MAC addresses per port on a switch (Chapter 6) provides a good way of controlling the number of systems connected to any one port. By using port security, you are able to detect a hub or switch with extra hosts connected. Because the network is small, visual inspection is a viable alternative if your switch is incapable of implementing port security.
• VLAN hopping best practices Although VLANs are not needed on this switch to support production traffic, they are possibly needed to support secure management of the device.
• ARP best practices If Address Resolution Protocol (ARP) inspection is available on the switch used in this area of the network, it should be enabled per Chapter 6. Again, because this network is small, you can also watch ARP tables from a management station using something like ARPwatch (Chapter 6).
• Private VLANs Private VLANs can be used here to partition systems from one another. This is problematic in a network of this size, however, because almost everyone needs to talk to everyone else. If further partitioning becomes necessary, an L3 switch might be needed (see design alternatives later in this section).
• DHCP best practices If available, DHCP snooping or VLAN ACLs (Chapter 6) can be deployed to stop most DHCP attacks. Again, like ARP inspection, the network is small, so these attacks should be easy to spot and contain even without these controls in place.

Internal Servers

In the small network campus design, the task of protecting the internal servers adequately falls almost exclusively on the servers themselves. ACLs and IDS are not available in the network to help because they aren't particularly cost effective. The most common internal servers in this design are file/print servers, e-mail, intranet, and DNS servers. E-mail and DNS in particular can be outsourced as discussed in Chapter 13. The key security techniques configured on the internal servers are as follows:

• Reusable passwords In a network of this size, internal authentication can be done exclusively with username/password pairs.
• Sessionapp crypto Any communications from the client to a server deemed sensitive (based on your policy) should be cryptographically protected with sessionapplication cryptography. Self-signed certificates are probably sufficient here because the server to which you are connecting is probably within walking distance!
• OS/application hardening This is by far the most important step to securely deploying any internal server. Be sure to properly harden the operating system (OS) and any applications, as identified in Chapter 5. An internal worm or remote control software attack will most likely go after your local servers. This requires that they be adequately hardened even though your own users might not directly attack internal resources.
• File system integrity check This should be done on every server as well because the cost involved should be manageable even in a small network.
• Host antivirus Host antivirus (AV) is the minimum host security control that should be deployed on every system in your campus (server or client). More extensive host controls as identified in Chapter 4, "Network Security Technologies," are a good idea, though they might be financially prohibitive for a small network.

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 might 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 automatically patch user systems as security fixes are released for the OS and its core applications. In a network of this size, you will do well to take advantage of these services unless you have the resources to test each patch first, as is recommended for larger networks. Hosts should receive basic hardening when first installed, though with users in control of their own systems, the hardening can atrophy over time.
• Host antivirus Host AV is the minimum host security control that should be deployed on every system in your campus (server or client). More extensive host controls as identified in Chapter 4 are a good idea, though they can be financially prohibitive for small networks. For user PCs, this could mean adding a personal firewallbut I don't recommend this unless you already have the OS/application security issues in your hosts well under control.

WLAN AP

The WLAN AP should be hardened and deployed as described in Chapter 11. Although using a separate VLAN for the wireless traffic is a recommendation from Chapter 11, because there is no capability for L3 segmentation in the small network campus design, this isn't possible. The WLAN must reside on the same network as the rest of the devices.

Optional AAA Server

Depending on your edge VPN selections and your internal WLAN security choice, you might need a AAA server to centralize user credentials for these services. 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 following is the one key additional security technique configured on this device:

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

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-2 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-2. Small Network Campus Design Attack Mitigation

Attack	Detect	Stop
Identity spoofing	Reusable passwords, RADIUS/TACACS+	Sessionapp crypto
Virus/worm/Trojan horse	FS check	Host AV
Rogue devices		Rogue device detection 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		Reusable passwords, RADIUS/TACACS+, host firewalls, sessionapp crypto, network/OS/application hardening, PVLANs
ARP redirection/spoofing		ARP BPs, private VLANs
Remote control software		Host AV, host firewalls, OS/application hardening
Buffer overflow	FS check	OS/application hardening

In this table, some of the top mitigation techniques are hardening (of all types), rogue device detection, and cryptographic protection for the session or application layer of key applications. The extent of defense-in-depth suffers in this design because of a lack of routing and any type of NIDS. In most cases, there are only two or fewer methods to stop any given attack. Still, even with a design as simple as the one presented, reasonable attack mitigation can be achieved.

Design Alternatives

The following are examples of potential design alternatives for the small campus design. There are others (including a design you develop suited to the needs of your own policies).

Increased Security Alternative

You can increase the security of the design without modifying the basic architecture in a number of ways:

• IDS Adding IDS at the network or host layer will aid significantly in detecting (and potentially stopping) attacks.
• L3 forwarding Changing the L2 switch into a basic L3 switch will allow significantly more granularity in filtering. Tagging VLAN traffic on an L2 switch and sending it to your edge device is not recommended because this creates a single point of security failure in your entire design (edge and campus).

Figure 14-2 shows these options implemented in the design.

Figure 14-2. Increased Security Small Network Campus Design

By using an L3 switch, this design more closely mimics the medium network campus discussed in the next section.

Decreased Security Alternative

The only way you can make this design less secure is to use a hub instead of a switch and to not harden your hosts against attack. This is not recommended.