Inhaltsverzeichnis

Wenn es um das Absichern von Netzwerken geht, ist das Verwenden von Authentifizierungsservern, wie beispielsweise RADIUS oder klassischen Domänencontrollern meist eine gute Überlegung. Insbesondere eine Kombination von Chillispot und RADIUS wird häufig verwendet, um Netzwerkzugänge zu kontrollieren und unerwünschte Nutzung zu unterbinden.

Beispiel und Szenario

Logischer Aufbau

Das Netzwerk eines Schulungsunternehmens besteht im Wesentlichen aus vier Subnetzen:

Die Clients im letzten Subnetz haben nach dem Beziehen einer Netzwerk-Adresse mittels DHCP keinerlei Netzwerkkonnektivität zu anderen Netzen. Die Schulungsteilnehmer, die ausschließlich über den Webbrowser arbeiten, erhalten erst nach dem Login an der Firewall eingeschränkten Netzwerkzugriff auf die DMZ und das Internet.

Als Firewall dient hier die quelloffene Linux-Distribution IPCop, sie kann mittels Add-On um Chillispot-Funktionalität erweitert werden.

Der Authentifizierungsserver ist ein Debian Linux System, zusätzlich wird die freie RADIUS-Implementation freeRADIUS installiert.

Demo-Video

Zusammenfassung der Netzwerk-Konfiguration

RADIUS-Server

Als RADIUS-Server wird ein Debian Lenny-System aufgesetzt, zusätzlich wird die freie Software freeRADIUS installiert.

Die Installation von Debian ist relativ simpel - und nicht Bestandteil dieses Artikels. Ich möchte lediglich anmerken, dass ein herkömmliches Standard-System genügt - alle weiteren Dienste werden im folgenden installiert und eine grafische Oberfläche ist nicht nur unnötig sondern auch ein potenzielles Sicherheitsrisiko.

Datenbank und Webserver

freeRADIUS bietet die Möglichkeit, Benutzer in einer MySQL-Datenbank anzulegen. Gegenüber dem klassischen Pflegen einer Benutzerdatei bietet dies mehr Komfort. Optional existiert eine Web-Administrationsoberfläche für freeRADIUS genannt Dialup Admin - diese kann nicht mit lokalen Dateien umgehen sondern erfordert strikt die Benutzerpflege auf Datenbankebene.

Für administrative Arbeiten an der Datenbank im Fehlerfall hat sich phpMyAdmin etabiliert - da es im Repository verfügbar ist, kann es kinderleicht mit dazu installiert werden.

Im Rahmen der Konfiguration von phpMyAdmin wird gefragt, ob bereits vorhandene Webserver zur Verwendung konfiguriert werden sollen. Apache2 kann so mit einem Tastendruck automatisch konfiguriert werden.

Die Installation erfolgt mit dem folgenden Befehl: 

root@vm-radius:~# apt-get install apache2 mysql-server phpmyadmin

Bei der Installation der Datenbank wird ein Passwort für den Benutzer root abgefragt, welches unbedingt sicher aufbewahrt werden sollte.

freeRADIUS

freeRADIUS liegt im Debian-Repository und kann mithilfe des folgenden Befehls installiert werden: 

root@vm-radius:~# apt-get install freeradius freeradius-common freeradius-utils freeradius-dialupadmin freeradius-mysql

Konfiguration

Zunächst wird die Datenbank für die Verwendung mit Copspot konfiguriert. Es werden Benutzer angelegt und Inhalte importiert.

Benutzer- und Datenbankanlage

Zuerst wird ein dedizierter Benutzer für Copspot angelegt - er erhält auch die Rechte auf einer dedizierten Datenbank: 

root@vm-radius:~# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1337
Server version: 5.0.51a-24+lenny4 (Debian)

Type 'help;' or '\h' for help. Type '\' to clear the buffer.

mysql> CREATE DATABASE radius;
Query OK, 1 row affected (0.04 sec);

mysql> exit;

Im folgenden wird die Datenbank mit Inhalten gefüllt: 

root@vm-radius:~# mysql -u root radius -p < /etc/freeradius/sql/mysql/admin.sql
root@vm-radius:~# mysql -u root radius -p < /etc/freeradius/sql/mysql/schema.sql
root@vm-radius:~# mysql -u root radius -p < /etc/freeradius/sql/mysql/ippool.sql
root@vm-radius:~# mysql -u root radius -p < /etc/freeradius/sql/mysql/nas.sql

Datenbankanbindung an freeRADIUS

In der Konfigurationsdatei /etc/freeradius/sql.conf werden die folgenden Einstellungen ggf. angepasst: 

server = "localhost"
login = "radius"
password = radpass"
...
readclients = yes

In der Konfigurationsdatei /etc/freeradius/radiusd.conf muss der folgende Abschnitt abgeändert werden: 

# Include another file that has the SQL-releated configuration.
# This is another file only because it tends to be big.
#
#$INCLUDE sql.conf

in: 

# Include another file that has the SQL-releated configuration.
# This is another file only because it tends to be big.
#
$INCLUDE sql.conf

In der Konfigurationsdatei /etc/freeradius/sites/enabled/default müssen die folgenden Bereiche abgeändert werden: 

authroize {
     ...
     #sql
     ...
}

accounting {
     ...
     #sql
     ...
}

in 

authroize {
     ...
     sql
     ...
}

accounting {
     ...
     sql
     ...
}

Clients

freeRADIUS verwaltet nicht nur Benutzer sondern auch Hosts/Clients - damit ein Login zustande kommt, müssen sowohl Client als auch Benutzer in der freeRADIUS-Datenbank bekannt sein. In der Konfigurationsdatei wird neben localhost noch ein passender Eintrag für den IPCop eingetragen: 

client 127.0.0.1 {
        secret          = radiussecret
        nastype         = other
}

client 192.168.4.1 {
        secret          = ipcop
        nastype         = other
}

Benutzer

Zu Testzwecken wird nun ein Benutzer in der Datenbank angelegt: 

root@vm-radius:~# mysql -u root radius -p
...
mysql> USE radius;
Database changed

mysql> INSERT INTO radcheck (UserName, Attribute, Value) VALUES ('sqltest', 'Password', 'test123');
Query OK, 1 row affected (0.00 sec)

mysql> exit
Bye

Wenn alles funktioniert hat, klappt nach einem Neustart des Dienstes die Authentifizierung: 

vm-radius:~# /etc/init.d/freeradius restart
Stopping FreeRADIUS daemon: freeradius.
Starting FreeRADIUS daemon: freeradius.
vm-radius:~# 
vm-radius:~# radtest sqltest test123 localhost 1812 radiussecret
Sending Access-Request of id 1337 to 127.0.0.1 port 1812
        User-Name = "sqltest"
        User-Password = "test123"
        NAS-IP-Address = 127.0.0.1
        NAS-Port = 1812
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=1337, length=20

IPCop

Verwendet wird hier die Version 1.4.20 - diese ist zwar schon leicht angestaubt, ist aber die einzige Version, die um Chillispot erweitert werden kann. Die nachfolgende Version 1.9 wurde derzeit noch nicht fertiggestellt und kann auch nicht mehr um Chillispot erweitert werden. Der Einsatz von nicht ausgereifter Software kommt in einer Produktivumgebung, wie dieser, keineswegs in Frage.

Installation

Das letzte CD-Abbild von IPCop 1.4.2x ist die Version 1.4.21 und kann auf der IPCop-Projektseite kostenlos bezogen werden. Ein Update auf die Version 1.4.21 ist nachher über die Weboberfläche möglich.

Die Installation selbst gestaltet sich relativ einfach - neben der Erstellung eines Dateisystems und dem Kopieren der Systemdaten wird auch das Netzwerk wie folgt konfiguriert:

Netzwerkkonfiguration

Update

IPCop-Update

Im Downloadbereich der IPCop-Projektseite befindet sich ein Update-Paket namens ipcop-1.4.21-update.i386.tgz.gpg. Dieses muss heruntergeladen und über die Web-Oberfläche des IPCops eingespielt werden.

Hierzu wird über den Administrator-PC, der als einziger Zugriff auf die Weboberfläche des IPCops hat, die Seite „System → Updates“ aufgerufen - auf dieser befindet sich ein Upload-Formular, über welches die Datei hochgeladen wird. Nach dem Upload wird das Update mit einem Klick auf „Jetzt anwenden“ installiert. Nach dem Update ist zwingend ein Reboot des IPCops erforderlich.

DHCP-Server

In diesem Szenario wird lediglich im BLAUEN Netz der Clients ein DHCP-Server benötigt. Die sich im GRÜNEN Netz befindenen Hosts werden statisch konfiguriert. Die Konfiguration des DHCP-Servers wird über die Weboberfläche des IPCops unter Dienste ⇒ DHCP-Server vorgenommen.

Konfiguriert wird für das blaue Interface:

Copspot

Das Copspot-Addon für IPCop kann hier bezogen werden: http://www.ban-solms.de/t/IPCop_old-copspot.html

Das auf der Seite angebotene Archiv muss heruntergeladen und mittels SSH/SCP auf den IPCop übertragen werden. Falls SSH noch nicht aktiviert wurde, müssen in der Weboberfläche des IPCops auf der Seite System ⇒ SSH-Zugriff die folgenden Haken gesetzt sein:

Ein Klick auf Speichern speichert diese Änderung und der IPCop ist über SSH erreichbar.

Kopiert wird die Datei von Admin-PC aus mittels SCP: 

christian@vm-admin:~/Desktop$ scp -P 222 copspot-ipcop-0.1.0.tar.gz root@192.168.4.1:~
root@192.168.4.1's password:
copspot-ipcop-0.1.0.tar.gz        100% 125KB 124.9KB/s  00:00

Auf dem IPCop wird nun die Checksumme der Datei überprüft, bevor mit der Installation fortgefahren wird: 

root@vm-ipcop:~ # md5sum copspot-ipcop-0.1.0.tar.gz
b9a7e2840d48b61f6beb3dd5c28d3a6c  copspot-ipcop-0.1.0.tar.gz

Es ist wichtig, dass die Prüfsumme mit der auf der Webseite angegebenen übereinstimt! Eine abweichende Prüfsumme ist ein Indikator für eine beim Download beschädigte Datei.

Stimmt die Prüfsumme wird das Archiv entpackt und die Erweiterung installiert: 

root@vm-ipcop:~ # tar xvfz copspot-ipcop-0.1.0.tar.gz 
copspot-ipcop-0.1.0/
copspot-ipcop-0.1.0/chilli
...
copspot-ipcop-0.1.0/favicon.ico
root@vm-ipcop:~ # 
root@vm-ipcop:~ # cd copspot-ipcop-0.1.0
root@vm-ipcop:~/copspot-ipcop-0.1.0 # ./install  -i
 
Installing now ...
Copying files
Adding language texts
Patching httpd config
Restarting web server
Patching log
Adding menu entry
Adding to status page
Adding to rc.firewall.local
Successfully done!

Ab sofort steht in der Weboberfläche des IPCops unterhalb Netzwerk ⇒ CopSpot eine neue Seite zur Verfügung.

Konfiguration von Copspot

Konfiguriert wird hier:

BlockOutTraffic

Die hier bisher vorgestellte Lösung ist weitesgehend bereits einsatzfähig - die Benutzer werden in einer Datenbank angelegt und gepflegt, eine automatische DHCP-Konfiguration wird vorgenommen und die Benutzer können nach Login im Internet surfen. Lediglich der Zugriff auf die DMZ aus dem Client-Netz gelingt noch nicht. Copspot sieht nur den Zugriff auf das ROTE Netz vor, sodass hier ein weiteres Add-On seine Benutzung findet: BlockOutTraffic alias BOT.

BlockOutTraffic dient zur Überwachung und Kontrolle von ausgehendem Netzverkehr. Auf Basis von definierten Regeln wird dieser Verkehr analysiert und ggf. geblockt. BlockOutTraffic arbeitet auf Paketebene, die Einrichtung erfordert Vorwissen.

Installation und Konfiguration

Das Add-On kann auf der BOT-Projektseite kostenlos bezogen werden. Mittels SCP wird es, wie bereits im vorherigen Abschnitt gezeigt, auf den IPCop übertragen. Anschließend wird die Checksumme der Datei überprüft, bevor mit der Installation fortgefahren wird: 

root@vm-ipcop:~ # md5sum BlockOutTraffic-3.0.0-GUI-b3.tar.gz
dad94a24d9b9ed08ca231fd5fa8cd226  BlockOutTraffic-3.0.0-GUI-b3.tar.gz

Es ist wichtig, dass die Prüfsumme mit der auf der Webseite angegebenen übereinstimt! Eine abweichende Prüfsumme ist ein Indikator für eine beim Download beschädigte Datei.

Stimmt die Prüfsumme wird das Archiv entpackt und die Erweiterung installiert: 

root@vm-ipcop:~ # mkdir bot
root@vm-ipcop:~ # tar xvfz BlockOutTraffic-3.0.0-GUI-b3.tar.gz -C bot   
setup
uninstall
readme
readme_DE
COPYING
version
uninstall_BOT
information
patch.tar.gz
root@vm-ipcop:~ # cd bot/ 
root@vm-ipcop:~/bot # ./setup 
 This is BlockOutTraffic 3.0.0 installing.
 BOT standalone installation (no Addons Server) 
 
blockouttraffic/
blockouttraffic/src/
...
07:40:30 reinstalling root's fcrontab
07:40:30 installing file /tmp/fcr-itQZ0o for user root
Modifications will be taken into account right now.
 
 BlockOutTraffic (BOT) is installed now. 
 You have to enable BOT via the WebGUI. 
 
root@vm-ipcop:~/bot #

Das Add-On muss noch konfiguriert werden, hierzu wird die Seite „Firewall ⇒ BlockOutTraffic“ aufgerufen - es erscheint eine Fehlermeldung, die besagt, dass BlockOutTraffic nicht konfiguriert ist. Mit einem Klick auf Bearbeiten wird ein Konfigurationsdialog angezeigt. Dort muss die MAC-Adresse des Admin-PCs eingetragen werden. Somit wird sichergestellt, dass dieser Rechner immer Zugriff auf den IPCop hat - auch wenn die Konfiguration im semantischen Sinne zerstört wird, ein Aussperren ist bei korrekter Angabe der MAC-Adresse nicht möglich.

Eingetragen wird hier:

Zusätzliches Netzwerk/Interface

Custom BOT-Einstellungen BOT kennt erstmal nur vier Schnittstellen (eth0 - eth3) und eine handvoll Netzwerke. Das Copspot/Client-Netzwerk ist im IPCop als tun0 bekannt und verfügt in diesem Szenario über das eigene Netzwerk 192.168.7.0/24. Diese Schnittstelle und das dazugehörige Netzwerk müssen in BOT eingetragen werden - im nachfolgenden Schritt werden diese Anpassungen zur korrekten Regelbildung benötigt.

Mit Klicks auf „Firewall ⇒ Erweiterte BOT Konfig“ wird ein Dialog zur erweiterten Konfiguration von BOT geladen. Dort werden im Menü rechts oben erst „Adress Einstellungen und im nachfolgenden Schritt „Interface Einstellungen“ angewählt und mit einem Klick auf „Zeige Firewall Einstellungen“ gesetzt.

Für das Netzwerk werden die folgenden Einstellungen gesetzt:

Das Interface wird wie folgt definiert:

Nachdem diese Anpassungen vorgenommen wurden, können die Zugriffsregeln gesetzt werden.

Zugriffsregeln

BOT-Regeln

BlockOutTraffic arbeitet in der Grundeinstellung so, dass jeglicher ausgehender Traffic, für den es keine spezielle Regel gibt, geblockt wird. Das bedeutet, dass für sämtliche benötigten Zugriffe Regeln definiert werden müssen - in diesem Szenario wären dies:

Die Konfiguration von BlockOutTraffic ist nicht trivial - sie erfordert Vorwissen in der Funktionsweise von/den Umgang mit Firewall-Systemen.

Mit Klicks auf Firewall ⇒ Block Outgoing Traffic wird der Konfigurationsdialog von BOT angezeigt - im Reiter „Neue Regel hinzufügen“ werden die Aktion „ACCEPT“ angewählt und der Button „Neue Regel“ angeklickt, um eine neue Regel zur Übertragung von Paketen zu erstellen.

GRÜN auf IPCop

Diese Regel sorgt dafür, dass der RADIUS-Server (192.168.4.2) Verbindungen zum IPCop herstellen darf. Diese Konnektivität wird aufgrund des installierten Copspot-Addons benötigt. Existiert diese Regel nicht, kann der Benutzer sich nicht einloggen. Grund hierfür ist die Unterbindung der Konnektivität zum RADIUS-Server - der Benutzer erhält als Resultat einen fehlgeschlagenen Loginversuch.

Im Dialog werden folgende Einstellungen übernommen:

GRÜN nach ORANGE

Diese Regel ist genau genommen in diesem Szenario optional. Der Sinn der Regel besteht darin, dass Hosts im GRÜNEN Netz Zugriff auf den DMZ-Webserver erhalten. Aktuell ist in diesem Netz lediglich der Admin-PC - und dieser verfügt über Sonderberechtigungen und darf in jedem Netz kommunizieren. Würde man einen weiteren Hosts in diesem Netz betrieben, hätte dieser keinerlei Zugriff auf die DMZ. Hierfür muss die folgende Regel implementiert werden:

Copspot nach ORANGE

Damit eingeloggte Clients Zugriff auf den Webserver in der DMZ erhalten ist diese Regel notwendig. Sie umfasst folgende Einstellungen:

ORANGE nach Copspot

Damit eine eingehende Frage aus dem Client-Netz auch vom Webserver beantwortet kann, muss der Webserver in der DMZ auch das Recht haben, Pakete in das Copspot-Netz zu senden. Mit der folgenden Regel wird dies gewährleistet:

ORANGE nach GRÜN

Diese Regel bewirkt ähnlich wie die oberere das Übertragen von Paketen vom DMZ-Server in ein Netz - hier handelt es sich um das GRÜNE Netz. Fehlt diese Regel bekommt der Webserver zwar eine Anfrage aus dem grünen Netz (von einem anderen Host als den Admin-PC!), kann diese aber nicht beantworten.

Client-Authentifizierung

Benutzer-Login Sobald der Benutzer versucht eine Webseite aufzurufen (in diesem Fall ist es egal, ob es sich um einen lokalen Webserver oder Internet-Server handelt), wird er auf eine Login-Seite weitergeleitet. Dort muss er sich mit seinen Zugangsdaten anmelden. Nach erfolgreicher Anmeldung öffnet sich ein Popup, über welches der Benutzer sich ausloggen kann. Gleichzeitig wird im ursprünglichen Browser-Fenster die angeforderte Webseite kontaktiert. Eine Verbindung ist nur möglich, solange der Benutzer eingeloggt ist - loggt er sich aus, hat er keinen Zugriff mehr auf Fremdnetze.

Mozilla Firefox definiert diese Umleitung bei der Verwendung der Erweiterung NoScript als “Cross-Scripting„ - diese Meldung kann in diesem Fall aber getrost ignoriert werden, da es sich um keinen Angriff sondern um eine gewollte Umleitung handelt.

Sicherheitsaspekte

Ping deaktivieren

Ping auf ROT deaktivieren

Standardmäßig lässt sich der IPCop auf allen Schnitstellen anpingen - also auch aus dem ROTEN Netzwerk. Da dieses Netzwerk in den meisten Fällen über eine Anbindung an das öffentliche Internet verfügt, ist dies nicht unbedingt eine gute Idee. Angreifer haben mit diesem Ping einen „Existenzbeweis“ für den IPCop und könnten versuchen ihn zu penetrieren. Der Ping sollte daher auf diesem Interface deaktiviert werden - hierfür gibt es unter „Firewall ⇒ Firewall Optionen“ einen entsprechenden Haken. Dieser wird gesetzt und ein Klick auf „Speichern“ übernimmt diese dringend notwendige Änderung mit sofortiger Wirkung.

Grundsatz Regelsetzung

Ein wichtiger Grundsatz bei der Definition von Firewallregeln ist es, so wenig Ausnahmen, wie möglich, aber so viel, wie nötig, zu setzen. Ferner empfiehlt es sich, Regeln möglichst “atomar„ zu halten - wird beispielsweise Zugriff von einem Host auf einen speziellen Port eines Servers benötigt, wäre es gefährlich und nicht sinnvoll das ganze Subnetz für jeglichen Zugriff des Zielservers zu authentifizieren. Ebenso riskant ist die berühmte “Any-Any-Regel„, die sämtlichen Verkehr zulässt.

SSH

SSH sollte, wenn möglich, deaktiviert werden - je mehr Dienste auf einem Host aktiv sind und Verbindungen ermöglichen, desto kritischer und anfälliger ist das Konzept. Wird SSH/SCP-Zugriff benötigt, kann dieser temporär über die Weboberfläche (die bei aktiviertem BlockOutTraffic in aller Regel nur für den Admin-PC zugänglich ist) aktiviert werden.

Fehlersuche

Copspot-Login nicht möglich

vm-radius:~# /etc/init.d/freeradius stop
Stopping FreeRADIUS daemon: freeradius.
vm-radius:~# freeradius -X

Internetverweise