Scan sg350-28 with Nessus Credentialed checks

Question

We recently bought the sg350-28 28 port Gigabit Managed Switch

I need be able to run Credentialed nessus scans on these devices

SSH is enabled

I can SSH from putty

I can SSH from the sever where nessus is installed

I can also SSH into the devices from other devices such as routers.

I have checked and nessus will do a Credentialed scan against other ssh devices, (RHEL 7)

Any idea why this is not working?

The user I am using is setup as level 15

username aftest

password Test1234 (really simple)

I created a user that can only log in via key, same thing.

I have followed the Nessus article

https://community.tenable.com/s/article/Authentication-Requirements-for-Credentialed-Cisco-Scans

Another thing I have noticed is that it looks like Nessus is not trying to ssh into the switch

On the left is the output of the logs from the switch, when I ssh in from the server running nessus I can see that ssh connections was accepted

However, when I started the scan, no logs at all. No login attempts

Not sure if any other logs might be helpful

Wireshark info, not sure what is important, however looking at the scan I can see that Nessus is trying to do something on port 22

Red bar output

Black bar output

nessussg350.pcapng

https://file.io/sQrmRAj7Psrj

104410 None 172.16.1.14 tcp 22 Target Credential Status by Authentication Protocol - Failure for Provided Credentials "Nessus was unable to log into the detected authentication protocol, using the provided credentials, in order to perform credentialed checks." "Nessus failed to successfully authenticate directly to the remote target on an available authentication protocol. Nessus was able to connect to the remote port and identify that the service running on the port supports an authentication protocol, but Nessus failed to authenticate to the remote service using the provided credentials.

There may have been a failure in protocol negotiation or communication that prevented authentication from being attempted or all of the provided credentials for the authentication protocol may have been invalid. A protocol failure may indicate a compatibility issue with the protocol configuration. A protocol failure due to an environmental issue such as resource or congestion issues may also prevent valid credentials from being identified. See plugin output for error details.

Please note the following :

• This plugin reports per protocol, so it is possible for valid credentials to be provided for one protocol and not another. For example, authentication may succeed via SSH but fail via SMB, while no credentials were provided for an available SNMP service.

• Providing valid credentials for all available authentication protocols may improve scan coverage, but the value of successful authentication for a given protocol may vary from target to target depending upon what data (if any) is gathered from the target via that protocol. For example, successful authentication via SSH is more valuable for Linux targets than for Windows targets, and likewise successful authentication via SMB is more valuable for Windows targets than for Linux targets." "Address the reported problem(s) so that credentialed checks can be executed." " Nessus was unable to log into the following host for which credentials have been provided :

  Protocol : SSH Port : 22 Failure details :

  • User : aftest

    • Plugin : netstat_portscan.nasl Plugin ID : 14272 Plugin Name : Netstat Portscanner (SSH) Message : ssh_recv failed in ssh_kex2.

    • Plugin : ssh_get_info.nasl Plugin ID : 12634 Plugin Name : Authenticated Check : OS Name and Installed Package Enumeration Message : ssh_recv failed in ssh_kex2. "

Answer 1

I've used a !arp && !dhcp && !stp && !cdp && !ssdp && !lldp display filter - I prefer filtering away what I don't want instead of just displaying what I want (tcp.port == 22) which could hide unexpected data.

• frame #57 contains the start of a TCP connection from 192.168.1.10 (assumed Nessus server) to 192.168.1.254 (assumed SG350)
• #60 is the beginning SSH handshake (server/switch response SSH-2.0-OpenSSH_7.3p1.RL) )
• #62 is the client/Nessus response SSH-2.0-OpenSSH_5.0
• the switch is slow with its ACK (#62 is retransmitted in #63)
• eventually ACKs in #64
• and then kills the connection in #102 (possible timeout)

That pattern repeats several times.

In a normal SSH connection, the client would initate the key exchange after #64. I'd say the Nessus software is at fault for failing to do that in time. It may be due to the switch generally missing the first ACK but that mustn't be a problem for a client.