Wireless Heartbeat

The wireless heartbeat system is intended to authenticate wireless (or other broadcast medium) users where private, secure, link-level access control is not applicable, then ensure that the authenticated user's IP and MAC address is not taken over by an attacker looking for a free ride.

Inspiration

We originally began development of this software because we needed a way of providing wireless access to some of our neighbors, while at the same time making sure that the neighbors we don't like didn't use our uplink. Enough of the requirements (below) are handled that it is presently in production use here, as well as at an educational institution across town (after convincing them to give up on shared WEP keys as their primary wireless access control method).

The technique is based on Bob Beck's 1999 LISA paper and software (ftp), fleshed out by subsequent discussions in Bob's BOF at CanSecWest 2001 and on the Shmoo Group's discussion boards.

How it works

Authentication uses either a captive portal-style redirect to an authenticating SSL/TLS web page, or an SSH2 connection to an authenticating server. Once authentication is successful, any web redirection is removed, and filter rules are added to permit appropriate traffic originated by the user's IP address to pass to and from the rest of the net.

After authentication and rule setup, a periodic heartbeat is sent over the encrypted SSL/TLS or SSH2 channel. The SSL/TLS heartbeat uses HTTP Refresh: headers to cause the browser to come back for another key a few time per minute. The SSH2 heartbeat is done via OpenSSH's ClientAlive facility. If the user misses too many heartbeats (or fails to provide the proper key in the heartbeat in the case of SSL/TLS), the rules allowing traffic originated by their IP address are torn down.

Requirements

Authentication: Require authentication across secure channel before network access is granted; Use secure channel heartbeat to ensure authenticated user has not been replaced
User Accountability: Disallow tunneling of IP via ICMP, DNS, etc. absent prior authentication
User vs User Privacy: No absolute reliance on shared link layer encryption
Auditing: Track bandwidth used per user; Track authentication events
User Software: Authentication and heartbeat must be OS-neutral -- no vendor lock-in; Use existing software on default OS installs when those include secure channels; No driver installation required; For SSL/TLS authentication, transparently redirect sessions to gateway until user authenticated

Code so far

Perl CGI for SSL/TLS heartbeat: Username CGI un.pl; Password CGI pw.pl; Logout CGI lo.pl; Heartbeat CGI hb.pl
Perl reaper: Reaper of stale sessions reaper.pl
Perl nuker: Nuker of deactivated account sessions reaper.pl
Perl utility functions for CGI & reaper: Utility functions hbu.pm
Perl DNS server for redirecting users to auth gateway: DSN gateway redirector authhb-dns.pl
HTML for heartbeat: User Intro index.html; SSL/TLS Login Form login.html; SSL/TLS User Blurb aboutwebheartbeat.html; SSH2 User Blurb aboutsshheartbeat.html
bsd_auth module to support tis authentication server: BSD_auth script login_tisauth-1.0p1.tar.gz (checksums) (openpgp signature)
PAM module to support tis authentication server: Available elsewhere
Secure SUID rule add/remove binaries: Working on them

Current release in a tar file: authhb-1.0.tar.gz (checksums) (openpgp signature)

To do

SSH2 heartbeat
Testing of SSH2 heartbeat with Mindterm, SSH Comm. Sec. SSH2, SecureCRT, ...
Authentication:
Secure rule add/delete methods:: Write pf rule add/delete applications; Write iptables rule add/delete applications
Allow different classes of traffic rules based on RADIUS settings?
Switch authenticated users/IPs from filesystem-based db to a real db