Securing Network Management VLANs with ACLs

Defining the Security Policy for a Management VLAN

Before writing any configuration, we must clearly define our security policy. A strong policy for a management VLAN is built on the principle of least privilege: only grant the minimum necessary access.

Let's establish a typical policy:

1. Permit Authorized Access: Only network administrators, connecting from a designated "IT Admin" subnet, are allowed to manage the network devices.
2. Permit Secure Protocols: Only secure management protocols should be allowed. This typically includes:
   • SSH (TCP Port 22) for secure command-line access.
   • HTTPS (TCP Port 443) for secure web-based GUI access.
   • SNMP (UDP Ports 161/162) for network monitoring (ideally SNMPv3, which adds encryption).
   • ICMP for basic connectivity testing (ping).
3. Deny Everything Else: All other attempts to access the management VLAN from any other source or using any other protocol must be denied.
4. Log Violations: All denied attempts should be logged to alert administrators to potential unauthorized access or misconfigurations.

This policy creates a hardened security perimeter around your most critical infrastructure.

Implementing the Policy: A Two-Layered Approach

In a Cisco environment, we have two primary tools to enforce this policy, and they are best used together for defense-in-depth:

1. VLAN-Level Filtering (SVI ACL): An ACL applied to the management VLAN's SVI. This protects the entire subnet from unauthorized traffic. It is the primary method for fulfilling our learning outcome.
2. Device-Level Filtering (VTY ACL): An ACL applied directly to the terminal lines (line vty) of a switch or router. This specifically protects the remote access (Telnet/SSH) ports of that single device.

We will focus on the SVI ACL, as it secures the whole VLAN, and then briefly cover the VTY ACL as a complementary hardening step.

Designing the SVI Access Control List

Let's assume the following network plan:

• IT Admin VLAN (VLAN 100): 10.10.100.0/24
• Management VLAN (VLAN 254): 10.10.254.0/24

Our goal is to create an ACL that protects VLAN 254. We could apply an inbound ACL on every single other SVI in the network, but as we discussed, this is inefficient. A much cleaner approach is to apply a single ACL on the SVI of the VLAN we want to protect: interface Vlan254.

Which direction? in or out?

• An inbound ACL on interface Vlan254 would filter traffic originating from the management VLAN. This is useful for controlling where your switches can connect to (like an NTP server), but it doesn't protect the switches from inbound attacks.
• An outbound ACL on interface Vlan254 filters traffic that has been routed from other VLANs and is about to exit the SVI to be delivered to a device within the management VLAN.

This is our target. Applying an outbound ACL is the most efficient way to protect a destination subnet from multiple sources.

Crafting the ACL

Given your familiarity with the CLI, let's look at a modern and scalable way to build this ACL using Named ACLs and Object Groups. This approach is much easier to read and maintain in a large network than using numbered lists with individual IP addresses.

First, let's review the concept and advantages of Object Groups.

Now, let's create our object groups and the ACL.

Step 1: Create Object Groups for Networks and Services
This is where we define our "who" and "what".

! Define the authorized administrator network
object-group network IT_ADMIN_NET
 description "Subnet for IT Network Administrators"
 10.10.100.0 255.255.255.0

! Define the allowed management services
object-group service MGMT_SERVICES
 description "Allowed Secure Management Protocols"
 tcp eq ssh        ! TCP 22
 tcp eq 443        ! HTTPS
 udp eq snmp       ! UDP 161
 udp eq snmp-trap  ! UDP 162

Step 2: Create the Extended Named ACL
Here, we combine our object groups into a clear, readable policy.

ip access-list extended PROTECT_MANAGEMENT_VLAN
 remark --- 10: Permit IT Admins to use secure management protocols ---
 permit tcp object-group IT_ADMIN_NET any object-group MGMT_SERVICES

 remark --- 20: Permit IT Admins to ping for diagnostics ---
 permit icmp object-group IT_ADMIN_NET any echo
 permit icmp object-group IT_ADMIN_NET any echo-reply

 remark --- 30: Deny all other access attempts and log them ---
 deny ip any any log

Note: We don't need to specify the destination in the ACL rules because we will apply this ACL to the management SVI. The outbound direction ensures it only affects traffic destined for that VLAN.

The final deny ip any any log is our explicit deny. It ensures any traffic that wasn't specifically permitted is dropped, and the log keyword generates a syslog message for each violation.

Applying the ACL to the SVI

The final step is to apply our newly created ACL to the management VLAN's SVI in the outbound direction.

Here is the configuration:

interface Vlan254
 description >> Management VLAN Gateway <<
 ip address 10.10.254.1 255.255.255.0
 ip access-group PROTECT_MANAGEMENT_VLAN out

With this single line, you have now enforced your security policy, protecting all devices within 10.10.254.0/24 from unauthorized access.

Layer 2: Device-Level Protection with access-class

As a complementary measure, you can also restrict who can SSH or Telnet directly to the switch's control plane. This is done using the access-class command on the VTY lines. This provides an extra layer of defense in case the SVI ACL is misconfigured or removed.

You can often reuse an existing ACL. For this, a simpler standard ACL is usually sufficient.

Here's a quick example of how you would configure it:

! 1. Create a standard ACL permitting only the IT Admin network
ip access-list standard VTY_ACCESS
 permit 10.10.100.0 0.0.0.255

! 2. Apply it to the VTY lines
line vty 0 15
 access-class VTY_ACCESS in
 login local
 transport input ssh

This configuration ensures that even if a packet makes it into the management VLAN, the switch itself will only accept SSH connections from the IT_ADMIN_NET.

Practice Scenario

Let's test your understanding. You are given a new security requirement for the network in the diagram below.

Network Details:

• IT Dept VLAN (VLAN 30): 192.168.30.0/24
• Server Farm VLAN (VLAN 20): 192.168.20.0/24

New Security Policy: "Only the IT Department is allowed to access the Server Farm. They should only be able to use RDP (TCP port 3389) and ICMP (ping). All other access to the Server Farm from any other VLAN must be blocked."

Your Task: Write the configuration for a named, extended ACL to enforce this policy. Then, state which interface and direction you would apply it to.

ip access-list extended PROTECT_SERVER_FARM
 remark --- Permit IT Dept RDP and ICMP access ---
 permit tcp 192.168.30.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 3389
 permit icmp 192.168.30.0 0.0.0.255 192.168.20.0 0.0.0.255

 remark --- Deny and log all other access attempts ---
 deny ip any 192.168.20.0 0.0.0.255 log

 remark --- Allow servers to initiate outbound connections ---
 permit ip 192.168.20.0 0.0.0.255 any

ip access-list extended PROTECT_SERVER_FARM
 remark --- Permit IT Dept RDP access ---
 permit tcp 192.168.30.0 0.0.0.255 any eq 3389

 remark --- Permit IT Dept ICMP access ---
 permit icmp 192.168.30.0 0.0.0.255 any

 remark --- Deny and log all other access attempts ---
 deny ip any any log

interface Vlan20
 ip access-group PROTECT_SERVER_FARM out

Conclusion

You have now successfully designed and applied an ACL for a real-world, high-stakes scenario. Securing the management plane is a foundational skill, and you've learned to do it in a scalable and maintainable way.

Key Takeaways:

• Protecting a destination VLAN: The most efficient way to protect a specific destination VLAN (like Management or Servers) from multiple sources is to apply an extended ACL outbound on that VLAN's SVI.
• Defense-in-Depth: Combine SVI ACLs (VLAN-level protection) with VTY access-class ACLs (device-level protection) for maximum security.
• Use Object Groups: For complex or large-scale networks, leverage object groups to make your ACLs more readable, manageable, and less prone to error.

In our next module, we'll start looking at more advanced routing topics. We will begin by exploring the purpose of route summarization and how it can be used to make your routing tables more efficient, which is especially important in the large-scale architecture you're building.