In the previous chapter, we learned about network-based attacks in which the attacker targets communications lines, and how to protect against them. In this chapter, we talk about attacks targeting network devices and how to harden your network devices against these attacks. By the end of this chapter, you will understand the risks to communications devices and learn how to protect against these risks.
In network devices, we focus on devices that are used for packet switching and forwarding, from simple Layer 2 switches, routers, firewalls, and load balancers to other devices that receive and send packets through the network.
This chapter starts with an explanation of the structure of communications devices— the management, control, and forwarding planes—then, we will drill down into each one, learn about the device resources assigned to each one of them, and learn about the risks and how to protect against them.
In this chapter, we will cover the following main topics:
In this section, we talk about the functional and physical structure of communications devices. We start with the functional structure.
As we saw in Chapter 1, Data Centers and the Enterprise Network Architecture and its Components, in the Data, control, and management planes section, a communications device's structure comprises three planes, categorized by the function they perform, as follows:
As there are three different functions, there are also three different ways to attack a device, as outlined here:
Before getting into further details, let's see the structure of a typical communications device so that we can understand its vulnerabilities better.
In data networks, a communications device is a hardware/software component that makes decisions and forwards packets according to these decisions. A local-area network (LAN) switch forwards packets according to Layer 2 information (that is, the switch media access control (MAC) forwarding table); a router forwards packets based on a Layer 3 routing table; a firewall forwards packets based on security policy; and so on. Let's look at these components in detail and see how they can be attacked.
A LAN switch operates in Layers 1 and 2 of the Open Systems Interconnection-Reference Model (OSI-RM). It forwards frames based on Layer 2 information. In the following diagram, we see the general architecture of a LAN switch:
As we see in the preceding diagram, frames are coming into the switch from PCs connected to it. Frames are forwarded through the input buffers, through the backplane, and forwarded through the output buffers to the destination PC.
The content-addressable memory (CAM) table holds the MAC address table and ports they have been learned from. The forwarding information base (FIB), access control list (ACL), and quality of service (QoS) tables store additional information, outlined as follows:
There are other tables and mechanisms, depending on the vendor and switch size. From an attack and defense point of view, this is the architecture we should consider when we plan our attacks and defenses.
A router is a device that makes decisions based on the Layer 3 information of the packets and forwards them. In the following diagram, we see a typical router architecture:
In the router architecture, we have Layer 1, Layer 2, and Layer 3 operations—Layer 1 because packets are received and sent to the wire, Layer 2 because packets are forwarded from port to port, and Layer 3 because decisions are taken based on Internet Protocol (IP) addresses and routing tables. For this reason, along with Layer 3 attacks, Layer 2 attacks can also affect routers.
In the control plane, we have several types of processes that run on a router. The first type, of course, is routing processes—these are the routing protocols that exchange information with other routers on the network. Other processes that control traffic forwarding are—for example—ACLs that forward or block traffic as configured by the network administrator, QoS mechanisms, network address translation (NAT), and many others.
The result of the routing and other control processes running on the router is forwarding and decision tables, according to which packets are forwarded.
Firewalls, load balancers, and other communications devices are devices that work on Layer 2 and above, forward packets, and perform additional operations, as per device type.
Firewalls forward packets according to security policy using the following mechanisms:
Important Note
There is a difference between the firewall forwarding mode and the decision a firewall makes as to whether to forward packets or not. As for the forwarding mode, the firewall can be configured to work as a LAN switch (that is, to make forwarding decisions based on Layer 2 MAC addresses)—or to work as a router (that is, to forward packets based on Layer 3 routing tables, which is more common). In both ways, a security policy is implemented on the packets that cross the firewall.
All these mechanisms run as processes on the firewall, preventing intrusions and other risks, but they can also be targeted by attackers.
Now that we have talked about communications devices' functionality and planes, in the next section, we will talk about potential risks and how to protect against them.
The management plane is the part of the device responsible for controlling the device—that is, to log in to the device and configure it, to receive SNMP commands, to send SNMP traps and System Logging Protocol (Syslog) messages to a management console, and so on.
For this reason, attacks on the management plane can be categorized as follows.
The first sorts of attacks are brute-force attacks for password discovery, such as the following:
The next kinds of attacks are attacks on the management plane intended to interfere with the management of the device. In this category, we have the following:
Let's see how such attacks are performed and how to protect against them.
The first type of attack that we are going to talk about is brute-force attacks, usually based on password-guessing mechanisms.
We talked about brute-force attacks in Chapter 5, Finding Protocol Vulnerabilities, in the Breaking usernames and passwords (brute-force attacks) section.
There are various types of testing tools. For password guessing, we have Linux tools such as nmap, John the Ripper, ncrack, Hydra, and Crunch.
For SNMP discovery, we can use tools such as the OpenNMS platform, SNMP scanners such as Lansweeper, or other open source or commercial tools.
For HTTP/HTTPS password cracking, you can use nmap or many other penetration testing tools, such as skipfish.
There are several simple measures to take against brute-force attacks, outlined as follows:
As we see from the preceding screenshot, the capabilities of the terminal will be as configured in the RADIUS server. It can be used to read information from the communications device, to write information, to change the configuration, or any other thing configured on the server—for example, one user can be assigned read-only privileges while another will be assigned full administrator privileges.
Configuring a device with RADIUS or TACACS is a vendor-specific procedure. You can implement this through Cisco (https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_rad/configuration/xe-16/sec-usr-rad-xe-16-book/sec-cfg-radius.html), Juniper Networks (https://www.juniper.net/documentation/en_US/junos/topics/topic-map/radius-authentication-accounting-basics.html), and others.
For RADIUS servers, there are many open source versions, such as FreeRADIUS (https://freeradius.org/), along with commercial implementations such as Identity Service Engine (ISE) from Cisco, and implementations from other vendors.
Important Note
RADIUS is an open standard first standardized by the Internet Engineering Task Force (IETF) in Request for Comments (RFC) 2138 (June 2000). TACACS+ is a Cisco proprietary protocol. RADIUS uses User Datagram Protocol (UDP) port 1812 for authentication and port 1813 for accounting, while TACACS+ uses TCP port 49 for both. Both protocols are used for authentication, authorization, and accounting (AAA)—that is, authenticating users, authorizing them for specific actions, and accounting, which is monitoring their activities, with minor differences between them.
Important Note
Every vendor has its own command reference, and in some cases, you will find different commands from different communications devices from the same vendor. When you understand what to protect and how to protect it, the remainder of your task will be to google it and read the manual. In this chapter, we will use examples mostly from Cisco, which is one of the leaders in communications networks, while in some cases of interest we will use examples from other vendors—Juniper Networks, Extreme Networks, HPE, and others—when relevant. In all cases, the purpose of this chapter is to provide a defense methodology and a what-to-do list. For a how-to-do list, refer to your network equipment manuals.
In Cisco, you will have to configure enable secret, like this:
enable secret <password>
Or, you can configure username and password, like this:
username <name> secret <password>
Important Note
Don't forget that Console, Telnet, and SSH are three different access methods. You must configure different passwords and security methods for each of them. For each of them, configure secured access or disable them.
Another feature to configure is Login Password Retry Lockout, which limits the number of login attempts so that in the case of brute-force attacks, the communications device will be locked for a while.
Let's go through the next potential vulnerability—SNMP.
A second way a brute-force attack can succeed is when trying to break the SNMP password—that is, the community string in SNMPv1 and SNMPv2c. In SNMPv3, we have encrypted passwords, so this is more difficult to do.
SNMP comes in three versions: SNMPv1, SNMPv2c, and SNMPv3. The first two versions use community strings that are simple clear-text passwords for read-only and read-write permissions. The third version, SNMPv3, can be configured with encrypted username and password mechanisms and is thus more secure.
To verify your devices are protected against SNMP vulnerabilities, study the following information:
Important Note
SNMP is a management-agent protocol in which you have a management application that has three functions: read information from the agent running on a device, write information to a device, and receive messages initiated by the device. Read information is performed by GET, GET_NEXT, and GET_BULK commands; write operations to a device are done by the SEND command; and messages initiated by the agent are called TRAP (SNMPv1/v2c) or INFORM (SNMPv3 only). Having permissions to access a device must be considered carefully—by reading information from a device, we will learn the network topology and functionality, and writing to a device can cause changes to the network.
For SNMP tests, you can use the following tools:
Now that we have looked at SNMP vulnerabilities and how they can be attacked, let's see how to protect against these attacks.
To protect against information from the communications device being read, do the following:
Important Note
SNMPv1 and SNMPv2c have default community strings—the word public for READ-ONLY and the word private for READ-WRITE. Change these defaults!
As we now have a sound understanding of the first two ways of accessing a communications device, let's look at the last one—that is, HTTP and HTTPS.
HTTP (TCP port 80) and HTTPS (TCP port 443) are also common ports on which we access communications devices and should be carefully handled.
In some cases, it will be easy to break through the web server. Try the following steps:
Now that we have talked about attack tools, let's see how to protect against these types of attacks.
To protect against hacking into communications devices' HTTP/HTTP servers for configuration, proceed as follows:
Now, let's see other potential risks and how to protect against them.
After we have checked for vulnerabilities in the standard protocols, that is the standard door to the communications equipment, lets see how other vulnerabilities can be used to attack these devices.
Here, it is simple. Run the NMAP scanner (Zenmap, which—as you see in the upper bar of the following screenshot—is the graphical version of nmap), and check which services are open. You can see how to do this here:
Now that we have seen how to scan against open services, let's see how to make sure these services are closed and protected.
To defend against attacks on open services is simple—close anything that is not essential to the device's functionality.
Let's take, for example, the router we scanned in the previous example. We have three open ports, as follows:
Now that we have talked about protecting against brute-force attacks, let's see how to protect against attacks targeting equipment availability.
Vulnerabilities in the management plane responding to SYN messages can happen when a massive TCP-SYN attack is coming from an external device, causing a high usage of CPU or memory in the device under attack. There are measures to take against these types of attacks. Let's see how to test for and how to protect against these vulnerabilities.
Testing for vulnerabilities on the management plane is quite logical, as we can see in the following steps:
Important Note
There are tools that directly generate SYN packets. With tools such as Colasoft Packet Builder, you can get to the bits and bytes, and configure and make changes to the sent traffic. You can send a SYN flag or any other combination that can load the tested device.
When simple TCP SYN flooding does not affect the tested device, you can try TCP flag combinations, several packets on different ports, and so on—anything that the router might not be configured to protect against.
You can see another example in Figure 7.9 and Figure 7.10, in which we used two steps in the attack, as follows:
In the first step, we used nmap with the following string: nmap -T4 -A -v 172.30.0.241. Let's look at what each of the commands in the string stands for, as follows:
Let's see how it's done, as follows:
You can see in the following screenshot the result of such an attack on a Cisco Catalyst 2960 using the show processes cpu history command:
Finally, what we will see on the management console (in this example, PRTG) is peaks of load, as illustrated in the following screenshot:
The reason we see 80% utilization in the Cisco command line and 70% in PRTG is due to the measurement's method: in the CLI, we have 1-second intervals between samples, while in the PRTG, we have 1-minute intervals.
The important thing is to use a management system that will alert on 70-75% CPU utilization; at these numbers, the device will start to have slow responses. In higher utilization numbers of 90-95%, the device will function very badly, with high delays and a high probability of packet losses.
Several mechanisms can be configured on the router to protect the management plane against TCP SYN flooding, outlined as follows:
The majority of brand devices have proprietary mechanisms for protecting against SYN attacks. In Cisco, you should enable the TCP Intercept option https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_dos_atprvn/configuration/15-mt/sec-data-dos-atprvn-15-mt-book/sec-cfg-tcp-intercpt.html; in Juniper, you can enable the SYN-ACK-ACK proxy protection screen option, explained in https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/security/security-attack-denial-of-service.pdf; in Extreme Networks, configure dos-protect, explained in https://documentation.extremenetworks.com/exos_commands_16/exos_16_2/exos_commands_all/r_configure-dosprotect-type-l3protect-notifythreshold.shtml?_ga=2.239065216.1810244091.1605352243-1044091113.1601730273.
For every device you configure, read the vendor's recommendation for hardening and securing the device or software.
The control plane, as we saw earlier in this chapter, contains the protocols and processes that communicate between network devices in order to move packets from end to end through the network. In this category, we have Layer 2 protocols such as the Spanning Tree Protocol (STP)/Rapid STP (RSTP); Layer 3 routing protocols that learn network topologies such as the Cisco Discovery Protocol (CDP) or the Link Layer Discovery Protocol (LLDP) that advertise equipment information to their neighbors; the Resource Reservation Protocol (RSVP) that establishes a guaranteed end-to-end (E2E) channel with pre-defined QoS; the Internet Control Message Protocol (ICMP) that is used for network reachability testing; and others.
In Chapter 10, Discovering LAN, IP, and TCP/UDP-Based Attacks, and in Chapter 12, Attacking Routing Protocols, we will get into the details of how to protect the network protocols themselves. What we talk about in this section is attacks and how to protect against the device resources.
There are actions performed by the communications device that have an influence merely on the device interfaces—Layer 2 switching, for example. There are actions that influence the entire device resources—that is, the device CPU, memory, and storage. When attacking a device, we focus on the second type: when our targets are processes that, when loading them, will overwhelm device resources to the point that it will slow down and even stop functioning. In this section, we see the most common ones.
Important Note
Many issues can load a communications device to the point of failure. One indicator for an attack on a device is that it's getting slow, and the best way (of course) is to set a threshold that will send a trap to your management system on a resource's high usage. To check what causes the high usage, use device commands such as the show processes command (Cisco), the show system processes extensive command (Juniper), or another vendor's command, and check what is the process that loads the device. It can be a sizing issue when the device is too small and weak for your network, but it can also be an attack on its resources. For attack patterns, refer to Chapter 9, Using Behavior Analysis and Anomaly Detection.
Let's see some of the processes that may consume significant system resources. The principles are outlined here:
Let's see more details on these.
Routing processes can load the router CPU. Routing protocols that can normally load a router are usually BGP protocols.
Attacks on routing processes will be discussed in detail in Chapter 12, Attacking Routing Protocols. For device health-check processes, verify there is no load coming from routing.
Encryption, when performed on a router of firewall CPU and not on dedicated hardware, can consume significant resources from the device CPU.
When you see high CPU utilization due to an encryption process, verify the following:
Let's now talk about the Address Resolution Protocol (ARP).
Any packet with IP options, fragmentation, and packets with a Time-To-Live (TTL) field equal to 1 are forwarded to the CPU for processing.
IP options were presented in the IP version 4 (IPv4) standard but never actually used until early 2021, when they were defined again for features such as Identifier-Locator Network Protocol (ILNP) (RFC 6746, November 2012), Label Edge Router Forwarding of IPv4 Option Packets (RFC 6178, March 2011) implemented in Multi-Protocol Label Switching (MPLS), and some other features that are not applicable for enterprise networks. For this reason, using them can load the device's CPU.
Another issue is with the TTL field in the packet. For TTL=1, which is used as a protection mechanism in some routing protocols, this is also something to be handled by the CPU and potentially loading it.
ARP is a protocol that is used to resolve the destination MAC address from its IP. We talked about ARP attacks in Chapter 6, Finding Network-Based Attacks, in the L3- and ARP-based attacks section. These types of attacks can cause network errors, as we talked about in Chapter 6, Finding Network-Based Attacks, but they can also cause load on device resources.
You can use an ARP rate limit to protect against ARP poisoning attacks. Refer to Dynamic ARP Inspection in the vendor's manuals to eliminate this issue.
Let's now talk about IP issues.
IP fragmentation is a standard mechanism that is used when a large IP packet must be transferred over Ethernet frames that have a maximum payload of 1,500 bytes (1,518 bytes including the header; 1,522 bytes including the header and virtual LAN (VLAN) tag, if this exists). Several problems can be caused by fragmentation, as outlined here:
To do so, refer to vendors' manuals—for example, the Cisco Security Configuration Guide at https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_acl/configuration/15-sy/sec-data-acl-15-sy-book/sec-refine-ip-al.html, or Juniper (https://www.juniper.net/documentation/en_US/junos/topics/example/routing-stateless-firewall-filter-security-handle-fragment-configuring.html). Now that we've seen what can be attacked, let's see how to defend against these attacks.
As we saw earlier, the data plane is the part of the networking device that's responsible for the transfer of data through the device, and therefore attacks on the data plane are those targeting processes and services that are responsible for data transfer. Data plane services are services such as ICMP, ARP, and Reverse ARP (RARP), among others. We will go through these services and see how to protect the data plane while using them.
Heavy traffic can cross a networking device interface—that's the purpose of it. The thing is to know when it happens and check if it is legitimate traffic. For this purpose, there are two things we can configure, as follows:
Configuring a threshold: 80-90% of the interface bandwidth should be a reasonable value. For example, for Cisco, refer to https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/21/Threshold/21-Thresholding-Config/21-Thresholding-Config_chapter_011000.pdf; for Juniper, refer to https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/interfaces-edit-threshold.html.
Important Note
In many places, we include links to vendors' documents. The links we include are to the most common equipment vendors—Cisco, Juniper Networks, and others—based on popularity only.
Configuring storm control: This command limits the percentage of the total amount of data that is transferred through an interface. Storm control should be limited to 10-15% of interface traffic. For configuring storm control, refer to the vendors' manuals.
Now, let's talk about attacks on equipment resources.
A communications device is a dedicated computer, and this computer has computer resources that can be attacked. In this section, we talk about potential attacks on these resources and how we can protect against them.
Memory leaks are static or dynamic memory resource allocations of memory that do not serve any useful purpose. This can be due to a software bug, inefficient software, or attacks that consume memory resources.
Memory leaks can be any of the following:
Let's see how to configure alerts for avoiding memory leaks.
Refer to the Cisco manual at https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bsm/configuration/15-2mt/bsm-mem-thresh-note.html and the Juniper user manual at https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/high-threshold-edit-system-services-resource-monitor.html on how to do this.
Configure a minimum memory reservation at which the networking device will be able to send critical notifications. Refer to the Cisco manual at https://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html and the Juniper manual at https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/pic-memory-threshold-edit-services.html for more information on this.
Let's now talk about CPU issues.
A device's CPU can be loaded due to legitimate or non-legitimate operations, while non-legitimate operations can be due to denial of service/distributed DoS (DoS/DDoS) attacks or other types of attacks.
To protect against CPU-based attacks on Cisco devices, configure alerts on CPU high consumption. To configure alerts, you should run the following commands:
To do the same for Juniper devices, refer to the Juniper manual at https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/snmp-traps.html.
The principle is to send a trap when the CPU load rises above a specific value configured in the <high-value> parameter, for period of time configured in the <high-time> parameter. Another trap will be sent when it goes down to a low value configured in the <low-value> parameter, for a period of time configured in the <low-time> parameter, which should be configured for the normal operation value, usually around 30%.
In this chapter, we talked about risks to networking devices, including attacks on the management, control, and data planes—attacks on the management plane that intend to break into devices or prevent us from managing them, attacks on the control plane that target the protocols that a device works with, and attacks on the data plane that forward the information. We also talked about attacks on device resources and how to discover and protect against them.
Now that you have completed this chapter, you will be able to protect your communications devices against various attacks targeting the management, control, and forwarding planes, and set notifications for such attacks when they happen.
In the next chapter, we will talk about eavesdropping, packet analysis, and behavior analysis, and then go on to how to defend against attacks on the network protocols, getting deeper into identifying and protecting our network.