We use Nethserver 7.6 as our internet firewall/gateway. We process credit card payments through our internet connection(s), and as such we are subject to Payment Card Industry Data Security Standards (PCI DSS) which include external scanning of our red ports. PCI DSS requires PHP 7, not PHP 5 due to multiple found vulnerabilities and PHP 5.4 having reached end of support. I love this distro and the many features it uses like multiwan, Suricata and DPI that I could not easily implement myself, however, I need the most recent versions of PHP and Apache installed. When I manually install PHP 7.2, it breaks the web interface. I have not even attempted Apache yet. Are there plans to upgrade the distro to use the current secure versions of PHP and Apache, or should I abandon Nethserver?
I have been using Nethserver for 3+ years and do not want to go back to ClearOS or get locked into a vendor’s product sales/lifecycle.
Respectfully,
Paul
( on a completely different note, I have ssh access to the nethserver firewall, but the :980 port browser interface initially refused all connections, but after opening the port on the firewall (iptables -I INPUT 1 -i em1 -p tcp --dport 980 -j ACCEPT
) it no longer rejects, but just times out.)
However, CentOS still backports security fixes for all major packages, so security, as such, isn’t a reason to need to do this. I’m not aware of any good way to upgrade Apache, though it’s already running a fairly recent version.
Is there a website on the NethServer instance processing the card payments? Or is it just the gateway?
You would have to triple-check this, but the following should help with the PCI compliancy if you’re not running the latest version of PHP:
Have all of the latest updates and patches installed.
The website not to advertise the PHP version or the Apache version or any versions of stuff that you are running.
The fun part of any PCI audit is that they check to see if these software versions are easily obtainable and if they are what vulnerabilities there are for them. They kinda have a bit of a panic attack in that situation and they ignore any patching and mitigation that would be in place for known vulnerabilities.
It is just a gateway, the cc terms are on a seperate blue segment with a blanket block for all but the provider site, but the provider still scans any outward facing ports.
Speaking of panic attacks, it is hard not to panic when you think your firewall has the latest patches and updates and then get a detailed 400 page report showing the alleged vulnerabilities. I was not aware of the apache team backporting fixes until I got the responses to my post. I tested the php 7.2 update given earlier and it works great on my home box.
Unfortunately, I did panic a bit and did not follow the RH approved path to update the server so I get to go in Sat morning and rebuild it.
That’s the key word - alleged. If the scans cannot tell which versions of the software is being used, then they cannot tell if there are any vulnerabilities. Even if they do know, the scans do not also say if the mitigation or patches for those vulnerabilities are in place.
I would say the best move would be the following (and I am not totally a massive fan of security through obscurity):
Block any and all ports that are not required, even for the provider’s remote site. If the provider doesn’t require access to a port for the equipment to work, no point in having it open.
Prevent Apache and PHP from reporting at least their version numbers and, if possible that they are being used.
Have other safeguards, such as DPI or Fail2Ban or whatever else you deem sufficient, to protect your infrastructure in place.
That should solve a massive part of that list.
I know about quite a number of sites which are running PHP 5.4 or 5.6 which are PCI Compliant because they have sufficient things in place to satisfy the requirements.