Does anyone have experience of scanning Ubuntu (26.04 LTS) hosts with ufw enabled, but SSH permitted from anywhere on the default port?
With ufw disabled, the SSH authentication works fine and the scan completes being able to carry out the regular tests with SSH access. With ufw enabled, and only allowing SSH on 22/tcp from anywhere the SSH authentication fails, the scan takes a long time to complete, and when it does it’s not been able to complete the regular tests from within the machine with root access.
To be clear, the only change I am making between it working and not working is enabling and disabling the ufw.
$ ufw status Status: active To Action From -- ------ ---- 22/tcp ALLOW Anywhere 22/tcp (v6) ALLOW Anywhere (v6)
SSHing to the client machine from the scanning host as root, using the same public key, works fine from the command line both with ufw enabled and disabled.
Changing the key pair type from ed25519, created outside of Greenbone, to an RSA key pair generated by the Greenbone GUI made no difference. Still works with ufw disabled, doesn’t work with ufw enabled.
Unfortunately, it’s not entirely clear to me what is being scanned here or what scanning methodology is being used.
Are authenticated checks enabled? I would assume not.
What are the keepalive test settings and configured values?
Firewalls will always introduce some overhead and slow down vulnerability scans. If the scan is not authenticated, it is typically conducted over TCP, making the results and scan performance much more dependent on firewall behavior and filtering.
I would never run a firewall on a scanner, that will open a your installation to a lot of issues like full state tables of the netfilter and other side effects like connection tracking table is full.
Default scan settings, so OpenVAS Default scanner and Full and fast scan config. Authenticated checks are enabled. Targets were set with “Use Scan Config Default” for the Alive Test, although I’ve also tried “Consider Hosts as Alive”.
Regardless of the overheads introduced, I would still expect the scanner to be able to do the basics and SSH to the target server, no?
In any case, it’s worth checking the SSH authentication logs on the target system being scanned. Also, make sure the logging level is set appropriately, as insufficient log verbosity can make troubleshooting difficult. A packet capture with tcpdump will quickly show whether the connection attempts are actually reaching the server. That said, these are fairly basic troubleshooting steps and a good place to start.