-
-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Results reported against wrong host when using --targets and --level parameters #309
Comments
Thanks for reporting this. I can confirm that the tool isn't outputting the target host correctly when As for the discrepancies between 10.0.125.25 and 10.0.125.26, that could be caused by transient network issues, or simply the hosts being too slow to respond. If you re-run the scans with |
@sscotter : I committed d9c703c, which will now always print the target host when multiple hosts are scanned regardless of the level setting. So now you're no longer required to use And more good news!: I think I found the cause of the confusion in the output results not matching the hosts. It turns out the After committing e318787, enabling batch mode no longer automatically enables verbose mode, so you won't see those asynchronous "Running against: X" messages anymore unless you explicitly run with I think all of your reported issues are now fixed. If you have time, please test the |
It should be noted, this is being run under WSL.
I've currently trying to audit 105 hosts across ten internal network segments. I've created a txt file which contains all the IP addresses I wish to audit (
hosts-with-port-22-open.txt
) and I'm looking specifically for hosts which are offering weak algorithms.I'm executing the following command
I've specified the above parameters for the following reasons
-b
- Without this, I get the fail results, but no mention of which host they relate to.--timeout
was out of desperation, didn't seem to make any different either way--threads
was so that hosts were audited sequentially to make it easier for me to follow what's going on. I think the problem occurs regardless of setting this this 1 or leaving it as the default 32 as even when--threads
wasn't specified I was seeing conflicting results which didn't match when checking a host individually.--targets=
points to a file with 105 IPs in--level=fail
so that I only see the hosts I need to go remediate.Here's the truncated output of the first five hosts...
The above output indicates that 10.0.100.100, 10.0.125.25 and 10.0.125.82 have no fails, and 10.0.125.26 and 10.0.125.43 have fails.
I thought this was odd as 10.0.125.25 and 10.0.125.26 are identical devices with practically identical configuration.
So, I used ssh-audit again scanning the hosts individually and got the following output...
The above output indicates that 10.0.100.100 and 10.0.125.43 have no fails, and 10.0.125.25, 10.0.125.26 and 10.0.125.82 have fails.
I believe output for the individual scans to be accurate.
I appears to me that the output when executed using
--targets
is incorrectly offset and the output attributed to 10.0.125.26 should have been for 10.0.125.25, and the output attributed to 10.0.125.43 should have been for 10.0.125.26The text was updated successfully, but these errors were encountered: