Switch Hardening: Is the Same Level of Detail Necessary for Every

Introduction: Firewall or Network Switch?

When we think of network security, firewalls are usually the first thing that comes to mind. However, network switches—the fundamental building blocks of any network—can pose just as critical a security risk as a firewall if they are not configured correctly. I have been working in system and network administration for years, and from what I have seen, switch hardening is either not given enough attention in many organizations or is done haphazardly without establishing a proper standard. In this post, I will explain the nuances of switch hardening, whether the same detailed configuration is truly necessary for every single device, and how I follow a pragmatic approach based on my own experiences.

Before diving into this topic, let’s first clarify what the word “hardening” means. Simply put, it involves steps like disabling unnecessary services, changing default settings, and tightening access controls to increase the security of a system or device. On network switches, this usually means restricting administrator access, securing monitoring services like SNMP, shutting down unauthorized ports, and taking preventative measures against various broadcast/multicast storms. But the question is: Should all of these measures be applied with the same intensity and detail for every single switch in the network?

Managed vs. Unmanaged Switches: The Core Distinction

We can divide network switches into two main categories in terms of security configuration: managed and unmanaged switches. Unmanaged switches operate on a plug-and-play basis and do not offer any configuration options. Therefore, it is not possible to perform a specific hardening process on these devices. However, managed switches offer many advanced features such as creating VLANs, setting up port security, configuring SNMP, and defining access control lists. This makes them both more flexible and devices that potentially present a larger attack surface.

In my experience, core switches in data centers and distribution layer switches generally require the highest security measures. These devices form the backbone of the network, and the volume of traffic passing through them is much higher. In contrast, a more simplified hardening approach may sometimes suffice for access layer switches where end-user devices connect. For example, an access switch on an office floor where every employee’s computer connects may not need security policies as complex as those of a core switch in the data center.

Layer-by-Layer Security: Who Connects Where?

Adopting “zero-trust” architecture principles in network security requires treating every device and every connection as a potential threat. This also applies to switch hardening. However, when applying this principle, we shouldn’t interpret it as “treat everything exactly the same.” It is smarter to determine the level of hardening by understanding the responsibilities and traffic flow between network layers.

Core switches are the points where all network traffic is aggregated and routed. On these devices, the focus is on securing routing protocols like OSPF or IS-IS, verifying BGP peers, properly setting up QoS (Quality of Service), and restricting administrator access to SSHv2. A vulnerability at this layer can compromise the security of the entire network.

Distribution layer switches, on the other hand, handle routing between different VLANs or subnets. Similar security measures are taken here, but the focus is often on controlling inter-VLAN traffic and port security. For example, access lists can be used to prevent unauthorized transitions from one VLAN to another.

Access layer switches are typically the points where end-user devices connect. The issues that require the most attention on these switches are: port security, MAC address filtering, DHCP snooping, ARP inspection, and 802.1X authentication. These measures help prevent unauthorized devices from connecting to the network and launching attacks against other devices. In my projects, I usually limit myself to securing administrator access on an access switch by allowing it only from specific IP addresses or over SSH. However, on core switches, I implement much more detailed restrictions using access control lists (ACLs).

Concrete Examples: Which Settings for Which Devices?

Let’s put this into practice. Consider three different scenarios in an organization:

1. Data Center Core Switch: This device manages the traffic of all servers in the data center. The measures we should take here might include:

   • Enforcing SSHv2: ip ssh version 2
   • Strong password policy: aaa new-model, aaa authentication login default local
   • Disabling unauthorized ports: Deactivating each unused port with the shutdown command and enabling only the ports that are needed.
   • Using SNMPv3: Configuring SNMPv3 with commands like snmp-server group <group_name> v3 priv to avoid the known vulnerabilities of SNMPv1/v2c.
   • BPDU Guard: Enabling spanning-tree bpduguard enable on critical ports to prevent STP (Spanning Tree Protocol) loops at endpoints. Although this is a feature that should be on access ports, it prevents loops on core switches in case a switch is plugged in accidentally or maliciously.

2. Layer 3 Distribution Switch: Handles routing between different VLANs.

   • The SSHv2, strong password, and SNMPv3 settings mentioned above are also valid here.
   • Inter-VLAN Access Control Lists (ACL): For example, allowing access from a server VLAN (VLAN 100) to a user VLAN (VLAN 200) only on specific ports:

     ip access-list extended VLAN100-TO-VLAN200
      permit tcp 192.168.100.0 0.0.0.255 host 192.168.200.50 eq 80
      deny ip any any log
     !
     interface Vlan100
      ip access-group VLAN100-TO-VLAN200 in

   • Routing protocol security: If OSPF is used, adding authentication with commands like ip ospf authentication message-digest.

3. Layer 2 Access Switch: Ports where employees’ computers are connected.

   • SSHv2 and strong password settings.
   • Port Security: Allowing only one MAC address on a specific port:

     interface GigabitEthernet0/1
      switchport mode access
      switchport port-security maximum 1
      switchport port-security mac-address sticky
      switchport port-security

     This setting prevents a user from connecting multiple devices to the same port. The MAC address is learned as “sticky” and is preserved even when the switch reboots.
   • DHCP Snooping: Preventing DHCP offers from untrusted sources:

     ip dhcp snooping
     ip dhcp snooping vlan 10,20,30  // Specify VLANs
     interface GigabitEthernet0/1
      ip dhcp snooping trust // Ports where the trusted DHCP server is connected
     !
     interface GigabitEthernet0/2
      ip dhcp snooping limit rate 10 // Do not exceed 10 DHCP packets per second

   • Dynamic ARP Inspection (DAI): Relies on DHCP snooping to prevent ARP spoofing attacks and validates ARP packets generated by the trusted DHCP server.
   • 802.1X Port-Based Authentication: Ensures that user or device identity is validated before connecting to the network. This is highly effective, especially in corporate networks. It is configured with commands like aaa new-model, dot1x system-auth-control.

These examples demonstrate how the measures to be taken vary for switches at different layers. Going into the same level of detail for every device can lead to both a waste of time and unnecessary complexity.

Trade-offs and Pragmatic Approaches

Every security measure comes with a cost. This cost can be a drop in performance, configuration complexity, increased financial cost, or the risk of misconfiguration. These trade-offs must also be considered in switch hardening.

For example, implementing MAC address pinning (port security mac-address sticky) on every port requires you to manually update the port configuration whenever a new device needs to be added. This can bring a serious operational burden, especially in environments with frequent device changes. In such cases, perhaps a more dynamic and centralized authentication mechanism like 802.1X might be preferred. In my own experience, I turned to 802.1X instead of port security in departments where users frequently changed devices. Although this was more complex to set up initially, it simplified management in the long run.

Another important trade-off is the processing power and memory of the switch. Implementing highly complex ACLs or security features can negatively impact performance, especially on older or entry-level switches. For instance, processing an ACL with thousands of lines can subject the switch’s CPU to heavy utilization. Therefore, it is critical to evaluate the hardware capabilities of your chosen switch and whether the security policies you will apply are compatible with these capabilities. Years ago, during a security update I performed for a manufacturing plant’s network, I saw that newly added detailed ACL rules pushed the CPU of older switches up to 90%, causing packet loss on the network. Back then, we solved the problem by optimizing the ACLs or applying certain rules to less critical ports.

Therefore, my approach has always been this: while applying the highest security measures to the most critical devices, determine a “good enough” hardening level for less critical ones that balances workload and complexity. This is based on the principle of “give each device the attention it needs” rather than “show the same care to every device.”

Conclusion: Smart and Targeted Security

In conclusion, the answer to the question of whether switch hardening should be reduced to the same level of detail for every network device is a clear “no.” Understanding your network architecture, the roles of the devices, and the criticality level of the traffic passing through them is the foundation of building an effective security strategy. While core switches require the most comprehensive and detailed hardening, more pragmatic and management-friendly approaches should be adopted for access switches.

This does not mean compromising on security. On the contrary, it means utilizing resources (time, manpower, device capacity) in the most efficient way to eliminate the greatest risks in the best possible manner. Security is like a marathon; every step must be taken consciously, and steps that will lead to unnecessary fatigue must be avoided. By establishing this balance in my own projects, I have aimed to both ensure network security and increase operational efficiency. Remember, the best security is not the one that is complex and incomprehensible, but the one that is understandable, applicable, and sustainable.