PCI compliance when update not available

Support for security such as Firewalls and securing linux
Post Reply
the_latebloomer
Posts: 2
Joined: 2018/01/15 16:28:23

PCI compliance when update not available

Post by the_latebloomer » 2018/01/15 16:42:31

Hi All,

I am trying to pass PCI compliance and one of the vulnerabilities we have to resolve is https://access.redhat.com/security/cve/cve-2017-3736. However, there is now RPM update available that address the CVE. Any recommendation on how I can go about resolving this. Thanks in advance.

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: PCI compliance when update not available

Post by TrevorH » 2018/01/15 16:56:09

Does your system match the criteria for allowing the bug to be present?
This only affects processors that support the BMI1, BMI2 and ADX extensions like
Intel Broadwell (5th generation) and later or AMD Ryzen.
The rest of the description makes it sound unlikely to be easily exploited:
Analysis suggests that attacks against RSA and DSA
as a result of this defect would be very difficult to perform and are not
believed likely. Attacks against DH are considered just feasible (although very
difficult) because most of the work necessary to deduce information
about a private key may be performed offline. The amount of resources
required for such an attack would be very significant and likely only
accessible to a limited number of attackers. An attacker would
additionally need online access to an unpatched system using the target
private key in a scenario with persistent DH parameters and a private
key that is shared between multiple clients.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

the_latebloomer
Posts: 2
Joined: 2018/01/15 16:28:23

Re: PCI compliance when update not available

Post by the_latebloomer » 2018/01/17 12:34:15

TrevorH thanks. Based on your response it looks like we should be fine. I guess we'll have to explain this to the company running the PCI scan. Thanks for your response.

JeffMings
Posts: 19
Joined: 2014/01/05 02:23:14

Re: PCI compliance when update not available

Post by JeffMings » 2018/01/19 19:42:15

PCI compliance will be affecting a LOT of Linux server operators.

I have the same problem. OpenSSH 7.4p1 is the latest available from the Centos repo, and there doesn't seem to be a newer version available from any of the "official" repos, including EPEL.

OpenSSH 7.6 is the version I need to avoid the PCI scan whining and moaning. I have filed a request for dismissing the OpenSSH 7.4p1 problem, because the associated exploit doesn't allow for control or compromise of the server:
https://www.cvedetails.com/cve/CVE-2017-15906/
However, this is not a tenable solution. I will have to receive compliance for about 9 other Centos 7 servers.

What is the safest way to "manually" upgrade a Centos 7 server to the latest version of OpenSSH? Repackage a Fedora RPM? (I would rather not re-package) Is there a lesser-known, but trustworthy, repo with the very latest OpenSSH packages? I use SSH _ALL_ of the time for server management, and it has to be absolutely reliable.

Thanks,
-Jeff

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: PCI compliance when update not available

Post by TrevorH » 2018/01/19 22:19:23

What is the safest way to "manually" upgrade a Centos 7 server to the latest version of OpenSSH? Repackage a Fedora RPM? (I would rather not re-package) Is there a lesser-known, but trustworthy, repo with the very latest OpenSSH packages? I use SSH _ALL_ of the time for server management, and it has to be absolutely reliable.
There is no safe way to do this without making yourself entirely responsible for security on the server thus defeating the point of using a distro in the first place. If you're going to go that way you might as well be using LFS.

This bug is trivial. It's a low severity CVE that, at the absolute worst, can result in a denial of service attack on your ssh server. It's only applicable to sftp sessions. See https://bugzilla.redhat.com/show_bug.cgi?id=1506630 - most specifically the statement from a RH employee in comment #2.

If you need it fixed then buy RHEL and raise a support request and bug RH to fix it.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

JeffMings
Posts: 19
Joined: 2014/01/05 02:23:14

Re: PCI compliance when update not available

Post by JeffMings » 2018/01/20 00:27:37

Thanks for the reply, Trevor.

I agree that the bug is not significant enough to raise alarm. However, the PCI compliance contractor working for our payment processor might not agree, and I don't know how long an answer will take, or if I'll receive a rational one - it's basically a policy matter on their end at this point. So, as a long-time Linux nerd, having learned a long time ago that it is always better to engineer a solution than work through politics, I am considering my options.

My favorite "extra" repos of choice, EPEL and RPMFusion, don't have anything for newer OpenSSH. So, I have a brand new Centos 7 box. I will see if the Fedora RPM will work on it shortly. I can't afford to leave my client without PCI compliance and face fines.

Sincerely,
-Jeff

Edit - checked the Fedora RPM from 27. It is only 7.5, not 7.6. And, I will have to replace/upgrade far too many items to make it work. Recompiling from source or repackaging the RPM will be vastly simpler. I will wait to hear from the compliance group.

User avatar
avij
Retired Moderator
Posts: 3046
Joined: 2010/12/01 19:25:52
Location: Helsinki, Finland
Contact:

Re: PCI compliance when update not available

Post by avij » 2018/01/20 01:46:40

Would it be a terribly bad idea to simply set up the firewall so that it allows incoming ssh only from some specific trusted IP addresses?

I would also recommend the "wait and see" approach, because this flaw will eventually be fixed by RH. If I really had to do something, I would get the latest CentOS 7 openssh source rpm, modify the spec to incorporate the patch and change openssh_rel to 13.0.1 and then recompile. That way your openssh would get updated to the CentOS packages when the next openssh (openssh_rel >13) gets released. Doing it this way would be much safer than using Fedora's packages or compiling from source.

Also, test the new packages on a scratch system before pushing those to production machines.

JeffMings
Posts: 19
Joined: 2014/01/05 02:23:14

Re: PCI compliance when update not available

Post by JeffMings » 2018/02/07 22:33:07

FYI, I finally solved this by implementing port knocking. It's been around a long time, and it works fairly well, but it requires packages that are not present in the main or EPEL repos:
https://li.nux.ro/repos.html

Here are my personal notes for implementation - I hope they save someone else some time:

Info for Centos 7 from good article:
https://howtodoit.eu/protect-ssh-firewa ... os7-linux/

Will need to install EPEL repo first. Then, can grab repofrom Nux Linux:
https://li.nux.ro/repos.html
Then, can install knock-server.
Better stop command to use (I set SSH to run on a non-standard port of, for example, 222 and created a firewalld service to match):
firewall-cmd --zone=public --remove-service=SSH-222 (when this is done, you will keep the SSH connection in use, but others will not be opened)
Return it with:
firewall-cmd --zone=public --add-service=SSH-222

Use to ascertain listening NIC and matching command:
firewall-cmd --get-active-zones
Receive:
public << zone to use
interfaces: p4p1 <<Interface to listen on
trusted
interfaces: blahblah

Then, check name of service:
firewall-cmd --zone=public --list-all
Receive:
public (active)
target: default
icmp-block-inversion: no
interfaces: p4p1
sources:
services: SSH-222 << service to stop/start
ports:
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:

This worked:
/etc/knockd.conf
[options]
logfile = /var/log/knockd.log
interface = p4p1

[opencloseSSH]
sequence = 55555:udp,22222:tcp,44444:udp
seq_timeout = 3
start_command = firewall-cmd --zone=public --add-service=SSH-222
cmd_timeout = 30
stop_command = firewall-cmd --zone=public --remove-service=SSH-222

You will probably have to put initial remove command in rc.local and set chmod 0755 /etc/rc.d/rc.local
I.e., add firewall-cmd --zone=public --remove-service=SSH-222 to the end of rc.local to start the ssh service in "hidden" mode after rebooting.
Remember- systemctl enable knockd
On Ubuntu, install knockd to get knock command.


I have changed some numbers from what I've actually used on my servers, of course.

You will be able to run the knocking by the knock client. If needed, you can do it with nc.

So, you will run something like:
knock Myhost.system.com 55555:udp 22222:tcp 44444:udp
ssh -p 222 SuperSecret@Myhost.system.com

Good luck!

Post Reply