10-27-2020 11:08 AM
I have an X460-G2 on firmware 30.3.1.6.
I want SSH access to only be available from VR-Mgmt, so I have configured as follows:
enable ssh2 vr VR-Mgmt
If I attempt to SSH to the device using an IP that belongs to VR-Default, while I can’t log in I do get an SSH login prompt. Additionally if I use portqry to probe port 22 the port is returned as ‘listening’. The addresses in question are accessible from the internet so this is not really acceptable from a security standpoint.
I have already disabled SSH and re-enabled specifically specifying VR-Mgmt.
Firstly - how can I prevent all SSH repsonse on VR-Default? Port 22 should not be seen as open.
I do not wish to restrict access to specific IP addresses - it should be allowed from VR-Mgmt and nowhere else.
Secondly - surely this behaviour is a bug and there should be no response on VR-Default? Why would the device respond when SSH is specifically only enabled on VR-Mgmt?
11-09-2020 10:29 AM
Thanks
11-06-2020 12:20 AM
The drawback is that when you add the next VLAN in the future and forget to add the policy to that VLAN, you’ll not have the intended protection. In security, always forbid everything and allow only what you explicitly want. I’d rather use an ACL allowing SSH from the management network and then a global ACL to deny it.
Oh, by the way, you just disabled all SSH access THROUGH the switch as well… I guess that’s not what you intended?
I’m pretty sure there’s a better way of doing this but it’s way too late for me to think straight now.
/Fredrik
10-27-2020 02:47 PM
Thanks for the suggestions - we did not want to go down the route of allowing specific IPs or IP ranges though. As mentioned above, there are only two active VLANs other than the management VLAN, so we have done the following:
create access-list DenySSH " protocol 6 ; destination-port 22 ;" " deny ;"
configure access-list add DenySSH last vlan VLAN1 ingress
configure access-list add DenySSH last vlan VLAN2 ingress
This seems to have done the job.
I’d be interested to know if there are any potential drawbacks to this approach?
10-27-2020 01:56 PM
Next thought is that since you and I both mentioned this looks like a bug, open a TAC case and see if it can be resolved.
Or this is not exactly what you wanted to do but seems like a good work around since it sounded like the internet was your primary concern.
entry AllowTheseSubnets {
if match any {
source-address 10.10.1.0 /24;
source-address 10.10.2.0 /24;
} then {
permit;
}
}