Designing the Enterprise Campus | Hardening Network Infrastructure. Bulletproof Your Systems Before You Are Hacked.

The most effective method to design a secure infrastructure is to employ a modular design principle. By employing a modular design, you gain the benefit of being able to plan and implement the security requirements of each module on a module-by-module basis, instead of trying to address the security needs of the network as a whole, which can be a daunting task. You also gain the ability to group common network devices into easier-to-manage modules, and then address the security relationship among the modules as opposed to among the individual devices.

In the broad sense, there is a three-tiered design model that should be used when planning and implementing the enterprise campus infrastructure. At the top of the design model is the core network layer, which is designed explicitly to facilitate communications throughout the entire enterprise. In the middle is the distribution network layer, which exists primarily as the location within the network where traffic and security are controlled and managed. As the name implies, the distribution layer is responsible for coordinating the traffic to and from end systems. At the bottom of the model is the access layer, which is where the users connect to the network itself. Figure 12-2 illustrates the relationship among the three layers .

Figure 12-2: Three-tiered design hierarchy

In this example, the core layer is used to connect the distribution layer devices that provide network access to two buildings . The access layer devices are connected to the respective distribution layer devices, providing network access for clients on each floor in the building.

As previously mentioned, the most effective method of putting the three-tiered design model into practice is through a modular design process. We are going to take a look at the following design modules and how they interconnect:

Core module This module exists to facilitate communications among all of the other modules in the design.
Server module This module exists to provide end user services and applications.
Building distribution module This module exists to provide data services to the building access module and to connect the building access module with the rest of the network.
Building access module This module exists to provide end user connectivity to the network.
Management module This module exists to facilitate the secure management of your network resources.
Lab module This module provides a safe and secure method for testing unsecured and new applications and services.

Figure 12-3 illustrates the interaction of the various network modules.

Figure 12-3: The enterprise campus

Core Module

The core module is a relatively simple module from a security perspective because there is no real security within its structure. The devices in the core module exist exclusively to transmit data among distribution layer devices and other modules in the fastest fashion possible. Because all traffic in the core module has to originate from somewhere else in the network, the security requirements are implemented at those other modules.

Server Module

The server module houses those resources that the user community requires access to. The server module contains the file servers, authentication servers (domain controllers), name resolution servers, e-mail servers, departmental servers, application servers, and similar devices. While in principle the servers should be hardened by their respective administrators, there are steps that can be taken at the network level to increase the security of these devices.

Perhaps the most important thing to do at this level is to exercise stringent ACLs to control who has access to a given resource. Because of the nature of server resources, it may be easier to deny access to resources than it is to grant access to resources, which is contrary to the minimalistic security approach employed throughout the rest of the network. The ACLs can be implemented as components of layer 3 switches, routers, or firewalls that control access to the devices in this module.

The server module should also make extensive use of IDS/IPS for the network connections as well as the hosts themselves . Throughout the enterprise the most valuable resources are invariably going to be located here, which makes this module a prime target for attack. Implementing IDS/IPS throughout this module to analyze traffic and generate alarms on suspicious activity is critical to ensuring the security of these resources.

The server module is also an excellent location for implementing private VLANs to control which servers can access each other. This establishes a trust model that ensures that if one server is compromised, it would be difficult for it to be used to attack the remaining servers in this module.

While the most effective design requires that the server module is a separate component from the core module, in smaller environments it may be cost prohibitive to separate these functions. Figure 12-4 details the server module.

Figure 12-4: Server module

At the entrance to the server module is a pair of redundant layer 3 switches with firewall and NIDS functionality. These devices can be replaced by routers with firewall functionality in smaller environments. Within the server module, servers that require increased bandwidth can be connected directly to the layer 3 switches, while other servers are distributed across access layer switches in the module. This can also be done to reduce the cost of additional access layer switches. All of the servers run HIDS/HIPS software to protect against operating system level exploits.

Building Distribution Module

Although it lacks the name, the building distribution module is truly the core of the security infrastructure. The building distribution module ties the access layer devices (particularly those in the building access module) to the rest of the enterprise through the core module. The building distribution module is designed to handle all packet manipulation such as routing, access, and Quality of Service (QoS), as well as all security functions such as access control, filtering, and packet inspection through the use of firewalls or firewall modules. While the building distribution module can have some intrusion detection functionality, that is usually reserved for the modules containing resources that are probable targets, such as the server, Internet, or remote access modules.

The building distribution module provides a location that can act as the first line of defense in protecting the rest of the infrastructure against internally sourced attacks. This protection is implemented through the use of VLANs and PVLANs to segment the network and prevent hosts from being able to access other hosts without explicit permission being granted.

The building distribution module is typically built around powerful, fast layer 3 switches, although in smaller environments the building distribution and core modules may be merged. Because the building distribution module is designed around a switched infrastructure, it is critical to employ switch hardening methods , as detailed in Chapter 6.

Disable any unused ports and place them in a VLAN that is not in use (such as a jail VLAN, as described in the earlier Using VLANs to Isolate Systems section). This will prevent accidental access to resources by incorrectly connecting new devices to the switch.
Use a dedicated VLAN ID for all trunk ports.
Implement dynamic ARP inspection to protect against ARP poisoning attacks.
Implement PVLANs to isolate traffic from devices that do not need to access each other. For example, you can place the access module for one floor into one PVLAN and place the access module for another floor into a different PVLAN, effectively preventing end user stations from communicating with each other.
Hard code the port speed, duplex, and trunk mode to prevent dynamic connections and mitigate the ability for an attacker to spoof as another switch in trunking mode, thereby gaining access to more data than they would have otherwise .
Do not use VLAN1. This is the default VLAN for all devices, and by using VLAN1 you allow any device the ability to potentially connect to and communicate throughout your network.
Deploy port security where possible, specifying which MAC addresses are allowed to connect, as well as implementing 802.1x port authentication where supported.
Enable spanning tree protocol attack mitigation to prevent a hacker from spoofing the root bridge and executing a denial of service or man-in-the-middle attack.
Restrict the use of Cisco Discovery Protocol to only where it s required.
Implement VLAN Trunking Protocol (VTP) passwords to force authentication of all VTP advertisements.
Implement firewalls or firewall modules in the switches to provide more granular packet inspection and filtering.

Building Access Module

The building access module exists primarily to provide network access and services to end user systems such as PCs and telephones. The building access module is the largest module in terms of connections because all end user connections terminate into this module. Unlike the building distribution and server access modules, which may employ layer 3 network functionality, the building access module almost exclusively provides layer 2 functionality. As a result of this we are limited in just how much hardening we can undertake at this layer, relying instead on the building distribution module for the majority of the security enforcement. However, this does not mean that there is nothing that we can do.

The majority of the hardening steps that can be taken in the building access module are going to be the responsibility of the desktop administrators. For the network equipment, we can undertake the same steps as we did for our building distribution module switches.

Management Module

The management module is the only module that does not show a clear connection to any other module. This is due to its very nature and purpose. The management module exists to facilitate the secure management of all of the devices within an enterprise. As a result, the management module is best implemented as a dedicated network that connects all of the network devices but does not connect to any other network segments.

The management module should be implemented as a dedicated subnet that is not advertised or accessible from the production network, thus providing a secure out-of-band management network from which to manage all the devices in the enterprise. Out-of-band management simply means that the network management traffic does not occur on the same subnet as the production data traffic that is being carried by the network device. If the device that needs to be managed does not support out-of-band management or does not have enough interfaces to support the connection to the management network, the management module provides the ability to connect via IPsec to a firewall that allows the remote management traffic to enter the management subnet, while also providing outbound SSH, SSL, and SNMP management traffic. Once again though, this should be implemented only in cases where out-of- band management is not supported. Figure 12-5 illustrates how this all comes together for the management module.

Figure 12-5: Management module

Because the information contained in this module is so critical (for example, device passwords, logging data, and SNMP community strings), it is critical that this module be protected from access from the internal network through the use of a firewall to segment it from the rest of the network. The firewall should accept only IPsec connections, and only from those network devices that require in-band management. All other connection methods should be dropped with ingress filtering. Similarly, you should employ egress filtering that allows access to the production network only when using defined management protocols such as SSH, HTTPS, SNMP, and TFTP, and then provide such access only to defined network devices. Everything else should be dropped.

Lab Module

The corporate lab module represents one of the largest internal threats to our network security due to the fact that so many of the devices in the lab environment are not adequately patched and updated. As a result, I highly recommend that the lab module be physically disconnected from the production network or be treated as a hostile DMZ network.

The Hazard of Connecting the Lab Module to Your Network

I worked at a company that connected their lab environment directly to the corporate network with no access restrictions. When CodeRed hit, over 1,000 unpatched systems in the lab became infected and generated so much ARP traffic as a result of the worm propagation methodology, that it effectively executed a denial of service attack on the network by filling the interface queues on routers throughout the enterprise. The painful lesson that was learned is that no matter how badly R&D claims that they need access to the production network from the lab, they probably don t need it as much as they think they do (i.e., checking e-mail, and so on). Try to find solutions that will allow them to perform the tasks they require while still providing the level of security that is required. For example, you might be able to set up a webmail system and grant access from the lab to that system and that system alone, allowing users in the lab to use the webmail system to check their e-mail.

Being a realist, however, I recognize that you may not be able to keep the lab module disconnected from the rest of the network. The next step then is to mitigate the risks associated with connecting the lab module to the rest of the network by implementing stringent access controls for all traffic passing to and from this module. You should be especially careful about allowing routing information out of the lab environment and into the rest of your production network where it could be propagated and cause problems.