Network Infrastructure Hardening

Network Infrastructure Hardening

Network infrastructure often sits at the foundation of an organization’s security architecture. Routers, switches, wireless controllers, access points, storage systems, server management interfaces and other infrastructure components can all become valuable targets if they are left with weak configurations or unnecessary exposure.

Hardening these systems is not about applying one configuration template everywhere. The goal is to reduce the attack surface, restrict administrative access, limit lateral movement, improve visibility and make infrastructure changes easier to control.

This guide covers a practical baseline across six areas:

  • Network segmentation and segregation
  • Protection of management interfaces
  • Identity and access control
  • Logging and monitoring
  • Backups, patching and configuration management
  • Wireless network security

Network Segmentation and Segregation

A flat network makes an attacker’s job much easier. Once one system is compromised, unrestricted connectivity can allow the attacker to discover other systems and move laterally through the environment.

Network segmentation should separate systems according to their role, sensitivity and security requirements.

Separate Networks by Function

Use separate security zones for systems with different purposes or trust levels. Depending on the environment, this may include:

  • Internet-facing or DMZ networks
  • Internal user networks
  • Server networks
  • Administrative networks
  • Infrastructure management networks
  • Guest networks
  • Security-sensitive systems

For highly sensitive infrastructure, physical separation can also be considered where the architecture and operational requirements justify it.

Use VLANs to Reduce Unnecessary Connectivity

VLANs provide a practical way to separate devices and users according to function. For example, administrative workstations, standard users, servers and network-management systems should not automatically share the same Layer 2 network.

Typical segmentation might include:

  • User VLAN
  • Administrative VLAN
  • Server VLAN
  • Management VLAN
  • Guest VLAN

Segmentation only provides meaningful security when traffic between those segments is controlled. Apply firewall policies or access control lists so that only required communication is permitted.

Filter Traffic Between Security Zones

Do not allow unrestricted communication between VLANs or network zones simply because they are part of the internal network.

Define the required communication paths and allow only those flows. Everything else should be restricted according to the organization’s network security policy.

On Internet-facing interfaces, filter inbound traffic claiming to originate from RFC 1918 private address ranges. Such addresses should not normally arrive from the public Internet.

Avoid Using VLAN 1 as the Native VLAN

Where supported by the network design, move the native VLAN away from the default VLAN ID 1 and avoid using VLAN 1 for normal user or management traffic.

Use 802.1X for Wired Network Access

Where the infrastructure supports it, use 802.1X authentication on access switch ports.

This allows users or devices to be authenticated before receiving normal LAN connectivity and can also be used to place authenticated endpoints into the appropriate VLAN according to their identity or role.

Disable Unused Switch Ports

Unused physical switch ports should not remain active indefinitely.

Administratively disable ports that are not required and place unused ports into an appropriate unused or isolated VLAN according to the network design.

Apply Port Security Where Appropriate

For user-facing access ports, switch port-security features can reduce the risk of unauthorized devices being connected.

Common controls include:

  • Limiting the number of MAC addresses learned on a port
  • Using sticky MAC learning where appropriate
  • Defining violation handling
  • Generating alerts when violations occur

An example for a Cisco Catalyst access port could look similar to:

Switch(config-if)# switchport port-security
Switch(config-if)# switchport port-security maximum 2
Switch(config-if)# switchport port-security violation restrict
Switch(config-if)# switchport port-security mac-address sticky
Switch(config-if)# switchport port-security aging time 15

The exact configuration should be adjusted to the environment and device role rather than copied to every interface without review.

Protect Routing and Redundancy Protocols

If dynamic routing protocols such as OSPF or EIGRP are used, enable protocol authentication where supported so that unauthorized devices cannot easily participate in routing exchanges.

The same principle applies to first-hop redundancy protocols such as HSRP, VRRP or GLBP. Use authentication mechanisms where available.

Protect Physical Infrastructure

Logical security controls provide limited value if anyone can physically access the infrastructure.

Network equipment should be installed in controlled locations such as locked communications rooms, racks, cabinets or data-center areas.

Access to critical infrastructure should be limited to authorized personnel and, where appropriate, protected through badge, smart-card or other physical access-control mechanisms.

Protect Management Interfaces

Management interfaces provide privileged access to infrastructure and should therefore have significantly tighter controls than normal production traffic.

Use a Dedicated Management Network

Where possible, use an out-of-band or dedicated management network for administrative access.

Management traffic should not need to traverse ordinary user networks.

Use Bastion or Jump Hosts

A hardened jump server provides a controlled entry point for administrative access.

Instead of allowing administrators to connect directly to switches, routers, storage systems or server-management interfaces from arbitrary endpoints, restrict management access so that connections originate from approved bastion systems.

A properly managed bastion can also provide additional controls such as:

  • Strong authentication
  • Centralized access control
  • Session logging
  • Administrative monitoring
  • Restricted software and network access

Restrict Management Access

Use firewall rules or ACLs to limit which networks and systems are allowed to reach infrastructure management interfaces.

Administrative interfaces should not be reachable from every internal subnet.

Where possible, only designated management networks and approved administrative systems should be able to initiate these connections.

Do Not Expose Management Interfaces Directly to the Internet

Direct Internet access to router, switch, storage, hypervisor or hardware-management interfaces should be avoided.

For remote administration, use an approved VPN, Zero Trust access mechanism, bastion architecture or another protected remote-access solution.

Management services on Internet-facing interfaces should be disabled or explicitly restricted.

Remove Insecure Management Protocols

Use encrypted management protocols wherever possible.

  • Use HTTPS instead of HTTP for web administration.
  • Use SSH version 2 for command-line administration.
  • Disable SSH version 1.
  • Disable Telnet.
  • Avoid FTP for administrative file transfers.
  • Disable SMBv1.

Services that are not required should also be disabled. Depending on the device and operational requirements, this may include protocols such as SMB, CDP, LLDP or other management and discovery services.

Do not disable a protocol simply because it appears on a generic hardening list. First verify whether it is required by monitoring, automation, troubleshooting or network operations.

Identity and Access Control

Administrative access to network infrastructure should be attributable to an individual identity whenever possible.

Remove Default Access

Default administrative credentials are one of the first things to address when deploying a new device.

  • Change all default passwords.
  • Disable unnecessary default accounts.
  • Rename default privileged accounts where the platform supports this and it provides value.

Common default names such as admin, administrator, root or manager should not be relied upon as the primary administrative identity.

Protect Administrative Passwords

Use strong passwords and the strongest credential-storage mechanism supported by the platform.

For older Cisco configurations, the following command can at least prevent supported plaintext passwords from being displayed directly in the configuration:

Router# configure terminal
Router(config)# service password-encryption

This should not be treated as a replacement for stronger password hashing or modern AAA. Use stronger platform-supported mechanisms whenever they are available.

On Cisco devices, use enable secret rather than the older enable password mechanism for privileged access.

For devices that still depend on local passwords, use a minimum length of at least 13 characters where supported. Legacy platforms that cannot support this should use the strongest value allowed by the device.

Configure Session Timeouts and Brute-Force Protection

Administrative sessions should not remain open indefinitely.

Configure idle-session timeouts for:

  • Console sessions
  • SSH sessions
  • Web-management sessions

Where supported, configure login throttling, account lockout or similar protections against repeated authentication attempts.

Use Role-Based Access Control

Not everyone who needs access to a network device requires full administrative privileges.

Use RBAC to separate roles such as:

  • Administrator
  • Operator
  • Read-only or monitoring access

This reduces both accidental changes and the impact of a compromised account.

Centralize Administrative Authentication

Where possible, integrate infrastructure devices with centralized AAA services such as RADIUS or TACACS+.

This provides centralized authentication, authorization and accounting and avoids creating unmanaged local accounts independently on every device.

Local emergency accounts may still be required, but they should be tightly controlled and treated as break-glass credentials rather than normal administrative accounts.

Logging and Monitoring

Infrastructure logs become much more valuable when timestamps are accurate and events from multiple devices can be correlated.

Configure Accurate Time

Configure the correct:

  • Date and time
  • Timezone
  • NTP servers

Consistent time synchronization is essential when investigating activity across routers, switches, firewalls, servers and security platforms.

Centralize Logs

Configure local logging where appropriate, but do not rely only on logs stored on the device itself.

Forward relevant logs to a centralized syslog, logging or SIEM platform. Apply retention and log-rotation policies according to operational and security requirements.

Use Secure SNMP

Where SNMP is required, prefer SNMPv3.

Legacy SNMPv1 and SNMPv2 deployments rely on weaker community-string-based security and should be removed where the infrastructure supports a migration to SNMPv3.

Avoid default community names such as public and private.

Backups, Patching and Configuration Management

Back Up Device Configurations

Create regular backups of important network-device configurations and store copies in a protected location.

For critical infrastructure, maintaining an offline or otherwise isolated backup can provide additional resilience.

Configuration files require special handling because they may contain:

  • Passwords
  • Authentication keys
  • SNMP credentials
  • Certificates
  • Other sensitive configuration data

If configurations are stored in Git or another version-control platform, make sure secrets are removed, protected or otherwise prevented from being accidentally committed to an exposed repository.

Keep Infrastructure Software Updated

Run tested and approved software versions and apply security updates according to the organization’s patch-management process.

Firmware, operating-system images and patches should come from trusted vendor sources.

Where the vendor publishes cryptographic hashes, verify downloaded images against the expected value before installation. This helps detect corrupted or modified packages.

Restrict Software-Update Paths

Software distribution and update traffic should use controlled network paths.

For environments that still use legacy TFTP-based workflows, restrict access to trusted update systems and, where useful, define the source interface used for update traffic.

For example, some Cisco platforms support:

ip tftp source-interface interface

Reduce Configuration Drift

Manually configured infrastructure tends to drift over time.

Where practical, use configuration-management or Infrastructure-as-Code tooling such as Ansible to maintain consistent device configurations and make changes easier to review and reproduce.

Wireless Network Security

Use Strong Authentication

For enterprise wireless networks, use 802.1X authentication where supported.

Where 802.1X cannot be used, apply the strongest WPA2 or WPA3 configuration supported by the environment and hardware.

Segment Wireless Networks

Do not treat every wireless client as part of the same trust zone.

Map SSIDs to appropriate VLANs and security policies. Different wireless networks may be required for employees, administrators, specialized devices and guests.

Where identity-aware infrastructure is available, network access can also be assigned according to the user’s role or device type.

Separate Guest Wireless

Guest wireless should normally be isolated from internal systems.

Place guests into a dedicated network or VLAN and restrict access to the Internet or explicitly approved services.

Enable Wireless Protection Features

Where supported by the access points and clients:

  • Use WPA2/WPA3 with strong AES-based encryption.
  • Enable management frame protection.
  • Use wireless client isolation where clients do not need to communicate directly with each other.

Final Checklist

A practical network hardening baseline should answer the following questions:

  • Are sensitive systems separated from ordinary user networks?
  • Is traffic between network segments limited to what is actually required?
  • Are unused switch ports disabled?
  • Are administrative interfaces restricted to dedicated management paths?
  • Can any management interface be reached directly from the Internet?
  • Have Telnet, HTTP, SSHv1, SMBv1 and other unnecessary legacy services been removed?
  • Are administrative identities centrally managed?
  • Is least privilege applied to infrastructure access?
  • Are infrastructure logs sent to a centralized logging or SIEM platform?
  • Are device clocks synchronized?
  • Are configurations backed up securely?
  • Are firmware and software updates obtained from trusted sources and verified?
  • Is configuration drift controlled?
  • Are corporate, administrative and guest wireless networks appropriately separated?

Network hardening should not be treated as a one-time deployment task. Device configurations, administrative access, firmware versions and network segmentation should be reviewed periodically as the infrastructure changes.

The objective is straightforward: minimize exposed services, restrict administrative paths, limit lateral movement, and make every privileged action visible and attributable.

Comments are closed.