ads

Style6

Style3[OneLeft]

Style3[OneRight]

Style4

Style5[ImagesOnly]

Style2

Fix Win NAT-T for L2TP and IKEv2

Problem:  

Windows 2012 RRAS IPsec VPN does not support NAT-T out-of-the-box.  By default, RRAS only works with public IP addresses -no NAT.  Windows 10 clients cannot connect with L2TP from outside the office.  Windows 2016 does not support L2TP for any client from behind routers running NAT.

Solution:  

Enable NAT-T on both Windows servers and the clients.  NAT-T allows the VPN server to serve clients (e.g., Windows 10, Android, Apple iOS) from behind the NAT device.  Modify MTU. 

Background

Why NAT-T? 

IPsec uses Encapsulating Security Payload (ESP) to encrypt packet headers and payloads.  By default, ESP is not compatible with Port Address Translation (PAT).  This is because TCP uses ports and ESP does not.  

TCP and ESP are different Internet protocols. TCP uses protocol number 6.  N.B., TCP protocol number 6 is not the same thing as TCP port 6.  TCP ports are communication endpoints.  For example, TCP uses port 80 for web traffic.  

ESP uses protocol (i.e., not port) number 50.   ESP is a protocol without ports.  Network Address Translation (NAT) uses port translation PAT to bind traffic flows with internal hosts.  Therefore, ESP does not work with NAT.

NAT-T allows ESP to work from behind NAT.  It encapsulates ESP protocol 50 inside User Datagram Protocol (UDP) 4500.   N.B, NAT-T is not the same as IPsec over UDP.

Enable NAT-T 


NAT-T is enabled on most operating systems (e.g., Android) -Windows is the exception.  Fortunately,  we can enable NAT-T on Windows 10 and Windows 2012 with a few simple changes. 

Windows IPsec clients are supposed to work from any location.  Therefore, only enable NAT-T on the 2012 RRAS server.  

Create a new registry key to enable NAT-T.

  1.   Edit Registry or create GPO:

                         HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent\Parameters\

  1.   Create new DWORD value:   AssumeUDPEncapsulationContextOnSendRule

  1.   Modify DWORD value:  2

These changes will fix those pesky L2TP-NAT problem.  

Troubleshooting Issues

Make sure clients use the latest edition of Windows 10.  Early versions had quirks where clients simply would not connect via NAT-T.  

   NAT-T does not work with  the following editions:

  • version 10240
  • version 1511 (i.e. November Update)
   Unconfirmed (may or may not work):  
  • version 1607 (i.e., Anniversary Update)
   Confirmed:

  • version 1703 (i.e., Creators Update)
   NAT-T works great with the registry fix and Creators Update.

   Workarounds:  

Some folks had to toggle the NAT-T registry value in order to connect (http://bit.ly/2r2CKnF).  I assume this fix was for the November or Anniversary Update.  

MTU

Don't forget to adjust the Max Segment Size (MSS):  
http://www.stevenjordan.net/2016/11/windows-ikev2-mtu.html.  

That's It!

TSA Searches Phones and Laptops



Headlines:  DIGITAL INTERROGATION? TRAVELERS' PHONES, SOCIALS SCANNED AT AIRPORTS... 

Takeaway:  


Personal electronic devices are subject to searches by the TSA and CBP agents -travelers beware.  U.S. Agents may request full access to smart phones, tablets and laptops.  Special emphasis is placed on search history, text history, and social media (e.g., Facebook).  TSA/ CBP may temporarily confiscate the device, up to thirty days, or copy the contents of the entire disk for further investigation.

News about digital frisking is en vogue because of recent political events.  However, this specific policy has been in effect before 2011 -during both Bush and Obama administrations. (, 2008).  The less told story, however, is that data is at greatest risk when traveling to other countries.

Problem:

It may come as a surprise to learn that most Western governments do not respect individual privacy rights -digital or otherwise.  For example, authorities at Paris Charles de Gaulle Airport are known to scan laptops (BBC, 1998).  Devices are also subject to search when traveling through Canada, Australia, or the U.K  -no warrants needed. (Hughes, 2014).  

Encryption to the rescue?  Encryption may protect your data but it's not fail-proof.  For starters, there are different types of encryption.  Some types of encryption are considered strong and nearly impossible to break.  However, encryption uses cryptographic algorithms that become obsolete within months or years.  Implementing secure encryption can be a complicated process.   

What's more, encryption may protect your data, but it will not stop a frustrated border patrol agent from taking your device or arresting you. (Hughes, 2014).

Why the Fuss?

There are two sides to every coin.  Governments have legitimate national security issues to contend with.  Digital search and seizure policies are a simple means to identify terrorists, child pornographers, and other criminal activity.

On the other hand, the majority of international travelers are not criminals.  At least in the U.S., and with exceptions, the right to privacy is a constitutional civil right.  There are legitimate reasons to keep trade secrets, health records, or financial information secret.

Data at Risk

Not all inspections are invasive.  Some agents may simply ask you to turn the device on.  Others may causally browse its contents.   However, there are situations that compromise data integrity:

  • If you provide a key code or password.
  • If the device is removed from your line of sight.
  • If the device is physically connected to another machine (e.g., scanned).
  • If the device connects to an agent's network (Ethernet or WiFi).
If a device is compromised it can no longer be trusted:

  • Your data is no longer confidential (e.g., pictures, credit cards, etc.)
  • Your data may have been altered or deleted.
  • The device may contain a viruses or malware.
  • All of your passwords may be compromised.
  • Your network accounts may be vulnerable (e.g., Exchange, VPN, RDP)

Conclusion:

In most situations, digital searches by the TSA/ CBP are probably harmless.  However, it's prudent to take extra precautions when traveling outside the United States.

Links:

http://www.vocativ.com/397897/travelers-affected-by-trump-ban-forced-to-unlock-phones-computers/
https://www.eff.org/wp/defending-privacy-us-border-guide-travelers-carrying-digital-devices
http://www.stevenjordan.net/2014/08/network-security-international-and.html
http://www.stevenjordan.net/2016/09/ipsec-security-levels.html
http://www.stevenjordan.net/2016/09/secure-ikev2-win-10.html
https://www.theguardian.com/profile/bruceschneier
http://news.bbc.co.uk/2/hi/science/nature/150465.stm


https://www.theguardian.com/technology/2008/may/15/computing.security

Android IKEv2 Client Setup

Task:  

Send end-user instructions on how to configure Android IKEv2 VPN clients.  

Solution:

Installation is a two-step process:

Step 1:  Install all three certificates.  The Administrator has sent a separate website link where you can download necessary certificates:  (a) user_device.PFX; (b) vpn_server.CER, and root.CER.  Open each attachment to start the installation.  Include the PFX password.

Step 2:  Configure the Android VPN client:  Android Settings → Connections → More Connection Settings → VPN → Add VPN.


VPN Settings (Figure 1):
N.B., Change the value for “IPSec user certificate” to “user_android”.
Figure 1.  Android IKEv2 VPN Settings.  
Hint:  VPN shortcut apps are available in the Google Play Store.  This provides a quick and easy method to connect.
For example:  https://play.google.com/store/apps/details?id=com.rosaneng.vpnsettings&hl=en


Also note, your device certificate contains a private key for your client certificate.  Anyone that gets a hold of this key can impersonate your account.  Please protect your device with a passcode and encryption.  This script is not intended for rooted devices.  I encourage you to delete this email from your mailbox after you’ve configured your devices. 

That's It!

Install Mobile-Config Script

Task:  

Setup instructions for manual distribution of mobile-config scripts for iPhones and iPads.

Assumptions:

These instructions assume the mobile-config script has already been generated,  These instructions are for situations when mobile device management (MDM) is not available.  It assumes email distribution from a private server.  Use caution whenever distributing certificates and private keys!

Background:

Mobile-device scripts run on any iPhone or iPad –simply open the email attachment to start the process.  It installs certificates and configures the IKEv2 VPN.  This script can configure multiple devices.

Security Considerations

Also note, the script includes the private key for the client certificate.  This provides identity validation, authentication, and authorization.  Anyone that gets a hold of this key can impersonate the account.  It’s critical to use a passcode and enforce encryption.  Do not install these files on jailbroken devices.  Delete the script from your mailbox after all devices are configured.

Brief instructions:

Step 1:  Open mobile-config file to start the profile installation.

· N.B., This script is not signed –that’s OK.
· Click Next.




Step 2:  Enter device passcode.

Step 3:  Consent.

· Brief description for mobile-config.
· Installation requires consent.
· Click Next.




Step 4:  Confirm Install.

· General VPN disclosure.
· Click Install.  Click Done.

Step 5.  Connect to the VPN.

· Open Settings.
· Toggle the VPN button.
· The VPN symbol appears in upper left-hand corner to confirm active VPN sessions.


The VPN is ready for action.  That's It!

Dynamic S2S VPNs


Task:

Create site-to-site (S2S) interfaces for dynamic IKEv2 VPN clients (e.g., iPhones).  Assign different cryptographic algorithms to each S2S interface.

What are dynamic S2S VPNs?

 S2S VPNs usually support static VPN endpoints.  For example, a dedicated (i.e., always-on) VPN that connects a branch office to its HQ office.  However, S2S VPNs can also connect mobile clients for dynamic connections.   This hybrid approach is for special circumstances.

Why use dynamic S2S VPNs?

Most folks should stick with the default RRAS dial-up VPN server.  It provides better management and reporting tools.  However, dynamic S2S VPNs support configuration features that are unavailable with the standard RRAS client VPNs.

For example, dial-up IKEv2 VPNs may authenticate any certificate issued from one of its trusted root certificates.  S2S VPNs can limit authentication to specific client certificates.  The best part, IMHO,  is the ability to apply unique cipher suites per S2S interface.  For example, we can create separate S2S interfaces for each client -including unique cipher suite standards.

How do we implement dynamic S2S VPNs?

PowerShell offers a straight-forward method to implement S2S VPNs.  However, consider using a GUI-Powershell hybrid approach that supports additional client management features.

Dynamic S2S via PowerShell:

The following example creates a new S2S interface with strong security targets:
• Certificate authentication
• IKEv2 Protocol
• Main Mode:   AES128-SHA256-DHGroup14
• Quick Mode:   AES256-SHA256

Add-VpnS2SInterface -name smj@stevenjordan.net -CustomPolicy -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod aes128 -IntegrityCheckMethod SHA256 -Destination 0.0.0.0 -Protocol IKEv2 -AuthenticationMethod MachineCertificates -ResponderAuthenticationMethod MachineCertificates -EncryptionType RequireEncryption

The interface name always matches the authentication certificate's subject name.  Some clients (e.g., iPhone) require a matching subject common name and matching subject alternative name (SAN) DNS name.  This attribute associates the authentication certificate with the S2S interface.  The destination flag is set to accept connection requests from any IP (i.e., it's dynamic).

Don't forget to lock down the VPN server.  Enforcing subject names does not secure the server.  Recall, Windows VPN server leaves its front door wide open -by default.  Windows VPN security requires manual changes:  http://www.stevenjordan.net/2016/10/door-wide-open-on-win-ikev2.html

Managing S2S connections via PowerShell:

Managing client connections is cumbersome compared to traditional RRAS client VPN tools.  For example, RRAS and Remote Access Management provide simple GUI tools to manage dial-up connections (Figure 1).  However, Remote Access Clients does not display S2S connections.  Additionally, RRAS Network Interfaces does display S2S interfaces by deafult.

Figure 1.  RRAS Client Connections.
The RRAS management GUI does not play well with dynamic S2S connections.  The Remote Access Clients tab does not display active connections.  However, the GUI will display active IKEv2 WAN Miniports:

Figure 2.  Active WAN Miniports.  Good enough.
PowerShell provides a better method to view active S2S connections:
PS C:\Users\SMJ> Get-VpnS2SInterface
RoutingDomain Name Destination AdminStatus ConnectionState
------ ------- ----------- ----------- ---------------
XXXXXX-XXXX-SMJ {0.0.0.0} True Connected

Dynamic S2S GUI-Powershell Hybrid

Alternately, create dynamic S2S interfaces with the RRAS GUI.  This approach offers some S2S client management benefits.  Keep in mind, these S2S interfaces use default cryptographic algorithms.  We'll need to modify S2S security targets with PowerShell:

Step 1.  RRAS → VNS server → Right-click Network Inerfaces → New Demand-Dial Interface:

• Interface Name:  Certificate's subject common name.
• Connection Type:  VPN → Next
• VPN Type:  IKEv2 → Next
• Hostname:  None (leave blank) → Next
• Protocols & Security:  Route IP packets on this interface → Next
• Static Routes:  None (or add based on your organization's needs).
• Dial-Out Credentials:  None → Next → Finish.

Step 2:  Edit S2S interface properties → Options tab.
• Connection type:  Persistent connection →  OK.

Step 3:  Edit security targets for S2S interface in PowerShell.
PS C:\Users\SMJ> Set-VpnS2SInterface -name xxxx-xxxx-SMJ -CustomPolicy -CipherTransformConstants AES256 -DHGroup Group14 -EncryptionMethod aes256 -IntegrityCheckMethod SHA256 -EncryptionType RequireEncryption

WARNING: VPN site-to-site adapter xxxx-xxxx-SMJ will be modified and the parameters 
other than IPv4Subnet/IPv6Subnet will be applicable next time the connection is dialed.

Check Hybrid S2S Connection from GUI:

 RRAS → VNS server → Network Interfaces:  Connection Status


Figure 3.  S2S connection status via RRAS GUI.

The RRAS Network Interface GUI now includes a list of S2S interfaces and connection status.  It also provides a simple method to disconnect or disable client connections.

Troubleshoot:

Use PowerShell to check server IPsec crypto-sets:
• Get-NetIPsecMainModeCryptoSet
• Get-NetIPsecQuickModeCryptoSet


Confirm server-client security targets work as intended:
• Get-VPNS2SInterface
• Get-NetIPsecMainModeSA
• Get-NetIPsecQuickModeSA

I also recommend using the Best Practice Analyzer (BPA) to check for any obvious S2S security warnings.
https://technet.microsoft.com/en-us/library/ee922676(v=ws.10).aspx


That's It!

MDM Cert Enrollment

Task:

How to manually request and enroll certificates for BYOD devices with Windows CA server.

Background:

Automated mobile device management (MDM)  (e.g., Microsoft Workplace-Join,) provides a secure method for device key management.  However, rolling out the right MDM solution can be a serious undertaking.  It may be overkill for some organizations.

This article covers device key-management for special use situations.  It provides instructions on how to manually generate device (e.g., iPhone) certificates for mutual authentication (e.g., IKEv2 VPNs).

Assumptions:

Solution:

Step 1:  Request the device certificate from from any workstation:

  • Start → MMC → File → Add Snap-In:  Add Certificates - Current User
  • Certificates → Current User →  Personal → Certificates → All Tasks → Request New Certificate


Step 2:  Complete the Certificate Enrollment Wizard:                 

  • Select Policy: No changes.  Click Next.
  • → Request Certificates:  User Device Auth → Click Details →  Click Properties.
  • → Certificate Properties:      

        →  [Subject Tab]
                  Subject Name:
                       Common Name (CN) = user_device@stevenjordan.net;  add.
                       Email = user_email@stevenjordan.net;  add. Given Name:  First and last name; add.
                  Alternative Name:
                        DNS = user_device@stevenjordan.net; add. N.B., DNS must match Full CN.
                        Email = user_email@stevenjordan.net; add.
         → [General Tab]
                   Friendly name:  user_device@stevenjordan.net
         → Click OK.

         → Request Certificates:  Add checkmark for User Device Auth → Click Enroll.
  • Note that status = Pending.
Step 3:   Approve request from Certificate Authority (CA) server.  

  • Open CA Server  MMC:
       → Certification Authority (Local) → Root-CA →  Pending Requests → Issue: 
Step 4:  Export certificate from workstation that initiated request:  
  • Certificates → Current User →  Certificate Enrollment Requests:
    → Certificate Export Wizard
         → Export Private Key:  Yes, export the key.
         → Export File Format:  Check Include all certificates in path.  Next.
         → Select Policy: No changes.  Click Next.
         → Security:  Check Password.  Enter Password.  Next.
                               N.B., Password = choose_password
         → File to Export:  Choose location:  C:\source\cert\user_device.pfx.  Next.
         → Export Root Certificate and VPN server certificate:  Location: \\securefileshare\
  • Repeat similar process to export CA public root certificate (CER).
  • Log onto the VPN server and repeat similar process to export public certificate (CER).
Step 5:  Distribute certificate files to client devices.
  • Distribute the client certificate and private key (e.g., PFX).  
  • Include the public VPN server and root certificates (e.g., CER).

Distribution methods: 

Security Considerations:

Safeguard your client PFX files!!  PFX files include certificates and their private keys.  An attacker can use this information to impersonate identity.  That means, it can be used to connect to the VPN, collect email, etc.  Do not let these PFX files fall into the wrong hands!  Mitigation:
  • Account for all PFX instances -these are security vulnerabilities!
  • Delete/ remove all device certificates generated from workstations.
  • Save client PFX file to secure off-line media. 
  • Consider IT policy that requires face-to-face installation with IT staff.
  • Email attachments can be forwarded -risk!
  • Internal web server on internal Wi-Fi SSID is preferred.  
  • Ad-Hoc Wi-Fi may be preferable to infrastructure mode. 
  • Do not enable the certificate's export flag.
  • Do not install on any rooted or jailbroken device.  
  • Ensure devices use encryption and passcodes.
  • Above all, use common sense!

That's It!

CA Template for VPNs

Task: 

Prepare Windows CA certificate template for end-user enrollment.

Assumptions:  


  • These instructions are for situations that require minimal VPN support.
  • This solution only supports enrollment requests from the Windows certificate snap-in.
  • It enforces administrative approval for end-device enrollment -this is not a completely automated process.
  • Workplace Join is the preferred method for device enrollment.  It provides self-service automation.  It provides secure key management.  This walk-through is not for Workplace Join.

Steps:


  1. Open certificate templates.  From the Windows CA:  Start → MMC → File → Add Snap-In:  Add Certificate Templates.
  2. Step 2:  Duplicate User template:  Certificate Templates → Right-Click on User (Template) →  Duplicate Template.  
  3. Step 3:  Edit Properties of New Template (Table 1):


Table 1:  New Certificate Template Properties.
Field
General
Cryptography
Extensions
Security
Template Display Name
User Device Auth



Validity Period
3 Years



Publish in AD
Un-check



Minimum key size

2048 or 3072


Providers

Microsoft RSA


Applications Policies


Client Authentication

Authenticated Users



Allow Read
Allow Enroll
Note:  3072 key size increases security strength for IKEv2 VPNs.  Choose validity to fit needs of organization.  Use short validity period for automated self-service (e.g., Workplace Join).  Disable certificate exports for automated self-service.   

The template becomes available for user enrollment requests from any Windows certificate snap-in.

Connect iPhone to Windows VPN

Task:  

These steps are necessary to connect an iPhone to a Windows VPN server.  It explains how to
generate Apple iOS mobile-config scripts with Apple Configurator 2.  These mobile configuration scripts configure settings unavailable through the iPhone GUI (e.g., IKEv2 cryptography algorithms),

Requirements:

  •  Apple OSX running Apple Configurator 2
  • Server certificates:  Root_CA.cer and VPN_Server.cer(s).
    N.B., this process does not require the private keys for the Root CA or VPN server.
  • Client Certificate
       (a) Subject CN in username format (e.g., smj@stevenjordan.net).
       (b) Enhanced Key Usage (EKU) uses client authentication (1.3.6.1.5.5.7.3.2).
       (c) Subject Alternative Name with DNS attribute that matches the subject CN
             (e.g., DNS Name=smj@stevenjordan.net)
       (d) IKEv2 requires RSA (2048) SHA256 certificate.  

Administrative Process:

Process consists of three steps: (a) Create, (b) distribute, and (c) import the mobile-config.

Mobile Config

Create the mobile-config using Apple Configurator 2.  N.B., this process requires the Root CA and VPN server certificates (e.g., CER files).  The device certificate and private key is optional (i.e., device.PFX).  Additional PFX considerations:

  • IKEv2 VPN authentication requires PFX installation.  
  • Merging the PFX and the mobile-config provides the best user experience.
  • All PFX installations require special security precautions -regardless of mobile-config.
  • Self-service MDM makes administration easier..

Apple Configurator 2:  

  1. Start the Configurator and create a new profile:  File → New Profile.  Alternetly, edit an existing profile:  File → Open → Shoreland_Mobile_Config.
  2. General Tab:  Name, identifier (default), Organization, etc.
  3. Certificates Tab:  Import root.crt, VPN_server.crt.  Import device.pfx (i.e., client cert and private key (optional).
  4. VPN Tab:

    Table 1.  Apple Configurator 2 IKEv2 VPN Example.

Connection Name
 *
Connection Type
IKEv2
Server
VPN FQDN (public facing)
(e.g., vpn.stevenjordan.net)
Remote Identifier
VPN FQDN (public facing)
Local Identifier
Subject CN from client certificate.
(e.g., smj@stevenjordan.net)
Machine Authentication
Certificate
Identify Certificate (Optional)
Choose User_Device.PFX from pull-down menu.
Certificate Type
RSA
Server Certificate Issuer Common Name
Root CA Issuer (CN). 
(e.g., Jordan_Root_CA)
Server Certificate Common Name
VPN FQDN (e.g., vpn.stevenjordan.net)
IKE SA Params
Encryption Algorithm:  AES-256
Integrity Algorithm:  SHA2-256
Diffie-Hellman Group:  14
Child SA Params
Encryption Algorithm:  AES-256
Integrity Algorithm:  SHA1-96
Diffie-Hellman Group:  14

    5.  Save mobile-config:  
           File → New Profile.  Optionally Sign the profile.  Signing the code is optional and requires a certificate from Apple.  Save to an accessible location (e.g., Documents).

Distribute Mobile-Config

The safest method to distribute these mobile configuration scripts, especially those with private keys, is from a mobile device management (MDM) server.  Apple Configurator works as a secure MDM solution.  The process configures each device via USB. The process is not 100% automated -but it is secure.  http://simplemdm.com/2016/03/14/how-to-enroll-in-mdm-with-apple-configurator-2/

Alternately, organizations can distribute mobile-config scripts via email or web.   For example, use Outlook OWA, upload to a website, or use a corporate OneDrive.  Include the device.pfx if not incorporated in the mobile-config.  

Please consider the security risks associated with these alternative distribution methods. Certificates and private keys are used to validate identity.  We DO NOT want the wrong person to intercept this data.  It will allow them to authenticate to network servers, send email, etc...  Please use common sense.  Always delete private keys after installation is complete.     

Import Mobile-Config

Send the end-user an email with the mobile-config.  The email can include the mobile-config file as an attachment.  The end-user simply needs to open the attachment to start the installation process.  
  • Installation requires the end-user's device PIN.  
  • The end user will receive an alert that the mobile-config file is not signed
  • The end user must install user certificates and private keys (e.g. device.pfx) as required.  PKIs can be incorporated into the mobile-config script.
  • User may receive a warning that the PFX is not signed or trusted.

Additional Information:  

Alternatives to Apple Configurator:  Edit mobile-config XML scripts with Notepad++:  http://www.stevenjordan.net/2016/11/ikev2-mobile-config-script.html

How to add certificates and private keys within mobile-config XML scripts using Notepad++:
http://www.stevenjordan.net/2016/11/add-certs-to-mobile-config-xml.html

http://www.stevenjordan.net/2016/09/harden-rras-ikev2.html

Configure Windows Server IKEv2 VPNS:
http://www.stevenjordan.net/2016/09/secure-ikev2-win-10.html

Edit Certificates in Mobile-Config XML

Task:

Add user device certificates (e.g., PFX and CER) into Apple mobile-config scripts.  

Solution:  

Encode PFX and CER files with Base64.   Merge output with mobile-config script.  Specific solution steps are listed below.

Mobile-Config Background:   

Mobile-config scripts are simple XML documents.  The XML "code" holds any number of Apple iOS configuration settings.    These scripts are user-friendly and run on iPhones and iPads.  Network Administrators use these scripts for mobile device management (MDM).  For example, a mobile-config script can automatically configure VPN settings.

The Apple Configurator 2 is a free application that generates mobile-config files.  It has a user-friendly GUI and is a simple method to manage Apple devices.  Apple Configurator only runs on MacOS.  However, mobile-config scripts can be managed with any XML editor.  Simply copy existing scripts and make changes as needed (e.g., Notepad++).

Certificate Background:  

PKCS12 is an archive file that bundles a X.509 certificates and private key.  PKCS12 succeeds Microsoft's PFX archive.  However, PCKS12 and PFX files are interchangeable formats.  Organizations that use Windows CA work with PFX files.

CER is an extension of SSL and TLS certificates.  These files are simply X.509 certificates -without private keys.

IKEv2 VPN servers authenticate devices with X.509 certificates.  Authentication requires the user certificate and private key (i.e., PFX).  It generally requires the VPN server certificate and trusted root certificate (i.e., CER).   The mobile-config script provides a user-friendly method to configure IKEv2 and import PFX and CER files.

Solution Steps:  

  1. Use Certutil.exe to encode PFX file with Base64.  This process creates a new encoded file (*.enc).C:\source\cert>certutil -encode iphone.pfx user.enc
  2. Encode CER files (e.g., trusted root and VPN server) as needed.
    C:\source\cert>certutil -encode vpnserver.CER VPNServer.enc
  3. Open the encoded file with any XML editor (e.g., Notepad+).  Copy and paste its contents to the appropriate section within the mobile-confg script.  

Alternate Solution Steps:

Use Notepad+ to encode the PFX with Base64.

1. Open the PFX with Notepad++.
2. Select all text (CTL-A)
3. Right-click the highlighted text → Plug-In Commands → Base64 Encode.
4. The encoded text is ready for the mobile-confg script.  Insert this text to the appropriate section within the mobile-config script.

Merge Base64 

Instructions on how to incorporate Base64 PFX into mobile-config:  http://www.stevenjordan.net/2016/11/ikev2-mobile-config-script.html

Risks

Theses scripts are simple text files.  Bad things can happen if they fall into the wrong hands. Take precaution for mobile-config scripts that contain certificates and private keys (i.e., PFX):

  • It's best to distribute scripts via MDM solutions.  
  • These certificates should not be exportable.  
  • Do not install private keys on rooted devices.  
  • IT staff should assist with all manual installations.  
  • Implement a process to ensure safe handling of private keys.  
  • Ensure scripts that contain private keys are deleted when work is complete.  

References:


Door Wide Open on Win IKEv2


Fix for Windows VPN Certificate Authentication Vulnerability

Problem:  

Windows Server 2016 VPN server has left the front door wide open for attackers –by default!  It authenticates ANY client certificate issued by ANY public CA.  This problem occurs when the client certificate trust chain matches a certificate in the server’s trusted root store.  For example, an attacker can authenticate with any DigiCert certificate (Figure 1).
  
How vulnerable are these servers?  I'm willing to wager that my twelve-year old son can hack it in under five minutes.  This is a pants-on-fire security hole that needs to be fixed before the server hits production.

Figure 1.  Win IKEv2 authenticates with ALL root CAs.  Yikes!
N.B., Take additional precautions to secure your VPN:  http://www.stevenjordan.net/2016/09/harden-rras-ikev2.html.

Solution:
There are two ways to fix this serious IKEv2 flaw: 
  • Remove public CAs from the Trusted Root certificate store.
  • Use PowerShell so RRAS only authenticates certificates issued from our private CA.

Certificate Store Solution: 

Use Windows CA or OpenSSL CA servers, etc.  DO NOT use a public CA.  Remove ALL public CAs from the server’s trusted root store.  Turn off automatic certificate updates.  Implement additional authentication safeguards.

Step 1:  Only use private certificates (e.g., Windows CA) –do not use public CAs. 
We won’t cover the entirety of installing a CA in this article.  However, it’s important to understand that the private CA root certificate resides in the Trusted Root certificate store –on both servers and clients.  

Step 2:  Edit Trusted Root Store:
Start → Type MMC → File → Add → Certificates → Local Computer → OK.
  • Backup your system.
     •    Exporting root certificates before you delete them –just to be safe.
     •    Take a system checkpoint if applicable.
  • Certificates to keep:
           •  Microsoft Root Authority 12/31/2020 -required
           •  Thawte Timestamping CA 12/31/2020 -required
           •  Microsoft Root Certificate Authority 5/9/2021 -required
           •  Private Root CA

  • Delete all other certificates in the Trusted Root Store.

Step 3:  Create new GPO that prevents certificate updates.
Edit GPO: 
   → Computer Configuration 
      → Policies  
         → Administrative Templates 
            → System 
               → Internet Communication Management 
                  →Internet Communication Settings 
                     → Turn Off Automatic Root Certificate Updates:  Enabled.  

PS Solution:

Is there a better method?  Until recently, there was no way to assign specific trust chains for IKEv2 client authentication.  The system was simply all or nothing.

Thankfully, Microsoft now provides a solution that fixes this authentication vulnerability.  We can finally configure specific root certificates for authentication purposes.  N.B., This solutions assumes we’re using a private CA for authentication.  Also not, that Microsoft documentation states that this method is only for site-to-site (S2S) VPNs –not true!

Step 1:  Confirm existing VPN authentication settings:  Get-VPNAuthProtocol (Figure 2):

Figure 2.  Confirm IKEv2 authentication with Get-VPNAuthProtocl.
The RootCertificateNameToAccept field should not be empty.  If so, your sever trusts ANY client from ALL Public CAs in the Trusted Root store.  Let’s fix this!

Step 2:  Configure the VPN server so it only authenticates certificates issued from our private CA:
PS C:\Windows\system32> $cert1 = ( Get-ChildItem -Path cert:LocalMachine\root | Where-Object -FilterScript { $_.Subject-Like "*THWATE*" } )

PS C:\Windows\system32> Set-VpnAuthProtocol -RootCertificateNameToAccept $cert1 -PassThru

WARNING: Configuration parameters will be modified after the Remote Access service is restarted.

The above example uses a variable that assigns a root certificate (i.e., issuer) from our Trusted Root store.  It requests a certificate that has “THWATE” in its subject.  This is for demonstration purposes only.  Do not use THWATE in your configuration.

Successful execution always provides output that specifies the associated root certificate (Figure 3):

Figure 3.  Set-VPNAuthProtocol secures our VPN.
Please note, this script does not provide errors if the variable doesn't match a subject a certificate in the Trusted Root store. The Root Certificate field simply remains empty (e.g., Figure 2).
 
Step 3:  Restart the RRAS service.

Additional Thoughts:

Consider additional PowerShell safeguards for certificate authentication:
  • Define the server certificate sent to clients:
    Set-VpnAuthProtocol –CertificateAdvertised
  • Only accept certificates issued for client authentication:
    Set-VpnAuthProtocol –CertificateEKUsToAccept 1.3.6.1.5.5.7.3.2
Consider implementing both certificate and EAP authentication.  This may not be a good fit for all devices because of different types of clients.  However, if every client is Windows 10 we may be better off with SSTP.

Alternately, S2S VPNs can serve as a work-around for this public CA free-for-all.  We can assign specific client authentication certificates to individual S2S interfaces.  The system works but it creates administrative overhead.  I’ll write more about this in a future article.

Finally, it’s OK to implement both solutions:  Remove all public CAs from the Trusted Root Store; and only authenticate clients from our private CA (i.e., PowerShell).

That’s It!

References:

https://social.technet.microsoft.com/Forums/windowsserver/en-US/52bd49e9-8842-42e2-916a-cbb07eddae33/ikev2-machine-certificate-authentication?forum=winserverNIS

https://support.microsoft.com/en-us/kb/293781

https://social.technet.microsoft.com/Forums/windows/en-US/9c90c7bb-af4a-4668-8ce4-852ce734ae8e/turn-off-automatic-root-certificates-update?forum=winserverDS

Transfer SQL TempDB

Task:  

How to transfer the TempDB.

Problem:  

MS SQL ran slow on 6Gb/s SAS hard drive (HHD).  Moved the user database (DB) to PCIe x4 (i.e., 31.52 Gb/s), MLC solid-state (SSD) storage -and it still runs slow!

Solution:  

Does the TempDB run on the old HHD drive or the new MLC SSD?  Consider how the TempDB can generate serious disk I/O.  Transfer the TempDB to the high-speed SSD as well.  N.B., this entire process gave new life to my old DPM2010 server.

  Step 1:  TSQL script to identify TempDB location:


Use master
GO

SELECT 
name AS [LogicalName]
,physical_name AS [Location]
,state_desc AS [Status]
FROM sys.master_files
WHERE database_id = DB_ID(N'tempdb');
GO
   TSQL output:

tempdev C:\Program Files\Microsoft DPM\SQL\MSSQL10.MSDPM2010\MSSQL\DATA\tempdb.mdf
templog C:\Program Files\Microsoft DPM\SQL\MSSQL10.MSDPM2010\MSSQL\DATA\templog.ldf


  Step 2:  TSQL script to move TempDB to new location.

USE master;
GO

ALTER DATABASE tempdb 
MODIFY FILE (NAME = tempdev, FILENAME = 'X:\SQL\Data\tempdb.mdf');
GO

ALTER DATABASE tempdb 
MODIFY FILE (NAME = templog, FILENAME = 'X:\SQL\Data\templog.ldf');
GO

   TSQL output:

The file "tempdev" has been modified in the system catalog. The new path will be used the next time the database is started.
The file "templog" has been modified in the system catalog. The new path will be used the next time the database is started.

  Step 3:  Restart SQL services

  Step 4:  Verify Change - See Step 1.

Conclusion:

SQL server runs quick with new storage.  Disk queue lengths, for all disks, are a thing of the past.  Individual results may vary based on load (duh).

That's It!

References:

http://dbadiaries.com/tempdb-best-practices
http://dbadiaries.com/sql-server-tempdb-whats-it-for
http://www.mytechmantra.com/LearnSQLServer/How-to-Move-TempDB-to-New-Drive-in-SQL-Server/

WIN 10 Secure IKEv2 VPN

How To:

Secure Windows 10 IKEv2 VPNs.  Improve IKEv2 security strength  -the easy way.  Enable hidden support for advanced cryptographic algorithms on Windows clients.

Problem:

The default Windows implementation of IPsec is highly vulnerable to Man-in-the-Middle (MITM) attacks.  It uses depreciated security algorithms and should not be trusted.  DO NOT use IKEv2 or L2TP/IPsec with Windows clients unless it negotiates secure cryptographic algorithms.

Solution:

A simple registry change enables secure IPsec.  This easy fix provides a respectable DH14-AES256-SHA256 negotiation.  Alternately, use PowerShell to enable even stronger security.  Both solutions provide a cryptographic baseline that ensures secure communications.

Background:

The VPN server confirms vulnerable  security:  3DES, SHA1, and DH2 -all bad.  Confirm active MM cryptographic algorithms with PowerShell:


PS C:\Users\stevenuwm> Get-NetIPsecMainMode
 
 Name                                : 51
 LocalEndpoint                       : x.x.x.x
 RemoteEndpoint                      : x.x.x.x
 LocalFirstId.AuthenticationMethod   : Certificate
 CipherAlgorithm                     : AES256
 HashAlgorithm                       : SHA1
 KeyModule                           : IkeV2
 CipherAlgorithm                     : DES3
 HashAlgorithm                       : SHA1
 GroupId                             : DH2
 KeyModule                           : IkeV1

3DES?  SHA1?  DH2?  Good thing we checked!

Security Guidelines:

The Internet Engineering Task Force (IETF) provides guidelines for securing IKEv2. (RFC4307 BIS-13).  These standards are based on key management security strength.  Do not use any cryptographic algorithm with less than 103-bits of security:  http://www.stevenjordan.net/2016/09/ipsec-security-levels.html.

Key Management Tips:

  • DH Group-2 SHOULD NOT be used.
  • Use DH Group-14.    
  • Use RSA-3096 certificates.
  • Use AES128 encryption.
  • SHA1 (Main-Mode) can be used.  SHA256 is a better alternative.
  • Use HMAC-SHA1.  It is not the same thing as SHA1
Theses tips serve as baseline security -a starting point.

Registry Solution:  

Create a registry key that enforces modern cipher and transform sets.

STEP 1:  Edit Registry or create GPO:

HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters\
STEP 2: Create new DWORD value:
NegotiateDH2048_AES256
STEP 3:  Modify DWORD value:

Table 2:  NegotiateDH2048_AES256 Values.
Value IKEv2 Security L2TP\IPsec (i.e., IKEv1)
None MM: IKE-DH2-3DES-SHA1
QM: ESP-3DES-SHA1(HMAC)
MM: IKE-DH2-3DES-SHA1
QM: ESP-3DES-SHA1(HMAC)
0 MM: IKE-DH2-3DES-SHA1
QM: ESP-3DES-SHA1(HMAC)
MM: IKE-DH2-3DES-SHA1
QM: ESP-3DES-SHA1(HMAC)
1 MM: IKE-DH14-AES256- SHA1
QM: AES256-SHA1(HMAC)
MM: DH14-SHA1-AES128
QM: AES128-SHA1
2 M: IKE-DH14-AES256- SHA256
QM: AES256-SHA1(HMAC)
MM: DH14-SHA1-AES128
QM: AES128-SHA1
   Note:  This security target assumes the VPN server supports DH14-AES256-SHA256.
   No value, or value of 0 uses client defaults -weak encryption and hash! 
   VPN client security MUST be set to maximum strength encryption in it property settings. 

   Example:

   Registry sub-key:
  HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters\
   Registry entry:
  NegotiateDH2048_AES256 Data Type:  Reg_DWORD
  
Value:  2

Windows VPN Server:

IPsec requires common cryptographic algorithms.  Windows 2012 IPsec is every bit as insecure as Windows 10.  Therefore we'll need to make adjustments to the server as well.

The above registry fix is recommended for Windows clients.  However it can work with Windows 2012 RRAS VPN server -with one catch.  It does improve security strength for DH and encryption, It does not improve the security strength for the hashing:

     DH14-AES128-SHA1.

This registry change meets the bare-minimum IETF recommendations for IKEv2.  It's better than before -but we can do better.

Should we trust SHA1?  It's probably OK for now.  On the other hand, Google Chrome and Microsoft IE no longer support certificates that use SHA1.  Weak hashes (e.g., SHA1) are vulnerable to sophisticated off-line attacks  In other words, an attacker can steal your identity! (Entrust 2014).

We're not talking about credit scores.  We're talking about digital identity and authentication.  Fake RSA signatures that authenticate to the VPN, email, etc.  Yikes!

Why risk SHA1 when we can easily implement SHA256?  There are other simple (yet hard to find) methods that improve IKEv2 security strength  on Windows servers.  We can do better:  http://www.stevenjordan.net/2016/09/harden-rras-ikev2.html

PowerShell

The Windows 10 registry fix is the path of least resistance.   However, PowerShell supports a wider range of cryptography algorithms.  N.B., These IPsec configurations are not available from the Windows GUI or registry.

Step 1:  Configure new IKEv2 VPN.

Create the new VPN connection with PowerShell.  Do not create the VPN connection with the GUI.
However, it's OK to use the GUI to edit authentication attributes after PowerShell creates the connection .

Add-VpnConnection -Name "IKEv2-VPN" -ServerAddress "vpn.stevenjordan.net" -TunnelType IKEv2 -AuthenticationMethod MachineCertificate

Step 2:  Configure an acceptable level of cryptography.

Set-VpnConnectionIPsecConfiguration -ConnectionName "IKE-SMJ" -AuthenticationTransformConstants None -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup Group14 -PfsGroup None -PassThru -AllUserConnection

AuthenticationTransformConstants : None

CipherTransformConstants         : AES256

DHGroup                          : Group14

IntegrityCheckMethod             : SHA256

PfsGroup                         : None

EncryptionMethod                 : AES256

PfsGroup                         : None

Additional Thoughts:

Why does Microsoft cripple IPsec VPN security by default?  Is it support for legacy devices?  Are there more nefarious reasons (e.g., Eric Snowden)?  Does it nudge folks away from IPsec toward SSTP?  If so it's as good of a reason as any!  In fact, I recommend SSTP for most situations.  The only problem with SSTP is that it's limited to Windows and Android clients.  Direct Access is another great VPN solution (that incorporates Windows IPsec).  

Conclusion:

In the end, NegotiateDH20148_AES256, is a Band-Aid for its default (i.e., broken) Windows IKEv2 VPN.   It provides bare-minimum IPsec security strength that should already be enabled by default. The registry fix may not be the best option but it's quick and it's easy.

On the other hand, Windows 10 supports stronger IKEv2 security strength via PowerShell commands.  By default, Windows IPsec VPN is not secure -it should not be trusted.  However, these VPNs can provide excellent security with a few simple changes.

That's it!

References:

http://www.stevenjordan.net/2016/09/harden-rras-ikev2.html
http://www.stevenjordan.net/2016/09/harden-rras-ikev2.html
Microsoft Windows 8 Windows Server 2-12 Supplemental Admin Guidance IPsec VPN Clien.docx. https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-00
http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-3
https://technet.microsoft.com/en-us/library/jj613766(v=ws.11).aspx
https://technet.microsoft.com/library/9e500d0b-ad09-463e-a5b7-e2986476bc58(v=wps.630).aspx
https://technet.microsoft.com/en-us/library/dn262642(v=wps.630).aspx