PCI Compliance on MX

[lpopejoy]

We are having recurring issues with PCI Compliance where Client VPN is in use.  I get that we can mitigate with strong keys and rotation, but shouldn't there be a way to configure a firewall so that we can be compliant?  

[jdsilva]

There is. Disable client VPN 😛

Seriously though, your question is more philosophical than practical. For people who don't work in a PCI environment they couldn't care less. For those who do evaluating this sort of thing should be done prior to implementing the device. It doesn't seem wise to put a non-compliant device into a PCI environment, and then blaming the device. I don't mean to take a shot at anyone in this position, but it's the truth.

There is IKEv2 support coming. And so is AnyConnect support. Those will solve this.

[Adam]

You could also isolate your VPN clients to just the resources they need, ideally non PCI data/network.  

Segmentation

[lpopejoy]

Most of these clients don't actually have credit card data, but they are required to pass a scan.  Separating into a different subnet wouldn't fix not being able to pass the scan.

[lpopejoy]

@jdsilvaHey, I get it - and maybe disabling the VPN is the solution. 

It seems like you are implying that the MX is a "non-pci compliant" device.  As far as I know, that isn't the case - are you saying otherwise?

Ikev2 would solve this, I think, as well as being able to disable weak cipher suites - which at this time is not exposed to the client VPN GUI. 

[PhilipDAth]

How does using IKEv1 or IKEv2 alter anything to do with PCI compliance?  I have never heard of this, so would be interested in the feedback.

The Client VPN uses L2TP over IPSec (which uses IKEv1).

Would not moving to 2FA for client VPN alleviate most of the concerns?

[lpopejoy]

Companies like trustwave probe your public IP and evaluate what responds.  If you enable client VPN on an MX, you fail their scan.  It doesn't matter how long your passphrase is or if you use 2fa. 

In the past, we have been able to say that we use a strong passphrase and rotate regularly, and they give us a pass.  However, that seems to be changing and now they want older cipher suites disabled as well which we have no control over.

[PhilipDAth]

They can't possibly detect that client VPN is enabled.  All they can detect is that they got an IKEv1 response.  That could also be because of site to site VPNs.

And until they commence VPN negotiation (which they can't without an initial authentication) you don't see the encryption algorithms available.

Furthermore, the encryption algorithms available are the same for IKEv1 and IKEv2.  IKEv2 is just a refreshed version of IKE that made a lot of the defacto standards a "proper" standard.

[lpopejoy]

Correct, they don't know if it is client vpn or "third party" vpn - thanks for pointing that out. 

However, they do know what cipher suites are available, because they fail if they detect weak ones... Here's the failure notice based on their scan:

Diffie-Hellman Groups 1 to 4 are no longer considered safe for strong encryption. It is estimated that these groups have a security level of 80-90 bits which is no longer adequate to protect the encryption keys used during IKE phase 2. Furthermore, Group 5 (Modp-1536) has a security level of 120 bits which is slightly under to protect AES-128 encryption keys. Stronger groups have been designed for the Diffie-Hellman key exchange in RFC 3526.

Weak encryption ciphers, such as DES or 3DES, were identified as supported on this VPN device.  These weak ciphers could make it easier for a context dependent attack to compromise the integrity of IKE sessions established with this device.

[jdsilva]

@lpopejoy No, I'm saying nearly all "PCI Complaint" devices are only PCI compliant when configured to meet PCI requirements. If you introduce a configuration that is not PCI compliant then the device is no longer PCI compliant. 

As with nearly all things, the devil is in the details. 

@PhilipDAth My understanding was this fails due to client VPN using Aggressive Mode. If there was an option for Main Mode it would pass. 

[lpopejoy · Accepted solution]

@jdsilva Point taken. 

From the case we opened with Meraki, they can disable the less secure cipher suites:

“We have an option where I can push the extra configuration to the MX for DH 5 and AES 128.

But I want you to understand that it may have a negative impact on the ability for different devices to connect to the client VPN. If any devices try to connect to the client VPN (when this extra config is is present) that do not support DH group 5, will be unable to connect and the only recourse on our side would be to remove the config.”

[VictorWise]

We have a client with a similar issue. After you disabled the cipher's did you have any issues with clients connecting to the VPN? I'm researching operating system compatibility but haven't found a good resource. We would have a mix of Macs and PC's connecting, with a variety of operating system versions.

Thanks in advance.

Victor

[JAMicro]

"For those who do evaluating this sort of thing should be done prior to implementing the device"

FYI these criteria were not failing criteria until May of this year.  I used to be able to get my scans approved by disputing the Aggressive IKE point and telling them that my PSK was sufficiently complex and rotated regularly, which they consider a compensating control.  But now, as @lpopejoy has shown in his screenshots, DH 1-4 are considered "unsafe" and are now considered a fail.  This is not our fault, it's Meraki's.

Just a bit of context.

[mvalpreda]

With PCI 3.2, this doesn't fly any longer. I now have a device that won't pass PCI compliance with client VPN enabled.

[PhilipDAth]

>This is not our fault, it's Meraki's.

Not really.  Meraki supports the strong DH14 - Microsoft does not.

[PhilipDAth]

I've done some work in this area and updated my client VPN wizard so it can now make connections to an MX with Windows 10 using DH14 making it PCI compliant.

https://www.ifm.net.nz/cookbooks/meraki-client-vpn.html 

[almightythor]

no, this was and still is a problem. Still waiting for ikev2...

[cmr]

@almightythor MX15?

[almightythor]

MX anything. People here saying compliance doesn't matter and just don't have a client vpn... ridiculous. Meraki is still my fav but lets be honest they are a huge fail for compliance and the covid world.

No ssl vpn. No certs for client vpn. Using algorithms that were outdated a decade ago. Still no IKEv2 unless you go full beta and that's only on STS VPN...and it's the year 2021. Can anyone seriously think this is okay for any security appliance?

[cmr]

@almightythor totally agree about the VPN, it is a shambles.  Also the SD-WAN has issues where if you have full tunnel from a z3 to an advanced license MX and then out, the advanced features such as L7 don't get applied to traffic from the z3.

However MX15 is reliable,  we've been using it for over a year across our 24/7 enterprise and are happy with the reliability.

FYI we use Sophos for our L7 firewalling and client VPN, so the issues you have and we would have with a full Meraki stack, don't appear.