• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 109
  • Last Modified:

protecting/filtering Management VLan using Cisco ACL

Due to legacy design, our Management VLan (where consoles of various servers, ESXi hosts, devices including WAF & Firewalls) are open to users to ssh/ssl in (though password will be prompted).

There's an urgency to fix this: I heard this VLAN sits on either the core or distribution Layer3 switches & not behind firewall :  to migrate it to behind firewall is going to take time & we may not have enough free firewall port/leg.

What's the fastest & safest (ie without causing disruption when making change) to get this VLan filtered/protected (pending firewall being purchased which will take a while) as it's considered quite a risk.

I suggest to put ACLs on the distribution/core switch but my netwk admin objected, saying core switch's function is
for fast routing/switching & we should not put ACLs as it will slow down the routing/switching.  He further argued that such ACL can be complex & accidentally blocked dynamic routing protocols (EIGRP & OSPF etc), causing disruption.

Our core & distribution switches sit in the same Nexus chassis.
0
sunhux
Asked:
sunhux
  • 3
2 Solutions
 
JustInCaseCommented:
Typically, you should configure access protection on each device, by limiting administration access to devices to some specific source device/network (typically jump server(s)). In this case only traffic that is destined to specific port (VTY lines) on device will be checked against ACL. Also, you can change access port for ssh to avoid attacker attempt brute force against standard ssh port if they attacker somehow get access to your jump server, but generally, as far as know, change of access port for ssh is rarely implemented if access is done via jump server.

Here is my home router config (no jump server - administration via local network only) :)
ip ssh port 2022 rotary 1
!
ip access-list extended VTY
 permit tcp 192.168.1.0 0.0.0.255 any eq 2022 log
 deny ip any any log
!
line vty 0 4
 access-class VTY in
 login local
 rotary 1 queued round-robin
 transport input ssh
 transport output ssh

Open in new window

Denied access to port 22
Jan 20 07:42:49.944: %SEC-6-IPACCESSLOGP: list VTY denied tcp 192.168.1.7(57276) -> 0.0.0.0(22), 1 packet

Open in new window

Permit access to port 2022
Jan 20 07:43:11.621: %SEC-6-IPACCESSLOGP: list VTY permitted tcp 192.168.1.7(57284) -> 0.0.0.0(2022), 1 packet

Open in new window

Access list changed:
C892(config)#no ip access-l ext VTY
C892(config)#ip access-list extended VTY
C892(config-ext-nacl)# permit tcp 192.168.1.6 0.0.0.0 any eq 2022 log
C892(config-ext-nacl)# deny ip any any log

Open in new window

Jan 20 07:45:37.505: %SEC-6-IPACCESSLOGP: list VTY denied tcp 192.168.1.7(57360) -> 0.0.0.0(2022), 1 packet
Jan 20 07:46:35.894: %SEC-6-IPACCESSLOGP: list VTY permitted tcp 192.168.1.6(57444) -> 0.0.0.0(2022), 1 packet
Jan 20 07:48:42.750: %SEC-6-IPACCESSLOGP: list VTY denied tcp 192.168.1.6(57474) -> 0.0.0.0(22), 1 packet

Open in new window

1
 
Benjamin Van DitmarsCommented:
What kinda of distribution/core switch do you have, it's not very dificult to make some acl's on the core to block
unwanted management traffic.

do you have a vlan / subnet that is allowed to do management work ?
1
 
sunhuxAuthor Commented:
I heard from our netadmins we use Nexus 5000 for core & another module in the same chassis as distribution switches.

Doubts I have:
a) it's not a practice to create ACLs in core switch to filter who (or which IP) could access the Management VLAN
b) the netadmin lead said it's not a practice to do so on distribution switch too;  he's not revealing whether our
    Management VLAN sits on core or distribution, just saying it's not a practice on both core+distribution to
    create ACLs.  In general practice, where do one place Management VLAN?  Is core, distri or access switch?

Currently the Management VLAN is open on all ports to entire corporate including our internal Wifi which I'm
very concerned
0
 
sunhuxAuthor Commented:
netadmin lead's concern of creating ACL is it will cause service disruption, blocking away dynamic routing protocols & caused slowness:
is this a valid concern?

Q1:
I've always thought ACL is applied on an interface so at most the Management VLAN is affected, am I not right?

Q2:
If it's a VLAN, can it not be easily be ported over to say, a distribution switch (as our Access switches are Layer 2 switch so IP ACLs are not possible)??
0
 
sunhuxAuthor Commented:
>do you have a vlan / subnet that is allowed to do management work ?
Yes, our sysadmins & netadmins access the various ESXi hosts, WAF/network consoles from 2 subnets/VLANs only, so I suppose this should not be too complex an ACL
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The Firewall Audit Checklist

Preparing for a firewall audit today is almost impossible.
AlgoSec, together with some of the largest global organizations and auditors, has created a checklist to follow when preparing for your firewall audit. Simplify risk mitigation while staying compliant all of the time!

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now