NetworkSherpa

VTY ACLs don't block HTTP/S access

John Harrington

I was doing some testing on a 3750X and saw that the http and http services were enabled. I knew that you could apply an ACL to restrict HTTP access, but had assumed that the HTTP security was an optional extra on top of the VTY ACL.
I tested this … and found out I was wrong. Although http(s) uses the same inband access path as SSH, web admin is not restricted in any way by VTY ACLS.
This will be quite obvious to some readers but it wasn’t for me, so I’ll assume at least one other person on the interwebz had the same issue.

Test – VTY ACL doesn’t block HTTP/S

Let’s start with a baseline. https and http secure are configured, and no VTY ACL is applied. A quick public safety announcement I’m consoled into a non-production switch.

TestSwitch#sh run | i http
ip http server
ip http secure-server

I’m testing here from another directly attached switch.

Switch_2#ssh -l admin 192.168.0.1
Password:     !! SSH Works
Switch_2#telnet 192.168.0.1 80
Trying 192.168.0.1, 80 ... Open   !! HTTP also works

Let’s create a deny-all ACL and apply it to the VTY lines

TestSwitch#
conf t
ip access-list extended VTYACL
deny ip any any
line vty 0 15
access-class VTYACL in
end

Testing again…

Switch_2#ssh -l admin 192.168.0.1
% Connection refused by remote host !! SSH is now blocked
Switch_2#telnet 192.168.0.1 80
Trying 192.168.0.1, 80 ... Open  !! Whaaa?

You do have the option of adding a basic access-list to restrict http access and https access You should do this…

TestSwitch(config)#ip http access-class ?
1-99 Access list number

….or you follow your instinct and blow away web access.

TestSwitch(config)#no ip http server
TestSwitch(config)#no ip http secure-server

And all is right with the world. I’d go back and adjust deny all VTY ACL though.

Switch_2#telnet 192.168.0.1 80
Trying 192.168.0.1, 80 ...
% Connection refused by remote host
Switch_2#telnet 192.168.0.1 443
Trying 192.168.0.1, 443 ...
% Connection refused by remote host

Learning and Actions