An IPSec VPN using pre-shared secret for authentication will fail PCI DSS security scans. Here's how to switch to using certificates on the router and the VPN client to pass the scan.
In my previous post on passing Payment Card Industry Data Security Standard (PCI DSS) external vulnerability scans I mentioned two unresolved scan failures, both connected with VPN access. In one case, the SSL VPN appliance, there was no solution with the existing hardware. Although we're still running that box, its days are numbered.
The second problem was with the IPSec VPN (sometimes referred to as a "normal" or "traditional" VPN to distinguish it from Secure Sockets Layer, or SSL, VPN) on our SonicWALL router. The users testing it out had found it faster and more reliable than the SSL VPN, so I really wanted to keep it. The problem was that solving the scan failure looked horrendously complicated.
To begin with, what's the problem? The PCI DSS scan reported this:
Synopsis: The remote IKEv1 service supports Aggressive Mode with Pre-Shared key. Impact: The remote Internet Key Exchange (IKE) version 1 service seems to support Aggressive Mode with Pre-Shared key (PSK) authentication. Such configuration could allow an attacker to capture and crack the PSK of a VPN gateway and gain unauthorized access to private networks.
- Disable Aggressive Mode if supported.
- Do not use Pre-Shared key for authentication if possible.
- If using Pre-Shared key cannot be avoided, use very strong keys.
- If possible, do not allow VPN connections from any IP addresses.CVE: CVE-2002-1623
I smiled at the advice to "use very strong keys" because the security scan is automated and will fail on this issue no matter how strong the key is. What didn't make me smile, however, was the fact that this vulnerability has been known for over 10 years (that's what the CVE number tells you). Why does the SonicWALL even allow such a vulnerable configuration? When I logged the problem with SonicWALL, they didn't answer that question but they did tell me:
- "Aggressive Mode" can only be disabled for a site-to-site VPN (which can run in "Main Mode"). That didn't help me as I'm not running site-to-site.
- The only alternative to Pre-Shared Key authentication is to use certificates. They sent me a wonderful out-of-date SonicWALL PDF document on using certificates. I read it and didn't understand it.
Before expending effort to fix this problem I first wanted to satisfy myself that a "traditional" VPN is still a good choice. After all, it needs special client software and gives the computers that connect full access to the LAN as if they were right there in the building. Surely SSL VPN is the preferred way these days?
Sure enough, articles from Cisco or Barracuda, for example, highlight the advantages of SSL VPN. Our experience with the "portal" concept of SSL VPN has been disappointing (i.e., applications responding very slowly or not working at all). And when your remote office staff tell you that the IPSec VPN works better for them, you need to take notice. On balance, therefore, we decided we had to bite the bullet and make our SonicWALL VPN behave.
Making this work was a three-step process:
- Install our wildcard SSL certificate on the SonicWALL. I enlisted the help of a local IT consultant, who was able to get to grips with SonicWALL's convoluted documentation to do this.
- On the SonicWALL router, reconfigure the WAN GroupVPN (under VPN | Settings) to use IKE Using 3rd Party Certificates instead of IKE Using Preshared Secret (another term for pre-shared key).
- Install the same certificate on the SonicWALL Global VPN Client (GVC) on each client machine.
In this post I'll describe step 1 in detail. A future post will cover the other two steps.
IntermediateIt's important to note that you need not only your own certificate but also relevant root and intermediate certificates. (As I've confessed before, I don't claim to understand how certificates work, including these chains and intermediate certificates. I just follow instructions.) Figure A shows our certificate (saved in .pfx format) followed by the intermediate and root certificates saved to a folder. In our case, the latter were downloaded from https://certs.godaddy.com/anonymous/repository.pki. Figure A
End-user and CA certificates ready for import
- On the SonicWALL, navigate to System | Certificates and click the Import button.
- In the Import Certificate dialogue, select Import A CA certificate and browse to the root certificate (in our case gd-class2-root.cer).
- Click Import.
- Verify that the certificate has been imported (Figure B). Figure B
- Once the class 2 certificate has been imported, select and import the intermediate certificate file (gs-intermediate.crt) in the same way. A warning about the file name appears (Figure C) but can be ignored. Figure C
- Import your company certificate as shown in Figure D. The Certificate Name is a name you choose; the Certificate Management Password is the password for the encrypted .pfx file (in our case).
CA root certificate imported
Warning when importing intermediate certificate
Importing the wildcard SSL certificateAfter following this procedure the certificate list should show three certificates, with the Validated column showing ‘Yes' for your company-specific certificate (Figure E). Figure E
All certificates imported; company-specific certificate validated.
You're now ready to change your VPN settings.
An IPSec VPN using pre-shared secret for authentication will fail PCI DSS security scans. The fix is to use certificates on the router and the VPN client. In this post I described how to install an SSL certificate onto a SonicWALL router. Part two will describe how to change the VPN settings on the router and the client.