I got four (why four?) emails from the bank's new partner. Two of them informed me that I'd be needing a new monthly scan in about a month's time (duh, it's monthly, that's what monthly means) and the other two reminded me that I have to "Maintain Scan Compliance" in two months time.
Sigh.
"Maintain Scan Compliance" means that I have to check that I'm doing all the things that a good secure system ought to do, such as maintain a list of all the people authorised to have passwords to the secure systems. My list is one. Me. And most of the other requirements are like that, so pretty easy for me to meet. I even have a written authorisation, written by me, that allows me to access ... you see how it goes. Most of what they're doing is entirely valid and sensible for multi-people organisations, and I don't think they've really been expecting a one-man-band.
Oh, and by the way, last time I looked, about 80% of organisations aren't compliant. I am, of course, because there's a certain amount of pleasure in keeping one step ahead of them.
The really useful part, is the monthly test. People are discovering new vulnerabilites all the time, and these days, they don't just number them like "CVE-2015-0291", they give them sexy names like CRIME, BEAST and POODLE. These vulnerabilites are reported to the people who make the software that we all use, they bring out a new version that fixes that vulnerability, the PCI DSS start testing for it, and we all have to upgrade our software, which is, of course, a bit of a PITA.
So in the latest test, I had three things reported. The first is that TCP timestamps are enabled (which has been true for donkey's years). That's only a "potential" problem, not an actual one, and it doesn't affect PCI DSS compliance. It means that an attacker can work out how long it is since you last rebooted, which means that if there's a fix that required a reboot, they can know if you've failed to apply that fix. The thing here, though, is that I'm running Linux, and I have never seen a problem that required a reboot. It's always a matter of upgrading the web server and restarting that, I've never had to reboot the system. So the TCP timestamps tell a potential attacker nothing useful.
But, to stop it complaining about this "potential", problem, here's what you do. To disable it now (no reboot needed), do:
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
To disable it at each reboot, edit /etc/sysctl.conf and add:
net.ipv4.tcp_timestamps = 0
So, now onto the meat of the matter. The first thing the scan complained about was that I'm using RC4, an old crypto system. But I'm only using RC4 in order to mitigate against BEAST, because that's what was recommended when BEAST was discovered. But now RC4 has been found to be vulnerable.
So now, if you're running Apache, and I'm assuming that you're running OpenSSL 1.0.2a (the latest, which I had to upgrade to in order to mitigate some previous issue, I don't remember the details) then your Apache configuration file should include:
SSLProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
So now you know.,
And the third thing it didn't like, was that I was using Apache 2.4.10, so I've upgraded to 2.4.12. What it didn't like about 2.4.10, is that there are vulnerabilities in some modules. I don't use those modules. But it doesn't know that, and it's easier for me to just upgrade, than to try to convince them that the vulnerability doesn't affect me. Upgrading was easy, I just downloaded the source code from Apache, configured and compiled it using OpenSSL 1.0.2a and restarted my web server. Actually, it wasn't quite that simple; I had to mess about a bit before I had the configuration files for Apache correct, because I can't use the files as in the distribution, I have to change things to reflect the name of my server and suchlike stuff.
I tested it with Qualsys who let you test your secure server free of charge and tell you about any problems, and it passed. So now I've resubmitted it to the PCI DSS test, and I'm waiting for the results, which might take a day or two. I've also asked Trustwave for a scan, that usually happens within an hour or so.
Update:
The Trustwave scan reported two problems. One was "No X-FRAME-OPTIONS header"; this is something to do with cross-scripting. So I've told Apache not to allow this, by appending this to my httpd.conf file.
Header always append X-Frame-Options SAMEORIGIN
The other issue, is that it objects to TLSv1.0 being supported (which was necessary to mitigate against POODLE (or was it BEAST?). So I've told Apache not to allow that, with the line in the httpd-ssl.conf file:
SSLProtocol all -SSLv2 -SSLv3 -TLSv1
Now to retest ...
Update ...
Looking good. I changed the header thing to DENY (because I don't use frames at all, so I don't need to allow them even for my servers), and now I can pass PCI DSS. But because of the protocols I've killed, my local check-the-servers thing can't access it. This means that if the secure server stops working, my server-checker won't know. But I can see a way around that; instead of redirecting all the http requests to https, I'll redirect all except the one that checks that the server is alive.
Update ...
That worked. In httpd-vhosts.conf
<VirtualHost *:80>
ServerName secure.example.com
Header set X-Frame-Options DENY
RewriteEngine On
RewriteCond %{REQUEST_URI} !report.txt
RewriteRule ^/(.*)$ https://secure.example.com/$1 [NC,R=301,L]
</VirtualHost>
No comments:
Post a Comment