topic Re: SSH port is still opened for network scanners. (ACL) in ExtremeSwitching (EXOS/Switch Engine)

SSH port is still opened for network scanners. (ACL)

Alex_Z — Mon, 02 Dec 2019 23:37:49 GMT

Hi everybody.
I have done management access to the switch through ssh and applied the Access Profile. The Access Profile is work. But SSH port is still opened for network scanners. And I have a huge amount of fail access attempts in a log file. How I can completely close the SSH port from outside?
X590-24x-1q
ExtremeXOS version 22.6

entry NOC {
if match any {
source-address x.x.x.x/26 ;
}
then {
permit ;
}
}
entry DenyAll {
if match any {
source-address 0.0.0.0/0;
}
then {
deny;
}
}

Thanks.

Re: SSH port is still opened for network scanners. (ACL)

Alexandr_P — Mon, 02 Dec 2019 23:52:06 GMT

Hello!

It have to be more information - how do you map this ACL. (to port, to vlan, inbout or outbount, access-profile...)

If you need to restrict SSH access to network - you can add match line with port 22.

If you want to restrict access to switch you have to map with # configure ssh2 access-profile <name>.

Also you don’t need match condition source-address 0.0.0.0/0, you can make just:

entry DenyAll {
if match {
}
then {
deny;

it will mark like “all other traffic”

Thank you!

Re: SSH port is still opened for network scanners. (ACL)

Alex_Z — Tue, 03 Dec 2019 00:35:10 GMT

Thanks for the fast answer.

I have mapped this ACL to access-profile :

#
enable ssh2
configure ssh2 access-profile TRUSTED-NETWORKS

Dec 2 18:29:19 x.x.x.x exsshd: SSH connection from source 112.85.42.237 has been denied by access-list TRUSTED-NETWORKS. Rejecting connection.
Dec 2 18:30:29 x.x.x.x exsshd: SSH connection from source 112.85.42.237 has been denied by access-list TRUSTED-NETWORKS. Rejecting connection.

Re: SSH port is still opened for network scanners. (ACL)

Alexandr_P — Tue, 03 Dec 2019 16:02:21 GMT

Hi!

So this ACL is working normally.
Because it’s block SSH access to switch from untrusted IP’s.

If you want block all SSH traffic from untrusted IP’s you have to map this ACL not to access-profile but to inbound port or vlan. (In this case ACL will be checking packet for combinations IP/port and if it from untrusted IP with port 22 switch will block this packet).

Thank you!

Re: SSH port is still opened for network scanners. (ACL)

Alex_Z — Tue, 03 Dec 2019 18:22:14 GMT

Thanks, it works.
I have applied access-profile to VLAN.
As I understand, it is impossible to apply the access-profile to the L3 subinterface (SVI in Cisco terms) of VLAN. Only to the whole L2 VLAN. Correct ?
And I have forced to change POLICY_NAME file.
When the file has been mapped to the ssh2 access-profile I could use a multiply source-address in IF construction. For example :
if match any {
source-address 82.144.x.x/26 ;
source-address 77.120.x.x/26 ;
}
And It was Ok.
But when the file had been mapped to VLAN the error appeared:
Line 4 : Attribute source-address already exists as a match statement in Acl entry ...
And I needed to create a separate entry for each source-address.

Re: SSH port is still opened for network scanners. (ACL)

Alexandr_P — Tue, 03 Dec 2019 18:51:32 GMT

SVI - it’s simple VLAN. In case of EXOS - all configurations are vlan-based. So if you have VLAN with IP, then you can map your ACL to VLAN and it would be like ACL for L3 subinterface.

access-profile is for snmp, telnet, ssh2 - for manage access to switch. (for example #configure ssh2 access-profile TRUSTED-NETWORKS)

configure access-list - it’s packet inspection (for example #configure access-list [any | ports < portlist > | vlan < vlanname >] ) - it’s static ACL.

Also you can create dynamic ACL (for example #create access-list UNTRUSTED-NETWORKS «source-address 82.144.x.x/26 ;» «deny» → #conf access-list add UNTRUSTED-NETWORKS ports 11-21 ingress )

About “error appeared:” - https://gtacknowledge.extremenetworks.com/articles/Solution/Summit-reports-error-when-applying-ACL-to-VLAN/?q=Attribute+source-address+already+exists+as+a+match+statement&l=en_US&fs=Search&pn=1

Thank you!

Re: SSH port is still opened for network scanners. (ACL)

Alex_Z — Tue, 03 Dec 2019 19:14:25 GMT

SVI - it’s simple VLAN. In case of EXOS - all configurations are vlan-based. So if you have VLAN with IP, then you can map your ACL to VLAN and it would be like ACL for L3 subinterface.

Yeah, but unlike of Cisco, ACL is mapped to all ports which contain this VLAN. In my case, it isn't a problem, but in other ones, it may be some nuances.

Re: SSH port is still opened for network scanners. (ACL)

Alexandr_P — Tue, 03 Dec 2019 19:23:48 GMT

Could you tell task more detailed?

If we talking about mgmt access to switch - then by security principles you have to ban all IP’s except few trusted. And map it to vlan and/or ports. Here is no need for SVI-based ACL.

Thank you!

Re: SSH port is still opened for network scanners. (ACL)

Alex_Z — Thu, 05 Dec 2019 20:22:31 GMT

It is a little bit strange implementation.
To completely hide SSH service from untrusted hosts, it demands to apply an access-profile to SSH and also to apply ACL to VLAN. If we have one L3 interface it is Ok. But if your switch has two or more L3 interfaces with the white IP it becomes not convenient to apply ACL to each L3 VLAN interface.
It is only my opinion.

So, now the issue about applying ACL to VLAN.
When I applied ACL to VLAN it was normal about half an hour.
After that time the switch's IP became unreachable. And I lost SSH to it.
After turning off ACL and turning on the situation repeated.
What can be the cause of this behaviour?

Re: SSH port is still opened for network scanners. (ACL)

Alexandr_P — Thu, 05 Dec 2019 20:33:10 GMT

Hi!

Actually, I think both your questions have to be directed to GTAC.

First question (it’s just my guesses) - when we talking about management access (access-profile), it’s pointed to session (like flows) it’s mean that you block management session (it’s like in flow-based inspection few packets can be forwarded to destination).

When we talking about ACL-based packet processing it’s more to per packet inspection and switch inspect every packet and make decision on it (block or allow).

About second issue - you have to give more information. Is there some logs about this issue? IP became unreachable from where (it’s better to have scheme and configuration)?

Thank you!