High Availability lässt sich heute mit günstiger Hardware und einer großen Auswahl an kommerzieller sowie freier Software realisieren. ADMIN erklärt die ... (mehr)

Radius verwaltet Benutzer

Mit dem RAS-Server, der alle berechtigten Supplikanten kennt, spricht der Switch das in RFC 2865 definierte Radius-Protokoll. Dessen Kommunikation schützt ein Shared Secret, das der Admin beispielsweise mit »pwgen -s -1« generiert und zunächst im Switch hinterlegt. Damit ist das Netzgerät vorbereitet. Alle weiteren Server-seitigen Einstellungen nimmt der Systemverwalter auf dem RAS-Server vor. Dort verwaltet er auch die Zertifikate, es sei denn, er möchte diese Aufgabe aus besonderen Sicherheitsgründen auf einen separaten Rechner verlagern.

Als Remote-Access-Server ist Free Radius die richtige Wahl [9]. Mit ein paar Anpassungen in den Standard-Konfigurationsdateien unter »/etc/raddb/« (Open Suse) oder »/etc/freeradius/« (Ubuntu) aktiviert der Admin EAP-TLS. Die Grundeinstellungen von Free Radius lassen sich in einer Reihe von Dateien erweitern. So kann die Software ihre Benutzerliste auch aus einer Datenbank oder einem Verzeichnisdienst beziehen oder Benutzern Zeitbeschränkungen auferlegen.

Allgemeine Einstellungen beherbergt »radius.conf« : Da der Server nur authentisieren soll, ist die Sektion »listen« mit »type=auth« relevant. Der Admin setzt die IP-Adresse beim Schlüssel »ipaddr« , anderfalls lauscht die Software auf allen Interfaces nach Anfragen auf UDP-Port 1812. Eventuell passt der Systemverwalter daher seine Firewallregeln an. Um später Anfragen besser nachzuvollziehen, hilft in der Sektion »log« die Einstellung »auth = yes« – sie protokolliert insbesondere fehlgeschlagene Versuche.

Die Datei »clients.conf« legt das Admin-Segment zwischen Server und Radius-Server fest, aus dem Letzterer Anfragen entgegennimmt. Der Eintrag »secret« enthält das gemeinsame Geheimnis zwischen den Partnern:

client 192.168.123.0/24 {
        secret     = hEoLw6DC
        shortname  = uebelhackers
}

Die Datei »radius.conf« bindet »eap.conf« ein. Dort setzt der Admin den Schlüssel »default_eap_type« auf »tls« . In der gleichnamigen Untersektion hinterlegt er noch bei »private_key_password« das Passwort, das ein noch zu erzeugendes Server-Zertifikat freischaltet. Es weist dem Supplikanten später nach, dass der RAS-Server authentisch ist.

Zertifikate erzeugen

Einige Distributionen haben ein Makefile im Verzeichnis »/etc/raddb/certs« . Damit bauen sie mittels OpenSSL drei Arten von Zertifikaten: Erstens das einer kleinen CA, die später die Urkunden sowohl für (zweitens) den Server und (drittens) die Clients unterzeichnet. Ist dieses Verzeichnis jedoch wie bei Ubuntu 9.04 leer, bezieht der Admin die Dateien aus dem Github von Free Radius unter »raddb/certs/« [10]. Für jedes Zertifikat kennt das Paket eine Konfigurationsdatei sowie ein steuerndes gemeinsames Makefile. Um ein neues CA-Zertifikat anzulegen, bearbeitet der Admin »ca.cnf« . Den Abschnitt »[certificate_authority]« passt er wie in Listing  2 an. Identische Werte setzt er bei »input_password« und »output_password« .

Listing 2

Auszug aus ca.cnf

 

Analog editiert der Admin die Sektion »[server]« in »server.cnf« , wählt aber dort einen anderen »commonName« , damit sich die Zertifikate unterscheiden (siehe Listing  3). An der Stelle für das Passwort fügt er das in der »eap.conf« festgelegte »private_key_password« ein. Schließlich erzeugt »make all« neben den CA- und Server-Zertifikaten auch die nötige Diffie-Hellman-Datei »dh« und die »random« -Datei, beides wichtige Bestandteile des Protokoll-Handshake von SSL/TLS.

Listing 3

Auszug aus server.cnf

 

Bei EAP-TLS benötigt jedes Gerät ein eigenes Client-Zertifikat, das der Systemverwalter mit der Datei »client.cnf« erzeugt. Das Makefile von Free Radius signiert diese Ausweise jedoch mit dem Server-Zertifikat. Damit stattdessen die CA signiert, ändert der Admin die Zeilen aus Listing 4 im Makefile und achtet auf das führende Tab in Zeile 2. So kann er dem Supplikanten später direkt das CA-Zertifikat mitgeben.

Listing 4

Makefile an CA anpassen

 

In der Sektion »[client]« legt der »commonName« den Benutzernamen für Berechtigungen und weitere Einstellungen unter Radius fest. Auch dieses Zertifikat schützt ein Passwort, das der Admin in »input_password« und »output_password« setzt:

[client]
countryName         = DE
stateOrProvinceName = Hamburg
localityName        = Hamburg
organizationName    = UebelHacker
emailAddress        = s@uebelhacker.de
commonName          = uebelacker

Anders als für CA und Server muss der Admin hier mehrere Zertifikate ausstellen – für jeden User eins. Da »make client« immer nur eins erzeugt, empfiehlt es sich, diese Aufgabe zu skripten. Die fertigen Zertifikate übergibt er den Benutzern zusammen mit ihrem Passwort und dem CA-Zertifikat auf sicherem Weg, beispielsweise per USB-Stick oder auf einer Smartcard.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2020