Das Netzwerk eines Schulungsunternehmens besteht im Wesentlichen aus vier Subnetzen:

• RED: Verbindung zum Internet über Router
• GREEN: „Sicherer“ Bereich des Netzwerkes, in welchem sich der Authentifizierungsserver (RADIUS) und ein Administrator-Rechner befindet.
• ORANGE: Demilitarisierte Zone, in welcher sich Server, wie beispielsweise Web- und File-Server, befinden.
• BLUE / tun: Subnetz für Clients der Benutzer

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.

• IPCop
  • RED-Netzwerk: dynamisch/DHCP, 192.168.150.0/24
  • GREEN-Netzwerk: statisch, 192.168.4.0/24
  • ORANGE-Netzwerk: statisch, 192.168.5.0/24
  • BLUE-Netzwerk: statisch, 192.168.6.0/24
• RADIUS-Server
  • IP-Konfiguration: statisch, 192.168.4.2/24
  • Hostname: vm-radius
• Admin-PC
  • IP-Konfiguration: statisch, 192.168.4.3/24
  • Hostname: vm-admin
• Client
  • IP-Konfiguration: dynamisch/DHCP, 192.168.6.x/24
  • Hostname: vm-client
• Webserver
  • IP-Konfiguration: statisch, 192.168.5.2/24
  • Hostname: vm-web
• Fileserver
  • IP-Konfiguration: statisch, 192.168.5.3/24
  • Hostname: vm-file

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.

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.

Die Installation erfolgt mit dem folgenden Befehl:

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

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

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

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

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
     ...
}

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
}

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

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.

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:

• Typ der Netzwerkkonfiguration: GREEN + ORANGE + BLUE + RED
• RED ⇒ DHCP
• GREEN ⇒ 192.168.4.1 / 255.255.255.0
• ORANGE ⇒ 192.168.5.1 / 255.255.255.0
• BLUE ⇒ 192.168.6.1 / 255.255.255.0

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.

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:

• Aktiviert: ja
• Anfangsadresse: 192.168.6.100
• Endadresse: 192.168.6.250
• Haltezeit-Voreinstellung in min: 60
• Max. Haltezeit in min: 480
• Domain-Name-Suffix: localdomain
• Primärer DNS: 192.168.6.1

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:

• SSH-Zugriff
  • Passwortbasierte Authentifizierung zulassen
  • Authentifizierung auf Basis öffentlicher Schlüssel zulassen

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

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.

Konfiguriert wird hier:

• Aktiviert: Ja
• Schnittstelle: BLAU
• Network: 192.168.7.0/24 - neues Subnetz für eingeloggte Clients
• Listenport for login page: 55445
• Radius Settings
  • Server 1: 192.168.4.2
  • Authentication port: 1812
  • Shared secret: ipcop (eingetragenes Passwort für den IPCop in der Client-Konfiguration von freeRADIUS)
• Das Textfeld „List of domains and networks that do not require authentication (one per line)“ wird geleert, da jeglicher Traffic in diesem Szenario eine Anmeldung erfordert

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.

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

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:

• Admin MAC: Mac-Adresse des Admin-PCs
• HTTPS Port: 445
• Verbindungs Status
  • Erlaube related, establed Verbindungen: ja
• Logging
  • Log Pakete die auf keine BlockOutTraffic Regel gepasst haben: ja
• Standard Block Aktion:
  • REJECT Pakete die auf keine BlockOutTraffic Regel gepasst haben
• Erweiterer Modus
  • Aktiviert: ja
• Interface Farben in der Regelübersicht anzeigen: ja

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:

• Name: Copspot
• Adressformat: IP
• Adresse: 192.168.7.0
• Netzwerkmaske: 255.255.255.0

Das Interface wird wie folgt definiert:

• Name: Copspot
• Schnitstelle tun0

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

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:

• Zugriff von GRÜN (beispielsweise vom Admin-PC) auf DMZ-Webserver
• Zugriff vom Copspot-Netzwerk auf den DMZ-Webserver
• Zugriff vom DMZ-Webserver auf das GRÜN- und Copspot-Netzwerk (Rückantwort nach Anfrageneingang)
• Zugriff vom RADIUS-Server auf den IPCop (Aufgrund des Copspot-Addons)

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.

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:

• Quelle
  • Standard Intefaces: Green
  • Adressformat: IP
  • Quell Adresse (MAC oder IP oder Netzwerk): 192.168.4.2
• Ziel
  • IPCop Zugriff
• Zusätzlich
  • Regel aktiviert: ja
  • Log Regel: ja
  • Regel Aktion: ACCEPT
  • Anmerkung: RADIUS-Login (tcp 1812)

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:

• Quelle
  • Standard Intefaces: Green
  • Standard Netzwerke: Green Network
• Ziel
  • Anderes Netzwerk/Outside: ja
    • Standard Interfaces: Orange
    • Ziel IP, oder Netzwerk: 192.168.5.2
  • Benutze Dienst: ja
    • Standard Dienste: http (80)
• Zusätzlich
  • Regel aktiviert: ja
  • Log Regel: ja
  • Regel Aktion: ACCEPT
  • Anmerkung: GREEN =⇒ DMZ-Webserver (tcp 80)

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

• Quelle
  • Custom Interfaces: Copspot
  • Custom Adressen: Copspot
• Ziel
  • Anderes Netzwerk/Outside: ja
    • Interface Farbe: Orange
    • Ziel IP, oder Netzwerk: 192.168.5.2
  • Benutze Dienst:
    • Standard Dienste: http (80)
• Zusätzlich
  • Regel aktiviert: ja
  • Log Regel: ja
  • Regel Aktion: ACCEPT
  • Anmerkung: Copspot =⇒ DMZ-Webserver (tcp 80)

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:

• Quelle
  • Standard Interfaces: Orange
  • Adressformat: IP
  • Quell Adresse (MAC oder IP oder Netzwerk): 192.168.5.2
• Ziel
  • Anderes Netzwerk/Outside: ja
    • Custom Interfaces: Copspot
    • Custom Adressen: Copspot
• Zusätzlich
  • Regel aktiviert: ja
  • Log Regel: ja
  • Regel Aktion: ACCEPT
  • Anmerkung: DMZ-Webserver =⇒ Copspot

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.

• Quelle
  • Standard Interfaces: Orange
  • Adressformat: IP
  • Quell Adresse (MAC oder IP oder Netzwerk): 192.168.5.2
• Ziel
  • Anderes Netzwerk/Outside: ja
    • Standard Interfaces: Green
    • Standard Netzwerke: Green Network
• Zusätzlich
  • Regel aktiviert: ja
  • Log Regel: ja
  • Regel Aktion: ACCEPT
  • Anmerkung: DMZ-Webserver =⇒ GRÜN

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.

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.

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 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.

• Stimmen die Zugangsdaten?
  • Lokalen Login mittels radtest auf RADIUS-Server testen
• Ist die Datenbank konsistent und aktiv?
  • Zugriff mit root und RADIUS-User probieren, Logs überwachen
• Ist die nötigte BOT-Regel für die Kommunikation zwischen IPCop und RADIUS-Server aktiv?
  • Haben sich ggf. IP- oder Netz-Adressen geändert?
• freeRADIUS-Daemon aktiv und arbeitsfähig?
  • Logs überprüfen
  • Im Debug-Modus starten:

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

• Präsentation zum Thema
• Handout zum Thema
• Auftritt des IPCop-Projekts: http://www.ipcop.org/
• Download-Bereich der IPCop-Projektseite: http://www.ipcop.org/download.php
• Webseite des Debian-Projekts: http://www.debian.org/
• Internetseite von freeRADIUS: http://www.freeradius.org/
• Webpräsenz des phpMyAdmin-Projekts: http://www.phpmyadmin.net/home_page/index.php
• Englisches How_To zur Implementation eines FreeRADIUS-Servers: http://www.howtoforge.com/setting-up-a-freeradius-based-aaa-server-with-mysql-and-management-with-daloradius
• FAQ zu freeRADIUS: http://wiki.freeradius.org/index.php/FAQ
• Artikel im freeRADIUS-Wiki zur Implementation einer Datenbank auf SQL-Basis: http://wiki.freeradius.org/SQL_HOWTO#Configuring_FreeRadius_to_use_SQL
• Webauftritt des Copspot-Addons: http://www.ban-solms.de/t/IPCop_old-copspot.html
• Webauftritt des BlockOutTraffic-Addons: http://www.blockouttraffic.de/
• Download-Bereich: http://www.blockouttraffic.de/download_de.php
• Kurzanleitung zur Inbetriebnahme von BlockOutTraffic: http://www.blockouttraffic.de/gettingstarted_de.php
• Artikel im IPCopWiki zur BlockOutTraffic: http://www.ipcopwiki.de/index.php/BlockOutTraffic
• Erweiterung „NoScript“ für Mozilla Firefox: https://addons.mozilla.org/de/firefox/addon/722/