Issue PCI Failure OpenSSH < 7.6

[Mark Patterson]

We are failing our PCI testing due to OpenSSH 7.4p1, which is the latest in yum.
PCI compliance requires a minimum of 7.6.
Please help.

 

[MarkM]

What Linux distro?

 

[Mark Patterson]

What Linux distro?

Linux version 3.10.0-327.36.3.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC)

 

[MarkM]

Well, first does it apply?

This only affects processors that support the BMI1, BMI2 and ADX extensions like
Intel Broadwell (5th generation) and later or AMD Ryzen.

If not, you can try explaining this to your PCI vendor.

Failing that, who utilizes ssh in your server? You may need to change SSH to a different port or implement port knocking till an update comes available. Alternatively, you could add a firewall rule to only allow certain IPs access to SSH.

 

[Mark Patterson]

Thanks, but no, that does not apply. My issues is described in CVE-2017-15906. IP blocking will not work for me because we have drivers on the road accessing over public networks.

 

[Mark Patterson]

I might add that the failure is not a result of penetration testing. The failure is generated by a simple check of the OpenSSH version number. Otherwise, the server passes all other PCI checks.

 

[MarkM]

Alright I was looking at a different CVE. I say port knocking may be your only option.

 

[Mark Patterson]

Why on earth would I ever want to implement port knocking to simply to pass a PCI test designed for my protection when all I have to do is implement a security update which is unavailable to plesk because the maintainers only support an outdated library?

 

[learning_curve]

@Mark Patterson We had this previously, but we have RedHat backported fixes and do also use IP Blocking for SSH.
We did find this related post elsewhere, which works. It is edited and our own current output is shown FYI:

"...Every PCI scanning company has different methods, but typically you can contest the result as a False Positive.
Provide them with your current OS version, SSH version and when it was installed. You can use:

rpm -qa --last|grep "name"

Where name is the name of the rpms for the service in which you are interested. In this case "openssh".
Send them this data. This is usually sufficient in most cases..."

# rpm -qa --last|grep "openssh"
openssh-clients-7.4p1-13.el7_4.x86_64         Sat 21 Oct 2017 04:29:59 BST
openssh-server-7.4p1-13.el7_4.x86_64          Sat 21 Oct 2017 04:29:47 BST
openssh-7.4p1-13.el7_4.x86_64                 Sat 21 Oct 2017 04:29:36 BST

October 2017 was the last, important RedHat backported bug fix, but there is a new advisory one, which is THIS one.
We assume this will be coming in a distro - yum update soon. Official PCI compliance verification is often inconsistent

 

[Mark Patterson]

Thank you everyone. This issue with trustwave has finally been resolved.

 

[Brujo]

Thank you everyone. This issue with trustwave has finally been resolved.

Would you be please so kindly and share with the community how you solved it? that others who use the Forum can Participate in the solution...

 

[Mark Patterson]

Certainly Brujo.

In sshd_config, I removed the line: Subsystem sftp /usr/libexec/openssh/sftp-server
and replaced it with: Subsystem sftp internal-sftp

Then I added the following rules to sshd_config, one for each user:
Match User username
ChrootDirectory /var/www/vhosts
AllowTCPForwarding no

I tried to be more specific with the ChrootDirectory, the server supports several domains, however that configuration did not work. So unfortunately, this method allows users to see all the directories in /vhosts. But, the user can only access that directory in which that user has permissions. So, internal security is maintained.

This solution is not ideal, but trustwave did approve my dispute allowing us to pass the PCI tests based on the actions listed above.