Active Portal

The Active Portal is a set of services that run on the gateway machine that sits between the wireless access point and the Internet. The access point may be external, such as an Apple Airport Base Station, or internal, such as a Linux Box with 802.11 card. Each Active Portal may serve one or many wireless access points.

The Active Portal provides network identification, user acceptance of an AUP, reverse intrusion detection, traffic shaping, and logging functions. Optional parts are a caching DNS server, and web proxy caching.

Active Portal Parts

• Universal Firewall Toolbox (UFT)
• Firewall
• Web Server with AUP (WAUP)
• Reverse IDS (RIDS)
• RIDS Rules Updater
• Spamradar
• Logging of NAT user activity
• DHCP Server

• Traffic Shaping Optional

• Caching DNS Server Optional

• Web Proxy Caching Service Optional

Universal Firewall Toolbox (UFT)

A toolbox that talks to major Free/Open firewall programs (netfilter/iptables, ipchains, ipfwadm, IP Filter, ipfw), and traffic shaping programs to set rules as directed by Active Portal Applications (RIDS and WAUP).

• Default, set to redirect/intercept all traffic to WAUP page
• After WAUP acceptance, set redirect/intercept to off and NAT to internet
• After RIDS detection, set redirect/intercept to Abuse Detected Page
• After adding or removing user, set traffic shaping options

Firewall

The following Free/Open Source firewall are to be supported by the UFT.

• netfilter/iptables (Linux 2.4)
• ipchains (Linux 2.2)
• ipfwadm (Linux 2.0)
• IP Filter (Solaris, SunOS, and BSD systems)
• ipfw (FreeBSD)

Rules and changes to rules come from UFT.

Web Server Page with AUP (WAUP)

User is automatically redirected/intercepted to AUP webpage, after the user agrees to the AUP, WAUP directs to UFT to allow this user through to the internet. This is so that users will recognize what network they are on (corporate sponsorship and recognition also), and agree to the AUP if necessary, and also authenticate if necessary. For permanent/privileged users, they will not have their web pages redirected upon initial requests. By storing a cookie on the client machine (AUP=Yes), future AUP acceptance can be avoided by checking for the cookie, updating the firewall rules, and then automatically forwarding the client machine to their original request.

Reverse IDS (RIDS)

Snort or other IDS monitors all outbound Wireless Traffic for Abuse. Abuse includes spam, hacking, and DoS attacks. Sends notification to UFT to disallow IP address after abuse. All client web requests after abuse is detected are redirected to web page notifying why access has been turned off and who to contact. This is done by turning the rules of Snort around (monitoring outgoing attacks instead of incoming attacks), and using a pearl script like Guardian (which changes the firewall rules [ipchains or netfilter]) to disallow an IP Address.

RIDS Rules Updater

Daily checks of centralized webpage via SSL of new and updated RIDS rules. Verifies SSL certificate of RIDS Rule server to prevent tampering via DNS poisoning. RIDS server covers all active portals in all cities (i.e. Seattle, SF, Portland, New York).

Spamradar

http://www.tycho.org/spamradar/ spamradar does watch for outbound - there's a file for tracking your own netblocks, and it will warn you if outbound traffic from a particular IP reaches a threshold.

Logging of NAT user activity

To help in tracking down malicious user activity. Since most access points will be using NAT, some sort of logging of the users is necessary. What information should be logged? At least DHCP IP Address, MAC Address, and time of use (could be logged by DHCP requests with short lease times [1 hour]). If possible what IP traffic was connected to, this way if someone does something illegal or abusive on the network, the person responsible for the AP doesn't just respond 'I don't know who it was, I was using NAT so all the traffic looks like it came from my machine.'

DHCP Server

Provides Private IP address to wireless users. No development work is required here. Gives the following information:

• IP Address
• Gateway (Active Portal)
• Netmask
• DNS Servers (Optional DNS caching Active Portal)
• Optional Web Proxy Server (if Active Portal has Proxy Server)

ISC DHCP Server (http://www.isc.org)

Traffic Shaping (optional)

Traffic Shaping may be integrated into Firewall program. Setting of traffic shaping rules is done by UFT. Multiple settings to include allowing bursting to full bandwidth when there is no contention for network traffic, or assigning a per user bandwidth based upon number of active users. Calculate number of active users and reallocate bandwidth to each user (this maybe a potential DoS so maybe just have a smaller fixed amount for each person). Includes priority for access point owners, owner's friends, etc. Per User Bandwidth Limitations for Guests and general public. This would allow a corporation donating their bandwidth to limit the bandwidth given to a public access users to something small, perhaps 10kBytes/sec per user. Permanent members would receive the full use of the bandwidth. Bandwidth rules could also be programmed so that a public user could use the full bursting speed, and when there was contention/competition for the bandwidth, all public users would be knocked down to a lower speed and priority.

Caching DNS Server (optional)

To increase reliability, speed, and decrease network traffic, an optional caching DNS server may be installed on the Active Portal. (BIND http://www.isc.org or DJBDNS http://cr.yp.to/djbdns.html)

Web Proxy Cache Server (optional)

To increase speed, and decrease network traffic, an optional web proxy cache server may be installed on the Active Portal. (Squid http://www.squid-cache.org) Usage of the proxy server is optional for the client, not forced.

Step by Step workings

• 1. Client comes within Wireless Range
• 2. Client does send DHCP request, active portal sends out DHCP response
• 3. Client gets IP Address (NAT Address), Gateway (Active Portal), DNS Server (Active Portal), and Netmask
• 4. Client opens web browser and every webpage is redirected/intercepted to WAUP
• 5. When client agrees to AUP, WAUP checks DHCP leases to confirm MAC address, and updates firewall rules via UFT to allow full internet access
• 6. UFT checks DHCP server logs. As long as client has active lease (2 hour renewal) firewall rules allow the user through to internet. When DHCP lease expires UFT updates firewall rules to redirect user to WAUP.
• 7. If user trips RIDS rules, RIDS through UFT updates rule to disallow client IP traffic to internet

Server Assigned Cookies for returning users

• After client agrees to AUP, server assigns cookie (perhaps over SSL).
• Upon initial redirection to WAUP, WAUP checks for cookie (AUP=Yes). If cookie exists, then WAUP notifies UFT to update rules, and user is redirected to their initial external website request (e.g. www.yahoo.com).

Other Related Web Pages

• Why use a Captive/Active Portal http://www.personaltelco.net/index.cgi/WhyCaptivePortal

• Captive Portal (the original idea) http://www.personaltelco.net/index.cgi/CaptivePortal

• Captive Portal Definition http://www.personaltelco.net/index.cgi/CaptivePortalDefinition

• Drafted RFC form NoCat on how a CaptivePortal might work http://nocat.net/nocatrfc.txt

-- TerrySchmidt

This is an evolution of the CaptivePortal idea which evolved from my interest in WikiWiki's use of wiki:SoftSecurity. The ActivePortal is an attempt to apply soft security principles to a computer network. I've discussed this a bit at MeatBall on the wiki:NetworkSoftSecurity page and on the NycWireless mailing list [http://lists.personaltelco.net/pipermail/nycwireless/2001q2/000039.html here] and [http://lists.personaltelco.net/pipermail/nycwireless/2001q2/000032.html here]. -- AdamShand

[CategoryDocumentation]