permit ssh access to specific router ip addresses only

[hakan.topcu]

Hi, I try to filter ssh connections to our routers, to permit the access only to specific router IP adresses and tried the following example configuration:

access-list 111 permit ip any 10.255.255.0 0.0.0.255 log
access-list 111 deny   ip any any log
!
line vty 0 3
 access-class 111 in
 transport input ssh

I hoped, unsing this ACL configuration, the access to the routers vty line could be filtered to an IP-address inside the 10.255.255.0/24 range only, independently on the source address. But this configuration does not work. The vty access-class policy seems not to be able to match on any destination IP:

An SSH connect, sourced from a neighboring router by: "ssh -vrf mgmt 10.255.255.3" is refused, because the connect matches always the final deny any rule and leads to the following syslog message on the target router:

Dec 22 15:29:06.233 UTC: %SEC-6-IPACCESSLOGP: list 111 denied tcp 10.255.255.2(65277) -> 0.0.0.0(22), 1 packet

Even the access-class out (with reversed ACL) command does not work, because this seems to match on outgoing connections only.

The background is, that we use a specific VRF for management purposes, and the permitted clients are already filtered by a firewall policy. But anyway, any client on any subnet on any other VRF ist able to connect to the router IPs inside their VRFs. Therefore the plan is, to restrict any access, to any router IP on the router, except those IPs, that are part of the management VRF.

Is there a way to implement such a policy, without implementing ACLs on every router IP interface (because this would mean to implement an ACL on hundreds of SVIs)?


Thanks in advance. Hakan

[aacole]

I too have run into this problem sometime ago, I found that the access-class policy seemed only to work with standard ACL's and source addresses.

From your experience it would seem that is still the case.

Can you filter only on your management source address range?

[Richard Burts]

It is not true that access-class works only with standard access lists. I would suggest that it works best with standard access list. But it does work with extended access list when the extended access list is correctly configured. I have configured access-class using extended access lists and it does work. What you need to be aware of is that access-class does not differentiate the destination address (only the source address). So a correctly configured extended access list for access-class with have permit any for the destination.

If the original poster wants to restrict SSH access to a particular destination address then access-class is not the correct approach. To accomplish this you would need an access-group on each router interface with a permit tcp <whatever_source> <router_address_allowed> eq 22 and then deny tcp <whatever_source> <each_other_router_IP> eq 22. Effectively you must permit the SSH to the router address that you want to work and then you must deny SSH to every other router address and you must do this on each interface.

HTH

Rick

[hakan.topcu]

Thank you Rick, yes, this would work also, but as I wrote, I want to avoid the approach, with an ACL on each router interface.

[Collin Clark · Accepted solution]

I do it with Control Plane Protection-

http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t4/htcpp.html

[Richard Burts]

Control Plane Protection is an excellent suggestion. It takes away the need to do filtering on every interface.

HTH

Rick

[hakan.topcu]

Thanks, the CoPP approach works perfectly. In my testconfiguration I used two class-map and two policy-map statements, the first one allows and polices the autorized SSH traffic (matched on the destination IP-address by an extended ACL) and the second one drops any else (the unwanted) SSH traffic. Tested on an Catalyst 6880X

Is this the recommended approach?

[...]
  class CLASS-COPP-SSH-AUTORIZED
    police 500000 conform-action transmit exceed-action drop violate-action drop
  class CLASS-COPP-SSH-UNWANTED
    police 32000 conform-action drop exceed-action drop violate-action drop

[...]