bommi's Blog Linux, Administration and other stuff

8Apr/140

Heartbleed TLS-Bug in Zimbra 8 schließen

Auch der Zimbra Collaboration Server in Version 8 ist von der Heartbleed Sicherheitslücke in OpenSSL betroffen.
Anders als bei anderer Software verwendet Zimbra allerdings nicht die OpenSSL Installation der Distribution, sondern bringt eigene libssl und libcrypto mit.

Ab Zimbra 8.0.8 wird die Lücke über die normalen Installationsbundles geschlossen werden, für alle Nutzer einer Zimbra Version zwischen 8.0.3 bis 8.0.7 gibt es folgendes Script, welches die SSL Libraries gegen eine nicht verwundbare Version austauscht:

Zuerst wird das Script heruntergeladen und als User root ausgeführt:

wget http://files.zimbra.com/downloads/security/zmopenssl-updater.sh
chmod a+x zmopenssl-updater.sh
./zmopenssl-updater.sh

Wenn alles geklappt hat erscheint folgende Ausgabe:

---------------------
[Generates the following output]
Downloading patched openssl
Validating patched openssl: success
Backing up old openssl: complete
Installing patched openssl: complete
OpenSSL patch process complete.
Please restart Zimbra Collaboration Suite as the Zimbra user via zmcontrol
restart
---------------------

Damit die neuen SSL Libraries auch von allen Zimbra Services verwendet werden muss Zimbra neu gestartet werden:

su - zimbra
zmcontrol restart

Ob die Lücke dann auch wirklich geschlossen ist, lässt sich mit einem der zahlreichen Heartbleed Tests nachvollziehen:

http://filippo.io/Heartbleed/

http://possible.lv/tools/hb/

veröffentlicht unter: Allgemein, Linux, Mail, Netzwerk, Webserver keine Kommentare
11Okt/130

FreeRADIUS mit EAP-PEAP 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-PEAP?
EAP-PEAP ist dass EAP Verfahren,welches von den meisten Betriebsystemen direkt unterstützt wird. Allerdings ist die Auswahl der Passwort-Backends auf jene beschränkt, die die Passwörter im Klartext oder als NT-Hash speichern.
Eine Übersicht, welches EAP-Verfahren mit welcher Art der Passwortspeicherung funktioniert findet ihr hier:
Protocol and Password Compatibility

EAP-PEAP ist wie auch zum Beispiel EAP-TTLS 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 wird das Passwort MS-CHAPV2 verschlüsselt übertragen.

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.

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-PEAP 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 = peap

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

Die Diffie-Hellmann Parameter können mit diesem Befehl erzeugt werden:

openssl dhparam 2048 > /etc/freeradius/certs/dh.pem

Die EAP-PEAP Konfiguration sollte folgendes aussehen haben:

peap {
default_eap_type = mschapv2
virtual_server = "inner-tunnel"
}

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 in die Datei modules/ldap eingetragen werden:

ldap {
server = ldap.example.org
port = 636 # Oder 389 falls der LDAP-Server keine SSL gesicherten Verbindungen anbietet.
binddn = "cn=manager,dc=example,dc=org"
password = manager-password
basedn = "dc=example,dc=org"
filter = "(&(objectClass=posixAccount)(uid=%{%{Stripped-User-Name}:-%{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
}

Typischerweise ist es nur einem administrativen Benutzer gestattet auf die NT-Hashes zuzugreifen, daher sollten die beiden Werte binddn und password angegeben werden.
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 sollten 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:

  1. IP-Adresse des RADIUS-Servers
  2. Der RADIUS-Server Port: 1812
  3. 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.

10Jul/130

UniFi WLAN Controller unter anderem Nutzer starten

Vor ein paar Wochen habe ich neue AccessPoints von Ubiquiti Networks gekauft, um das WLAN Netzwerk in der Firma neu aufzubauen.
Die AccessPoints haben eine wesentlich bessere Reichweite und sehen auch besser aus als unsere alten AccessPoints.
Die kostenlos erhältliche Controller-Software bietet mir alle benötigten Features, inklusive Gäste über zeitlich begrenzte Tickets zu authentifizieren ( ähnlich wie in Hotels ).

Soweit so gut, allerdings läuft die Controller Software standardmäßig unter dem User root, für einen richtigen Linux Admin geht so etwas natürlich gar nicht.
Es ist aber grundsätzlich möglich die Software auch unter einem anderen User laufen zu lassen, und dies werde ich nun erklären:

Als erstes wird die Software gestoppt:
/etc/init.d/unifi stop

Nachdem die Software heruntergefahren ist erstellen wir einen neuen User mit dem Namen "unifi":
adduser unifi

Diesem User und der gleichnamigen Gruppe übertragen wir die Rechte an den Ordnern und Dateien der Software:
chown unifi:unifi -R /usr/lib/unifi
chown unifi:unifi -R /var/lib/unifi
chown unifi:unifi -R /var/log/unifi

Zuletzt müssen wir noch das init-Script dahingehend anpassen, dass die Software mit dem neuen User gestartet wird.
Hierzu öffnen wir das init-Script unter /etc/init.d/unifi mit einem Editor und suchen nach folgenden Zeilen:

JSVC_OPTS="${JSVC_OPTS}\
-home ${JAVA_HOME} \
-cp /usr/share/java/commons-daemon.jar:${BASEDIR}/lib/ace.jar \
-pidfile ${PIDFILE} \
-procname ${NAME} \
-outfile SYSLOG \
-errfile SYSLOG \
-Djava.awt.headless=true -Xmx1024M"

In diesem Block fügen wir nun die markierte Zeile ein:

JSVC_OPTS="${JSVC_OPTS}\
-home ${JAVA_HOME} \
-user unifi \
-cp /usr/share/java/commons-daemon.jar:${BASEDIR}/lib/ace.jar \
-pidfile ${PIDFILE} \
-procname ${NAME} \
-outfile SYSLOG \
-errfile SYSLOG \
-Djava.awt.headless=true -Xmx1024M"

Jetzt kann die Software wieder gestartet werden:
/etc/init.d/unifi start

Zu diesem Thema habe ich schon ein Ticket beim Hersteller geöffnet, mal sehen ob dieses Problem in einer der nächsten Versionen behoben wird.

Wichtig: Bei jedem Update / Upgrade der Software werdet ihr gefragt, ob die Änderungen am init-Script überschrieben werden sollen. Außerdem werden die Zugriffsrechte an den Ordnern und Dateien wieder an den User root übertragen, dies muss dann wieder geändert werden.

20Apr/130

Fail2Ban und Postscreen

Fail2Ban lässt sich dahingehend erweitern, um auf die Ausgaben von Postscreen zu reagieren und die IP Adressen zu blocken.

Man könnte Fail2Ban anweisen die ankommende IP zu blocken, falls diese von Postscreen auf einer Blacklist oder mehreren Blacklists gefunden wurde.
Der entsprechende Postscreen Log-Eintrag sieht so aus:

NOQUEUE: reject: RCPT from [x.x.x.x]:xxxx: 550 5.7.1 Service unavailable;
client [x.x.x.X] blocked using zen.spamhaus.org;
from=<spammer@domain.tld>, to=<spam@kupschke.net>, proto=ESMTP, helo=<...>

Nun muss man den Fail2Ban Postfix Filter entsprechend anpassen, diesen findet man in der Datei /etc/fail2ban/filter.d/postfix.conf:
Original:

 failregex = reject: RCPT from (.*)\[<HOST>\]: 554

Meine Anpassungen:

 failregex = reject: RCPT from (.*)\[<HOST>\]: 554
             reject: RCPT from (.*)\[<HOST>\]:([0-9]{4,5}:)? 550

Sofern die Fail2Ban Standardeinstellungen gesetzt sind, würde ein Spammer jetzt nach 3 Versuchen für 10 Minuten gebannt werden.
Mein Postscreen fragt allerdings mehrere Blacklists ab und blockiert den Spammer erst wenn er in mehreren Blacklists eingetragen ist, diese Überprüfungen sind recht teuer, daher möchte ich den Spammer bei seinem ersten Versuch für eine Stunde blockieren.
Um diese Konfiguration einzurichten öffnen wir die Datei /etc/fail2ban/jail.conf und ändern die Einträge wie folgt ab:
Originial:

[postfix]
enabled  = true
port     = smtp
filter   = postfix
logpath  = /var/log/mail.log

Meine Anpassungen:

[postfix]
enabled  = true
port     = smtp
filter   = postfix
logpath  = /var/log/mail.log
maxretry = 1
bantime = 3600

Ob man auch alles richtig eingestellt hat, und welchen Erfolg man bisher mit diesen Regeln gehabt hätte, kann man sich mit diesem Befehl anzeigen lassen:

fail2ban-regex /var/log/mail.log /etc/fail2ban/filter.d/postfix.conf

Mithilfe von Fail2Ban kann man natürlich auch auf alle anderen Ausgaben von Postscreen und Postfix reagieren und die Spammer sehr effizient abwehren.

12Jul/120

Standard Terminal setzen

Um das Standard Terminal zu ändern gibt es unter Debian und Ubuntu diesen Befehl:

update-alternatives --config x-terminal-emulator

Auf meinem System erhalte ich folgende Ausgabe:

Es gibt 5 Auswahlmöglichkeiten für die Alternative x-terminal-emulator
(welche /usr/bin/x-terminal-emulator bereitstellen).

  Auswahl      Pfad                 Priorität Status
------------------------------------------------------------
* 0            /usr/bin/terminator   50        Auto-Modus
  1            /usr/bin/koi8rxterm   20        manueller Modus
  2            /usr/bin/lxterm       30        manueller Modus
  3            /usr/bin/terminator   50        manueller Modus
  4            /usr/bin/uxterm       20        manueller Modus
  5            /usr/bin/xterm        20        manueller Modus

Drücken Sie die Eingabetaste, um die aktuelle Wahl[*] beizubehalten,
oder geben Sie die Auswahlnummer ein: 4

In meinem Beispiel war "terminator" als Standard gesetzt, dies habe ich durch die Eingabe der 4 auf die Unicode Variante von xterm umgestellt.

veröffentlicht unter: Allgemein, Debian, Linux, Ubuntu keine Kommentare
28Jun/120

Arbeiten mit Git – Remote Repository hinzufuegen

In einem älteren Artikel habe ich ja schon erklärt wie man mit einem lokalen Git Repository arbeitet. Wenn man die Daten jedoch auch Remote ablegen möchte, sei es um mit mehreren Personen zu arbeiten oder zur Sicherung der Daten, ermöglicht es Git sogenannte Remote Repositorys hinzuzufügen.
Um ein Remote Repository einem lokalen Repository hinzuzufügen muss man zuerst in dass Repository wechseln und dann folgender Befehl eingeben werden:

git remote add <symbolischer-name> protocol://example.org/git/<remote-repository>

Mit diesem Befehl kann man sich dann alle verfügbaren Repositorys anzeigen lassen:

git remote show

Als Ausgabe erhält man alle Symbolischen Namen, welche man während des hinzufügen der Remote Locations vergeben hat.

Falls man mehr Information über ein bestimmtes Remote Repository erfahren möchte muss nur dessen Symbolischen Namen angeben:

git remote show <symbolischer-name>
27Jun/120

Gerrit Code Review mit Tomact,MySQL und LDAP

Dieses Howto beschreibt die Installation eines Gerrit Code Review Systems, anstatt des mitgelieferten Jetty Application-Servers wird ein Tomcat eingesetzt. Als Datenbank wird ein MySQL-Server genutzt und die Benutzerdaten kommen aus einer bestehenden LDAP Installation.
Die Installation funktioniert unter Debian und Ubuntu, sollte aber mit geringem Aufwand auch auf anderen Linux-Distributionen funktionieren.

1. Benötigte Pakete installieren

apt-get install git git-core openjdk-6-jre apache2 libapache2-mod-jk mysql-server tomcat6

2. CA Zertifikat in den Java Keystore übernehmen
Dieser Schritt ist nur dann wichtig, wenn der LDAP-Server über eine SSL/TLS geschützte Verbindung angesprochen werden soll.

Für OpenJDK lautet der Importbefehl wie folgt:

keytool -import -trustcacerts -alias "example-ca" -file CA.pem -keystore /etc/ssl/certs/java/cacerts -storepass "changeit"

Falls ein Oracle Java genutzt wird sieht der Befehl etwas anders aus:

keytool -import -trustcacerts -alias "example-ca" -file CA.pem -keystore /etc/java6-sun/security/cacerts -storepass "changeit"

3. MySQL-Datenbank anlegen
Zuerst muss man sich in die MySQL-Datenbank mit dem während der Installation gesetzten Passwort einloggen:

mysql -u root -p

Nun legt man eine neue Datenbank und einen Benutzer für die Gerrit Instanz an:

CREATE USER 'gerrit'@'localhost' IDENTIFIED BY 'gerrit';
CREATE DATABASE reviewdb;
ALTER DATABASE reviewdb charset=latin1;
GRANT ALL ON reviewdb.* TO 'gerrit'@'localhost';
FLUSH PRIVILEGES;
quit;

4. Initiale Gerrit Konfiguration durchführen
Zuerst muss ein Ordner für die Gerrit Git-Repositorys und einige Konfigurationsdateien angelegt werden:

mkdir /opt/gerrit
cd /opt/gerrit

Nun können die benötigten Installationsdateien heruntergeladen werden:

wget https://gerrit.googlecode.com/files/gerrit-2.4.2.war -O gerrit.war

Die Gerrit Installation wird mit diesem Befehl gestartet:

java -jar gerrit.war init -d /opt/gerrit/gerrit-home

Während der Installation werden einige Fragen gestellt, die entsprechenden Antworten habe ich fett markiert:


*** Gerrit Code Review 2.4.2
***

Create '/opt/gerrit/review_site' [Y/n]? y

*** Git Repositories
***

Location of Git repositories [git]: /opt/gerrit/git

Database server type [H2/?]: mysql

Gerrit Code Review is not shipped with MySQL Connector/J 5.1.10
** This library is required for your configuration. **
Download and install it now [Y/n]? y
Downloading http://repo2.maven.org/maven2/mysql/mysql-connector-java/5.1.10/mysql-connector-java-5.1.10.jar ... OK
Checksum mysql-connector-java-5.1.10.jar OK

Server hostname [localhost]:
Server port [(MYSQL default)]:
Database name [reviewdb]:
Database username [root]:
gerrit's password :
confirm password :

*** User Authentication
***
Authentication method [OPENID/?]: ldap
LDAP server [ldap://localhost]: ldaps://ldap.example.org
LDAP username :
Account BaseDN [DC=example,DC=org]: OU=Users,DC=example,DC=org
Group BaseDN [OU=Users,DC=example,DC=org]: OU=Groups,DC=example,DC=org
*** Email Delivery
***

SMTP server hostname [localhost]:
SMTP server port [(default)]:
SMTP encryption [NONE/?]:
SMTP username :

*** Container Process
***

Run as [root]:
Java runtime [/usr/lib/jvm/java-6-openjdk-i386/jre]:
Copy gerrit.war to /opt/gerrit/review_site/bin/gerrit.war [Y/n]? y
Copying gerrit.war to /opt/gerrit/review_site/bin/gerrit.war

*** SSH Daemon
***

Listen on address [*]:
Listen on port [29418]:

Gerrit Code Review is not shipped with Bouncy Castle Crypto v144
If available, Gerrit can take advantage of features
in the library, but will also function without it.
Download and install it now [Y/n]? n
Generating SSH host key ... rsa(simple)... done

*** HTTP Daemon
***

Behind reverse proxy [y/N] y?
Use SSL (https://) [y/N] y?
Listen on address [*]:
Listen on port [8080]:

5. Gerrit in den Tomcat deployen
Als aller erstes wird Tomcat gestoppt:

/etc/init.d/tomcat6 stop

Damit der Zugriff auf die Datenbank aus dem Tomcat funktioniert muss eine Datasource in der Datei /etc/tomcat6/context.xml angelegt werden:

<Context>
....
  <Resource name="jdbc/ReviewDb" auth="Container" type="javax.sql.DataSource"
               maxActive="100" maxIdle="30" maxWait="10000"
               username="gerrit" password="gerrit" driverClassName="com.mysql.jdbc.Driver"
               url="jdbc:mysql://localhost:3306/reviewdb"/>
....
</Context>

Um nachher die den Apache-Webserver über mod_jk anzubinden muss zuerst der AJP1.3 freigeschaltet werden. Die Freischaltung geschieht in der Datei /etc/tomcat6/server.xml, so sehen die Zeilen vor der Bearbeitung aus:

    <!-- Define an AJP 1.3 Connector on port 8009 -->
    <!--
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
    -->

Und so nach der Bearbeitung:

    <!-- Define an AJP 1.3 Connector on port 8009 -->
        <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> 

Nun werden die benötigten Daten in die entsprechenden Tomcat Verzeichnisse verschoben:

cd /opt/gerrit/gerrit-home/
cp bin/gerrit.war /var/lib/tomcat6/webapps/
cp lib/mysql-connector-java-5.1.10.jar /usr/share/tomcat6/lib/
chown tomcat6.tomcat6 -R /opt/gerrit/

6. Tomcat über mod-jk anbinden
JK-Worker für Gerrit anlegen:

vi /etc/libapache2-mod-jk/workers.properties

Die workers.properties sollte so aussehen:


workers.tomcat_home=/usr/share/tomcat6
workers.java_home=/usr/lib/jvm/default-java
ps=/

worker.list=gerrit_worker

worker.gerrit_worker.port=8009
worker.gerrit_worker.host=localhost
worker.gerrit_worker.type=ajp13
worker.gerrit_worker.lbfactor=1

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=gerrit_worker

Als nächstes wird eine Konfigurationsdatei für eine generelle mod_jk Konfiguration angelegt:
touch /etc/apache2/conf.d/jk.conf

Die Datei wird mit diesem Inhalt gefüllt:

JkShmFile /var/log/apache2/mod_jk.shm
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel info
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions +RejectUnsafeURI +ForwardKeySize
JkMount /gerrit gerrit_worker
JkMount /gerrit/* gerrit_worker

Als letztes muss man die VirtualHosts anpassen, in denen die Applikationen verfügbar sein sollen, dazu fügt man folgende Zeile ein:

JkMountCopy On

Zum Abschluss sollten der Tomcat- und der Apache-Server einmal neugestartet werden:

/etc/init.d/tomcat6 restart
/etc/init.d/apache2 restart

Nun könnt ihr euer Gerrit Code Review System über http(s)://your-host/gerrit aufrufen.

Zum Abschluss poste ich hier noch meine funktionierende gerrit.config:

[gerrit]
basePath = /opt/gerrit/git
[database]
type = MYSQL
hostname = localhost
database = reviewdb
username = gerrit
[auth]
type = LDAP
[ldap]
server = ldap://ldap.example.org
accountBase = OU=Users,DC=example,DC=org
groupBase = OU=Groups,DC=example,DC=org
[sendemail]
smtpServer = localhost
[container]
user = root
javaHome = /usr/lib/jvm/java-6-openjdk-i386/jre
[sshd]
listenAddress = *:29418
[httpd]
listenUrl = proxy-http://*:8080/
[cache]
directory = cache

16Apr/120

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:

  1. EAP
  2. CHAP
  3. MS-CHAP
  4. MS-CHAPv2
  5. 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.

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

Die Diffie-Hellmann Parameter können mit diesem Befehl erzeugt werden:

openssl dhparam 2048 > /etc/freeradius/certs/dh.pem

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 in die Datei modules/ldap 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 sollten 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:

  1. IP-Adresse des RADIUS-Servers
  2. Der RADIUS-Server Port: 1812
  3. 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.
Für alle die sich tiefer mit der Materie auseinandersetzen wollen kann ich folgende RFCs empfehlen:
RFC zu RADIUS: http://www.ietf.org/rfc/rfc2865.txt
RFC zu EAP-TTLS: http://tools.ietf.org/html/rfc5281

23Feb/120

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 >

20Feb/121

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=31556926"
</VirtualHost>

Mit dieser Anweisung sagen wir dem Browser, dass er die nächsten 365 Tage 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=31556926 includeSubDomains"