Open Source Wifi Hotspot Implementation

The goal of this paper is to describe a design—including the hardware, software, and configuration––for an open source wireless network. The network designed will require authentication. While care will be taken to keep the authentication exchange secure, the network will otherwise transmit data without encryption.

The goal of this paper is to describe a design-including the hardware, software, and configuration--for an open source wireless network.The network designed will require authentication.While care will be taken to keep the authentication exchange secure, the network will otherwise transmit data without encryption.

W
ireless networks are an essential tool for provid ing service for colleges and libraries.This paper will explain the setup of a wireless network using opensource software and inexpensive commodity hardware.Opensource software was employed exclu sively.This allowed for flexibility in design and reduction in expense while also providing a platform for students to learn more about the internal workings of the system by examining particular sections of code in which they have interest.Standard commodity hardware was used as a means of saving cost.This should allow others to repeat this design with a minimum of funding.
The purpose of a network, like any resource, is to provide a service for those who own it; in this case, the patrons of a library, or students, faculty, and staff at a col lege.To ensure that this network serves its owners, users will be required to authenticate before gaining access.Once authenticated, the central captive portal can pro vide different levels of service for specific user groups, including guest access, if desired.For this system, ease of access for users was the primary concern; other than using the Secure Socket Layer for authentication, the remainder of the traffic was unencrypted.
Other than the base nodes, the remaining access points were connected to each other using a wireless connection in order to avoid physically connecting all access points across campus and to further reduce the expense for the deployment of the network.This was accomplished using the WDS (wireless distributed system) feature on the wireless routers.All access points connect to a centralized set of servers that provide: DHCP, Webcaching proxy, DNS caching, radius, Web server, a captive portal, and logging of network traffic.
n Hardware Requirements for the network were relatively modest, using inexpensive wireless routers along with several Linux servers built upon older Pentium 3 desktop systems.Linksys WRT54GS routers were chosen as the access points as they are inexpensive, readily available, and possess the ability to run custom opensource firmware.Other access points could be used; however, the configuration sugges tions are specific to the WRT54GS and may not apply to other hardware.The routing functions of the WRT54GS were not used in this implementation.The servers need not be anything special; older hardware will work just fine.For this implementation, decommissioned 900 MHz units with 512MB of RAM and 40GB hard drives were used.
n Wireless router software In order to provide the functionality required, the units had their firmware flashed with an opensource, Linux based operating system available from OpenWrt for the Linksys routers (http://www.openwrt.org).Support is also available for other wireless devices."The firmware from OpenWrt provides a fully writable file system with pack age management.This allows developers the freedom to customize the devices by choosing only the packages and software that are necessary for their applications." 1As the routers have limited storage, being able to hand select only the necessary components is a definite advantage.
n Server software For the operating system on the servers, Fedora Core was chosen. 2 Fedora provides the Yellow Dog Updater, Modified (yum), which eases the updating of all pack ages installed on the system, including kernel updates. 3his aids security by providing a platform for easily and frequently updating the system.Fedora Core is an open source distribution that is available for free.Fedora Core also comes with many other opensource packages that were used in this design, such as the Apache Web server.While the designers had more familiarity with Fedora, other distributions are also available that provide simi lar benefits (Suse, Ubuntu, OpenBSD, Debian, etc.).The server was run in command line mode with no graphical user interface in order to reduce the load on the server and save space on the hard drive.

n Captive portal
In order to require authentication before gaining access to the network, a captive portal was used.Some of the desired features in the choice of the captive portal were: encrypted authentication, traffic logging, and the ability to provide different levels of service for different user groups.Logging traffic allows the system administrators to identify accounts that have been misusing the network.Those who inadvertently misuse the system or perhaps have had their accounts compromised can have their access temporarily disabled until they can be contacted with instructions concerning acceptable use of the net work.As the network must be shared by all, those who habitually abuse the resource can have their accounts per manently disabled.The captive portal should also redi rect Web traffic to a login page that is served on the Secure Socket Layer until the user logs in.Chillispot was chosen as it possesses all of the features mentioned above. 4Server layout As can be seen in appendix A, three servers were used for this implementation.The first server was used as the main router to the Internet.The second server ran a Squid Web caching server. 5It also ran a DNS cach ing server and the FreeRADIUS server. 6The third was used for the captive portal.Three servers were used for various reasons.First, this distributed the load.Second, portions of the network that were not behind the cap tive portal could more easily use the services on the second server running Squid, DNS, and FreeRADIUS.It should be noted that three independent servers are not required; many of the services could be consolidated on two or even one single server to reduce the hardware requirements.The implementation depends upon the specific needs for the network.
n Server installation Installing the operating system (Fedora Core) on each server is a relatively straightforward procedure.Each machine was partitioned with 1024 MBs of swap space with the rest of the drive being an ext3 partition with the mount point "/".Only the minimal set of packages required were installed at this time.The first server, server #1 (router), was given three network interfaces, one for the Internet connection, one to connect to a switch that then connects to server #2 (Web/DNS caching and radius) as well as other machines that do not connect through the captive portal, and one connecting to server #3 (captive portal machine).The second server, server #2, only needs one interface, but the third, server #3, requires two interfaces, one for the master wireless access point, and one to connect to the switch connecting this machine to the rest of the network (appendix A).SSH login for root was also disabled at this time for added security.
n Server #1 configuration For server #1, very little setup was required.Since this server works mainly as a router, the only major items that went into its configuration were the iptables rules, which are shown and described in appendix B. 7 Rules were set up to: A reference to this script was placed in the /etc/rc.d/rc.local file so that it would run when the server boots.
Last was the setup of the three network interfaces in the machine.This can be done during system installation or afterwards on the Fedora Core based server by editing the configuration files in the /etc/sysconfig/networking scripts/ directory.One of the configuration files used in this implementation can be seen in appendix C. Of course the configuration will change as the topology of the net work changes.
n Server #2 configuration The second server required significantly more setup to configure all of the necessary services that it runs.The first service added for this implementation was the Web caching proxy server, Squid.Squid's default configura tion file (/etc/squid.conf) is quite large; fortunately it requires little modification to get a simple server up and running. 9The changes made for this implementation can be seen in appendix D. The most important lines in this configuration are the last few, which enable it to act as a transparent proxy server, making it invisible to the users and requiring no setup of their browsers.
As there was no need for an authoritative DNS server, just DNS caching for the network, dnsmasq, which is easy to configure and can handle both DHCP services as well as DNS caching, was chosen. 10In this instance, the captive portal was used to provide DHCP services for the wireless clients; however dnsmasq was used for dynamic clients on the remaining portion of the network.Dnsmasq is relatively easy to configure, requiring only one change in its default configuration file, which points to the file in which the DNS server addresses are stored, in this case /etc/dnsmasq_resolv.conf.
Next is the configuration of FreeRADIUS server.There are two files that need to be modified for the radius server; both are in the /etc/raddb/ directory.The first is clients.conf(appendix E).In this file at least two clients must be listed, one for localhost (this machine) and one for the captive portal machine.For each machine, a pass word must be specified as well as the hostname for that machine.This establishes the shared key that is used to encrypt communication between the captive portal and the radius server.The second is the users file (appendix F).In this file, each user for the captive portal system must be listed with his/her password.This implementa tion also included a class, a session timeout (dhcp lease time), idle timeout, accounting interim interval, and the maximum upload and download speeds.If guest access is required, one or several guest accounts should be added to this file along with entries for the registered users.An entry was added for each access point so that they can obtain an IP address from the DHCP server.Finally for this machine, the interface configuration file was changed according to the network specifications.For this machine the configuration is simple since it only has one interface, and the only requirement for its address is that it be on the same network as the interface on the main router server to which it is connected.
n Server #3 configuration The third server required the installation of the captive portal software, in this case Chillispot.In order to install Chillispot, if Fedora was used for the base system, it may be possible to install it as a prepackaged binary in the form an RPM package manager (rpm) file.Otherwise, if you find that you need to compile Chillispot from source code, you may need to deviate from a minimal installa tion of the operating system and base components and also include the GNU compiler collection (gcc).
When installing from source code, first download the code from the Chillispot Web site.Once the code is down loaded, unzipped and untarred, installing the Chillispot daemon is done by entering the directory containing the source files and entering the standard commands: ./configure make make install When Chillispot is on the system, either by compiling from source or through an rpm file, two more files must be configured and copied to the proper directory, the main configuration file and the login file.
The configuration file, chilli.conf, is located in the directory that contains the source files.Move this file to the /etc/ directory and make the necessary changes.In this implementation, the file required several changes (appendix G).One of the more significant alterations was to change the default network range of 192.168.182.0/24, which would be limited to less than 256 addresses.The address range was for the DHCP server was also expanded to allow for more users.The lower portion of the network range was left to make room for addresses that could be assigned to the wireless access points.An entry was added to allow the access points to obtain a static IP address in that lower range.
After this, settings must be changed for the DNS addresses given out to clients, and the address of the radius server.There is also a setting in the Chillispot configuration file that allows users to access a certain list of domains without logging in.For this implementation, the decision was to allow the users access to the campus network, as well as to the DNS server.Next, the "radi ussecret" must be set.This is the same password that was entered into the clients.conffile on the radius server for this machine.It is also necessary to set the address of the page to which users will be directed.Two lines must also be added to allow authentication using the physical or media access control (mac) address for the access points.All of the access points shared a common password.Chillispot passes the physical address of the access point to the radius server along with this password.A separate entry must exist in the radius configuration file for each IP/physical address combination.
For this setup, the redirect page was placed on this server, therefore Apache (using yum) was also installed, and this server's address was added as the Web address for the redirect page (also note that the https module may be required for apache if it does not automatically install).Rather than write a new page at this time, the sample page (hotspotlogin.cgi) from the Chillispot source folder was copied and modified slightly (appendix H).In addi tion, a Secure Socket Layer (SSL) certificate was installed on this server.This is not necessary, but it helps to avoid the warnings that pop up when a client attempts to access the login page with a browser.
A few iptables rules need to be added.The first com mand needs to be executed in order to utilize Network Address Translation (NAT) and have the server forward packets to the outside network.

/sbin/iptables t nat A POSTROUTING o eth0 \ j MASQUERADE
The next is used to drop all outbound traffic originating from the access points.This prevents anyone spoofing the physical address of the access point from accessing the Internet, while still allowing the access points and the Chillispot server to communicate for configuration and monitoring.
/sbin/iptables A FORWARD s 192.168.182.0/24\ j DROP These commands need to be executed when the Chillispot machine boots, so they were placed into the /etc/rc.d/rc.localfile.It may also be necessary to ensure that the machine can forward network traffic.This can be accomplished with the following command, which is also found as the first executable command from the script in appendix B: echo "1" > /proc/sys/net/ipv4/ip_forward Finally, the configuration files for the interfaces were set up.
n OpenWrt installation and configuration Several ways exist to replace the default Linksys firmware with the OpenWrt firmware. 11The tftp protocol can be used with both Windows and Linux, and one such method can be found in Appendix I. 12 In addition, other methods for using the standard Web interface can be found on the OpenWrt Web site. 13There are several versions of the OpenWrt firmware available; the newest version that uses the squashfs filesystem was chosen because it utilizes com pression that frees more space on the access point.
OpenWrt comes with a default Web interface that can be used for configuration, however, ssh was enabled and a script using the nvram command was used to configure each access point (see appendix J).Before ssh can be used, you must telnet into the router and change the default password (which for Linksys routers is 'admin').
NOTE: Even if you decide to use the Web interface, you should still change the default password.
As several services that were installed with the default configuration were not used in the implementa tion, they were disabled once the firmware was flashed by removing the modules that boot at startup: the Web interface, dnsmasq, and the firewall.This is done by deleting their entries in the /etc/init.ddirectory.Changes were needed to set the mode of the access point, to turn on and configure the clients needing to use WDS, to set the network information for the access point and then to save these settings.All of the wireless access points that communicate with each other via a wireless connec tion must have their physical addresses entered using a nvram command.For example, the command used for the main access point for the library would be: nvram set w10_wds="MAC_4_lib1 MAC_4_lib2" All of this is detailed in appendix J.A final set of com mands, which were needed for the WRT54GS, are included to allow the access point to obtain its IP address from the DHCP server.These commands may not be necessary depending upon the type of access point used.Since extra wireless access points are available, if an access point fails or is having problems for some reason, it is simply a matter of running a script similar to the one found in the appendix on one of the extra routers and swapping it out.
n Security Unfortunately this system is not very secure.Only the login credentials are encrypted via SSL.General data packets are in no way encrypted, so any information being transmitted is available to anyone sniffing the channel.WEP and WPA could be used for encryption, but they have known vulnerabilities.Other methods exist for securing the network such as WPA with RADIUS or the use of a Virtual Private Network, however the client setup for such systems may not be considered trivial for the typical user.Therefore it was decided that it was better to inform the users that the data was not being encrypted and let them act accordingly, rather than use encryption with known flaws or invest the time required to train the general population on how to configure their mobile units to use a more secure form of encryption.As the main goal of this particular network was connectivity and not security, it was felt that this was a fair trade off.As new standards for wireless communication are developed and commodity hardware that supports them becomes available, this may change so that encrypted channels can be employed more easily.

n Conclusion
This implementation is in no way completed.It is a work in progress, with many goals still in mind.Also, as new features are desired, parts of the system will change to accommodate these requirements.Current plans for the future are first to develop scripts to check the status of the access points and display this information to a Web page.These scripts will also notify network administrators when access points go offline.This will help the adminis trators in making sure the system is up at all times.After this, scripts will be developed to parse the log files to find abusive activity (spamming, viruses, etc).However, the current project as described is complete and has already functioned successfully for nearly a year providing con nectivity for the library and portions of the McKendree College campus.

n
set up network address translation; n allow traffic to flow within the network; n log the traffic from the wireless portion of the net work; n allow for the transparent setup of the Web proxy server; and n set up port knocking before allowing users to log into the router via SSH. 8