ACL to block management on all but one VLAN interface

[timstumbo]

Our core switch handles all our VLAN interfaces and you can telnet to the switch using any one of the VLAN interface IP addresses. I would like to lock this down so that you can only access the core switch using the management VLAN interface IP address. I found some documentation online on this but it doesn't seem to be working so I would like to get y'alls opinion. 

The management VLAN IP scheme is 10.15.10.0

I created a standard ACL: 
Standard IP access list 20
10 permit 10.15.10.0, wildcard bits 0.0.0.255

I then applied to ACL in the VTY line:
line vty 0 4
access-class 20 out

I applied the ACL but I'm still able to telnet to the switch using any of the VLAN interface IPs. 

[BradEast1]

Try "access-class 20 in", rather than "out".

[timstumbo]

When I apply the ACL as "In" it blocks me from connecting. I'm assuming if I changed my IP address to the 10.15.10.0 subnet it would let me in because that's whats defined in the ACL. 

I could be wrong but I believe "Out" is the correct direction, I just must be missing something else. 

[Reza Sharifi]

Try this example:

vlan 10 and 11 are the other vlans

access-list 101 deny ip any 10.15 10 0.0.0.255 (this is the mgmt subnet)

access-list 101 permit any

interface vlan 10 

access-group 101 in

interface vlan 11

access-group 101 in

HTH

[Meheretab Mengistu]

Hi,

Using access-lists on the VTY lines you can decide which IP addresses are allowed to remotely connect and which are not allowed. What you want to achieve could not be achieved using access-list on the VTY lines. To limit which interfaces are listening for telnet/ssh traffic, you will need to apply access-lists on each SVI interface. I know it is tedious, but that is the way to do it. 

Also, avoid using telnet if possible; it is not secured at all. Use SSH instead (if your switch supports it).

HTH,

Meheretab

[timstumbo]

Thanks for the response. Not all of our switches have the security images on them yet so I have to finish upgrading them before switching over to SSH. 

What about about setting up an ACL on each SVI that blocks port 22 and 23? Wouldn't that be easier than doing it by IP address? 

[Joseph W. Doherty]

Sure, but it would block those ports for all traffic using those ports.

What's often done is to use an "in" ACL on the VTY controlling what subnets can send to the device. Normally only certain source subnets are allowed access. I haven't tried it, but perhaps you could use an extended ACL to restrict access to only your management network, with, or without, also controlling source networks.

E.g.:
ip access-list 101 permit any 10.15.10.0 0.0.0.255

line vty 0 4
access-class 101 in

[Meheretab Mengistu]

Hi Tim,

What about about setting up an ACL on each SVI that blocks port 22 and 23? Wouldn't that be easier than doing it by IP address? 

 When you block tcp ports 22 & 23 from any to any, you will block all traffic traversing through the SVI. The best way is to block those ports from any to the SVIs IP addresses. 

HTH,

Meheretab

[Meheretab Mengistu]

What about about setting up an ACL on each SVI that blocks port 22 and 23? Wouldn't that be easier than doing it by IP address? 

 When you block tcp ports 22 & 23 from any to any, you will block all traffic traversing through the SVI. The best way is to block those ports from any to the SVIs IP addresses. 

HTH,

Meheretab

[Sigurbjartur Helgason · Accepted solution]

Hi timstumbo,

As a general rule, I avoid using interface ACLs for protecting network equipment. On some platforms or in environments with a lot of traffic, using an interface ACL can negatively impact network throughput since every packet that needs to be routed to a different VLAN needs to be parsed against every entry in the list before being switched to the egress interface, not just the packets matching the ACEs in the list. That's not to say you should never use interface ACLs, only that you should avoid them if there are other ways.

To avoid having to do that, Cisco provides two methods for performing this task. The first one is the access-class on the terminal line and the other one is control plane policing (CoPP).

While CoPP is more powerful and very useful in defending against DoS attacks directed at the box, it's also more complex and requires more planning and insight into the traffic that needs to go to the CPU.

Therefore I suggest you use the access-class method.

First of all, direction "out" is only used for connections egressing the line. If this was a serial line or an AUX port connected to a modem, that would make sense but for VTYs you only ever use the "in" direction.

Try this:

ip access-list standard management-stations
 remark Management network
 permit x.x.x.x 0.0.0.255

line vty 0 4
 access-class management-stations in

Put the IP network where your management workstation resides in place of the x.x.x.x and also change the wildcard if needed.

This will prevent anyone from connecting to the VTY lines, from any source IP network, other than the one specified in the list.

[Sigurbjartur Helgason]

Sorry, I submitted the same response twice by mistake and I can't delete it.

My apologies