Coova Chilli Hotspot

Einleitung

Unterscheidungen

Wer einmal in die Verlegenheit kommt, einen Hotspot (einen Zugangspunkt für Rechner mit W-Lan) aufsetzen zu müssen, der dürfte zu Beginn zwei Überlegungen anstellen:

• Embedded AP (Access Point für W-Lan Geräte) oder ein dedizierte Rechner
• Die eingesetzte Software

Erstere bieten den Vorteil der geringen Stromaufnahme sowie (meistens) leichtere Handhabung, jedoch sind dedizierte Rechner flexibler, was den Ausbau angeht. Da muss weniger auf die Schnittstellen, RAM Verbrauch od. CPU geschaut werden.

Wird die Entscheidung über die Hardware getroffen, so grenzt das zumeist auch automatisch die Auswahl der Software ein. Während es für die Hardware APs viele bekannte Projekte gibt, wie DD-WRT od. OpenWRT - welche alle auf Linux setzen - und die Möglichkeit bieten, einen Access Point aufzusetzen, so sieht dies für reine Rechner nicht mehr so rosig aus.

Das Problem besteht vor allem in der Wahlfreiheit, wie ich meinen Zugang gestalten möchte. Dabei lassen sich drei Stufen unterscheiden:

• Offen

Hierbei hat jeder sofort die Möglichkeit dem Netz beizuwohnen und z.B. im Internet zu browsen

• Offen aber an Bedingungen geknüpft

Bei dieser Möglichkeit wird der Zugang erst gewährt, wenn der Benutzer eine Zugangsbedingung (Disclaimer) abgenickt hat.

• Geschlossen

Bei der letzten Möglichkeit erhält der Benutzer erst Zugriff auf das Netz, wenn dieser über einen Benutzeraccount verfügt - eine Authentifizierung ist damit unabwendbar.

Die Aufgabe

Einzig die erste Methode ist einfach umsetzbar und bedarf kaum der Erwähnung. Schwieriger hingegen wird es bereits bei der zweiten Art. Denn was nach einer einfachen Umsetzung klingt, kann zu einem Problem werden (wie der Autor leidlich feststellen durfte). Um dies genauer zu erörtern, bedarf es einer kurzen Aufgabenliste:

• Zu lösende Aufgaben

1. Der "unbekannte" Benutzer loggt sich in einen AP ein
2. Der Rechner erhält eine IP Adresse aus einem definierten Pool zzgl. seinem Gateway (somit kennen wir auch gleich die eindeutige Hardware Adresse des Clients (MAC))
3. Ein Satz von Firewall Regeln sorgen dafür, dass der Benutzer keinen Zugriff auf Resscourcen im Netzwerk erhält und somit auch nicht ins Internet kommt. Einzig der Zugriff auf einen dedizierten Webserver wird ihm gestatet
4. Der Benutzer öffnet seinen Browser und wird - unbhängig von der aufgerufenen URL - auf eine Seite geleitet, die ihn zu einer Login Seite od. zu einem Disclaimer umleitet.
5. Hat der Benutzer sich dem System gegenüber authentifiziert oder den Bedingungen zugestimmt, werden die Firewall Regeln für ihn angepasst, sodass er Zugang erhält
6. Ein optionales Sitzungs- Zeitlimit sorgt dafür, dass er sich nach einiger Zeit wieder einloggen muss

Sie Sache mit dem Proxy

Nun wird der eine od. andere einbingen, dass dies über einen Proxyserver bequem zu lösen sei, der wird sich schnell getäuscht sehen. Denn abgesehen davon, dass der Benutzer genötigt wird die Daten für den Proxy Server in Erfahrung zu bringen (und so manche Informationspolitik lässt den Benutzer dann doch zum UMTS Stick greifen), so hätten wir auch das Problem der Nachweisbarkeit und Sicherheit. In der Regeln arbeitet ein Proxy Server auf der OSI Schicht 5-7 (Anwendungsschicht). Somit wäre der Nachweis schwierig, welcher W-Lan Client zu welchem Zeitpunkt welche IP Adresse erhalten hat (was noch über die DHCP Lease Datei/Arp Cache lösbar wäre und gleichzeitig den Bedingungen zugestimmt hat. Der Proxy Server muss an dieser Stelle wissen, welcher MAC Adresse er Zugang zum Internet gewähren darf. Auf IP Ebene könnte es zu Problemen führen, wenn viele nur kurz mal Mails prüfen. Im Schlimmsten Fall gewährt er Zugang, da das Sitzungslimit noch nicht erreicht wurde und somit der Nachfolger der IP das Restkontigent erbt (Es ist dann wie im Wachsalon bei den Trocknern, wenn der Münzengeber seine Wäsche früher rausgeholt hat ...)

Der Aufwand wäre also ungleich höher, um dies einem Proxyserver dies bei zu bringen. Allerdings sei noch angemerkt, dass der Proxyserver Squid ACLs mittels MAC Adressen Unterstützt, allerdings muss dies beim compilieren mit angegeben worden sein (was bei den geläufigen Distributionen wohl der Fall ist). Des weiteres gibt es auch ein Session Modul, was diese oben genannte Aufgabe ebenfalls mit einigem Geschick lösen kann, welches sich squid_session nennt.

Was bisher noch keine Erwähnung fand, waren Protokolle wie z.B. POP3, SMTP und VPN. Was nutzt der vorgeschaltete Proxy Server, wenn sich dieser leicht aushebeln lässt, indem die Verbindung durch VPN genunnelt wird? Auch möchte der Betreiber gezielt bestimmte Protokolle (Ports) durchlassen, während andere wiederum gesperrt bleiben. All dies wäre mit einem Standard HTTP Proxy nicht umsetzbar (außer man schreibt eben diesen um).

Ich hoffe, die Problematik hier veranschaulicht zu haben. Es spricht natürlich nichts dagegen, den Proxy als zusätzliches Glied in der Kette zu verwenden, jedoch er allein hilft uns nicht, bei dem Aufbau eines HotSpots.

Software

Wie bereits oben angesprochen, gibt es für die Hardware AP einiges, was das Aufsetzen eines HotSpots zum Kinderspiel werden lassen, doch wird ein dedizierte Rechner verwendet, so lichtet sich der Wald bereits.

Der Autor (moi) hat dabei auf folgende Kriterien geachtet:

• Kriterien
  • Sicherheit
  • Einfache Benutzung durch Nicht- Admins
  • Flexibilität
  • Erweiterbarkeit
  • Projekt Aktivität

Vor allem der letzte Punkt kann zum Ausschluss führen:

• NoCat - Nocat ist eine community die mehrere Programme bieten, einen Hotspot zu etablieren. Leider sind deren Programme teils hoffnungslos veraltet.
• WiFiDog - Erleidet derzeit das selbe Schicksal. Das letzte Update ist schon eine weile her.
• Coova Chilli -> mittelmäßig aktiv
• ZoneCD von PubLicIP -> Donation

ZoneCD - PublicIP

Während die ersten beiden Projekte aufgrund ihres Alters rausgeflogen sind, fand vor allem die ZoneCD von Public IP gefallen. Sie ist nur ein Teil des Ganzen. Die ZoneCD ist eine auf Morphix (Knoppix) basierende LiveCD, welche einen Rechner in einen HotSpot verwandelt. Dabei wird der Rechner zwischen dem Access Point und dem Internet geschaltet. Sie hält alles dafür nötige bereit und ist sehr einfach zu konfigurieren. Die Konfiguration wird auf einem externen Medium (floppy/USB/lokale Festplatte) abgelegt. Der eigentliche Clou liegt in der Konfiguration. Beim Starten erfragt ein Assistent Benutzernamen und Passwort. Diese verwendet er, um sich seine Zoneneinstellungen aus dem Internet zu besorgen. Die eigentliche Konfiguration, ob und wie der HotSpot Benutzer in das internet - respektive lokale Netze - erfolgt über eine Webseite von http://www.publicip.net. Ein Zonenassistent führt durch die Konfiguration und ermöglicht verschiedene Einstellungen. Bei publicIP werden zwei Accounts unterschieden:

• Master Account

Er muss als erstes konfiguriert werden und erstellt sowie beherbergt die einzelnen Zonen.

• Zonen Account

Mit ihm kann nur Einblick in die jeweilige Zone gewährt werden. Dieser Account wird von der ZoneCD erfragt.

Jede Zone kann in unterschiedliche Klassen aufgeteilt werden. Die Klassen beginnen mit "Der Benutzer darf nur HTTP und darf keine ZIP/EXE ... Dateien herunterladen. Des weiteren ein Downloadlimit sowie ein Zeitlimit pro Tag", bis hin zu "Der Benutzer darf alles".

Ob der Benutzer sich jeweils einloggen muss, oder nicht, kann ebenfalls entschieden werden. Die Gestaltung der Loginseite kann dabei leicht variiert werden. Eine HTML Datei kann als Template dienen. Definierte Schlüsselwörter werden dann durch die Login Box bzw. des Links zum Disclaimer ausgetauscht. Einfluss auf die Loginbox selbst (z.B. Beschriftung der Felder) kann dabei genommen werden.

Fazit

So viele positive Eigenschaften die Kombination aus ZoneCD und Webportal auch hat, einen gravierenden Nachteil darf man nicht außer acht lassen: die Abhängigkeit vom externen Dienstleister. Dieses Projekt wird vor allem durch Spenden und kommerziellen Support am Leben erhalten. Auch die Aktivität ist derzeit nicht sonderlich hoch, was für nur wenige Entwickler spricht. Zwar ist die LiveCD selbst GPL, das Webportal jedoch nicht, was den Nachbau erschwert. Dass es um die Reaktions- Schnelligkeit auch nicht zum Besten steht, bewies sich kürzlich, als der Autor beim Kunden stand und ein abgelaufenes SSL Zertifikat vom Webserver den Dienst unbrauchbar machte. Ein einloggen war nicht mehr möglich. Erst rund fünf Tage später war der Dienst wieder erreichbar.

Doch sollte nicht unerwähnt bleiben, dass die bereits eingerichteten HotSpots weiterhin funktionieren. Sie arbeiten mit der bisherigen Zoneneinstellung weiter.

Coova Chilli

Das Projekt mit dem etwas ungewöhnlichem Namen Coova Chilli ist im Gegensatz zur ZoneCD von PublicIP keine Distribution, welche Out-of-the-box läuft, sondern eine Software, die den Zugriff der W-Lan Clients auf das Netzwerk kontrolliert. Wer OpenWRT einsetzt, der hat bereits Teile von Coova Chilli innerhalb der Firmware.

Die Software übernimmt folgende Aufgaben:

• Aufgaben von Chilli
  • DHCP Server stellen für die W-Lan Clients
  • Firewall Regeln aufstellen
  • Die Authentifizierung überprüfen
  • Sitzungsdauer überprüfen und ggf. sperren
  • Benutzer auf ein Login Portal umleiten

• Die Grafik zeigt den Aufbau:

Auch hier kann sowohl eine Version für einen Hardware Accesspoint verwendet werden, als auch ein dedizierter Rechner. Innerhalb dieser Anleitung wird nur auf die Variante für einen eigenen Rechner eingegangen.

Komponenten

Wer sich für Coova Chilli entschieden hat, hat dafür folgende Komponenten einzurichten:

• Linux Debian Etch/Lenny|Ubuntu Hardy
• FreeRadius Server für die Authentifizierung
• Apache Webserver mit SSL
• HotSpot Login Seite / Disclaimer Seite

Der FreeRadius Server ist auch dann einzurichten, wenn nur eine Disclaimer Seite angezeigt werden soll. In diesem Fall wird lediglich mit dem Benutzer "Gast" gearbeitet. Durch die MAC und IP Adresse ist dennoch nachvollziehbar, wer sich wann am System angemeldet hat.

Installation

Dann genug der Worte, springen wir zur Installation.