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

sexigraf 0.99g : OS vulnerabilities detected in banner reporting (PCI-DSS check) / severity high / CVSS v2 7.5 #294

Closed
etrescol opened this issue Apr 12, 2022 · 7 comments

Comments

@etrescol
Copy link

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

@rschitz
Copy link
Member

rschitz commented Apr 12, 2022

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?

@etrescol
Copy link
Author

etrescol commented Apr 13, 2022 via email

@rschitz
Copy link
Member

rschitz commented Apr 13, 2022

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.

@rschitz
Copy link
Member

rschitz commented Jun 1, 2022

any news?

@etrescol
Copy link
Author

etrescol commented Jun 2, 2022 via email

@rschitz
Copy link
Member

rschitz commented Jun 2, 2022

ok cool, let me know how it goes

@etrescol
Copy link
Author

etrescol commented Jul 21, 2022 via email

@rschitz rschitz closed this as completed Jul 27, 2022
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