Wireless LAN Security Assessments Steps

After deploying a wireless LAN, you need to implement a security assessment, which ensures that the WLAN complies with effective security policies. For most situations, this is necessary whether or not the network implements effective security mechanisms. Don't put too much trust in the design of a system. It's best to run tests to be certain that the network is hardened enough to guard against unauthorized persons attacking company resources.

In fact companies should conduct regular, periodic security reviews to ensure that changes to the WLAN don't make the system vulnerable to hackers. A review once each year may suffice for low risk networks, but a review each quarter or more often may be necessary if the network supports high risk information (e.g., financial data, postal mail routing, manufacturing control functions, etc.).

When performing a wireless LAN security assessment, consider completing the following steps:

1. Review existing security policies. Before getting too far with the security assessment, become familiar with the policies that the company has regarding wireless LAN security. This provides a benchmark for determining whether or not a company is complying with their own policies. In addition, you'll be able to make an assessment and corresponding recommendations for policy modifications. Determine whether the policy leaves any room for a hacker (e.g., a disgruntled employee) to access or harm company resources. For example, the policy should describe adequate encryption and authentication mechanisms, keeping in mind that 802.11 WEP <DEFINE: WEP> is broken. Also, the policy should mandate that all employees coordinate with the company's information systems organization before purchasing or installing access points. It's very important that all access points have configuration settings that comply with the policies and provide the proper level of security. In addition, you need to ensure that methods are in place that disseminates security policies to employees in an effective manner.
2. Review the system architecture and configurations. Meet with information systems personnel and read through related documentation to gain an understanding of the system's architecture and configurations of access points. You'll need this to determine whether there are any design flaws that provide weaknesses that could allow a hacker inside the system. For example if static WEP is in use, then a hacker could utilize tools such as AirSnort to break through the encryption process. In addition, the dependence on 802.11 authentications alone will only verify the radio NIC and not the user, which could allow an unauthorized person to steal someone's wireless-equipped laptop and access the corporate network.
3. Review operational support tools and procedures. Some security weaknesses materialize when a company supports a WLAN. As a result, learn as much as possible about existing support tools and procedures to spot potential issues. Most companies, for example, configure the access points over the wired Ethernet backbone. With this process, the passwords sent to open a connection with a particular access points is sent in the clear (i.e., unencrypted) over the wired network. As a result, a hacker with monitoring equipment hooked to the Ethernet network can likely capture the passwords and reconfigure the access point.
4. Interview users. Be sure to talk with a sample of employees to determine whether they are aware of the security policies, at least to a level of security that they can control. For example, do the users know that they must coordinate the purchase and installation of wireless LAN components with the appropriate organization? Even thought the policy states this, don't count on everyone having knowledge of the policy. A new employee or someone who hasn't seen the policy may purchase an access point from a local office supply store and install it on the corporate network (without any security settings enabled) to provide wireless connectivity within their office. It's also a good idea to verify that people are using personal firewalls (or that they know they should).
5. Verify configurations of wireless devices. A portion of the security policy should define appropriate access point configurations that will offer an applicable level of security. As part of the assessment, walk through the facilities having access points and use tools such as AirMagnet or AiroPeek to capture the access point configurations. If the company has centralized support software (such as AirWave or CiscoWorks) in place, then you should be able to view the configuration settings from a single console attached to the wired side of the network. This is to determine which security mechanisms are actually in use and whether or not they comply with effective policies. For example, the policies may state that access points must disable the physical console port, but while testing you determine that most access points have the ports enabled. Of course this would indicate non-compliance with the policies, and it would enable a hacker to possibly reset the access point to factory default settings with no security enabled. In addition, look at the firmware version of each access point to see if it's up-to-date. Older firmware versions might not implement the more recent patches that fix encryption vulnerabilities.
6. Investigate physical installations of access points. As you walk through the facilities, investigate the installation of access points by noting their physical accessibility, antenna type and orientation, and radio wave propagation into portions of the facility that don't have physical security controls. The access points should be mounted in a position that would make it difficult for someone to go unnoticed and physically handle the access point. An access point simply placed on top of book shelf, for example, would make it easy for a hacker to swap the access point with an open one that doesn't have any security enabled. Or, the hacker could attach a laptop to the console port to reset the access point. If the access points are all mounted above the ceiling tiles and out of plain view, however, someone would need to use a ladder and would probably be noticed by an employee or security guard.
7. Identify rogue access points. A problem that's difficult to enforce and significantly undercuts the security of the wireless LAN is when an employee installs a "personal" access point in their office. Most of the time, these installations don't comply with security policies and result in an open, non-secure entry port to the corporate network. In fact, a hacker can utilize sniffing tools to alert them when such an opportunity exists. As a result, scan for these unauthorized access points as part of the assessment. Most companies will be surprised to learn how many they'll find. The most effective method for detecting rogue access points is to walk through the facilities with sniffing tools, such as AirMagnet or AiroPeek. In addition, the company should periodically scan the network for potential rogue access points from the wired side of the network.
8. Perform penetration tests. In addition to hunting for rogue access points, try going a step further and attempt to access corporate resources using tools common tools available to hackers. For instance, can you utilize AirSnort to crack through WEP? Is it possible to associate with an access point from outside the company's controlled perimeter? Of course if WEP is turned off, then your job will be easy. If strong encryption and authentication techniques are in use, then you'll likely not find a way in.
9. Analyze security gaps. The information you gather during the assessment provides a basis for understanding the security posture of a company or organization. After collecting information in the above steps, spend some time thinking about potential gaps in security. This includes issues with policy, network architecture, operational support, and other items that weaken security, such as presence of unauthorized access points and abilities to penetrate the network. This requires you to think like a hacker and uncover any and all methods that make it easier for someone to penetrate and access (or control) company resources through the wireless LAN.
10. Recommend improvements. As you spot weaknesses in the security of the wireless LAN, research and describe methods that will counter the issues. Start by recommending improvements to the policies, which dictate what the company requires in terms of security for the wireless LANs. This provides a basis for defining technical and procedural solutions that will strengthen the security of the system to a level that protects the company's interests.

With these steps in mind, you're on the right tract to performing a wireless LAN security assessment.

Wireless LAN Security Guide

Security for any organization large or small

Introduction

One of the most common questions that people ask me about Wireless LANs is "are Wireless LANs really safe?" immediately followed up by "what kind of security do I need for my Wireless LAN?" The answer to the first question is "yes, if you implement good security measures" but the second question forces me to resort to the old "it depends". It depends on what level of risk is acceptable to your home or organization. It depends on what level of management and cost you are willing to bear. To simplify this extremely complex topic, I've come up with four arbitrary levels of WLAN (Wireless LAN) security as a general guideline that is designed to suit everyone's needs from the home to the military.

• Level 1: Home and SOHO WLAN security
• Level 2: Small Business WLAN security
• Level 3: Medium to large Enterprise WLAN security
• Level 4: Military grade maximum level WLAN security

Level 1: Home and SOHO WLAN security

Unfortunately, many home users are either using some old equipment, old drivers, or older operating systems that don't natively support WPA so they are still using WEP if anything at all. WEP encryption was thought to be good for a week for most light traffic home wireless networks because the older WEP cracking tools needed 5 to 10 million packets to recover a WEP key, but the newest WEP cracking techniques can break WEP in minutes. Even if there isn't that much traffic, the attacker now has ways to artificially generate traffic and accelerate WEP cracking. Because of this, consumers should avoid any product that doesn't support WPA TKIP mode at a minimum but preferably WPA AES capable or WPA2 certified devices. If they have WEP only devices, check with the vendor to see if there are any firmware and/or driver updates that will upgrade the device to WPA mode. If not, anyone who cares about privacy should throw out those devices. As harsh as that may sound, it is comforting to know that newer Access Points and Client Adapters that do support WPA can be purchased for as little as $30. Client side Wireless LAN software (officially known as Supplicants) also need to be updated to support WPA or WPA2. Windows XP SP1 with the WPA patch can suffice, but Windows XP SP2 is highly recommended.

The home or SOHO (Small Office Home Office) environment is very unlikely to have any kind of Authentication and PKI in place. This may change when TinyPEAP gets launched, but that is currently in BETA phase and is not ready for prime time yet. TinyPEAP puts a PEAP authentication server and PKI Certificate Authority in your home's Wi-Fi enabled Linksys Router which was once the exclusive domain of large organizations with dedicated authentication servers. For the time being, the only viable option for this environment is WPA PSK (Wi-Fi Protected Access Pre-Shared Key) mode. WPA mode mandates TKIP at a minimum but also has an optional AES encryption mode. AES mode is highly recommended because it has a rock solid pedigree in cryptanalytic resistance whereas TKIP may be under attack in the near future. Note that AES in WPA2 (fully ratified version of 802.11i) is no longer optional and is mandated today. Since most home users would be lucky if all of their equipment and software was TKIP capable, most homes will have to be content with TKIP mode for now.

WPA PSK mode can be an effective security mechanism but leaves a lot to be desired in terms of usability. This is because WPA PSK can be cracked with offline dictionary attacks so it relies on a strong random passphrase to be effective. Unfortunately, humans are very bad at memorizing long random strings of characters and will almost always use simple to remember words and phrases or some slight variation of that. This lends itself to dictionary attacks where a hacker will try every variation of every combination of words in the dictionary. To make this very difficult to hack, use a 10 digit string of random characters comprised of a-z, A-Z, 0-9 or use a very long word phrase made up of 20 or more characters. Unfortunately, this will force many users to write down their passphrases which in itself may lead to passphrase theft. WPA PSK is not a good long term security solution and leaves Level 1 security with much to be desired, but it can be safe when used correctly.

Level 2: Small Business WLAN security

Small businesses must move beyond Level 1 by incorporating authentication in to their Wireless LAN access controls. The standardized method for doing this is 802.1x and PEAP or TTLS authentication. 802.1x restricts access to the Datalink layer of a network by only permitting access to the network if a user proves their identity through the EAP (Extensible Authentication Protocol) mechanism. There are many forms of EAP, but the two forms of EAP that is most appropriate for Level 2 security is PEAP (Protected EAP) and TTLS (Tunneled Transport Layer Security). Note that PEAP in the general context refers to PEAP-EAP-MSCHAPv2 mode, which only requires a Server Side Digital Certificate and a Client Side Username/Password. There are stronger forms of PEAP which we'll cover later in the higher security levels. TTLS is actually a little better in security than PEAP-EAP-MSCHAPv2 because it does not divulge the username in clear text. However, both forms of authentication do a good job of protecting passwords because the MSCHAPv2 password challenge session is protected inside an encrypted tunnel. This is why PEAP or TTLS is so much better than Cisco's LEAP mechanism which transmits the MSCHAPv2 session in the clear lending itself to easy offline password dictionary cracking.

To implement PEAP or TTLS, the organization needs to implement a RADIUS Authentication Server. There are many ways to do this no matter what your software preference is. There are options for Microsoft Windows 2003 Server with IAS, 3rd party applications such as Funk Odyssey (needed for TTLS mode) that run on Windows, Open Source solutions with FreeRADIUS. However, in order to run in PEAP or TTLS mode, the RADIUS server must have a server side x.509 digital certificate. This certificate can be purchased from a 3rd party Certificate Authority such as Verisign, or it can be issued from an organization's internal Certificate Authority. These two options are conventional wisdom but neither option is particularly appealing to small businesses since they won't like paying $500/year for a 3rd party Digital Certificate and they most likely don't have a PKI in place which requires a Certificate Authority server. An excellent way to get around this problem is to use a Self Signed Certificate on your RADIUS server. Self Signed Digital Certificates violates all best practice concepts for PKI, but I say be damned with them if the alternative is to use no Digital Certificates at all on your RADIUS server and run a completely vulnerable EAP mechanism such as LEAP. Running a secure EAP mechanism such as PEAP or TTLS is too important to let PKI be an obstacle. A newer protocol from Cisco called EAP-FAST promises to solve this problem by claiming that you don't need PKI and Digital Certificates but if you read the fine print from Cisco, that's clearly not the case. Self Signed Certificates would solve the problem for PEAP, TTLS, or EAP-FAST for organizations too small to run a dedicated PKI Certificate Authority infrastructure.

The easiest method by far if you're a Microsoft Windows 2003 Server shop is to use the built in RADIUS server of Windows 2003 called IAS (Internet Authentication Server). For a small business, there is nothing wrong with adding the IAS service to an existing Windows 2003 server even if it's their only server which also happens to be the Active Directory server. You can, either convert that server in to a Certificate Authority as well and grant yourself a digital certificate for the RADIUS server or simply Self Sign a digital certificate. With this in place, the Root Certificate (the public key of the Digital Certificate) for the RADIUS server must be installed in all of the client's computers. With Active Directory, this can be easily be pushed out via Group Policy. All of the clients also need to configure their wireless settings on the WZC (Wireless Zero Configuration) service built in to Windows XP SP1 or SP2. However, Active Directory allows you to configure this globally for all your users with Active Directory Group Policy. Using the Microsoft method, a secure wireless network can be deployed throughout an organization big or small in hours. If you don't have IAS, it comes with Windows 2003 Standard Edition which costs around $500 per copy. IAS in my experience is extremely robust, reliable, and secure.

For those who wish to implement TTLS, they will need to either purchase Funk Software's Odyssey server (in the $2000 range) or implement FreeRADIUS on Linux which is Open Source. Note that Windows does not have a built in TTLS client built in, you will need to purchase a wireless Supplicant (AKA Client software) for your end users. MDC has an Open Source version for Linux, but you'll need to purchase one for Windows which is what most people are using. You'll either need to implement the Root Certificate on the Clients manually or you'll need to purchase a 3rd party Digital Certificate which has its Root Certificate already preinstalled. As for client side configuration, you'll need to find some other method to automate the installation process since Active Directory does not support the automation of 3rd party clients.

While 802.1x and PEAP or TTLS addresses the authentication half of the equation when it comes to security, encryption must also be addressed. Up until recent months, it was thought that "Dynamic WEP" where WEP keys are rotated often (commonly 10 minutes) was considered to be "good enough" encryption. With the next generation of WEP cryptanalysis tools, this is no longer the case and TKIP is the new bare minimum. The WPA standard implements TKIP which is a rewrite of the WEP protocol which will hold against current cryptanalysis techniques for now, but newer methods of attacking TKIP are on the horizon. The reliable long term solution from the IEEE standards body is the 802.11i standard which mandates AES. The recommendation for Level 2 through 3 is that you should be using WPA with TKIP at a minimum and upgrade to AES as soon as possible. Note that some WPA devices already support AES encryption while all WPA2 certified devices must support AES encryption. To be on the safe side, only buy products that support 802.11i and are WPA2 certified.

From a vulnerability standpoint, the only way to break this security level is to steal a user credential by either looking over someone's shoulders to see what password they are typing, coaxing them in to telling you what the password is (this is easier than you think), or installing a key logger on to a user's computer so you can record their key strokes as they type in the password. Barring password theft, it would be far easier to break in to your premise and tap in to a Wired LAN than to attempt to crack Level 2 Wireless LAN security. Level 2 is a good choice for most small businesses but organizations where security is a high priority should seriously consider the next two levels because a single lost password could compromise the entire system..

Level 3: Medium to large Enterprise WLAN security

Level 3 Wireless LAN security builds on the same principles of Level 2, but you're not allowed to use the "cheats" such as bolting on the RADIUS server on to an existing server or using Self Signed Digital Certificates. PEAP-EAP-MSCHAPv2 is also disallowed because of its sole dependency on passwords which would be classified as "single factor" authentication. EAP-TLS or PEAP-EAP-TLS using "soft" Digital Certificates (certificates that are stored on the user's hard drive) would be the recommended authentication method for this security level. PEAP-EAP-TLS is an improved version of the original EAP-TLS protocol that goes further to encrypt client digital certificate information. Both PEAP-EAP-TLS and EAP-TLS have the same server and client side digital certificate requirements, but PEAP-EAP-TLS may not be compatible with some older Supplicants (Client Software) or some non-Microsoft client side implementations.

To implement EAP-TLS or PEAP-EAP-TLS, not only does the server require a Digital Certificate but the users as well. This means you will need a full blown Certificate Authority to issue a proper Server Digital Certificate on a pair of dedicated RADIUS servers and not just a Self Signed Certificate on a makeshift RADIUS Server. For this security level, the proper PKI best practices should be followed. There should be at least a single dedicated PKI Root Certificate Authority, but preferably it should at least be a 2 or 3 tier PKI design. A two tier chain for a medium Enterprise organization would have an offline Root Certificate Authority and an online Issuing Certificate Authority. A large Enterprise should implement the three tier design with offline Root Certificate Authority, offline subordinate Certificate Authority, and online Issuing Certificate Authority. The reason for this is that if a Certificate Authority is ever compromised, you can revoke it and create a new one from the higher offline Certificate Authorities without having to start your PKI deployment from scratch. Building a PKI from scratch because of a compromised Certificate Authority would be completely unacceptable in a large scale environment.

To deploy Digital Certificates to the user community, a PKI management infrastructure must be deployed and permanent human resources must be allocated to manage end user certificates if your user base numbers in the thousands or more. Medium size Enterprises can add PKI management to their current hire/termination procedure. Microsoft Active Directory with an Enterprise Root Certificate Authority (a PKI that is completely integrated in to an Active Directory) can issue digital certificates automatically, but be warned that this is not a substitute for proper management. Lost or stolen laptops or terminated employees must have their digital certificates revoked and this is not an automatic process even if a user account is disabled or deleted. After the certificates are revoked, they must be published in a CRL (Certificate Revocation List) and be applied to all Authentication servers or else the revoked certificates are still usable. If Active Directory auto-enrollment is used, it is highly recommended that you do not just apply the policy to the entire domain by default so that everyone will automatically get a user digital certificate. The policy should be set on just a particular OU (Organizational Unit) so that users who need user certificates and Wireless LAN access must be manually moved to that Certificate enabled OU. Automatic enrollment should be used as a way to simplify management, not substitute management.

As for encryption, the same requirements and recommendations from the previous 2 levels apply. TKIP at a minimum but AES is recommended as soon as possible. Level 3 organizations should probably be the first to jump to the next level of encryption. The size of these organizations that would select Level 3 wireless LAN security can make upgrading difficult, but it's too important to ignore. The good news is that once AES is achieved, it is expected to hold for some time.

From a vulnerability standpoint, Level 3 is reasonably secure. The only way to compromise this security level is if the hacker can not only steal a user's password, but also steal that user's Digital Certificate which is much more difficult than just stealing a user's password. To steal a "soft" Digital Certificate, either the laptop needs to be stolen in which case it would be obvious and the certificate could be revoked, or a malicious program like a backdoor, virus or worm would have to be installed on the laptop to "harvest" the private key of the digital certificate. The latter option is much more sinister because a theft could occur totally undetected and the certificate would not be revoked. The same malicious code could also "log" the user's keystrokes and the user's password would be compromised as well. At this point, Level 3 security would be totally defeated hence the need for an even stronger solution in Level 4. Discriminating Enterprises should seriously consider the next security level.

Level 4: Military grade maximum level WLAN security

Level 4 builds on Level 3 but aims to solve the key logging certificate stealing malicious code threat. From a PKI Certificate Authority standpoint, not only is a 3 tier architecture required but the use of FIPS 140-2 Level 3 compliant HSMs (Hardware Security Modules AKA Cryptographic Modules for server side applications) are mandated. These modules cost thousands of dollars in the form of a tamper resistant external module. All Certificate Authorities should use one of these modules to ensure maximum security. Even a malicious code compromise on the Root Certificate Authority cannot compromise the Root CA's private key although such a compromise on a Certificate Authority would still be very serious. This is why the top two tiers of the PKI chain are never connected to the network as an extra precaution so that all interactions between the PKI tiers must be hand carried.

On the user side, the Digital Certificate cannot be stored on the hard drive so EAP-TLS or PEAP-EAP-TLS with "hard" tokens are mandatory. The certificates must be stored inside an HSM (these are called Cryptographic Tokens on the client side) which are typically in the form of a USB dongle the size of two fingers carried on a person's key chain or a smartcard. USB dongles are usually much more practical because they can be used by notebooks without a smartcard reader. Some newer Notebook computers have a built in HSM called a TPM (Trusted Platform Module) but it can't be separated from the computer. If an HSM empowered computer is infected with malicious code, the password can be logged and stolen but the digital certificate cannot. This is because the HSM never divulges the private key of the digital certificate to its host computer because all asymmetric cryptographic operations happen inside the HSM and not on its host computer. This makes it nearly impossible to steal a private key unless the TPM Notebook or USB dongle is physically stolen. If that were to occur, it would be fairly obvious and the Digital Certificate stored inside the stolen HSM could be easily revoked by an administrator as part of the PKI management process. To further enhance security, more expensive USB dongles and smartcards have built in finger print readers so that they are useless unless they have your living finger or they can figure out some extremely complex method of fooling the finger print reader. But the biometrics portion is just a last defence meant to buy you enough time to revoke a certificate before unauthorized access is gained. With biometrics enabled HSMs, you have the strongest 3-factor authentication system possible.

From an encryption standpoint, AES is the only encryption algorithm permitted for Level 4 and it also happens to be mandated for federal government and military applications. AES was created by the NIST and its encryption algorithm was selected from a list of finalists that represented the best encryption algorithms in the world. To comply with the AES requirement, 802.11i (AKA WPA2) compliant Wi-Fi gear is required on all Access Points, client Adapters, and software. Most consumer Wi-Fi products sold do not support 802.11i while most newer business class Wi-Fi products do. You'll have be look for the 802.11i or WPA2 logo on any Wi-Fi products you buy. Many organizations may already own products that are AES compliant if they would simply update their firwares and drivers on their Access Points and Client Adapters. Cisco products are a perfect example of this because it is probably the most dominant player in the enterprise Wireless LAN market yet most of their customers are not running the latest firmware. Upgrades on such a large scale are very difficult but corporations cannot afford to put off good security because not only is it good business, it may be the law because of SOX and HIPAA compliance.

From a vulnerability standpoint, Level 4 is rock solid and extremely difficult to compromise. The hacker would have to not only steal a user's password, but also physically steal that user's cryptographic token or a TPM notebook and take advantage of it before the user realizes anything wrong and reports the theft. With 3-factor authentication, it is practically impossible to break in to the Wireless LAN from the wireless side. The attacker will have to try some other means of compromising the network and a crowbar would be far more effective at that point.

Conclusion
Contrary to popular belief, a Wireless LAN can indeed be secure. Depending on the level of risk versus cost trade off you are willing to take, you will need to decide if you need to implement Level 1, 2, 3 or 4. Fortunately, most of the security measures that you need to implement can also serve you in other aspects of IT infrastructure. The same RADIUS, PKI, and Cryptographic Tokens can be used to secure your VPN and Remote Access solution. PKI, Digital Certificates, and Cryptographic Modules are the fundamental building blocks of strong authentication and there is no way around that. You can make the best of it by leveraging the hefty investment for all your security needs.

Wireless Firewall Gateway White Paper

Introduction

With the deployment of wireless network access in the workplace, the requirement for a more enhanced security design emerges. Wireless technology offers a more accessible means of connectivity but does not address the security concerns involved with offering this less restrained service. In order to facilitate management of this network, maintain a secure network model, and keep a high level of usability, a multi-functional device to do these tasks must be placed in the wireless environment.

Design Objectives

The WFG (Wireless Firewall Gateway) is designed to take on several different roles in order for the process to be near transparent to the user. Since the wireless network is considered to be a distrusted environment, access is restricted in order to limit the amount of damage that can be inflicted on internal systems and the Internet if an intruder invokes an attack. This impedes the convenience of the wireless service to users who wish to access external sites on the Internet. Since unknown users are difficult to identify and hold accountable for damages, a method of user authentication is needed to ensure that the user takes responsibility for their actions and can be tracked for security concerns. A trusted user can then gain access to services and the commodity Internet from which unauthenticated users are blocked.

Keeping simplicity in mind, the WFG acts as a router between a wireless and external network with the ability to dynamically change firewall filters as users authenticate themselves for authorized access. It is also a server responsible for handing out IP addresses to users, running a website in which users can authenticate, and maintaining a recorded account of who is on the network and when.

Users of the wireless network are only required to have a web browser if they wish to authenticate and dynamic host configuration (DHCP) software, which comes standard on most operating systems. Minimal configuration is required by the user, allowing support for a variety of computer platforms with no additional software. The idea is to keep the wireless network as user-friendly as possible while maintaining security for everyone.

Internals

Given the multiple functionalities and enhanced security required for this device, a PC running OpenBSD Unix was chosen with three interfaces on different networks: wireless, external (gateway), and internal (management). The following sections elaborate upon the services that constitute the device's various roles:

1. Dynamic Host Configuration Protocol (DHCP) Server is used to lease out individual IP addresses to anyone who configures their system to request one. Other vital information such as subnet mask, default gateway, and name server are also given to the client at this time. The WFG uses a beta DHCPv3 open-source server from the Internet Software Consortium with the additional ability to dynamically remove hosts from the firewall access list when DHCP releases a lease for any reason (client request, time-out, lease expiration, and so on). Configuration files for the server are located in /etc and follow the ISC standard (RFC) format. However, the server executable is customized and does not follow these standards. If the server needed to be upgraded, then the source code would need to be re-customized as well.
   
   The DHCP server is configured to only listen on the subnet interface of the wireless network. This prevents anyone from the wired network to obtain a wireless IP address from this server. As an added security measure, packet filters prevent any DHCP requests coming in on any other interfaces.


2. Filtering - Stateful filtering is accomplished using OpenBSD's IPF software. IP routing is enabled in the kernel state allowing for the packet filtering to occur between the wireless and external network interfaces. Static filters are configured on boot up in the /etc/ipf.rules file and are designed to minimize remote access to the WFG. Only essential protocols such as NTP, DNS, DHCP, and ICMP are allowed to reach the system. This builds a secure foundation for the restricted environment. For the users who do not require an authenticated session, access is granted to selected servers for email, VPN, and web. Where applicable, packet filtering is done at a transport layer - UDP or TCP, to allow for stateful inspection of the traffic. This adds a higher level of security by not having to explicitly permit dynamic or private port sessions into the wireless network.
   
   The same script that authenticates a user over the web also enables their access to the unrestricted environment. When a user connects to the web server, their IP address is recorded and upon successful login, gets pushed to the top of the firewall filter list, permitting all TCP and UDP connections out of the wireless network for that IP address.
   
   In order to prevent succeeding users from being allowed trusted access when the IP address is recycled, the in-memory database software removes the firewall filter permit rule whenever the user's next lease binding state is set to free, expired, abandoned, released, or reset. The DHCP server will not issue the same IP address until it frees the lease of the last client. This helps avoids the security issue of someone hijacking an IP address that's been authenticated and using it after the valid user is no longer using the wireless service


3. Web Authentication - The need for web-based authentication is necessary so that any user running any platform can gain access to the wireless network. Apache (open-source) web server is designed to securely handle this task. The server implements Secure Socket Layer (SSL) for client/server public-and-private key RSA encryption. Connecting to the web server via HTTP automatically redirects the client browser to use HTTPS. This ensures that the username and password entered by a user will not be sent in clear text. To further increase security, the SSL certificate is signed by Verisign, a trusted Certificate Authority (CA), which assures that an attacker is not imitating the web server to retrieve a user's password information.
   
   A website is setup where a user can go to type in their username and password information. This site displays the standard government system access warning and shows the IP address of the user's system (using PHP). Once a user has typed their username and password at the website where prompted, a Perl/CGI script then communicates with a Radius server with RSA's MD5 digest encryption to determine if the information submitted is correct. If the account information matches what is in the Radius database, then commands to allow their IP address, obtained through the Apache environment variables, are added to the IPF access rules. If the user is not found in the Radius database, or if the password entered is incorrect, a web page stating "Invalid Username and Password" is displayed to the user. If everything is successful, the user is notified of their privileged access.


4. Security - Every step is taken to ensure that a desirable security level is maintained both on the WFG system and the wireless network while not hindering functionality and usability. Only hosts connecting from the wireless network can access the web server. For system management purposes, Secure Shell (OpenSSH) connections are permitted from a single, secured host. All other methods of direct connection are either blocked by the firewall filters or denied access through the use of application-based TCP wrappers.
   
   Users' authentication information is encrypted throughout the process: SSL encryption with a certificate signed by a trusted CA between the client's web browser and the server, and MD5 digest encryption between the web server and the Radius system for account verification.
   
   Logs are kept for all systems, which gain access to both the restricted and authorized network. The DHCP server keeps a record of what MAC address (NIC address) requests an IP address and when it is released, then passes that information to syslog. Syslog then identifies all logging information from DHCP and writes it to /var/log/dhcpd. Additionally, any user who attempts to authenticate via the web interface has their typed username and source IP address logged with the current time along with whether or not they were successful. When a lease on an IP address expires and is removed from the firewall filters, it is noted with the authentication information in /var/log/wireless. These logs are maintained by the website script and DHCP server software, not syslog. Combined, it is possible to identify who is on the network at a given time - either by their userid, or by their burned-in physical address, for auditing purposes.
   
   With the DHCP server managing the firewall filters, it is possible for a user to manually enter a static IP address and authenticate, with the permit rule never being removed. To prevent this, the CGI script reads in the dhcpd.leases file and determines if the source IP address, obtained through the environment variable $ENV{'REMOTE_ADDR'}, has an active lease. If no lease is found, or if the lease is expired or abandoned, authentication is denied.