[PCI Result] Vulnerable SSH versions
-
I did a vulnerability scan with Tenable and the version of Vulnerable SSH was detected. Look:
- OPIE w/ OpenSSH Account Enumeration
- OpenSSH < 7.6
- OpenSSH S/KEY Authentication Account Enumeration
- OpenSSH >= 2.3.0 AllowTcpForwarding Port Bouncing
Four SSH vulnerabilities were found, how can I justify or evidence for passing PCI?
-
Not sure why ssh would be open to pci path of data flow? Turn it OFF would be the simple solution ;)
Where does it say when doing PCI certification that you need to scan ssh on the firewall that is only available via management network?
If that was the case you should be scanning all your switches with ssh from say cisco, they sure and the F are not greater than 7.6 ;) for example..
The key to passing pci compliance is to scan what is required to be scanned - not every freaking device in your whole network ;)
-
FreeBSD patches relevant vulnerabilities without updating the visible version, especially if it's being probed remotely. If it's guessing purely on version number then it's almost certainly incorrect.
If you can cite specific CVE IDs it would make searching FreeBSD easier to find relevant fixes.
-
The problem with these scanning, in generating vulnerabilities based on banners. :(
Is it possible to remove the default Nginx page or change the HTML?
-
@fernando-domenike said in [PCI Result] Vulnerable SSH versions:
The problem with these scanning, in generating vulnerabilities based on banners. :(
Yes, which is horribly inaccurate. Though the alternative is actively attempting to exploit the problems for which it's scanning but that's much more disruptive.
Is it possible to remove the default Nginx page or change the HTML?
Where are you seeing that used? It's certainly not offered by the GUI web service by default. The default file is in
/usr/local/www/nginx-dist/index.htmlbut that directory is not served by the GUI web server.Maybe it's from an add-on package you're running, or maybe it's actually scanning something to which you are forwarding a port and not pfSense directly.
-
Are you doing the external scan or internal scan? The scope of what actually needs be scanned when your doing internal is open for interpretation for sure. But your ssh and or web gui should not be available on any network that would be involved in your pci process.
If so your doing basic security wrong - and should fail compliance just for that, be it the services have open vulnerabilities or not..
When you go for pci compliance - you don't have to scan your PC network, or your IOT network for example. So why are you scanning a management network that only can only be accessed via access controls in the first place..
And you only have to do an internal scan if your a provider, etc. When you do internal scan, only high or critical stuff has to be addressed. And since its an internal scan you can apply your own risk assessment and take into account restricted access, segregation of the network, likely hood of attack from the outside, etc. etc..
These sorts of services should not be available at all to any network that is dealing with the PCI equipment, and therefore scans of such services like the web gui to a switch or router or firewall that is only available via a restricted network, with other security controls to access no matter what the vulnerability of said service would be mitigated to a very low risk..
Which vendor are you having do that scan that is saying pfsense ssh service is a issue?
-
@johnpoz, I'm doing the External PCI Scan.
It is a banking startup.
We need the ASV Certificate to continue operating.I'm using Tenable.
Nginx was also identified because of the banner.
There is some planning for Netgate to mitigate "vulnerabilities". Example: change the SSH banner and the default error page?
We will disable SSH.
-
So this is an external scan - wtf do you have ssh or web gui open on your public IP for?
SSH nor the gui is open to the public internet out of the box.. You would of had to open those ports up on purpose - why would be the big question?
-
Not.
Is have segmented. ;)
-
If ssh is not open to your external scan, then it wouldn't shown up in their scans. If you forwarded stuff, those the destination device is what you have to fix, not pfsense.
-
The team create rules, to Tenable access and execute scanning.
But the "external Scan" follow architecture of banking.
Not is open for world, is segmented.The have fear the application PFSense not work e lost access to server.
-
@fernando-domenike said in [PCI Result] Vulnerable SSH versions:
The team create rules, to Tenable access and execute scanning.
Well that is failure right there - there is nothing in the in the PCI compliance testing that says a firewall has to be set to ANY ANY on its wan for a scan..
-
The team create rules, to Tenable access and execute scanning.
But the "external Scan" follow architecture of banking.
Not is open for world, is segmented.The Team have fear the application PFSense not work e lost access to server.
