NoCatAuth Basic Setup Dec 16, 2004 S.Benedict Testing of the package was done with a fairly basic setup. I've included this document just as a little more of a guide to getting things going. There are security issues of course in opening your network to public access. A more secure setup would be to use a seperate gateway machine. In this document I have the auth server and gateway on the same machine. (urpmi both nocatauth and nocatauth-gateway) WAP -> eth1 -> install machine -> eth0 -> WAP/Router -> Cable Modem eth1: 192.168.193.0 eth0: 192.168.192.0 WAP Open System, no WEP fixed IP 192.168.193.2 channel 11 ESSID nocat WAP/Router Shared Key 128 Bit WEP fixed IP 192.168.192.12 channel 6 ESSID ays_net Server eth1 is 192.168.193.1 eth0 is 192.168.192.35 gateway is 192.168.192.10 The fact that the Router also is a WAP is incidental. As it turns out, it allows me to continue to use WEP on that box for my own devices, while allowing open access through the WAP for public access. The WAP has a 12dBi omni antenna mounted on the roof. I live in a very rural area, so my exposure as far as war driving etc., is pretty small. Iptables is installed on the server machine. You would want to have IP forwarding/masquerading enabled to forward the eth1 traffic to eth0 for outside access. A script to set this up, if you're not using the "Internet Sharing" setup can be found at (works for 2.6 kernel also): http://www.ecst.csuchico.edu/~dranch/LINUX/ipmasq/examples/rc.firewall-2.4 I'm running dhcpd on the server machine, with fixed IPs asigned to my own gear, and a dynamic pool to the 192.168.193 network. I'm also running named on this machine. domain-anme-servers should point to an appropriate address. subnet 192.168.193.0 netmask 255.255.255.0 { # default gateway option routers 192.168.193.1; option subnet-mask 255.255.255.0; option domain-name "linuxcontrol.org"; option domain-name-servers 192.168.193.1; option nis-domain "linuxcontrol.org"; range dynamic-bootp 192.168.193.100 192.168.193.150; default-lease-time 21600; max-lease-time 43200; } Initial setup: /etc/httpd/conf.d/74_authserv.conf: Uncomment the stanza: <VirtualHost 192.168.192.34:443> DocumentRoot /usr/share/nocat/authserv/htdocs Options Indexes FollowSymLinks ScriptAlias /cgi-bin/ /usr/share/nocat/authserv/cgi-bin/ SSLEngine on SSLCertificateFile /etc/ssl/apache2/server.crt SSLCertificateKeyFile /etc/ssl/apache2/server.key </VirtualHost> For my setup the first line becomes: <VirtualHost 192.168.193.1:443> Sample cert files are provided in the rpm package. /etc/nocat/authserv.conf: Define the LocalGateway: LocalGateway 192.168.193.1 /etc/nocat/gateway.conf: Define the AuthServiceAddr: AuthServiceAddr 192.168.193.1 Add a user: admintool -c stew womad admintool -a stew users Restart Apache, start the gateway: service httpd restart service nocatath-gateway start You can monitor the gateway activity log: tail -f /usr/share/nocat/gw/nocat.log I'm connecting with a Zaurus 5500, opening Opera and going to http://www.myzaurus.com. The log loks like this: [2004-12-16 16:35:51] Gateway running on port 5280. [2004-12-16 16:36:15] Spawning child process 23283. [2004-12-16 16:36:15] Connection to 192.168.193.1 from 192.168.193.150 [2004-12-16 16:36:15] Capturing 192.168.193.150 for http://www.myzaurus.com/ [2004-12-16 16:36:15] Notifying parent of Capture on peer 00:06:25:24:91:35 [2004-12-16 16:36:15] Got notification Capture of peer 00:06:25:24:91:35 [2004-12-16 16:36:15] Child process returned 1 [2004-12-16 16:36:34] Connection to 192.168.193.1 from 192.168.193.150 [2004-12-16 16:36:34] Spawning child process 23291. [2004-12-16 16:36:34] Received notify from 192.168.193.150 [2004-12-16 16:36:34] gpg --decrypt --homedir=/usr/share/nocat/gw/bin/../pgp --keyring trustedkeys.gpg --no-tty -o- returned error message: gpg: WARNING: unsafe permissions on homedir "/usr/share/nocat/gw/bin/../pgp" gpg: Signature made Thu 16 Dec 2004 04:36:28 PM EST using DSA key ID 9C56D675 gpg: Good signature from "Mandrake Developer (Mandrake Rocks) <developer@mandrakesoft.com>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: E001 7D5C 6987 C472 A206 22C4 C8EA C130 9C56 D675 [2004-12-16 16:36:34] Got auth msg: Member users Mac 00:06:25:24:91:35 User stew Token $1$34872581$EMwJudBptfTZKnXlJNCK91 Redirect http://www.myzaurus.com/ Action Permit Mode login Timeout 600 [2004-12-16 16:36:34] User (users Any) v. trusted (Any) [2004-12-16 16:36:34] User stew permitted in class Member [2004-12-16 16:36:34] Notifying parent of Permit on peer 00:06:25:24:91:35 [2004-12-16 16:36:34] Available MACs: 00:06:25:24:91:35 [2004-12-16 16:36:34] Got notification Permit of peer 00:06:25:24:91:35 [2004-12-16 16:36:34] Child process returned 1 At the client end, the request for http://www.myzaurus.com gets redirected to a nocat login splash screen, where the user authenticates and then is forwarded to the desired URL. The timeout of 600 you see above is determined by LoginTimeout in /etc/nocat/gateway.conf. when this expires the user is asked to authenticate again to continue browsing. If you were to wget a URL at the client, you'd see something like this: wget http://www.yahoo.com --14:57:17-- http://www.yahoo.com/ => `index.html.1' Connecting to www.yahoo.com:80... connected! HTTP request sent, awaiting response... 302 Moved Location: https://192.168.193.1/cgi-bin/login?redirect=http%3a%2f%2fwww%2eyahoo%2ecom%2f&timeout=600&gateway=192%2e168%2e193%2e1%3a5280&mac=00%3a06%3a25%3a24%3a91%3a35&token=%241%2426942885%24%2e%2epXrefXYjDfBUJylzmms0 [following] https://192.168.193.1/cgi-bin/login?redirect=http%3a%2f%2fwww%2eyahoo%2ecom%2f&timeout=600&gateway=192%2e168%2e193%2e1%3a5280&mac=00%3a06%3a25%3a24%3a91%3a35&token=%241%2426942885%24%2e%2epXrefXYjDfBUJylzmms0: Unknown/unsupported protocol. There are a number of different options you can use for configuring user databases and other features. Both the authserv.conf and gateway.conf documents are pretty well documented with comments. Note: Be sure your DNS setup is solid on both the client and the server. Lags in lookups can keep the authentication setup from working properly.