-
Notifications
You must be signed in to change notification settings - Fork 21
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
sexigraf 0.99g : OS vulnerabilities detected in banner reporting (PCI-DSS check) / severity high / CVSS v2 7.5 #294
Comments
Hi and thank you for your support. 0.99g and 0.99h base are totally different so you can't simply update it unfortunately. You have to migrate from one another. What data you don't want to loose exactly? |
Hello team,
Thank you for your feedback, but.
Just to refocus, we first want to correct the critical vulnerability detected on our nessus scan on sexigraf 0.99g (see explanation on issue #294 or below on reminder).
Reminder (on issue #294)
We get a PCI-DSS production environment and we run recurrent scan on all components which are inside the PCI-DSS perimeter. The main goal of these scans is to detect securities vulnerabilities on these components and correct them as soons as possible when the severity level is high or critical. On this PCI-DSS perimeter, we get a sexigraf appliance 0.99g and the last scan detects a vulnerability of level high on this component.
description : OS vulnerabilities detected in banner reporting (PCI-DSS check)
severity : high
CVSS v2 : 7.5
plugin (link to nessus information about this vulnerability) : http://www.nessus.org/plugins/index.php?view=single&id=108591
The plugin link proposes to update the component. Recently I saw a new version of sexigraf 0.99h so we can imagine updating it.
So, my first question is (see also on issue #294), is it mandatory to update (sorry migrate) our actual sexigraf 0.99g appliance to sexigraf 0.99h to correct the above vulnerability or do you get a workaround so that we can apply it on our actual sexigraf 0.99g appliance ?
If you say we need to migrate to sexigraf 0.99h to correct our vulnerability, to answer your question, we don't want to lose anything.
Thank you.
Emmanuel
|
This vulnerability is about the OS version it self (ubuntu 16.04) so you'd have to upgrade everything which will brake things because there is a lot of perl and graphite dependencies. So yes, in order to correct this vulnerability you have to migrate to the new appliance but don't worry, you'll only loose vsan latency history which is not that important since the point is to use it for troubleshooting not for history, that's why vsan data history is limited to 120 days anyway. |
any news? |
Hello,
We made the update of sexigraf with the 0.99h version. It remains to execute a nessus scan on this component to see if the vulnerability is fixed.
|
ok cool, let me know how it goes |
Hello,
We made the update of sexigraf with the 0.99h version. It remains to execute a nessus scan on this component to see if the vulnerability is fixed.
Emmanuel
|
Hello team,
We get a PCI-DSS production environment and we run recurrent scan on all components which are inside the PCI-DSS perimeter. The main goal of these scans is to detect securities vulnerabilities on these components and correct them as soons as possible when the severity level is high or critical. On this PCI-DSS perimeter, we get a sexigraf appliance 0.99g and the last scan detects a vulnerability of level high on this component.
description : OS vulnerabilities detected in banner reporting (PCI-DSS check)
severity : high
CVSS v2 : 7.5
plugin (link to nessus information about this vulnerability) : http://www.nessus.org/plugins/index.php?view=single&id=108591
The plugin link proposes to update the component. Recently I saw a new version of sexigraf 0.99h so we can imagine to update it.
But according to the last version of sexigraf 0.99h (https://www.sexigraf.fr/sexigraf-0-99h-highway-17-is-out/), vSAN performance metrics will be LOST during this migration and as our actual sexigraf 0.99g appliance is connected to a VMware environment and also VMware vSAN, we do not want lose data.
The question, is it mandatory to update our actual sexigraf 0.99g appliance to correct the above vulnerability or do you get a workaround so that we can apply it on our actual sexigraf 0.99g appliance ?
Thank you for your feedbacks.
Emmanuel
The text was updated successfully, but these errors were encountered: