IKEv2 Mobile-Config Script


Manually create and edit a mobile-config script for iPhone IKEv2 VPNs.  


  • Script with a common XML editor -no need for Apple Configurator.
  • Use secure cryptography algorithms.
  • Include all certificates for mutual authentication:  User certificate and private key, VPN server certificate, and trusted root certificate.


  1. Preparation:  Encode certificates (e.g., PFX and CER) with Base64:
  2. Copy the mobile-config script (below) to an XML editor -I personally recommend Notepad+
  3. Edit the mobile-config script.  Remove certificate payloads and replace them with output generated from Step 1.
    (a) User certificate and private key:  Lines 24 - 64.
    (b) VPN server certificate:  Lines 165 - 205.
    (c) Private root certificate:  Lines 225 - 245. 
  4. Change addition text fields to match your organization:
    (a) Consent:  Lines 9 - 10.
    (b) PFX Password:  Line 19.
    (c) PFX file name:  Line 21.
    (d) PFX Payload Display Name:  Line 69.
    (e) IKEv2 Local Identifier String:  Line 117.  N.B., This string must be the same as the user certificate's DNS name listed under in its subject alternative name.
    (f) Remote address (i.e., VPN FQDN):  Line 123.
    (g) Remote identifier (i.e., VPN FQDN):  Line 125.
    (h) Server certificate issuer (i.e., CA):  Line 127.
    (i)  User Defined VPN Name (optional):  Line 156.
    (j)  Server payload display name (e.g., VPN FQDN):  Line 210.
    (k) Root certificate file name (i.e., CER):  Line 222.
    (l)  Root CA payload display name:  Line 250.
    (m)  iPhone profile description:  Line 262.
    (n)  iPhone profile payload display name:  Line 264
    (o) iPhone profile payload identifier (change prefix):  266
    (q) iPhone profile organization name:  268
  5. Save file as:  File_Name.mobileconfig
  6. Distribute.
Please note, this mobile-config contains the user certificate and private key.  Ensure document is deleted from all sources after device configuration is complete.  

Door Wide Open on Win IKEv2

Fix for Windows VPN Certificate Authentication Vulnerability


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:

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
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!


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.


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.


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.


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:

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:

STEP 2: Create new DWORD value:
STEP 3:  Modify DWORD value:

Table 2:  NegotiateDH2048_AES256 Values.
Value IKEv2 Security L2TP\IPsec (i.e., IKEv1)
1 MM: IKE-DH14-AES256- SHA1
MM: DH14-SHA1-AES128
2 M: IKE-DH14-AES256- SHA256
MM: DH14-SHA1-AES128
   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. 


   Registry sub-key:
   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:


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:


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 "" -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).  


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!

Microsoft Windows 8 Windows Server 2-12 Supplemental Admin Guidance IPsec VPN Clien.docx.

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.


Windows RRAS server negotiates insecure IKEv2 and L2TP/IPsec cryptographic algorithms:

  • DH2-3DES-SHA1.   
Weak security strength risks data integrity and confidentiality.  IKE SA authenticates with RSA certificates.

This problem impacts all RRAS VPN clients:  Windows 10 phones, iPhones, Android, Cisco, Juniper and Sawn.  


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:


Step 2:  Create new key:


Step 3:  Create new DWORDs (Table 1):

Table 1
IKEv2CustomPolicy DWORD Attributes

IntegrityMethod1Integrity check algorithm to be negotiated during MM SA negotiation [RFC4306].
EncryptionMethod4Encryption algorithm to be negotiated during MM SA negotiation [RFC4306].
CIPHER_AES_128 (0x2)
CIPHER_AES_256 (0x4)
CipherTransformConstant5Encryption algorithm to be negotiated during QM SA negotiation [RFC4306].
AuthTransformConstant1Specifies the hash algorithm to be negotiated during QM SA negotiation [RFC4306].
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.
DHGroup3Type 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
PfsGroup0Diffie-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:

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 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!  


IPsec Security Levels

What are security bits?

VPN Problem:  

What is the most secure VPN cryptographic algorithm?   What is the best-practice for choosing IPsec security strength?


Use Key Management methodology to determine IPsec security strength.

Key Management

The National Institute of Standards and Technology (NIST) publishes up-to-date guidance for choosing appropriate VPN ciphers.  It uses Key Management methodology to rate the effectiveness of different cryptographic algorithms.

Security Strength 

Security strength is a Key Management assessment that estimates the effectiveness of cryptographic algorithms against known attacks over time.  New or improved attacks may affect these equivalencies in the future.

Security strength uses bits-of-security to represent cipher strength.  Security-bits are not the same thing as key-length bits.  For example, a 1024-bit RSA certificate provides 80-bits of security.

In addition, different security algorithms may share common security strength levels (Table 1).  It's best practice to match similar security strength when working with different sets of cryptography algorithms (e.g., transfer-sets and cipher-sets).  Consider, one depreciated algorithm can compromise the entire security target.

IPsec Cipher Assessment

Use Key Management security strength assessments to implement secure IKEv2 and L2TP/IPsec VPN.  Consider how security-bits represents cipher strength:

  • 89 security-bits are vulnerable to known attacks.
  • 103 security-bits are not vulnerable to known attacks -for now.  Status forecast to depreciate in the near-future (may be months or years).
  • 128 security-bits are not vulnerable to known attacks.  Status forecast remains secure for near-future.
  • 192 security-bits are not vulnerable to known attacks.  Status forecast remains secure for long-term future (years).
Cisco dubs 192-bit security as Next Generation (NG).  NG security strength includes DH-19 that uses 256-bit key with elliptic-curve algorithms.  It provides a 1024-bit key exchange and does not require intensive hardware resources -wow!

Table 1
VPN Security Strength 

Security Strength DH RSA IKE Encryption IKE Hash ESP Encryption ESP HMAC Hash Assessment***
80-bit 5 1024 AES-128 SHA1 AES-128 SHA1 Bad
89-bit 5 2048 AES-128 SHA1
AES-128 SHA1
103-bit 14 2048 AES-128 SHA1
AES-128 SHA1
128-bit 15 3072 AES-128 SHA256
AES-128 SHA1
192-bit* 16 4096** AES-256 SHA256**
AES-256 SHA1

Note:  DH-EC not included in this table -for simplicity.  DH-EC provides for a 1024 or 7068 security bit key exchange.
*192-bit security level requires 7680-bit RSA. Some systems do not support 7680-bit RSA.
 **Security level mismatch. 4096-RSA security-strength is 140-bit (i.e., not 192-bit). This mismatch impacts all security levels.
***The assessment column is not official NIST Key Management.  It is this author's independent qualitative interpretation derived from NIST Key Management.

Table 2
Diffie-Hellmand (DH) Security Strength Levels.

DH Group DH Key Security Strength
(i.e., Bits of Security)
DH5 1536 bits 89 bits
DH14 2048 bits 103 bits
DH15 3072-bit 128 bits
DH16 4096 bit 192 bits
DH19 (ECP) 256-bit (ECP) 1024
DH20 (ECP) 384-bit ECP 7680

Table 3
Encryption Security Strength Levels

AES AES Key Security Strength
(i.e., Bits of Security)
AES-128 128 128
AES-256 256 256

Table 4
RSA Security Strength

Certificate RSA Key Symmetric Key
RSA 1024-bit 80-bit
RSA 2048-bit 112-bit
RSA 3072-bit 128-bit
RSA 4096-bit 140-bits*
RSA 15360 -bit* 256-bit**

 *No formal recommendation for Symmetric key.
RSA 4096 offers marginal 28bit increase for symmetric key.
**15360 is not usable. Therefore, use RSA 3072-bit key.

Table 5
Hash Security Strength

Hash Hash-only HMAC Security Strength
(i.e., Bits of Security)
SHA SHA512 SHA-256

Note: Hash security level determined by algorithm,
scheme or application and by the minimum security-strength provided.

That's it!


NLA Default Location

How to set the default location for NLA.


 Users do not have Internet access after connecting to wireless networks. Network Location Awareness (NLA) appears to hang on identifying network.

Additionally, defining the default location is important because it directly impacts firewall rules. It’s not prudent policy to open client ports on an untrusted hotspot.


 Use Group Policy to pre-define the default network location for unidentified AND identifying networks.
GPO: Computer Configuration → Policies →Windows Settings → Security Settings →Network List Manager Policies → (a) Unidentified Networks and (b) Identifying Networks.

Network Name:  

Choose either the Private or Public network: 

  • Outbound:  Most outbound traffic permitted.
  • Inbound:  Unsolicited SMB (e.g., file and print sharing). 

  • Outbound:  Most outbound traffic permitted.  No SMB traffic permitted.
  • Inbound:  No unsolicited traffic permitted.
N.B., Err on the side of caution.  Consider, do we really want unidentified networks to permit unsolicited traffic?  The Private network location invites common SMB replay attacks that steal credentials.  Further adjust client firewall rules to align with your organization’s security policies.

That’s It!

How to Disable RTF in Office


Microsoft Office is vulnerable to memory corruption vulnerabilities.  Malicious emails, sent in rich text format (RTF), can provide attackers remote code execution (RCE).  In other words, RTF emails are not safe!


Common vulnerability and exposure (CVE) CVE-2016-0127 impacts Office 2007, Office 2010, and Office 2013.


  1. Run Windows Updates on a regular basis.    
  2. Enable Microsoft Office File Block Policy to block RTF documents.

Disable RTF in Office 2007:  


  • RtfFiles DWORDvalue: 1

Disable RTF in Office 2010:  

  • RtfFiles DWORD: 2
  • OpenInProtectedView DWORD:  0

Disable RTF in Office 2013: 

  • RtfFiles DWORD: 2
  • OpenInProtectedView DWORD:  0
That's It!


How To Enable Startup PIN for BitLocker

Summary:  How to enable Bit-Locker PIN for pre-authentication prompt.

Problem:  BitLocker encryption protects offline data.  Windows uses an encryption key stored in the TPM.  Therefore, the computer is vulnerable to authentication bypass compromises after Windows starts.  Data only remains fully encrypted (i.e., secure) before the operating system starts.

The BitLocker PIN is an optional security feature.  The computer will not load (i.e., boot into) Windows without PIN authentication.

Solution:  Enable and enforce the Bit-Locker startup PIN.


Use Group Policy Management or Local Group Policy Editor:

Computer Config > Administrative Templates > BitLocker Drive Encryption > Operating System Drives

Policy Settings:

     Allow enhanced PINs for startup:

     Settings for computers with a TPM:
       --Configure TPM startup:  Allow TPM
       --Configure TPM startup PIN:  Require PIN with TPM
       --Configure TPM startup key:  Allow startup key with TPM
       --Configure TPM startup key and PIN:  Allow startup key and PIN with TPM

N.B., the enhanced PINs provide support for alphabetical and special character use.  This can make the PIN strength stronger and easier to remember.  

Configure Client:

Run the following command with Administrative privileges:
manage-bde -protectors -add c: -TPMAndPIN
That's it!


Prevent Rouge Access Points: Wireless IDS/ IPS

Wireless Threat Detection and Countermeasures:  Monitor and Protect Your Wireless Access Points.

Takeaway:  Automated countermeasures discover, attack, and disable rouge Wi-Fi devices! This article explores Wireless Access Controllers, Intrusion Detection Systems (IDS), and Intrusion Prevention Systems (IPS).   These instructions explain how to enable countermeasures for Juniper Wireless Controllers (WLCs).  Cisco, Aruba, and other controllers offer similar mitigation.  

Problem:  Corporate networks are vulnerable to rouge wireless technology.  Wireless access points (WAPs), wireless routers, and wireless bridges can extend the corporate network and provide an insecure entry point.  Untrusted wireless technology risks data integrity and confidentiality.

Internal and External Rouge Wireless Threats.

Threats:  Internal threats include unapproved wireless devices that extends or bridges the corporate network.  For example, an employee may install a residential WiFi router to provide network access to their smartphone.  Their intent may not be malicious but it nonetheless exposes the network to compromise.

Hackers or wireless devices in proximity to corporate access points are external threats.  External threats can intercept and harm company data.  Additional threats can entirely disrupt wireless communication (Table 1).  

Enable Countermeasures:  The WLC includes countermeasures that attack rouge devices.  These countermeasures consist of packets that disrupt client communications to rouge devices.   Rouge devices are rendered useless once the WLA initiates an attack.  WLC countermeasures are disabled by default.  Enable countermeasures on all rouge devices:

LocalWLC#set radio-profile default countermeasures rogue
Alternately, enable countermeasures on all rouge and interfering devices:

LocalWLC#set radio-profile default countermeasures all

Enable ad-hoc countermeasures if desired:

LocalWLC#set rfdetect classification ad-hoc rogue 

Configure SSID list to whitelist existing SSIDs:

LocalWLC#set rfdetect ssid-list BIZ_SSID
Enable log messages to display on console:

LocalWLC#set rfdetect log enable
N.B., Interfering devices may include neighboring APs using the same radio channels.  The WLC includes RF Auto-Tuning that changes WLA channels as needed.  Consider rouge-only countermeasures when located near other businesses. 

Rouge Classifications:  The WLC identifies all nearby 802.11 wireless devices.  It uses a classification system to detect rouge devices: 

LocalWLC# sh rfdetect classification
Rule      Rules for RF Classification             Classification
----     ---------------------------              --------------
N      1. If AP in Rogue list ....................... ROGUE
N      2. If AP is part of Mobility Domain .......... MEMBER
N      3. If AP in Neighbor list .................... NEIGHBOR -------------------------------------------------------------------
Y      4. If AP is Masquerading our SSID ............ ROGUE
Y      5. Client or Client DST MAC seen in network .. ROGUE
Y      6. If AP is acting as an Ad-hoc device ....... SKIP-TEST -------------------------------------------------------------------
N      7. If SSID is in SSID list ................... NEIGHBOR -------------------------------------------------------------------
Y      8. Default Classification .................... SUSPECT

Rouge List:  The WLC attacks all devices in the Rouge list.  The WLA does not transmit client traffic while it attacks rouge devices.  WLAs can be provisioned in Sentry mode for dedicated scanning and attacking purposes.

Suspect List:  Devices in the Suspect list are considered potential Rouges.  The WLC does not attack suspect devices unless they become a threat.  In most circumstances, suspect devices are neighbor APs which have not been manually added to the Neighbor list.

Neighbor List:  The Neighbor list acts as a whitelist.  The WLC does not attack its neighbors.  Be a good Samaritan and add your neighbors' APs to the Neighbor list.  The Juniper WLC GUI makes identifying and adding neighbors a cinch.

Juniper WLC GUI:  RF Neighbors

 Countermeasures in Action:  What happens if an employee connects a wireless AP to the corporate network?  For this example, assume the switch access ports are not configured for 802.1X authentication or BPDU Guard.

1.  Employee discretely connects a Linksys wireless router to the network. 
Employee adds unapproved wireless access point to company network.

2.  The Linksys router connects to the company network and advertises its SSID:

3.  The Linksys SSID remains in the Suspect list as long as clients are not connected it.
4.  The employee connects their laptop to the Linksys SSID.  The WLC immediately identifies the Linksys AP as a rouge device:

ROGUE Sep 24 11:11:26.009242 NOTICE ROGUE_AP_ALERT: Client Mac 88:XX:XX:XX:XX:XX(Rogue AP Mac 00:XX:XX:XX:XX:XX) is seen on the wired network by Switch on port X vlan X tag 0. Detected by listener a8:XX:XX:XX:XX:XX(AP 1, radio 1), channel 6 with RSSI -55 SSID "linksys".
5.  The WLC begins its countermeasure attack:

ROGUE Sep 24 11:12:35.065652 NOTICE ROGUE_AP_ALERT: COUNTERMEASURES STARTED for Xmtr Mac 00:XX:XX:XX:XX:XX Performer Mac a8:XX:XX:XX:XX:XX SW-I Paddr AP 1 Radio 1 Channel 6
6.  Confirm countermeasures:

WLC# sh rfdetect countermeasures Total number of entries:1
          Type(Adhoc/Infra) Countermeasures                        Port/Radio
Rogue MAC         /Class    Radio Mac        RSSI MX IPaddr        /Channel ----------------- -------- ----------------- ---- --------------- ------------ 00:XX:XX:XX:XX:XX I/rogue  a8:XX:XX:XX:XX:XX -59       AP 1/1/6

WLC Detected a Rouge SSID
Conclusion:  Tests confirm wireless clients cannot connect to rouge SSIDs when WLC countermeasures are enabled.  Interestingly, the WLC countermeasures are similar to those available on some WiFi hacking tools.  These countermeasures compliment existing mitigation strategies;  Enterprise WPA2, 802.1X authentication;  BYOD Policy, client and server certificate authentication; disabling client auto-connect; Windows IPSec, etc... 

Table 1. Wireless Threats and Mitigation.
Type of Attack

RF Jamming
DoS - Flooding
Overwhelms WLAN with high-power noise.
WLA detects excessive interference on a channel.  WLC Auto-Tuning changes the radio to a different channel.

De-authenticate frames
DoS Precursor to Identity Spoofing
Basis for man-in-the-middle attacks.  Spoofing changes source MAC so frames appear to come from a legitimate AP.

WLA checks packets for the source MAC address. 

Broadcast De-authenticate Frames
DoS Precursor to Identity Spoofing
Spoofs de-authenticate frames to disconnect all clients attached to an AP.
WLA checks for de-authenticate broadcast frames.

Disassociation frames
DoS Precursor to Identity Spoofing
Disassociation frames from an AP instructs clients to end their association to AP.

WLA checks for  disassociation frames

Null probe response
Rogue devices send probe response with null SSID.  NICs can lock up upon null probe responses.

WLA checks for Null probe responses.

Decrypt Errors
 Identity Spoofing
Rogue device pretends to be a legitimate device by spoofing the MAC address.
WLA checks for excessive number of decrypt errors.  This indicates multiple clients are using the same MAC address.

Fake APs
Rouge device sends beacon frames for excessive SSIDs or BSSIDs.  Clients cannot connect to valid Aps.

WLA check for excessive beacon frames.

Fake SSIDs
 Identity Spoofing -MITM
Rouge device pretends to be a legitimate SSID in your network.  Clients associate with rouge SSID.

WLA checks for APs masquerading as company SSID.

Spoofed WAPs
 Identity Spoofing -MITM
Rouge device pretends to be legitimate AP by changing its MAC source address.
WLC detects spoofed AP attacks based on AP fingerprint.  WLA signatures must be enabled to detect AP spoofing.

Netstumbler and Wellenreiter
Hacker applications gather information about APs, location, manufacturer, and encryption.

WLC syslog warnings identify Netstumbler and Wellenreiter.

Wireless Bridge
Identity Spoofing
Extends network to personal or rouge devices.
 WLA identifies internal wireless bridges.

Ad-Hoc Networks
Identity Spoofing
Client Wireless NICs extend network to personal or rouge devices.

 WLA identifies internal Ad-Hoc Networks.

Weak WEP Keys
Brute Force Vulnerability
Network systems vulnerable to attacks.
WLC syslog warnings identify clients using weak WEP. 

 Note:  IDS console messaging and SNMP alerts are additional mitigation features.  WLAs are configured to actively scan for threats (i.e. Active Scan) by default.

Table 2.  Rouge Determination

Wireless AP, bridge, or ad-hoc Network

Does the device have a known MAC address from the wired network?

Does the destination header contain a known MAC from the wire network?

Does the SSID belong to the SSID list?

Is the device use a Juniper transmitter?

Does the client or AP MAC address on the blacklist?

Does the client or AP MAC address belong to the Rouge list?

Does the client or AP MAC address belong to the Neighbor list?

References:  Juniper Mobility System  Software Configuration Guide