PCI Compliance fun
-
I set up PFSense 1.2.3 on an Alix board for a customer a few years ago, I don't support them for their IT needs, I just installed it as part of a VoIP system. Since then, they've started PCI Compliance testing with "Security Metrics". They failed the remote probe tests, as I had port 22 and port 80 forwarded for the phone system. They asked me to close those ports, so I did, leaving everything closed except port 443 for remote firewall administration. They ran the test again, and still failed with the following results:
Protocol Port Program Risk Summary
TCP 22 ssh 10
Description: OpenSSH 4.3 is vulnerable adsl-xxx-xxx-xxx-xxx.dsl.sndg02.sbcglobal.ne txxx-xxx-xxx-xxxJun
10 07:15:20 2011newSeverity: Critical Problem CVE: CVE-2006-4924 CVE-2006-4925 CVE-2006-5051
CVE-2006-5052[More]
TCP 80 http 10
Description: vulnerable Apache version: 2.2.3 adsl-xxx-xxx-xxx-xxx.dsl.sndg02.sbcglobal.ne
txxx-xxx-xxx-xxxJun 10 07:15:20 2011newSeverity: Area of Concern CVE: CVE-2006-4110 CVE-2006-
5752 CVE-2007-1863[More]
TCP 443 https 7
Description: vulnerable Lighttpd version: 1.4.23 adsl-xxx-xxx-xxx-xxx.dsl.sndg02.sbcglobal.ne
txxx-xxx-xxx-xxxJun 10 07:15:20 2011newSeverity: Critical Problem CVE: CVE-2010-0295
5.01798new11Impact: There[More]
TCP 80 http 5
Synopsis : The remote web server might transmit credentials in cleartext. Description : The remote
web server contains several HTML form fields containing an input of type 'password' which[More]
TCP 80 http 5
Synopsis : The configuration of PHP on the remote host allows disclosure of sensitive information.
Description : The PHP install on the remote server is configured in a way that allows disclosure[More]
TCP 80 http 5
Description: Web server allows cross-site tracing adsl-xxx-xxx-xxx-xxx.dsl.sndg02.sbcglobal.ne
txxx-xxx-xxx-xxxJun 10 07:15:20 2011newSeverity: Area of Concern 2.648new11Impact: A malicious
web site could[More]
TCP 443 https 4
Synopsis : The remote service supports the use of medium strength SSL ciphers. Description : The
remote host supports the use of SSL ciphers that offer medium strength encryption, which we
currently[More]I used their PFSense VPN as a proxy to run the "Shields-Up" test and it reported back that all but 443 are indeed closed.
I'm not super concerned about this, as like I said, I'm not their IT support, I'm just curious if anyone has seen this before. Should PFSense pass PCI compliance testing if all ports are closed?
-
If you have nothing open on WAN, yes you'll pass a PCI scan no problem. The scanning vendor you mentioned is actually a customer of ours, they use pfSense on their network and customer networks. You have something open on WAN with those results, though it may be before it gets to your firewall (DSL modems at times can listen on your public IP, but there shouldn't be a discrepancy between ShieldsUp and their results in that scenario) or could be on a different IP possibly. Whatever you're seeing there isn't services listening on the firewall itself, could be port forwards.
-
Nope, no port forwards at all. The only port forward is to "WAN Address" for port 443. There must be more to the story then I've been made aware of. I've done all I can do remotely for them, I told them via email that I'd be happy to help if they can't figure it out. I just wanted to make sure there wasn't something obvious I might be missing. I'll post here if I learn anything interesting, but I think it may be a case of user error lol.
-
Also I wouldn't leave the web interface open to WAN, not sure if that alone would fail them but it's not secure. At a minimum, restrict it to specific remote IPs, or better log in via VPN first.
-
I'm not sure what happened on that test I copied pasted above. I emailed back to the client and told them that they could hire me if they wanted to get to the bottom of this, they agreed and gave me the login to their security metrics account. Without changing a thing on the pfSense, I ran the test again, it took about 4 hours, and came back with SSL as the only vulnerability. Still to severe to win verification, but better. So I'm not sure why it came back with SSH and HTTP vulerabilities last time…maybe they ran the test again right after I closed the ports and a few states were still left open from the previous test?
Well, anyway, I took CMB's advice and locked down port 443 to my block of IP's, which is a bit of a PITA as I spend half the day at other customer's sites, and if I have to get into their system, it now means either VPN into their network, or proxy though mine to get in. Oh well, I guess that's the price we pay. I guess I could have been slick and just locked down security metric's block of IP's evil laugh but I'll play nice.
The two deal breakers for HTTPS are:
*****Description: vulnerable Lighttpd version: 1.4.23 adsl-xxx-xxx-xxx-xxx.dsl.sndg02.sbcglobal.ne txxx-xxx-xxx-xxxJul 07 18:10:58 2011newSeverity: Critical Problem CVE: CVE-2010-0295 5.01798new11Impact: There are denial of service and file read and security bypass vulnerabilities. Background: Lighttpd Web Server is Open Source small footprint web server. Resolution [http://www.lighttpd.net/download/] Upgrade Lighttpd to 1.4.26 or higher, or upgrade as designated by Linux vendors. Vulnerability Details: Service: https Received: Server: lighttpd/1.4.23
Just out of curiosity, is Lighttpd upgraded to the secure release in pfSense 2.0?
*****Synopsis : The remote service supports the use of medium strength SSL ciphers. Description : The remote host supports the use of SSL ciphers that offer medium strength encryption, which we currently regard as those with key lengths at least 56 bits and less than 112 bits. Note: This is considerably easier to exploit if the attacker is on the same physical network. Solution: Reconfigure the affected application if possible to avoid use of medium strength ciphers. Risk Factor: Medium / CVSS Base Score : 4.3 (CVSS2#AV:N/AC:M/Au:N/C:P/I:N/A:N)
I'm fine with pfSense regardless, just passing the info on.
-M@
-
The issue with lighttpd is only DoS of the web interface itself and since that should never be open to the Internet and can't really do any harm we didn't release an update for that. 2.0 has the latest, and disables the ciphers it's noting.