Stop scan at runtime based on failed authentication?


Certain scans, when we run them at our site, we expect to always use authentication and log in via ssh. We’ve got this working, but on a semi-regular basis, for one reason or another, we’ll trigger the scan against the wrong sort of machine, or perhaps one that’s being rebuilt, doesn’t have scanning keys set up yet, etc. causing authentication to fail. This produces what looks like a ‘clean’ scan, when in fact we’re just not seeing the non-updated software and so forth.

Of course you can detect this by looking at log-level plugin output, but I’d like to make it very obvious.

I’ve considered writing a simple VT to throw a max-priority vulnerability if ssh login fails; that I could do, but it doesn’t seem like exactly the right thing. Can a VT (also, or instead) call/return something to cancel/halt the entire scan? That seems like more of what I think I want - at that point it should be obvious the scan failed and we don’t have to worry about downstream automated systems getting confused by the results.

Is there a simple solution or best practice for this?


Such VTs for all currently possible credential types already exist for this purpose:"(SMB|SSH|ESXi|SNMP)+Login+(Successful|Failed)+For+Authenticated+Checks"

If you want to go this route you can set an override for those to a “high” level vulnerability.

Unfortunately VTs don’t have such capabilities to control the scan directly. While it could be possible to call external tools like e.g. gvm-tools / a GMP script via the NASL pread() function this looks quite fragile to me.

The only chance i’m seeing here is that you’re calling the following from your VT after the login has failed:

set_kb_item( name:"Host/dead", value:TRUE );

Once this is called the scanner will stop the scan against this single target (not the whole scan if multiple hosts are scanned).



The override is a much simpler idea, hadn’t thought of that but it’s probably what we’ll end up with.

I did give the “Host/dead” flag a try; it does appear to have stopped the scan (which saves a bit of time and resources, I guess), but it’s still producing a complete scan/valid report, so it doesn’t really address the main issue of vulnerabilities appearing to resolve on a host just because authentication started failing.