Chapter 14. Network Infrastructure

It is easy to focus our attention on application and operating system security, and to overlook fundamental building blocks of an environment such as the network infrastructure. We should always be cognizant that attacks against this infrastructure can be very effective. Networks can be attacked for the purposes of disruption, such as Denial of Service (DoS) attacks, which cause unexpected outages. Networks can also be attacked as a means of redirecting the flow of traffic on a network to achieve goals such as bypassing security technologies or steering traffic toward compromised systems, which could be used by an attacker for the interception or modification of traffic elsewhere in the network.

A well-designed and maintained network will hamper an attacker’s efforts to move laterally within a network or to exfiltrate data, and it will aim to keep him contained within a particular area of the network in the event that a breach should occur.

In this chapter we will discuss good practices you can employ within your environment to harden network infrastructure against a range of attacks.

Firmware/Software Patching

As with other infrastructure, network equipment runs software or firmware, and that requires patching to stay up-to-date in the same way that servers, desktops, and your cellphone do. There is often a tendency to incorrectly believe that firmware contains special properties that somehow make it less susceptible to vulnerabilities. In most respects that matter, firmware is just the same as software except that it is loaded from chips as opposed to other media, such as hard disks. Many types of network equipment do not separate into various abstraction layers such as operating system, device drivers, and applications in the way that desktops and servers do. Network devices are nevertheless running what is essentially software, which exhibits many of the same flaws as desktops and servers; firmware should be considered in a very similar way to a server operating system when it comes to patching. Patches should be tested, approved, and deployed under your internal change control processes, but they should also be deployed as swiftly as is appropriate to close security holes and remain on a vendor-supported version.

Unlike Windows or Unix systems, however, patches are often delivered as a single large image that updates software for the entire device, rather than subcomponents such as drivers or applications, as you may find in a desktop or server operating system. This means that upgrades are often not a vector to a previous version that updates key files, but are more akin to overwriting an entire disk with a complete fresh image with only your own configuration remaining.

Automated and scheduled updates for network infrastructure are more unusual, so a more manual approach to vetting and installing patches is often required. This is not necessarily a bad thing, as core network infrastructure components updating automatically is probably something that most organizations would be as comfortable with as they are with the same approach on desktops and servers.

The method of deployment will vary from vendor to vendor, as will the requirements around backing up configuration beforehand, and the amount of time required for an update. It is recommended that the vendor documentation be consulted to ensure that requirements are met and the correct procedure is followed. Typically, vendors will issue release notes, which contain details of key changes and bugs, including security vulnerabilities that have been fixed for any given release. Consulting the release notes prior to performing any upgrades is strongly advised.

On consumer-grade equipment, the process is generally as simple as downloading a binary package from a website, verifying the signature, and installing via a web interface by uploading to the relevant form. On enterprise-grade equipment, the task is somewhat more complicated. The specific vendor’s documentation should be consulted when upgrading software or firmware, although depending on the update processes for major networking infrastructure manufacturers, the process is generally one of preparation and upgrade.

Here are the steps to prepare:

Select the correct system image for download from the network equipment manufacturer. Images are often specific to hardware and license, as well as the version of the software or firmware you wish to run.
Verify prerequisites. Some software versions will require that the existing software version be of a particular minimum version, for example. RAM, storage, and other hardware requirements may need to be met for successful installation of software of firmware.
Verify the signature of the image. Unlike operating systems for general-purpose computers, many network devices do not have a built-in channel for download and verification of software and firmware images. Thus, where possible, the digital signatures of firmware/software patches should be manually verified prior to using the image in an update. This is typically either via cryptographic signature or file hash.
Backup existing configuration. Although it is generally not possible to back up entire network devices, it is generally the case that the configuration can be backed up to another location. Unlike servers and desktops, network infrastructure does not really store data, and the configuration is typically all that is needed to restore normal operation in the case of an update that loses previously stored information.

And here are the steps for upgrading:

Copy the verified image to the device. Many network devices have a certain amount of flash storage onboard. Copying the image prior to upgrade avoids issues with updating over the network, as network outages can leave a device with a partial image.
Upgrade. This is the process of replacing the running image with the new image. Typically this is a single command that overwrites the existing software or firmware with the new copy.
Reboot. Due to the nature of network devices, in-suite upgrades are often impossible and a reboot onto the new version will probably be required.
Verify successful operation. Ensure that the equipment is functioning as expected. If not, consult the running configuration and compare against the backup copy.

Device Hardening

Hardening network devices is an effective way to drastically reduce the risk of compromise or abuse of a network device and by extension, your environment.

Services

Although not as configurable as a server with regards to running services, networking infrastructure will typically run services of sorts for remote management, time synchronization, telemetry data, etc.

As with hardening a server or desktop, disabling unused services on network infrastructure reduces the opportunity for an attacker to find a flaw in code that is listening on the network and use it to their advantage.

Ideally the device configuration and management interfaces should make it clear which services are running; however, this is not always the case. In this situation we can use other tools, prior to moving into production, to determine which services appear to be running. For example, by using a portscanner like nmap, we can determine which TCP and UDP ports are listening on equipment and make educated inferences to determine which services may be running.

To scan all TCP ports we use the command:

nmap -sT -p1-65535 10.0.10.1/32

-sT: Sets the scan type to TCP connect. nmap has many scanning options, many of which are used to circumvent poor firewalling or ACLs. However, if you are on the same network as the equipment being scanned and it is using no countermeasures of its own, you can connect using a true TCP handshake and obtain more accurate results.
-p1-65535: Tells nmap to scan ports in the range 1 to 65535—i.e., all of them. This can be more time consuming, but will give a more complete view, especially if the vendor has taken a not-unusual approach of running additional management interfaces on higher ports.
10.0.10.1/32: The target to scan, in this case the host 10.0.10.1. The /32 is CIDR notation for a single host. Entire networks can be scanned by using the correct CIDR notation for a wider range.

This will produce something like the following output:

$ nmap -sT -p1-65535 10.0.10.1/32
Starting Nmap 7.12 ( https://nmap.org ) at 2016-01-01 00:00 UTC
Nmap scan report for targethost (10.0.10.1)
Host is up (0.00043s latency).
Not shown: 1021 closed ports
PORT    STATE SERVICE
23/tcp  open  telnet
80/tcp  open  http
443/tcp open  https

In this case, we can see that ports 23, 80, and 443 are open. Typically these ports are assigned to telnet, HTTP, and HTTPS. This is not an entirely unusual set of results. It is most likely that telnet is used for command-line remote administration, while HTTP and HTTPS are used to present the same web-based management interface both with and without encrypted transport.

In this example we would consider how the host should be administered. If the command line is to be used exclusively, then disabling the HTTP and HTTPS interfaces is likely to be worthwhile, as this will remove the opportunity to pass data to the code that runs the internal web server, thus reducing the attack surface available to an attacker. In this case, it would also be advisable to determine if the device is capable of using an encrypted protocol, such as ssh, as opposed to the cleartext telnet. Assuming ssh is available, it is advisable to enable ssh and disable telnet.

This process can be repeated, substituting the -sT for -sU to scan all the UDP ports. UDP ports are likely to highlight SNMP and time synchronization services.

SNMP

SNMP, or Simple Network Management Protocol, is a protocol that has many uses. The most common use is for collecting telemetry data such as bandwidth usage per interface, CPU usage, memory consumption, etc. SNMP can also be used to obtain more sensitive configuration data and, if using the “private community string,” to re-configure devices remotely.

SNMP Community Strings

Access to SNMP is granted via community strings, which are essentially just passwords. By default, these are set to “public” for read only access and “private” for read/write access.

The number one configuration change to make with regards to SNMP is to change the community strings to something other than the defaults. There are three main reasons for this:

Data that can be obtained, even via the public community string, is often very sensitive and at the very least will leak information about your organization’s network architecture. This sort of information is very useful for attackers in determining other targets within your network and avoiding defenses. Data that is available ranges from IP addressing information through to, in some cases, user credentials stored in the configuration.
The private community string allows an attacker to reconfigure devices. If an attacker can control your organization’s network infrastructure, then your defenses are no longer effective, and you may not even know about it.
SNMP produces vastly disproportionate output compared to its input. And so an open (i.e., default credential) SNMP service can be used by others as an amplifier for DoS attacks.

DDoS Amplification

DDoS Amplification is a technique whereby an attacker who wishes to attack host X will find an amplifier (i.e., a host whose output is larger than the input) host Y. By spoofing (faking) network packets to appear to come from host X to host Y, host Y will send disproportionately larger responses back to host X thinking that it is the originator of the request. This means that host X is flooded with more traffic than the attacker produced originally, thus amplifying the attack.

SNMP has three versions: v1, v2c, and v3. From a security perspective, v1 and v2c are functionally the same, with most modern devices automatically using v2c as opposed to v1. If, however, the option for v3 is available, it is advisable to make use of it as both encryption and authentication are features that become available, keeping data secure in transit and reducing the risk of attacks against the simpler community string model.

Encrypted Protocols

Network equipment is often not as mature as server operating systems when it comes to the use of cryptography. This means that encrypted management is not always available, or is not enabled by default.

In the earlier example we saw that not only were both HTTP and HTTPS configured for use in the web interface, but that the command line used telnet as opposed to ssh. This is not an unusual situation.

Of course this sort of issue will vary from vendor to vendor, but it is worth checking the documentation to determine if encrypted versions of management protocols can be used. Needless to say, login credentials will pass over that channel and protecting login credentials to network equipment is key to keeping them secure.

Management Network

Networking equipment typically allows configuration that restricts access to configuration and management functions to a single physical network interface.

It is advisable to build a dedicated management network and configure all devices to restrict access to their management consoles to network interfaces that are connected only to the management network.

Access to the management network can be exclusively through a bastion host, meaning that no management consoles are placed on either public or internal networks, other than for those with credentials to access the bastion host. By restricting access to these interfaces, an attacker would have to compromise the management network before she could attempt to compromise the management interface of the device.

Bastion Hosts

Bastion hosts (or jump boxes) are specifically hardened servers placed on a network that serve as the single point of entry to that network. They typically have a very minimal and locked-down build, with an above-average level of auditing enabled. Only access to these hosts will grant access to the networks that they are on, thus providing a single point of management and enforcement for access to the management network.

Routers

All of the preceding advice is applicable to routers. However, there are some router-specific security considerations worth discussing in more depth.

Routers typically contain options to provide some rudimentary packet filtering in the form of Access Control Lists (ACLs). ACLs are very much like simplified firewall rules, which allow a router to drop packets based on simple criteria such as IP addressing information. ACLs are typically not stateful nor particularly intelligent so as not to impact routing performance, but they do serve some useful purposes:

Other than for management purposes, there is typically no reason for traffic to be destined to a router’s own IP address. ACLs can drop all traffic to the router unless it originates from specific networks authorized to manage the router, for example, a network operations center or bastion host.
ACLs can provide coarse filters for other equipment or networks, for example dropping traffic directed to, as opposed to through, firewalls.
Fragmented packets have a history of causing issues for security devices and so attackers can use fragmentation to circumvent tools such as Intrusion Detection Systems. By dropping fragmented packets, this sort of technique is limited to only a local LAN. However, the implications of such an ACL on your network should be understood prior to implementation of such a measure, as some networks will have legitimate fragmented packets.

Routers may, depending on vendor and default configuration, ship with dynamic routing protocols such as Interior Gateway Protocol (IGP), Routing Information Protocol version 2 (RIPv2), Enhanced Interior Gateway Routing Protocol (EIGRP), or Open Shortest Path First (OSPF). These protocols, if used properly, can dynamically determine the fastest routing path between two hosts and to route around failed devices, links, and network segments. However, if improperly configured, an attacker can leverage such protocols to route traffic via a malicious device that he controls for the purposes of eavesdropping or launching a man-in-the-middle attack.

The specific intricacies of each protocol could be a chapter in its own right, but as with services, it is recommended that routing protocols that are not used by your network be disabled to remove the possibility of abuse. The correct configuration of dynamic routing protocols will be something that is not only specific to vendors, but also to the architecture of your network.

Switches

As with routers, the previous advice is equally applicable to switches, only there are some switch-specific configuration options that may be of use.

For the most part, even managed layer-2 switches are fairly simplistic devices when compared to routers and firewalls. A managed layer-2 switch is a network switch that can be configured with features such as supporting multiple VLANs, SNMP monitoring, VLAN trunking, span ports, and other settings not available on a basic unmanaged switch. Switches have much higher port density than other devices and are used to directly connect devices to the network, and so they have some additional options that are useful:

Virtual Local Area Networks (VLANs): As the name suggests, these are virtualized broadcast domains that can be used to provide logical segmentation. Many performance improvements can be achieved with VLANs, but from a security perspective they can be used to contain groups of devices together and restrict broadcast protocols such as DHCP from reaching other hosts. However, it should be noted that VLANs are not as secure as physical segmentation and should not be considered a security boundary in the same way, as there are still attacks that can make use of VLAN hopping attacks.
Port security: Can be used to prevent an attacker from gaining access to a network by unplugging a legitimate device and plugging in a malicious device in its place. This can be achieved with static MAC address-based controls or dynamic controls, which allow any MAC address on first physical connection to a port, but do not allow that MAC address to change without administrator authorization.
802.1X: A standard for providing port-level authentication. The difference between this and, for example, Windows authentication is that when Windows authentication is used, the host is already on the network and authenticates against Active Directory. Failure to authenticate will not permit access to Windows resources, but at an IP level the host is already on the network and can send and receive traffic. With 802.1X, the host has to authenticate in order for the network port to be connected to the rest of the network.

Egress Filtering

Egress filtering refers to filtering outbound traffic—that is, traffic originating from your internal network destined to another network, such as the internet. But why would you want to filter network traffic exiting your network? Aren’t all of the bad people and viruses on the internet trying to get in from the outside? (No.)

Even if we discount the issues surrounding the insider threat, egress filtering is a very useful, cheap, underused technique. Not only could internal traffic heading outbound be worthy of blocking, it could be a useful indicator that there is an active breach that you should address:

Malware command and control traffic typically originates from infected desktops “calling home” to command and control infrastructure. By restricting outbound traffic only to protocols and IP addresses that are expected as part of normal use, command and control infrastructure running on other ports and IP addresses will be unavailable to the malware. Not only this, but by reviewing logs of dropped traffic it is possible to determine which hosts internally may be infected with malware and are worthy of further scrutiny.
Data exfiltration attempts by someone trying to steal data from a compromised host can often take the form of outbound connections from the internal network. Data theft often takes place using network resources, as opposed to being copied to removable media. By blocking access to all but the expected resources, data exfiltration can be made more difficult to achieve. Again, by reviewing logs of dropped traffic, it may be possible to spot failed attempts at data exfiltration.

IPv6: A Cautionary Note

IPv6, the successor to IPv4, has been in existence for quite some time, but it is often considered by many to not be in use because of the lack of adoption by many ISPs on internet connections, without the use of a tunnel broker. However, the major operating systems all ship with both IPv4 and IPv6 stacks, and have for some time. This means that most networks are unwittingly running a dual IPv4 and IPv6 stack without the knowledge of the network administrators. Furthermore, many security devices are not yet fully IPv6 aware.

Without configuration, IPv6-enabled hosts will configure themselves onto the fe80::/10 prefix and will be able to communicate on, at least, the local LAN using native IPv6.

If devices are prebuilt to use a tunneling protocol such as Teredo, 6in4, 6to4, or 6rd, then they may well have not only internet access using IPv6, but internet access that is effectively unfirewalled and unmonitored. Why is this? Your network equipment will most likely only see IPv4 traffic and not inspect inside the tunnel to see the true IPv6 destination, and thus access controls and monitoring facilities will be ineffective. This, if it is not clear, is bad.

Teredo, 6in4, 6to4, and 6rd

Teredo, 6in4, 6to4, and 6rd are the four flavors of tunneling protocol allowing the use of IPv6 addresses transported over IPv4 to a tunnel broker. This allows the use of IPv6 when connected to an ISP that only supports IPv4.

The preference, of course, is to take control of the situation and to run an IPv6 network yourself to avoid this situation. However, this is not a minor undertaking and is at least a book in its own right.

Egress filtering may take care of the tunneling portion of the problem, but the issue remains that many network security devices may not be capable of properly detecting or preventing IPv6-based attacks. There is no panacea, as many devices are still catching up, so self-education and vigilance are required until such time as IPv6 becomes the de facto standard in networking protocols.

TACACS+

When the word TACACS is mentioned, it most likely means TACACS+, which has replaced TACACS and XTACACS.

TACACS+, or Terminal Access Controller Access-Control System Plus, provides AAA architecture for networking equipment.

AAA

AAA architecture refers to:

Authentication
Authorization
Accounting

By setting up a TACACS+ server, networking equipment can make use of central authentication, which, as with server and desktop operating systems, brings with it all the benefits of a single point of provisioning and deprovisioning of users. Additionally, the accounting features provide centralized storage of accounting data in a central logging repository.

Note

Both centralized authentication and central logging are discussed elsewhere in this book.

Conclusion

Network infrastructure is often considered to be “just plumbing,” as it often will not directly serve requests to applications. However, the underlying integrity of the network is core to the security of other components.

By following good practices such as patching, hardening, enabling encryption, and filtering connections, you can vastly reduce the risk posed to the rest of your environment.

Previous Chapter

13. Password Management and Multifactor Authentication

Next Chapter

15. Segmentation

Table of Contents for Defensive Security Handbook, 1st Edition