Harden RRAS IKEv2
How To:
Harden Windows Server 2012R2 Routing and Remote Access (RRAS) VPN server. Implement strong IKEv2 VPN cryptography:• Diffe-Hellman Group (DH) 14 or DH Group 19
• Enable AES256 and SHA256 L2TP/IPsec and IKEv2 on Windows Server VPNs.
This simple method significantly improves security strength for Windows 2012 IPsec VPNs.
Problem:
Windows RRAS server negotiates insecure IKEv2 and L2TP/IPsec cryptographic algorithms:- DH2-3DES-SHA1.
This problem impacts all RRAS VPN clients: Windows 10 phones, iPhones, Android, Cisco, Juniper and Sawn.
Solution:
Enable strong IPsec security algorithms in the Windows server registry:- IKEv2 DH14-AES256-SHA256
This (mostly) original approach is hands-down the easiest way to secure a Windows 2012 IKEv2 or L2TP/IPsec VPN.
Step 1: Regedit:
HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\IKEV2\Step 2: Create new key:
\IKEv2CustomPolicy\Step 3: Create new DWORDs (Table 1):
Table 1
IKEv2CustomPolicy DWORD Attributes
| ||
| IntegrityMethod | 1 | Integrity check algorithm to be negotiated during MM SA negotiation [RFC4306]. INTEGRITY_SHA1 (0x1) INTEGRITY_SHA_256 (0x2) |
| EncryptionMethod | 4 | Encryption algorithm to be negotiated during MM SA negotiation [RFC4306]. CIPHER_AES_128 (0x2) CIPHER_AES_256 (0x4) |
| CipherTransformConstant | 5 | Encryption algorithm to be negotiated during QM SA negotiation [RFC4306]. (0x3) CIPHER_CONFIG_CBC_AES_128 (0x5) CIPHER_CONFIG_CBC_AES_256 |
| AuthTransformConstant | 1 | Specifies the hash algorithm to be negotiated during QM SA negotiation [RFC4306]. AUTH_CONFIG_HMAC_SHA_1_96 (0x1) HMAC secret key authentication algorithm. SHA-1 (Secure Hash Algorithm) data integrity and data origin authentication algorithm. [RFC2404]. AUTH_CONFIG_HMAC_SHA_256_128 (0x2). HMAC secret key authentication algorithm. SHA-256 data integrity and data origin authentication algorithm. |
| DHGroup | 3 | Type of Diffie-Hellman group used for Internet Key Exchange (IKE) key generation during MM SA negotiation [RFC4306]. DH_GROUP_2 (0x2) DH_GROUP_14 (0x3) DH_GROUP_2048 (0x3) - IKE for DH-14. Name change to match standard terminology |
| PfsGroup | 0 | Diffie-Hellman algorithm to be used for Quick Mode Perfect Forward Secrecy (PFS) [RFC4306]. PFS_NONE (0x0) PFS_2 (0x2) PFS_2048 (i.e., DH-14) (0x3) PFS_MM (0x6) - Uses same DH as MM that contains this QM. |
| Note: DWORD values for IKEv2 Custom Policy Key: HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\IKEV2\IKEv2CustomPolicy\ This method also supports stronger security (e.g., DH-EC and GCM). See MSDN MS-RRASM for additional options. | ||
Additional Thoughts:
- This method works great with Windows Server 2012R2 and 2016.
- This method may or may not work for 2012 -I haven't test it.
- Do not use pre-shared keys (PSK).
- Use RSA certificates with a 3072-bit key length:
http://www.stevenjordan.net/2016/09/ipsec-security-levels.html
Client Requirements:
VPN clients must support the same cryptography in order to connect. Consider how Windows clients use DH2-3DES-SHA1 by default (yikes). I'll provide instructions on how to update Windows 10, iPhones, and Android IPsec clients in an upcoming article.
PowerShell:
PowerShell can implement stronger IKEv2 secuirty targets for both Windows 8.1 and 2012R2:
New-NetIPsecMainModeCryptoProposal -Encryption AES256127 -Hash SHA256 -KeyExchange DH19
Be warned, the process is challenging. If you go this route don't test it out on production servers. Also, the TechNet examples create new GPO policy specific to IKEv2. It does not account for all the other firewall rules. In other words, it creates a new firewall policy that only permits IKEv2 traffic -it's easy to get locked out without console access.
The trick is to copy ALL firewalls rules and IPsec rules, crypto-sets, and IPsec rules (and anything else I haven't thought of) to the new GPO -all through PowerShell. Alternately, use the GUI to copy the existing firewall settings to a separate firewall policy (i.e., separate from the PowerShell IKEv2 GPO). Do not use the GPO GUI to edit the IKEv2 (i.e., PowerShell) firewall or you risk corrupting it. You can then apply both GPOs to the VPN server.
Also, we may be able to accomplish the same thing by saving the object to the local policy store. Don't take my word on this because I haven't tried it yet. So yeah, this is a bit more work but the benefits should provide solid security and greater interoperability.
If anyone completes this script before I get around to it please forward me your work! Either way, I'm sure it will be good material for another blog article.
That's it!
References:
https://msdn.microsoft.com/en-us/library/hh536658.aspx
https://technet.microsoft.com/en-us/library/jj573824(v=wps.630).aspx
https://technet.microsoft.com/en-us/library/jj554897(v=wps.630).aspx