PCI.....again

[HCHTech]

I hate this topic, I have spent I don't know how many hours fighting with my own shop's setup, as well as various clients' setups. But I digress....

So, this new client is using Trustwave for their PCI scans. They do NOT have a domain, there are 5 computers in a workgroup. They have a single internet-connected cc terminal. I have it on it's own VLAN. They do have a static IP.

They have a Sonicwall TZ300 which has the latest firmware. They were getting failed scans originally because a third-party SSL cert couldn't be detected. Makes sense - there was only the built-in self-signed certificates on the Sonicwall. Also, when I open the management interface over the web, I get the standard warning from Chrome - "This site is not secure."

So:

• I created a new A record in their DNS: sonicwall.companyname.com pointing to their static IP
• I purchased an SSL cert from their webhost, namecheap.com (ugh). The CSR used sonicwall.companyname.com as the common name, and I entered their static IP as an alternative subject name (not sure if this helps, hinders, or is irrelevant). The server platform chosen was Apache (clearly required per several Sonicwall kb articles).
• The zip file received from namecheap contained a .crt file, a .p7b file and a "bundle" file. I chose to import the .crt version (not sure if this was a mistake)
• I then bound the certificate to the management interface, saved the configuration file and rebooted the device

Now, when I open the management interface over the web (which I can do successfully using the sonicwall.companyname.com URL), I no longer get the "This site is not secure" warning from Chrome. Yea! It works! I would think, anyway.

Unfortunately, a new PCI scan is still failing because "12.345.678.90 SSL Certificate is Not Trusted (external scan)" and "12.345.678.90 SSL Certificate is Self-Signed". Obviously the IP address I've shown isn't the real one, but the address in the actual failure message is correct, and does match the IP I put in for the alternate subject name in the CSR.

BTW, the certificate I purchased from namecheap wasn't their cheapest one, but the next one up - I think it was $18/yr - still dirt cheap compared to what I have seen in the past from other vendors.

Also, namecheap uses Comodo as their CA, and I DO see the Comodo intermediate certificate in the Sonicwall as well as the one I imported.

Normally, I've seen these scans fail for other reasons (usually the firewall doing it's job by blocking what it sees as unwanted traffic), but this one is clearly getting in, it's just not detecting the certificate.

Anyone see what I might have done wrong?

 

[HCHTech]

$&%#@. This might have been a false alarm. I forgot we had SSL-VPN enabled, and didn't bind the certificate there. So I just did that, which requires a reboot, which can't be done until after-hours, and then we'll queue another scan tomorrow, which takes a day, and then see if that was the problem. I mentioned I hated PCI, right?

 

[tek9]

I don't do Sonicwalls, but on the Untangle boxes I've deployed I had to disable WAN access to the admin side of the router to get the PCI scan to pass. Now whenever I have to do anything on the router I login to it via OpenVPN and do it locally. Bit of a pain but easy and cheap.

 

[YeOldeStonecat]

$&%#@. This might have been a false alarm. I forgot we had SSL-VPN enabled, and didn't bind the certificate there. So I just did that, which requires a reboot, which can't be done until after-hours, and then we'll queue another scan tomorrow, which takes a day, and then see if that was the problem. I mentioned I hated PCI, right?

Yeah...we gotta unload that on Untangle (or turn it off).

Alsy, Tek9, do you lock the custom port WAN access down to only allow traffic from your offices IP? Should get you past the sniff instead of having it seen as wide open to the world (plus it's just good practice anyways).

Also, for a lot of firewalls that have been in service for a while..and upgraded...often the self signed cert remains the original and will fail due to being an old standard, so run a new self signed cert generation to get a more current standard one.

 

[tek9]

Alsy, Tek9, do you lock the custom port WAN access down to only allow traffic from your offices IP? Should get you past the sniff instead of having it seen as wide open to the world (plus it's just good practice anyways).

My office is currently not on a static IP, so I can't use that. I just change the port number to a custom one and lock it down totally from the WAN side. I login to the router either by first doing a VPN or by using the Untangle Command Center or whatever they call it.

 

[fencepost]

@tek9 I'm sure that there's a way to do port knocking on Untangle boxes, so consider doing that. You can set up a protected page on your website with one-click buttons to "unlock" access from your current location to any of your clients for an hour or two, using either a standard knock pattern or something customized for each client. I tend to use the client's phone number and street address with each "knock" happening within 5 seconds of the previous one. If all of those numbers are in increasing order I'll also swap things around a bit so there's some level of up/down/up and a basic port scan wouldn't trigger it; I should add some detection on in-between ranges to catch port scans but haven't done so yet.

 

[HCHTech]

Just a follow-on question to this issue. In my own shop, I have a block of 5 static IPs. I have one dedicated to the VLAN for the credit card terminal, a second one is our main WAN connection, and 3 are lying fallow. I have a subdomain A record (something.mycompany.com) pointing to the IP of the main WAN connection. If I want one cert to cover BOTH IPs in use (or all of the statics for that matter should I ever use more of them), I will need a wildcard SSL cert to cover *.mycompany.com, is that right? Then, I would create additional A records for each IP in use for whatever purpose....something2.mycompany.com, something3.mycompany.com, something4.mycompany.com, etc. Do I have that right?

 

[YeOldeStonecat]

As asterisk instead of a sub domain (the wildcard approach), any/all IPs you tie to that domain will fly.

 

[HCHTech]

Thank you. Haven't had to do that before, so I wanted to buy the right cert the first time - haha.

I'm still wondering how exactly the cert thing works with PCI scans. You don't give the PCI Scanning folks the domain or subdomain name, you only give them the IP to scan. But you can't get a certificate for an IP, only a FQDN. So....wouldn't the cert produce a name mismatch no matter what? I did put the IP on the subject alternative name field in the CSR, but that didn't seem to help. When I import the cert in the Sonicwall and check the cert properties, it still shows the sub-domain name in the subject alternative name field. If I connect to the Sonicwall over the web and examine the cert from the browser, same thing.

Plus, I don't know how it works on other firewalls, but on a Sonicwall, you can only bind the certificate to the management port (which is only 1 IP address) and to the SSLVPN connection (which uses that same IP). There is no way to bind it to the 2nd WAN port or one of the other static IPs. So, on some of my setups where I have the credit card terminal traffic coming in and leaving on a different static IP from the main WAN, it's no wonder they can't detect the cert, and I fail because of that! So my other choice is to assign the management port to the same static IP that is being used for cc terminal traffic, then they can see the cert, but I fail because I have a port open for web management. I'm not sure I see a way to win this game.

 

[nextechinc]

Not that I would ever do such a thing, but usually the PCI scans will tell you what IP they’re going to be testing from. Again, not that I would ever do such a thing, but if you block all the traffic from that IP you would, theoretically, pass the scan with flying colors.

 

[HCHTech]

but if you block all the traffic from that IP you would, theoretically, pass the scan with flying colors.

No, that wouldn't work. The scan would fail, and you would then have to [digitally] sign a statement saying you weren't blocking them on purpose. As long as you sign that, you would get a passing result....for that quarter. This is essentially what I'm doing for my own shop since I gave up trying to get a scan to pass after much research and about 40 test scans over a period of about a year. The scan has to get in and detect the IP terminal but find no other vulnerabilities to pass.

For this current client, the scan gets in, detects the terminal, but because it cannot detect the SSL cert, it fails. The problem is obviously that the cert isn't correctly loaded somehow. There is a block of 5 static IPs and with the Sonicwall, once you load the cert, your only choice is to bind it to the management IP (which uses a different static IP than the IP terminal) and/or to the SSLVPN port (which uses the same IP as the management interface). Having the IP terminal use a different IP and subnet is how I am segregating the CC traffic from the rest of the internet traffic, so I'm not keen to change that.

 

[nextechinc]

If that's the case, then, only allow the traffic required to see their terminal. I find it odd that they would want to see their terminal from the outside. Seems like a giant security hole to me.

 

[HCHTech]

It's not that simple - it's never that simple. PCI compliance makes no sense, you would think having a secure connection would be all that is necessary - it isn't. You have to lower security to allow the scans to see if you are secure - it's madness. Then, just to make it better, you can't ask them what the problems are, or how to pass the scan. You get their results and that's it - pass or fail, here's why - you're on your own to fix it.

 

[HCHTech]

An update to this thread. I opened a ticket with Trustwave about this problem back in July and I received the final resolution after two escallations. I spoke today with one of the folks who apparently is in charge of the scanning at Trustwave.

I suspect they were crafting their response so that I wouldn't have any way to dispute them, then I would give up my fight to receive a passing scan (and they could close the ticket). The basic problem is that a third-party SSL cert is required, but there is no way to validate that certificate. Because you cannot purchase an SSL cert for an IP address, AND you cannot request a scan to a FQDN, the scan will always produce a name mismatch and therefore not trust the cert = failed scan.

Trustwave's statement, when presented with this impasse is that *NO* IP-connected terminal installation can receive a passing scan under the current system. None of them. Every. single. one. will fail the scan. The business has to then dispute the failing scan, which includes a statement to the effect of "our network is secure - trust us." Once the dispute is received, a passing result is issued for the current scan. Then time passes until the next required scan (quarterly in my client's case) which will fail, they will have to lodge a dispute, then receive a pass. Rinse and repeat every. single. quarter.

This will continue until the PCI Security Standards Council (or whatever they are called) comes up with new scanning methods that allow you to prove mechanically that the network is secure. Until such time, if you want avoid this mess, get a telephone-line-connected credit card terminal. Maybe the rules were written and the scans designed back when you could get an SSL cert for an IP address, I don't know and don't really care anymore.

I don't know if this is the real truth, and I suppose I'll never find out as there is nothing left for me to do. I thought I would post it here so hopefully someone would pipe up and say "That's bull puckey! I have an IP terminal and I just got a passing scan last week! Here is a [redacted] copy!"

Just for kicks I submitted a summary of the problem and conclusions to the PCI standards council. If I hear anything back, I'll update the post.

 

[mikeroq]

I have a customer who has Trustwave for their ASV.

I had to white list Trustwave's IP addresses and now their scans pass. Keep in mind this client has nothing that needs to be externally exposed.

Also remote management on their router is disabled.

 

[HCHTech]

I have a customer who has Trustwave for their ASV.

I had to white list Trustwave's IP addresses and now their scans pass. Keep in mind this client has nothing that needs to be externally exposed.

Also remote management on their router is disabled.

Do you have an SSL cert on the edge device?

What whitelist did you add the scanning IPs to? Gateway AV? DPI? Other? Or did you just build a rule to "allow all" traffic from those IPs?

I have already disabled web (remote) management (that was one of the causes for failure early in this game). Doing this just changed the failure message.

In my case, I don't think whitelisting will help, their scans have no trouble reaching my equipment. If I remove the SSL Cert, then the failure is because of the self-signed certificate native to the Sonicwall. If I load the SSL Cert, the failure is because the Cert can't be verified (because of the name mismatch.)

Could you post a redacted copy of the passing scan report?

 

[mikeroq]

I added these IPs in the firewall in their router. Nothing fancy. I'll have to check it and see what I did for sure.
https://www3.trustwave.com/support/kb/Article20965.aspx

64.37.231.0/24 (64.37.231.1 through 64.37.231.254)
111.108.90.138-111.108.90.139
124.211.46.74-124.211.46.75
204.225.91.58-204.225.91.59
209.90.139.122-209.90.139.123
220.101.105.8-220.101.105.9
220.101.107.8-220.101.107.9