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