T-Shoot Yubikey Minidriver

Problem:  

RDP fails to authenticate Yubikey smart card.

Error:  

The requested key container does not exist on the smart card (Figure 1).

Figure 1.  Smart card container error.

Assumptions:

• Yubikey runs as PIV smart card.
• Smart card has multiple authentication certificates.
• Certificates reside on slots 81-95.

Solution:

Important:

Figure 2.  How to Install the Yubikey Minidriver.

Task:  

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.

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!

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

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

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.   

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.  

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):

VPN Problem:  

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

Solution:

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

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 SHA256	AES-128	SHA1 SHA256	Bad
103-bit	14	2048	AES-128	SHA1 SHA256	AES-128	SHA1 SHA256	Good
128-bit	15	3072	AES-128	SHA256 SHA384	AES-128	SHA1 SHA256	Better
192-bit*	16	4096**	AES-256	SHA256** SHA384	AES-256	SHA1 SHA256**	Best
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	SHA-1 SHA-256 SHA-512	SHA-1 SHA-256 SHA-512	80
SHA	SHA256 SHA384 SHA256	SHA-1 SHA-256 SHA-512	112
SHA	SHA256 SHA384 SHA256	SHA-1 SHA256 SHA-512	128
SHA	SHA-384 SHA-512	SHA-256 SHA-384 SHA-512	192
SHA	SHA512	SHA-256 SHA-384 SHA-512	SHA256
Note: Hash security level determined by algorithm, scheme or application and by the minimum security-strength provided.

That's it!


References:
https://www.nist.gov/
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
http://infosecurity.ch/20100926/not-every-elliptic-curve-is-the-same-trough-on-ecc-security/
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf

How to set the default location for NLA.

Problem: 

 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.

 Solution: 

 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:  

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

Problem:

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!

Versions:  

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

Solution:  

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

Disable RTF in Office 2007:  

Disable RTF in Office 2010:  

Summary:  

How to configure Bit-Locker and enable PIN for pre-authentication prompt.

Problem:  

Bit-locker encryption protects data-at-rest (i.e., offline data).  It protects data with an encryption key that is stored in the TPM.  This private key cannot be exported so its encrypted data should be secure from physical theft.  Why then, do we need a pin?

Recall, BitLocker only protects data-at-rest.  The hard dive is only encrypted before the operating system starts -not after.  This caveat makes data vulnerable to authentication bypass attacks. 

The BitLocker PIN is an optional security feature.  The computer will not load Windows without PIN authentication.  You data remains secure.

Solution:  

Enable and enforce the Bit-Locker startup PIN.

Instructions:

Start by enabling BitLocker from Control Panel.  If this step is skipped you may receive the following error:

     "The group policy settings for bitlocker are in conflict and cannot be applied."

Next, open the Group Policy Management or Local Group Policy Editor:

     

BitLocker Drive Policy:

Computer Config; 

         Administrative Templates;

            BitLocker Drive Encryption;

Drive encryption and cipher strength:

       -Enabled:  

         --OS:      XTS-AES 256-bit

         --Fixed:  XTS-AES 256-bit 

         --USB:   AES-CBC 256-bit

Disable new DMA devices when computer is locked:

-Enabled:  This prevents rouge devices from pawning your locked PC. 

    E.g., https://forums.hak5.org/topic/29621-question-rubber-ducky-and-the-windows-lock-screen/

Prevent memory overwrite on restart

  -Enabled:  Protect your device from cold boot attacks. 
                        Wipe those BitLocker secrets from memory during a restart.  

                         E.g., https://citp.princeton.edu/research/memory

BitLocker OS Settings:

Computer Config; 
         Administrative Templates;
            BitLocker Drive Encryption;
               Operating System Drives:

  Allow enhanced PINs for startup:
       --Enabled

  Require additional authentication at startup:
       --Configure TPM startup:  Allow TPM
       --Configure TPM startup PIN:  Require Allow 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

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

Also note, additional authentication requirements are all set to allow, rather than require.  This helps avoid BitLocker errors, on new devices, after this group policy has been applied.  Keep in mind, the UAC protects BitLocker from undesired changes.  Therefore, avoid Administrator interactive logons.

Configure Client:

Run the following command with Administrative privileges:

   manage-bde -protectors -add c: -TPMAndPIN

Note:  Windows 10 version 1903 no longer requires command line configuration.  Instead, Windows provides an option to enable BitLocker PIN from the initialization wizard -cool beans!

That's it!

References:

http://ctogonewild.com/2009/08/28/10-things-you-dont-want-to-know-about-bitlocker/
http://www.pcworld.com/article/3005182/encryption/bitlocker-encryption-can-be-defeated-with-trivial-windows-authentication-bypass.html
https://technet.microsoft.com/en-us/library/jj649837(v=wps.630).aspx
https://technet.microsoft.com/en-us/library/cc766295(v=ws.10).aspx#BKMK_S5

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
User
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 172.16.1.2 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 172.16.1.2 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  172.16.1.2       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.

Threat	Type of Attack	Purpose	Mitigation
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	DoS	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	DoS	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	Reconnaissance	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	Yes	No
Does the device have a known MAC address from the wired network?	Rouge	Suspect
Does the destination header contain a known MAC from the wire network?	Rouge	Suspect
Does the SSID belong to the SSID list?	Member	Rouge
Is the device use a Juniper transmitter?	Suspect	Rouge
Does the client or AP MAC address on the blacklist?	Rouge	Suspect
Does the client or AP MAC address belong to the Rouge list?	Rouge	Suspect
Does the client or AP MAC address belong to the Neighbor list?	Neighbor	Suspect

References:  Juniper Mobility System  Software Configuration Guide