SonicWall devices may see false positives for SSH Brute Force Logins With Default Credentials Reporting (oid 1.3.6.1.4.1.25623.1.0.103239) and others because of their response on SSH.
Instead of following standard SSH responses, sonic wall returns with their own messages first when trying to login. Therefore, the scanner thinks it was possible to login to SSH.
Okay, so in order to resolve this issue, this needs to be done in the Git repository? I’ll look if I can make a Pull Request, or does Greenbone has a resolution for this issue scheduled already?
Yes, any improvement would need to be done in the ssh_userauth() function of the scanner (as used in the ssh_login() function of ssh_func.inc) below as this is the one which is reporting the successful login to the VT in question even if it seems that the login wasn’t successful.
Currently i’m not aware of any schedule for this issue, thanks a lot for your interest / considering to provide a pull request.