FreeRADIUS mit EAP-TTLS und LDAP zur sicheren WLAN Authentifizierung
1. Beschreibung
Warum WPA2 Enterprise?
WPA2 Enterprise ermöglicht es jedem Benutzer eigene Zugangsdaten verwenden zu lassen, falls ein Benutzer keinen Zugriff mehr auf das WLAN Netzwerk haben soll, muss nur dessen Account deaktiviert werden. Bei einem Passphrase geschütztem WPA Netzwerk wäre hier der Austausch der Passphrase notwendig, welche man dann an alle bestehenden Nutzer erneut verteilen muss.
Warum EAP-TTLS?
EAP-TTLS ist eines der flexibelsten EAP Verfahren, da es kaum eine Beschränkung in der Auswahl des Backends zur Passwortverwaltung gibt ( Textdateien, SQL-Datenbanken, Active Directory oder LDAP ).
EAP-TTLS ist wie auch EAP-PEAP ein sogenanntes 2 Phasen Verfahren, hierbei wird in der ersten Phase ein TLS-Tunnel zwischen dem WLAN Client und dem FreeRADIUS-Server aufgebaut.
In der zweiten Phase unterscheiden sich die Verfahren jedoch deutlich, hier unterstützt EAP-PEAP nur MS-CHAPV2, dagegen werden unter EAP-TTLS folgende Verschlüsselungsverfahren unterstützt:
- EAP
- CHAP
- MS-CHAP
- MS-CHAPv2
- PAP
Sollten die Passwörter im LDAP-Server als besonders sichere "Salted SHA-1"-Hashes hinterlegt sein kann nur PAP in der zweiten Phase eingesetzt werden, wie man in dieser Tabelle erkennen kann:
Protocol and Password Compatibility
Der in der ersten Phase initialisierte TLS-Tunnel schützt die im unverschlüsselten Password Authentication Protocol (PAP) übertragenen Zugangsdaten.
2. Konfiguration des FreeRADIUS Servers
Installation der Software
Auf dem Server werden die folgenden Pakete installiert:
apt-get install freeradius freeradius-ldap freeradius-utils
SSL Zertifikate erzeugen
Während der Installation werden zumindest unter Ubuntu und Debian sogenannte selbst signierte SnakeOil Zertifikate angelegt.
Diese SnakeOil Zertifikate eignen sich zum testen des Aufbaus sollten aber vor der Inbetriebnahme durch Kaufzertifikate oder zumindest durch die Zertifikate einer eigenen CA ausgetauscht werden, um Man in the Middle Attacken abzuwehren.
AccessPoints als Clients des FreeRADIUS-Server einrichten
Die AccessPoints werden in der Datei /etc/freeradius/clients.conf eingerichtet:
client {
secret = Passwort
shortname = Symbolischer Name
}
Den FreeRADIUS-Server auf EAP-TTLS konfigurieren
Die zu verwendende Verschlüsselungsmethode wird in der Datei /etc/freeradius/eap.conf eingerichtet:
Zuerst muss der Standard EAP-Typ eingestellt werden:
default_eap_type = ttls
Für die TLS Konfiguration müssen das Server Zertifikat, der Private Key, die Diffie-Hellman Parameter und /dev/urandom als Zufallszahlengenerator angegeben werden:
tls {
private_key_file = /etc/freeradius/certs/radius-key.pem
certificate_file = /etc/freeradius/certs/radius-cert.pem
dh_file = /etc/freeradius/certs/dh.pem
random_file = /dev/urandom
cipher_list = "DEFAULT"
}
Zuletzt müssen noch einige EAP-TTLS Konfigurationen angepasst werden:
ttls {
default_eap_type = md5
virtual_server = "inner-tunnel"
}
Warum in der TTLS Konfiguration der default_eap_type auf MD5 gestellt werden muss konnte ich nicht herausfinden, falls man den Wert ändert startet der FreeRADIUS Server nicht mehr.
Der Parameter virtual_server lädt die entsprechende Konfiguration für die Phase 2.
Verbindung zum OpenLDAP Server einrichten
Um den FreeRADIUS-Server an den LDAP Server anzubinden müssen die Verbindungsparameter und die entsprechenden LDAP-Filter eingetragen werden:
ldap {
server = ldap.example.org
port = 636 # Oder 389 falls der LDAP-Server keine SSL gesicherten Verbindungen anbietet.
basedn = "dc=example,dc=org"
filter = "(&(objectClass=posixAccount)(uid=%{User-Name}))"
groupmembership_filter = "(&(objectClass=posixGroup)(memberUid=%{User-Name}))"
groupmembership_attribute = "cn=Gruppe,ou=Groups,dc=example,dc=org"
ldap_connections_number=5
dictionary_mapping = ${confdir}/ldap.attrmap
}
Die LDAP Filter in diesem Beispiel müssen nicht unbedingt auf jedem LDAP Setup funktionieren, diese muss man dann an dass jeweiliges Schema anpassen.
Abschließend muß die Umsetzung zwischen den RADIUS und den LDAP Attributen in der Datei /etc/freeradius/ldap.attrmap konfiguriert werden.
Es sollte alle eventuell vorhandenen Attribute gelöscht werden, sodass die Datei die folgenden fünf Zeilen enthält:
checkItem $GENERIC$ radiusCheckItem
replyItem $GENERIC$ radiusReplyItem
checkItem LM-Password sambaLmPassword
checkItem NT-Password sambaNtPassword
checkItem SMB-Account-CTRL-Text acctFlags
3. Konfiguration der AccessPoints
Mittlerweile unterstützen die gängisten AccessPoints und WLAN-Router das RADIUS-Protokoll, hierbei sind immer folgende Angaben zu machen:
- IP-Adresse des RADIUS-Servers
- Der RADIUS-Server Port: 1812
- Das Shared Secret aus der clients.conf
Nun sollte man ein funktionsfähiges WPA2 Enterprise Setup besitzen, falls es zu Problemen kommt kann man den FreeRADIUS in einem ziemlich gesprächigem Modus starten:
freeradius -vv
RADIUS und EAP als Protokolle und FreeRADIUS als Software sind recht komplexe Themengebiete, also nicht gleich aufgeben falls etwas nicht klappt.
Git Server mit Apache und dem Git Smart HTTP Protokoll
Um ein zentrales Git Repository mit mehreren Personen zu nutzen bieten sich verschiedene Methoden an. Als eleganteste Lösung empfinde ich den Datenaustausch über einen Apache Webserver, da man aus den meisten Netzwerken ohne Probleme an den HTTPS Port 443 kommt.
In diesem Tutorial sprechen die Clients mit dem Repository über das sogenannte "Git Smart HTTP" Protokoll, dies ermöglicht es auch serverseitig Hooks einzusetzen, die typischen Tutorials gehen nur auf die WebDAV-Anbindung ein die dies nicht ermöglicht. Git über Smart HTTP soll auch eine bessere Geschwindigkeit gegenüber WebDAV bieten, genau nachgemessen habe ich es jedoch nicht.
1. Software installieren
Zusätzlich zu einem bestehenden Apache Webserver wird nur noch folgendes Paket benötigt:
apt-get install git-core
2. Verzeichnisstruktur für Git anlegen
Für die Git Projekte lege ich typischerweise eine neue Ordnerstruktur an:
mkdir -p /data/git
3. Git Repository anlegen
Zuerst wird ein leeres Verzeichnis angelegt:
mkdir /data/git/<projekt>
Jetzt wechselt man in das Verzeichnis und initialisiert das Repository, hierbei ist es wichtig die Datei "git-daemon-export-ok" anzulegen, damit das Repository über Smart HTTP exportiert werden kann:
cd ${GIT_REPO}
git init --bare
git update-server-info
touch git-daemon-export-ok
Zum Schluss müssen die Recht soweit angepasst werden, damit der Apache Webserver in dem Verzeichnis lesen und schreiben darf:
chgrp www-data ${GIT_DIR} -R
chown www-data ${GIT_DIR} -R
chmod 750 ${GIT_DIR}
4. Repository übergreifende Apache Konfiguration
Damit der Smart HTTP Export nachher funktioniert müssen einige Umgebungsvariablen definiert werden, dafür legen wir unter /etc/apache2/conf.d die Datei git.conf an:
SetEnv GIT_PROJECT_ROOT /data/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/
Jetzt werden alle Repositorys exportiert in denen die Datei "git-daemon-export-ok" enthalten ist, die Absicherung über einen Benutzernamen und Passwort wird in Punkt 5 des Tutorials beschrieben.
In dem VirtualHost über den die Git-Repositorys angeboten werden muss folgender Alias gesetzt werden:
Alias /git /data/git
5.Absicherung des Git-Repositorys mit einer Basic-Authentication
Zuerst wird eine Datei angelegt, in der die einzelnen Gruppen definiert werden:
touch /etc/apache2/groups
Die Gruppen und Benutzer trägt man nach diesem Schema ein:
groupname : user1 user2
Jetzt wird eine Passwortdatei angelegt in der später die Benutzer und ihre Passwörter eingetragen werden:
touch /etc/apache2/passwd
Die Nutzer werden mit diesem Befehl angelegt:
htpasswd /etc/apache2/passwd username
Nun wird man aufgefordert das Passwort des Benutzers zweimal einzugeben.
In dem Verzeichnis /etc/apache2/conf.d/ wird nun für das Repository eine eigene Konfigurationsdatei angelegt, zum Beispiel projekt.conf mit folgendem Inhalt:
< Location "/git/projekt" >
AuthType Basic
require group groupname
AuthName "Projekt"
AuthUserFile /etc/apache2/passwd
AuthGroupFile /etc/apache2/groups
SSLRequireSSL
< /Location >
HTTP Strict Transport Security mit Apache
HTTP Strict Transport Security (HSTS) ist ein Verfahren, dass es einem Angreifer erschweren soll einen Nutzer von einer HTTPS gesicherten auf eine ungesicherte Seite der gleichen Domain umzuleiten.
Solche Angriffe sind dann interessant, wenn man sich in dem gleichem WLAN-Netzwerk wie das Opfer befindet um dann die Session Cookies abzugreifen und die Sitzung zu übernehmen (Firesheep).
Es muss sich allerdings nicht immer gleich um einen Angriff handeln, manchmal sind es sich auch schlicht Fehler in der Website/Web-Applikation welche den Benutzer auf einen ungeschützten Bereich umleiten.
Um solche Fehler und / oder Angriffe ins leere laufen zu lassen kann der Webserver dem Browser des Nutzers mitteilen, wie lange er diese Domain oder auch alle Subdomains nur noch HTTPS gesichert aufrufen darf.
Um HSTS im Apache zu aktivieren benötigt man erst das "Headers"-Modul, dieses aktiviert man mit diesem Befehl:
a2enmod headers
Jetzt trägt man den HSTS-Header in jeden VirtualHost ein den man absichern möchte:
<VirtualHost www.kupschke.net:443>
ServerAdmin dominik@kupschke.net
DocumentRoot /var/www
Header always set Strict-Transport-Security "max-age=3600"
</VirtualHost>
Mit dieser Anweisung sagen wir dem Browser, dass er innerhalb der nächsten Stunde die Domain www.kupschke.net nur noch über HTTPS aufrufen soll.
Die entsprechende Dauer kann man über den Wert "max-age" einstellen, welcher die Zeit in Sekunden aufnimmt.
Falls man zusätzlich noch alle Subdomains mit absichern möchte erweitert man die Zeile wie folgt:
Header always set Strict-Transport-Security "max-age=3600 includeSubDomains"
Mehrere Git-Repositorys mit git gc komprimieren
Um ein Git-Repository mit git gc zu komprimieren muss man immer in das Verzeichnis des Repositorys wechseln, sobald man eine größere Anzahl an Repositorys pflegt wird es nervig.
Folgendes Script komprimiert alle Repositorys in einem bestimmten Verzeichnis und gibt die Größe des Ordners vor und nach der Komprimierung aus:
#!/bin/bash
GIT_PATH=/data/git
echo 'Gesamtgröße vor der Komprimierung:'
du -sh ${GIT_PATH}
cd ${GIT_PATH}
for i in *
do
cd ${GIT_PATH}/$i
git gc
done
echo 'Gesamtgröße nach der Komprimierung:'
du -sh ${GIT_PATH}
Das Script lässt sich mit lokalen und bare Repositorys auf einem Server nutzen.
GRUB2 auf mdadm Raid installieren
Vorsicht: Dieser Artikel bezieht sich auf ein Debian Testing System von Anfang 2012, ob und wie dieses Vorgehen auch unter anderen Linux Systemen zum Erfolg führt kann ich nicht sagen.
Damit Debian Wheezy von jeder Festplatte des RAID Verbundes booten kann, muss folgende Zeile in der Datei "/etc/default/grub" auskommentiert werden:
GRUB_TERMINAL=console
Jetzt müssen alle Datenträger für den Grub2 registriert werden:
grub-mkdevicemap -n
Zum Schluss aktualisiert man noch die Grub2 Konfiguration und installiert den Grub2 Bootloader in jede Festplatte des RAID-Verbunds:
update-grub
grub-install /dev/sda grub-install /dev/sdb
Jetzt kann das System von jeder Festplatte des RAIDs gestartet werden.
IPv4 und IPv6 Dual-Stack
Wie viele von euch sicherlich mitbekommen haben, findet am 8. Juni der World IPv6 Day statt.
Da mein Server-Hoster mir schon seit einiger Zeit 16 IPv6 Adressen zur Verfügung stellt, habe ich mich heute mit der Konfiguration einiger Dienste beschäftigt.
Ich habe mir zum Ziel gesetzt, alle aus dem Internet erreichbaren Dienste über eine IPv4 und IPv6 Dual-Stack Konfiguration anzubieten.
Bei den eingesetzten Diensten handelt es sich um einen Apache2 Webserver, einen Postfix MTA und einen Dovecot IMAP Server.
Zuerst sollte man zusätzliche DNS-Records für die entsprechenden Dienste anlegen, typischerweise kann man bestehende A-Records kopieren und das eine "A" durch "AAAA" ersetzen.
1. Konfiguration des Apache2 Webservers
Ein Apache auf einem aktuellen Debian Squeeze ist von Haus aus in der Lage, einen VirtualHost mit einem über IPv6 auflösbaren DNS-Record auszuliefern. Probleme bekommt man allerdings wenn man einen SSL-VirtualHost für IPv4 und IPv6 nutzen möchte, als Lösung bleibt einem nur die Konfiguration des VirtualHosts zu kopieren und die IPv6 Adresse in den neuen VirtualHost einzutragen.
Die Lösung wird an diesem Beispiel verdeutlicht:
Alter IPv4 SSL-VirtualHost (bleibt bestehen):
<VirtualHost kupschke.net:443>
ServerName kupschke.net
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/ssl.crt
SSLCertificateKeyFile /etc/apache2/ssl/ssl.key
</VirtualHost>
Neuer IPv6 SSL-VirtualHost:
<VirtualHost [2a01:4f8:121:1085::58c6:9011:1]:443>
ServerName kupschke.net
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/ssl.crt
SSLCertificateKeyFile /etc/apache2/ssl/ssl.key
</VirtualHost>
Nach einem Neustart des Apache Webservers sollte es problemlos möglich sein, die Website geschützt mit SSL unter IPv4 und IPv6 aufzurufen.
2. Konfiguration des Postfix
Einen Postfix auf den Betrieb von IPv4 und IPv6 umzustellen ist recht einfach, dazu wird /etc/postfix/main.cf mit einem Editor geöffnet und diese Zeile entsprechend erweitert:
inet_protocols = ipv4,ipv6
3. Konfiguration des Dovecot IMAP / POP3 Servers:
Der Dovecot Daemon lässt sich sehr leicht an die neue Situation anpassen, dazu öffnet man die Konfigurationsdatei /etc/dovecot/dovecot.conf und sucht nach folgender Zeile:
listen = *
diese wird dann wie folgt erweitert:
listen = *,[::]
Anhand der drei exemplarischen Dienste sieht man, dass eine Umstellung auf IPv6 aus Sicht der Softwarefeatures nicht unbedingt schwer ist.
Ein Großteil der Fehler wird typischerweise durch fehlerhafte DNS-Records erzeugt, hier sollte man genügend Zeit für eine entsprechende Qualitätssicherung und Tests einplanen.
DKIM Signaturen mit Postfix und dkim-filter auswerten
DKIM ist eine Technologie um die Authentizität einer E-Mail zu überprüfen. Der sendende Mailserver signiert jede ausgehende E-Mail mit seinem privaten DKIM Schlüssel, ein empfangender Mailserver kann die Herkunft der E-Mail dann mit dem öffentlichen DKIM Schlüssel, welcher im DNS hinterlegt ist überprüfen.
Sollte eine E-Mail nicht oder falsch signiert sein, besteht die Möglichkeit diese E-Mail zu verwerfen.
Software installieren:
Damit Postfix die Möglichkeit hat, die DKIM Schlüssel zu überprüfen muss folgendes Paket installiert werden:
apt-get install dkim-filter
DKIM-Filter konfigurieren
Der DKIM Filter ist jetzt schon in der Lage die DKIM-Signaturen zu überprüfen, allerdings sollte man noch folgende Konfiguration in /etc/dkim-filter.conf einfügen:
X-Header yes
On-BadSignature reject
Die Variable X-Header sorgt für eine Ausgabe der DKIM-Überprüfungen in den Logfiles und die zweite Variable sorgt für eine Zurückweisung der E-Mails falls die Signatur falsch ist.
DKIM init-Script anpassen
Typischerweise läuft dkim-filter über Unix Sockets, da der Postfix MTA später die Daten an localhost auf Port 8891 weiterleitet muss dies im init-Script geändert werden.
Öffnen sie dazu die Datei /etc/init.d/dkim-filter und ersetzen sie diese Zeile:
SOCKET=local:$RUNDIR/$NAME.sock
durch diese:
SOCKET="inet:8891@localhost"
Integration in Postfix
Damit der Postfix-MTA die Daten an den dkim-filter Prozess weiterreichen kann werden folgende Daten am Ende in die /etc/postfix/main.cf eingefügt:
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891
Abschliessend werden beide Dienste einmal neu gestartet:
/etc/init.d/dkim-filter restart
/etc/init.d/postfix restart
Jetzt ist der eigene Postfix Server in der Lage die Authentizität von signierten E-Mails zu überprüfen, aufbauend auf diesem Setup ist es möglich die eigene Domain mit einer DKIM Signatur auszustatten.
Subversion Server mit Apache
Subversion ist eines der verbreitetsten Versionsverwaltungsysteme, auch wenn es mittlerweile durch dezentrale Verfahren wie zum Beispiel Git oder Mercurial in Bedrängnis kommt.
Um einen Subversion Server zu betreiben gibt es verschiedene Protokolle, welche genutzt werden können. Typischerweise empfehle ich jedoch, die Repositorys SSL geschützt über einen Apache auszuliefern. Obwohl das HTTP Verfahren langsamer als die anderen Verfahren ist, ergeben sich einige markante Vorteile:
1. Die HTTP/S Ports sind üblicherweise nicht gesperrt.
2. Die Nutzerverwaltung kann innerhalb eines LDAP-Servers realisiert werden.
3. Einfache und sichere SSL Verschlüsselung.
4. Das Repository lässt sich mit jedem gängigen Webbrowser öffnen.
Zusätzlich zu einem vorhandenen Apache2 Webserver benötigt man noch das Subversion Paket, unter einem Debian/Ubuntu Linux installiert sich es wie folgt:
apt-get install subversion
Da Subversion vom Apache über ein spezielles WebDAV Modul ausgeliefert wird sollte man dieses aktivieren:
a2enmod mod_dav_svn
/etc/init.d/apache2 restart
Jetzt wird ein Verzeichnis angelegt, in dem sich später alle Subversion Projekte befinden:
mkdir -p /data/svn/
Jetzt kann das erste Subversion Repository angelegt werden:
1. Anlegen des Verzeichnisses:
mkdir /data/svn/projekt
2. Subversion initialisieren:
svnadmin create /data/svn/projekt
3. Die Rechte setzen:
chgrp -R www-data /data/svn/projekt
chmod -R 750 /data/svn/projekt
chmod 2770 /data/svn/projekt/db
# Wird ab SVN 1.6 benötigt:
chmod 760 ${SVN_REPOSITORY}/db/rep-cache.db
Jetzt muss dem Apache noch mitgeteilt werden, wie er dieses Projekt auszuliefern hat. Unter /etc/apache2/conf.d/svn-projekt.conf füge ich folgende Konfiguration ein:
<Location /svn/projekt>
DAV svn</Location>
SVNPath '/data/svn/projekt/'
Options +Indexes
Allow from all
RewriteEngine off
AuthType Basic
AuthName "Projektname"
require group 'projekt'
AuthUserFile /etc/apache2/passwd
AuthGroupFile /etc/apache2/htgroups
SSLRequireSSL
Zum Schluss sollte man die Apache Konfiguration einmal neuladen:
/etc/init.d/apache2 reload
Greylisting mit Postfix und sqlgrey
Für diese Anleitung wird ein lauffähiger Mailsserver mit Postfix und eine MySQL Datenbank benötigt.
1. Was ist Greylisting?
Greylisting bietet einen Schutz vor Spam bevor er überhaupt am Mailserver abgeladen wird. Wenn ein anderer Mailserver eine E-Mail an einen mit Greylisting geschützten Server senden möchte überprüft dieser ein sogenanntes Triplet, dieses Triplet besteht aus folgenden Daten:
1. IP-Adresse des sendenden Mailservers
2. Absenderadresse
3. Empfängeradresse
Wenn das Triplet so noch nicht vorgekommen bricht der Mailserver die Verbindung ab und sagt dem sendenden E-Mailserver, dass er später noch einmal vorbeikommen soll. Ein korrekt konfigurierter E-Mailserver wird typischerweise nach einer kurzen Zeitspanne wieder vorbeikommen und die E-Mail erfolgreich absenden können, da das Triplet nun bekannt ist. Die meisten Spam Nachrichten kommen jedoch von recht simplen Bots, welche meistens keine Warteschlange eingebaut haben und ein erneutes senden nicht unterstützen.
2. Anlegen der Datenbank
Zuerst logt man sich als root in der MySQL Instanz ein:
mysql -u root -p
Dann legt man eine neue Datenbank an:
CREATE DATABASE sqlgrey
Als letztes muss noch ein Benutzer mit den entsprechenden Rechten für sqlgrey angelegt werden:
GRANT ALL ON sqlgrey.* TO 'sqlgrey'@'localhost' IDENTIFIED BY 'Passwort';
3. Installation von sqlgrey
Die Installation ist einfach mit folgendem Befehl erledigt:
apt-get install sqlgrey
Bearbeiten der sqlgrey Konfiguration
Folgende Konfigurationsdatei öffnen:
vi /etc/sqlgrey/sqlgrey.conf
Und die Datenbankkonfiguration anpassen:
## Database settings
db_type = mysql
db_name = sqlgrey
db_host = YOUR_DATABASE_SERVER
db_port = default
db_user = sqlgrey
db_pass = YOUR_PASS_WORD
db_cleandelay = 1800
clean_method = sync
4. sqlgrey in Postfix einbinden
Um den sqlgrey Dienst in Postfix einzubinden wird die main.cf geöffnet:
vi /etc/postfix/main.cf
Im Bereich der smtpd_reciptient_restrictions fügt man diese Regel ein:
check_policy_service inet:127.0.0.1:2501
Zum Abschluss muss man die Dienste einmal neustarten:
/etc/init.d/sqlgrey restart
/etc/init.d/postfix restart
Upgrade auf WordPress 3.1
Nachdem heute WordPress 3.1 freigegeben wurde habe ich mich direkt mal an das Upgrade gemacht.
Damit man nach einem fehlgeschlagenen Upgrade kein Desaster erlebt sollte man vorher Backups erstellen:
Zuerst erzeugt man eine Kopie des Verzeichnisses:
cp -a /data/wordpress/ /data/wordpress-backup/
Als nächstes wird eine Kopie der Datenbank erstellt:
mysqladmin -u -p > wordpress.dump
Das Upgrade kann jetzt im Administrationsbereich angestoßen werden:
Dashboard --> Aktualisierungen --> Automatisches Update
Nachdem Upgrade lief bei mir das Plugin DB Cache Reloaded nicht mehr, ansonsten verlief dass Upgrade ohne weitere Probleme.