Skip to content
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

reason of rating #3

Closed
MAngel666 opened this issue Apr 14, 2022 · 2 comments
Closed

reason of rating #3

MAngel666 opened this issue Apr 14, 2022 · 2 comments

Comments

@MAngel666
Copy link

MAngel666 commented Apr 14, 2022

it would be nice to know, what was the reason for a score. I mean, if I use --warn B --crit C and the check is "CRITICAL" or "WARNING" then it would be nice to know what is the reason not beeing A. It is possible to get such information with the API of Qualys?
(it is more feature request than issue)

@philfry
Copy link
Owner

philfry commented Apr 14, 2022

Even though having this kind of information shown in nagios/icinga/… could be useful, I'd say "no" due to several reasons:

  • the perfdata/status length in nagios/icinga/nrpe and others is limited. I don't know what exact length is allowed, but I played around with "more verbose" checks and perfdata a while ago and ran into that limit (fwiw, nrpe has or had a limit or 1kb). If this changed in the meantime, fine. Then this argument would be invalid.
  • not getting an A-grade can have several reasons. I believe it's not wise to have – in worst case – dozens of informations in a tiny result field, instead of just looking at the ssltest webpage to see what's wrong.
  • the information is simply not (fully) provided by the api. Even though there are some hints like "vulnBeast": true, the list is incomplete and needs interpretation (i.e. accepting which ciphers would lead to downgrade etc.), which would be overkill for this (simple) check scripts.
  • the required information is not provided at all when checking cached results.

@philfry philfry closed this as completed Apr 16, 2022
@MAngel666
Copy link
Author

the status field in icinga2 seems to be much bigger than in icinga/nagios etc... It would be still nice to have some more information there. It could be an "verbose" version of the status... A lot of checks has a verbose version of the output :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants