or: how to become a hotspot ISP…
Status: Working, but security problems.
Security: It turned out, that only "WLAN&LAN" (with other words dev br0) works, therefore other LAN ports can not be used (traffic goes via bridge br0 and bypasse both the kernel netfilter and chillispot. "Solution": Only WAN ethernet-port can be used, but unauthorized access to the "exposed" web-server (not just port 80) and to the LAN-interface (IP) of WRT is still possible. Partly this is due to the implementation of chillispot, but the exposure of the web-server seems to be a general problem. If the access-point is not physically secure, utilization of chillispot in the AP is problematic anyway.
But: It works, and here is how to get that far:
The DD-WRT is a open-source (GPL) third party software for many variants and OEMs of the Linksys WRT54G wireless LAN access point. I did my installations on a WRT54GS Version 1.1 (data according to http://en.wikipedia.org/wiki/WRT54G: Version 1.1, CPU-clock 200 MHz, RAM 32 MBytes, FLASH 8 MBytes, serial starts with CGN2.., Chipset: Broadcom BCM5325EKQM). I believe that the results with other variants of this product may be very similar.
I decided to update to the latest DD-WRT which is v23 SP1. DD-WRT seems to use openwrt as a basis. There are several versions available, I decided for the "standard" version. This package includes chillispot, a captive portal software.
What is chillispot?
chilispot: "When the user starts a web browser chilli will capture the tcp connection and redirect to browser to an authentication web server. The web server queries the user for his username and password. The password is encrypted (with uamsecret) and sent back to chilli (by means of redirecting the web browser). chilli forwards the authentication request to a radius server. The radius server sends an access-accept message back to chilli if authentication was successful."
DD-WRT includes a web-interface which allows the configuration of chillispot. By "saving" the configuration in the web-interface, actually a number of "nvram" variables are written in the WRT and the device is rebooted. On reboot, these nvram_chillispot-variables are read and a chillispot-configuration-file (chilispot.conf) is created at /tmp (/tmp is the mount point of the RAM-disk within the WRT) and chillispot is started with the command line parameter "-c /tmp/chillispot.conf".
But the naming of the variable name is a bit confusing:
- uamsecret of chilli.conf is named UAM secret in the web-interface of the WRT and chilli_uamsecret in nvram
- radiussecret of chilli.conf is named Shared key in the web-interface, chilli_pass in nvram and secret in (clients.conf [or potentially in the nas-sql table]) of freeradius (typical defaults are "secret" or "testing123″).
The web-interface seems to be unable to delete unused variables from nvram, therefore "nvram unset chilli_xxx" and "nvram commit" are required (via ssh/telnet).
What is needed beside chillispot?
A typical chillispot-configuration requires a web-server (typically Apache2.0, this is where the new user is redirected to and where she is presented a form to fill in a username and password), a RADIUS-server (typically freeradius, this is where chillispot sends the credidentials received from the web-server) and a SQL-server (typically mysql) which is used as a backend by the RADIUS-server.
Radius-Server, database and web-server typically run on a single Linux-box but can of cource run on seperate machines. A common configuration is to use a single server for a number of chillispots/a number of access points. In such configurations it may be convient to tunnel/encrypt traffic, but this is not essential and will not be covered by this document.
Authentication of the user is done in the following way:
- User associates her WLAN-client with the WRT, all traffic is directed to chillispot by the WRT.
- Chillispot assigns an IP (typically 192.168.182.x/24) to the WLAN-client via an DHCP-server inside chillispot (the DHCP-server of the WRT is not used).
- User enters an arbitrary URL in her web-browser
- The web-server inside chilispot resonds with a redirect to the URL defined in uamserver (eg. https:///cgi-bin/hotspotlogin.cgi)
- The user enters her username and password in a form
- The web-server redirects the browser to the web-server inside chillispot including the credidentials as parameters. If the "userpassword" flag of the default hotspotlogin.cgi is set, the password will not be encrypted. Important note: If the password is encryted, also radius will need an encrypted password, else authentication will fail!
- Chillispot creates a RADIUS authentication request (including the creditentials received from the user) to the RADIUS server
- Radius-server forwards the authentication as sql-query (SELECT statement) to the sql-database
- Radius-server receives response from database
- Radius-server sends response to chillispot
- Chillispot-webserver sends response to user ("logged in") and now works as a NAT for traffic coming from the client - user can now surf the net.
During this process a number of communication-channels are used:
- UDP port 67 (DHCP) between client and chillispot
- ARP between client and chillispot
- TCP port 443 (https) between client and web-server
- TCP port 3990 (http) between client and chilli-webserver
- UDP port 1852 (radius) between chilli and RADIUS-server
- TCP port 3306/unix socket (mysql) between RADIUS-server and MYSQL-server
The following methods are used to secure the communication-channels
- TLS (https) between client and web-server: server-certificate on web-server
- uamsecret (shared secret) between web-server/client and client/chillispot
- radiussecret (shared secret) between chilispot and RADIUS-server
- optional: CHAP (parameter userpassword in cgi-script on web-server) between web-server/client/chillispot/mysql
While encryption between client and web-server is strong, the other elements have only week security applied, especially dictionary attacks could be applied. Without optional CHAP there is no security at all between RADIUS-server and my-sql, therefore these two services should be hosted on the same machine.
Configuration of DD-WRT
- During configuration you have to use the LAN-ports, later these ports shall NOT be used because traffic on the LAN-ports bypasses chillispot (both are "br0″ from chillispots point of view.
- If you want have remote access (via the WAN-port), you have to enable it first (normaly ssh/http is only possible from the LAN and WLAN-ports.
- Connect the wired network to the WAN-port of the WRT. Depending on your wired network (cooperate LAN, single DSL-router etc.) different networking configurations (DHCP, static IP) are required. I only tested with a static IP. The subnet here has to be different from the subnet used on the wireless network (controlled by chillispot's DHCP-server)
- In total 3 subnets are used: WAN, LAN and chillispot. In normal operation the LAN-subnet is not used (but has to be used during configuration).
- Access to the web-interface shall be protected by a username/password different from defaults (root/admin).
Configuration of chillispot
The best documentation can by found by typing chillispot �help. Another choice is the Wiki at https://wiki.ubuntu.com/ChillispotHotspot.
- Configure "WLAN & LAN" - the other configuration options (WLAN, LAN) do not work
Configuration of web-server (Apache2.0)
The configuration of the web-server is covered by a posting on the chillispot-forum. There is illegal line-break before "+SymLinksIfOwnerMatch" inside the server-configuration, this option shall be in the same line as the "Options" directive.
The hotspotlogin.cgi can be found inside the chillispot source package.
Configuration of RADIUS (freeradius)
There is not much to do on this, but there is almost no documentation on the few steps required. The best configuration can be found in the Gentoo Howto at http://gentoo-wiki.com/HOWTO_Chillispot_with_FreeRadius_and_MySQL.
The shared secret radiussecret from chillispot has to be put into clients.conf of freeradius. This secret is used to authenticate the access to RADIUS. The radiusd.conf file contains a lot of comments. The best thing to to is to backup this file and remove all coment by typing
egrep -v '(^[ ]*#|^#|^$)' file_name
This way it is also possible to compare different "recommended" configuration files found on the net. Basicly "sql" has to be put into the "accounting" section of radiusd.conf. In sql.conf the sql user/password/address has to be configured. To test the configuration it is usefull to run "radiusd -xxyx -l stdout" and check the debug output. Another possibilty is to test with the free radius server from https://radius.chillispot.org/radius/. I had no luck with this service because I could not find the uamsecret to use.Configuration of database (mysql)
A good tuturial on sql & freeradius can be found at http://www.frontios.com/freeradius.html
Freeradius ships with a set of SQL-queries inside sql.conf which are configured for a "typical" database structure which can be found inside the free-radius sources (/src/modules/rlm_sql/drivers/rlm_sql_mysql/db_mysql.sql). The database can be imported into sql (mysql -uroot -prootpass radius < db_mysql.sql). For authentication only a single table radcheck is required, other tables can be usefull for accounting. There are some php-interfaces to enter accounts etc, but it seems that theses interfaces (eg. sourceforge project phpmyprepaid) require variants of the database structure, at least I did not get them to work. So the best is to enter username and password by hand (eg. phpmyadmin).
It works. Due to security issues I think about moving chillispot out of WRT into the RADIUS/Apache box and install a VPN-tunnel (openVPN) to the WRT instead.