Posts Tagged ‘Wifidog’

Auf der Suche nach einem Captive Portal bin ich neben Wifidog u. a. auf CoovaChilli gestoßen. Wifidog hatte ich bereits im letzten Jahr eingesetzt und wollte es deshalb auch in diesem Jahr wieder verwenden, allerdings scheint die Entwicklung des Projektes leider etwas zu stagnieren. Deshalb fiel die Entscheidung auf CoovaChilli.

Auf der Suche nach guten HowTos fand ich schnell das Tutorial der Ubuntu-Community, allerdings entstand beim abarbeiten genau der Fehler, der auch im Titel erschien. Dieser Fehler lies sich auch nach zahlreichen Versuchen nicht lösen, weshalb ich entschied einmal selbst Hand anzulegen und getreu dem Motto “Weniger ist manchmal mehr” zu handeln. Nun genug des Vorgeplänkels:

Voraussetzung ist ein Computer mit 2 Netzwerkkarten:
eth0 – Verbindung in das Internet
eth1 – neues Netzwerk für die zu schützenden Computer

Die Installation des Ubuntu-Servers funktioniert ohne jegliche Besonderheiten. Es muss auch nichts aus dem Auswahlmenü installiert werden, allerdings ist ein SSH-Server sehr hilfreich. Die Netzwerkkonfiguration sollte man hier für die Netzwerkkarte festlegen, die mit dem Internet verbunden ist (bei mir ist das eth0).

Als nächstes sollte das System auf den aktuellen Stand gebracht werden:

sudo apt-get update
sudo apt-get upgrade
sudo reboot

Um die Benutzer zu authentifizieren nutzt CoovaChilli Freeradius, der als nächstes installiert werden sollte:

sudo apt-get install freeradius

Freeradius besitzt eine Vielzahl von unterschiedlichen Ressourcen, in denen die Benutzer gesucht werden, u.a. SQL, LDAP und einfache Dateien. Nach der Installation von freeradius muss lediglich ein Benutzer in die Datei /etc/freeradius/users eingefügt werden. Die Konfiguration von Freeradius, um SQL oder LDAP zu nutzen wird hier nicht weiter erwähnt.

# /etc/freeradius/users
“benutzer”  Cleartext-Password:=”password”

Nach dem Speichern und neu starten des Services sollte der Benutzer sich mit radtest bereits erfolgreich testen lassen:

sudo service freeradius restart
sudo radtest “benutzer” “password” 127.0.0.1 0 testing123

Als Resultat müsste etwas wie

rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=213 length=20

ausgegeben werden. Wenn der Radius-Server auf dem gleichen Rechner läuft wie das Captive-Portal, muss nichts weiter verändert werden, anderenfalls muss der Rechner, auf dem CoovaChilli läuft als Client in die Datei /etc/freeradius/clients.conf eingetragen werden, z. B.:

# /etc/freeradius/clients.conf
client 192.168.0.0/24 {
secret  =  testing123-2
shortname  =  private-network-rad
}

Für die nächsten Schritte wird voraus gesetzt, dass Freeradius ordnungsgemäß wie oben beschrieben funktioniert. Sonst müssen erst die Fehler behoben werden, bevor fortgefahren wird.

Installation von CoovaChilli

Die CoovaChilli installation unter Ubuntu 10.04 ist sehr einfach: Den aktuellen Binary-Build herunterladen und mit dpkg installieren:

wget http://ap.coova.org/chilli/coova-chilli_1.2.5_i386.deb
sudo dpkg -i coova-chilli_1.2.5_i386.deb

Damit CoovaChilli startet, muss die Datei /etc/default/chilli so angepasst werden, dass der Parameter START_CHILLI auf 1 steht:

# /etc/default/chilli
START_CHILLI=1

Wenn CoovaChilli beim Systemstart automatisch gestartet werden soll, müssen noch Startuplinks angelegt werden:

sudo update-rc.d chilli defaults 99 1

Eine Konfigurationsdatei von CoovaChilli ist neben der default-Datei noch nicht vorhanden, um also eine eigene Konfiguration zu verwenden, muss die default-Datei kopiert werden. Danach kann diese angepasst werden:

sudo cp /etc/chilli/default /etc/chilli/config
sudo nano /etc/chilli/config
# /etc/chilli/config
# minimale Änderungen die durchgeführt werden müssen
# Radius-Einstellungen:
HS_NASID=0
HS_RADIUS=127.0.0.1
HS_RADIUS2=127.0.0.1
HS_UAMALLOW=10.1.0.1,www.coova.org
HS_RADSECRET=testing123

Alle weiteren Einstellungen können auch modifiziert werden, allerdings sollte Vorsicht walten, bevor man Parameter verändert und danach nichts mehr funktioniert.

Eine letzte Anpassung die gemacht werden muss ist die Installation von Haserl:

wget http://downloads.sourceforge.net/project/haserl/haserl-devel/haserl-0.9.28.tar.gz
tar -xzf haserl-0.9.28.tar.gz
cd haserl-0.9.28
./configure
# Sollten hier Fehler auftreten, liegt es vermutlich daran,
# dass die nötigen Programme nicht installiert sind:
# sudo apt-get install build-essential
# schafft in diesen Fällen Abhilfe
make
sudo make install
# Jetzt einfach neu starten:
sudo reboot

Nach diesem Neustart sollte nun eigentlich alles Funktionieren und bei der Verbindung eines Clients auf der Netzwerkkarte eth1 sollte dieser auf die Login-Seite weitergeleitet werden.

Bei mir trat jedoch ein Fehler auf, beim Versuch eine Seite aufzurufen:

You need to install haserl to serve pages with this wwwsh script!
see http://haserl.sourceforge.net

Der Fehler verwunderte mich, da ja haserl bereits installiert war. Ein Blick in das Script /etc/chilli/wwwsh brachte mich auch nicht weiter, denn das Kommando, um den Pfad von haserl zu bestimmen funktionierte bei mir tadelos. Da der Pfad bekannt war, wurde er schlichtweg statisch eingetragen (vielleicht nicht unbedingt elegant, aber es funktioniert):

#haserl=$(which haserl 2>/dev/null)
haserl=/usr/local/bin/haserl

nun funktionierte alles wie gewünscht und die Clients konnten sich erfolgreich Authentifizieren.

Um Wifidog als Captive-Portal zu nutzen muss man einerseits den Authentifizierungs-Server und andererseits die eigentlich Gateway Software installieren. Der Authentifizierungs-Server ist grundlegend ein einfacher Webserver mit den entsprechenden PHP-Dateien und einer PostgreSQL-Datenbank im Hintergrund. Zunächst möchte ich hier beschreiben, wie man die Gateway-Software auf Basis von Ubuntu 8.04.04 (i386) installiert.

Voraussetzung:

Grundsätzlich gibt es viele Möglichkeiten die Gateway-Software zu installieren. Man kann Sie z.B. auf einem OpenWRT-System installieren – z.B. auf dem berühmten Linksys WRT54GL oder ähnlichen Routern. Andererseits kann man auch einen Computer mit 2 Netzwerkkarten nutzen, was wir getan haben:

Computer/Server mit 2 Netzwerkkarten
Die Hardware-Kompatibilität mit Ubuntu 8.04 versteht sich von selbst. Eine der Netzwerkkarten ist mit dem Netz verbunden, in dem der Webserver steht und von welchem aus Zugang zum Internet besteht. Die andere ist für die zukünftigen Clients des Captive-Portals zuständig.

    Installation von Ubuntu 8.04.04 i386 Server-Edition:

    Der Installation von Ubuntu folgen bis zur Auswahl der primären Netzwerkkarte. Hier muss man die Ethernet-Karte auswählen, die mit dem zu sperrenden Netz – im Normalfall dem Netz mit dem Webserver und Zugang zum Internet – verbunden ist. Als nächstes habe ich die automatische Konfiguration der Netzwerkinformationen abgebrochen und das Netzwerk manuell konfiguriert – wie zum Beispiel:

    Adresse 10.49.127.10
    Subnetzmaske 255.255.255.0
    Gateway/DNS-Server auch entsprechend angeben.

    Die Installation abschließen (sinnvoll wäre auch gleich während der Installation von Ubuntu den OpenSSH-Server zu installieren, welcher allerdings keine Voraussetzung für die Software ist).

      Update und Grundkonfiguration

      Nach der Installation und dem Neustart des Rechners wird es Zeit das System zunächst auf den aktuellen Stand zu bringen und nötige Updates zu installieren:

        sudo apt-get update
        sudo apt-get upgrade

        Als erstes ist es sinnvoll die 2. Netzwerkkarte richtig zu konfigurieren. Diese Netzwerkkarte wird Teil des späteren Client-Netzwerks sein. Die Clients die in diesem Netzwerk verbunden sind versuchen durch diese Netzwerkkarte auf das gesperrte Netzwerk (auf der während der Installation eingerichteten Netzwerkkarte) zuzugreifen. Folgende Konfiguration könnte man vornehmen:

          sudo nano /etc/network/interfaces
          # öffnet die Netzwerkkonfigurationsdatei
          # anfügen und gegebenfalls anpassen:
          auto eth1
          iface eth1 inet static
          address 192.168.10.1
          netmask 255.255.255.0

          eth1 muss man durch die entsprechende Netzwerkkarte ersetzt werden. Wenn eth1 benutzt wird um ins Internet zu gelangen, dann sollte es üblicherweise eth0 sein. Speichern und Schließen und anschließen ein Neustart der Netzwerk-Komponenten:

            sudo /etc/init.d/networking restart

            Um nun den Clients die im Netzwerk, des gerade ebend konfigurierten Interfaces, angeschlossen sind durch das 1. Interface Informationen aus dem gesperrten Netz empfangen zu lassen richtet man eine NAT-Regel ein und stellt IP-Forward an:

              sudo sysctl net.ipv4.ip_forward=1
              sudo iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE
              # wenn eth0 das Interface ins gesperrte Netz ist
              sudo iptables -A FORWARD -i eth1 -j ACCEPT
              # wenn eth1 das Interface für die Clients ist

              Um dieses Konfiguration dauerhaft zu übernehmen muss sie in /etc/sysctl.conf (um IP-Forward zu enablen, Suchstring: “net.ipv4.ip_forward”) bzw. /etc/rc.local für die iptables-Regeln. Die iptables-Regeln sind einfach (ohne sudo) in die rc.local einzufügen.

                DHCP und Bind9 (DNS-Server) Installation:

                Um die Clients auch automatisch mit den nötigen Netzwerkinformationen zu versorgen, sobald sie sich ins Netzwerk einklinken, ist ein DHCP- und ein DNS-Server notwendig. Diese installiert man mit folgendem Kommando:

                  sudo apt-get install dhcp3-server bind9

                  Anschließend muss man beide Konfigurieren. Beginnen wir mit dem DHCP-Server. Die entsprechende Datei ist /etc/dhcp3/dhcpd.conf Eine minimale Konfigurationsdatei könnte folgendermaßen aussehen:

                    default-lease-time 36000;
                    max-lease-time 72000;
                    authoritative;
                    subnet 192.168.10.0 netmask 255.255.255.0 {
                    range 192.168.10.5 192.168.10.250;
                    option domain-name-servers 192.168.10.1;
                    option broadcast-address 192.168.10.255;
                    option routers 192.168.10.1;
                    option subnet-mask 255.255.255.0;
                    }

                    Nun sollte man den DNS-Server konfigurieren. Das Konfigurations-Verzeichnis ist /etc/bind9 hier sind vor allem die Dateien named.conf.options und named.conf.local interessant. Man muss mindestens den bzw. die Referenz-DNS-Server angeben, den der lokale DNS-Server fragt, wenn er selbst den Namen nicht kennt.

                      /etc/bind/named.conf.options

                      forwarders {
                      # Eine Liste öffentlicher DNS-Server findet man leicht
                      # in einer Suchmaschine
                      194.25.2.129;
                      194.25.2.130;
                      };
                      ….

                      Nun muss man den DHCP- und DNS-Server neu starten, um die neue Konfiguration zu übernehmen

                        sudo /etc/init.d/dhcp3-server restart
                        sudo /etc/init.d/bind9 restart

                        Jetzt kann man Testen, ob alles einwandfrei funktioniert. Dies ist erforderlich, um mit den nächsten Schritten fortzufahren. Wenn ein Computer, der im Client Netzwerk hängt eine IP-Adresse via DHCP zugewiesen bekommt und ins Internet bzw. in das später gesperrte Netz zugriff hat, dann sollte alles geklappt haben.

                          Wifidog-Gateway Installation

                          Zuerst einmal sollte man Programme installieren, die für das Kompilieren notwendig sind:

                            sudo apt-get install build-essential

                            Jetzt ist es Zeit den Quelltext der Wifidog-Gateway-Software herunterzuladen und zu installieren:
                            Aktuelle Download-Links sind auf http://dev.wifidog.org/wiki/Download zu finden.

                              wget http://downloads.sourceforge.net/project/wifidog/wifidog-gateway/1.1.5/wifidog-1.1.5.tar.gz
                              tar -xzf wifidog-1.1.5.tar.gz
                              cd wifidog-1.1.5
                              ./configure
                              make
                              make install

                              Jetzt nur noch die Konfigurationsdatei kopieren und Wifidog mittels Symbolischen Link zur Verfügung stellen:

                                cp wifidog.conf /etc
                                # Befindet sich die Datei wifidog.conf nicht im aktuellen
                                # Verzeichnis (dem Verzeichnis der entpackten Software), kann
                                # man danach suchen: find / -name wifidog.conf
                                # Symbolischer Link für Wifidog-Software erstellen.
                                ln -s /etc/wifidog.conf /usr/local/etc/wifidog.conf

                                Wifidog-Gateway Konfiguration

                                Nun ist es an der Zeit die Software zu konfigurieren. Die Wifidog-Konfigurationsdatei (/etc/wifidog.conf) ist eigentlich selbsterklärend. Für eine minimale Konfiguration sollten folgende Dinge geändert werden:

                                  GateWay Id: hotspot1
                                  ExternalInt: eth1
                                  InternalInt: eth0
                                  AuthServer {
                                  Hostname login.example.com
                                  SSLAvailable no
                                  Path /
                                  }
                                  # Hier muss man login.example.com durch die spätere
                                  # (Sub)Domain des Webservers ersetzen, auf dem die
                                  # Login-Seite laufen soll. Natürlich auch die Interfaces
                                  # entsprechend ändern.

                                  Wifidog Starten

                                  Nun sollte alles erfolgreich konfiguriert und installiert sein. Für das starten der Gateway-Software ist es notwendig den Webserver für den Login bereits installiert zu haben.

                                    wifidog -f -d 7
                                    # -f bedeutet, dass wifidog im Vordergrund auf der Konsole laufen soll
                                    # -d 7 wählt das Debuglevel.

                                    Wenn folgender Fehler auftritt: “wifidog: error while loading shard libraries: libhttpd.so.0: cannot open shared object file: No such file or directory”, muss man folendes Kommando ausführen, danach sollte Wifidog normal starten:

                                      ldconfig