©Steve Byland, 123RF.com

Wer seinen Rechner richtig absichern will, muss zu Einmalpasswörtern greifen. Da finden sich diverse proprietäre Backends, die mit Radius kommunizieren. Feature-technisch ist Lin OTP das einzige freie Pendant. Auch wenn es noch in einem frühen Stadium ist, hat es doch das Zeug zur ernsthaften Alternative .

Wissen ist Macht, das gilt auch heute noch für viele sicherheitsrelevante Systeme. Dabei bietet der bloße Passwort-Sicherheitsmechanismus bei genauerer Betrachtung nur in den wenigsten Fällen ausreichende Sicherheit. Jedermann könnte sich durch bloße Kenntnis der Benutzer-Passwort-Kombination gegen das Zielsystem authentifizieren. Angriffsvarianten wie Brute Force, Sniffing, Replay Attacks oder das Benutzen eines Hard- oder Software-basierten Keyloggers stellen für sensible Datenbestände eine ernsthafte Bedrohung dar. Üblicherweise erweitern Admins in solchen Bereichen die Sicherheit ihrer Systeme durch eine zusätzliche Komponente, den physikalischen Besitz eines Hard- oder Software-Token.

Neben zahlreichen proprietären Varianten steht seit Kurzem auch das freie Lin OTP [1] des Darmstädter Herstellers Lsexperts zur Verfügung. Der Software-Architektur entsprechend funktioniert es mit allen HMAC-OTP-Tokens [2], offiziell unterstützt es die Hardware des Marktführers Aladdin, Etoken-NG OTP [3], Etoken PASS [4], auch das Safeword Alpine [5] ist erfolgreich im Einsatz.

Mobile OTPs

Nahezu jedes Mobiltelefon mit Java-Unterstützung lässt sich darüber hinaus mit Mobile OTP von LSE in ein Token verwandeln. Die Authentifikation geschieht durch zwei Faktoren: den festen Passwort­anteil und den vom Token generierten OTP-Wert. HMAC-OTP ist ein in RFC 4226 [2] definierter Standard, nach dem Lin OTP unter Zusammenarbeit von Hashfunktionen, eines Counters und eines geheimen Schlüssels das Einmalpasswort generiert. Sowohl der geheime Schlüssel als auch der Counter für jeden Benutzer landen im Backend, aber auch auf dem mobilen Token für die Initialisierung.

Der Aufbau von Lin OTP ist in der aktuellen Form noch recht statisch (siehe Abbildung 1) und setzt einen Open-LDAP- Server voraus. Das Freeradius-Modul »rlm_linotp« nutzt das LDAP-Backend als Informationsträger und stellt gleichzeitig den Authentifikationsmechanismus für die Applikationen bereit.

Abbildung 1: Lin OTP in Version 1.3: Otpadm verwaltet die Tokens und speichert die Daten in Open LDAP. Freeradius erledigt die Authentifizierung für Applikationen gegen das LDAP-Verzeichnis.

Als Administrationswerkzeug kommt bei der Enterprise Edition das
CLI-basierte »otpadm« zum Einsatz, das die Tokens
initialisiert, resynchronisiert und sperrt. Bei der Community
Edition hilft das Python-Skript »pyotpinit« bei der
Initialisierung. Dem sicherheitsbewussten Administrator sollte es
jedoch lediglich als Beispiel dienen, da dabei der HMAC-Key in der
Prozessliste erscheint. Andere Benutzer auf dem System könnten
diesen allzu leicht abfangen.
Die Nutzer der Community Edition werden daher bei intensivem Einsatz um ein eigenes Scripting-Framework um das LDAP-Schema nicht herumkommen, da hier alle Daten zur Generierung des OTP (HMAC) vorhanden sind, ebenso diverse andere Attribute zum Aktivieren oder Deaktivieren von OTP-Benutzern.

Radius

Aufgrund der Radius-Kopplung unterstützt Lin OTP automatisch jeden Dienst, der mit dem Authentifizierungsserver sprechen kann. Das reicht von VPNs bis zur Wireless-Authentifikation. Mit Radius Gina oder dem Radius Credential Provider (beides Non-OSS-Komponenten von LSE) ist es möglich, normale Windows-Workstations (Radius Gina: XP; Credential Provider: Vista, Windows 7) per OTP zu versorgen (Abbildung 2). Mit einer Samba-Konfiguration als PDC lässt sich auf diese Weise ein vollständiger Authentifikations-Stack mit Einmalpasswörtern auf Linux-Basis realisieren. Durch das bei der Anmeldung simultan eingegebene Domänen-Kennwort funktionieren alle üblichen Windows-Mechanismen und Protokolle wie zum Beispiel Kerberos/SSO weiter.

Abbildung 2: Die Windows-Anmeldung an der Samba-Domäne mit dem Client Radius Gina.

Installation

Aktuell existieren lediglich für die Enterpise Edition von Lin OTP Debian-Pakete, die Community Edition muss der Interessierte noch mit Mercurial aus den Repositories auschecken und kompilieren. Wer Aladdin-USB-Tokens einsetzen will, hat für deren Initialisierung Aladdins offiziellen PKI-Client zu verwenden, weil nur dieser (in der Enterprise Edition) die Bibliotheken zum Zugriff auf die Tokens bietet.

Die folgende Installationsprozedur knüpft einen groben Leitfaden zur Kompilierung der Lin-OTP-Komponenten auf Debian Lenny. Es empfiehlt sich immer, vor der Installation die jeweils mitgelieferten Readme-Dateien sowie das Lin-OTP-Manual [5] zu konsultieren. Als Basis verwendet dieser Artikel Freeradius 1.1.7.

Freeradius 2 ist für Lin OTP ab Version 1.3. jedoch getestet und unterstützt. Im ersten Schritt erfolgt das Auschecken der aktuellen Repositories:

hg clone http://opensource.lsexperts.de/hg/linotp/libotpdb
hg clone http://opensource.lsexperts.de/hg/linotp/utils
hg clone http://opensource.lsexperts.de/hg/linotp/rlm_linotp

Dann installiert der Admin benötigte Pakete mit »apt-get install gcc make automake libtool libLDAP2-dev libz-dev libssl-dev libusb-dev« nach, kompiliert und installiert Lin OTP mit Freeradius 1.1.7 und der Konnektor-Bibliothek:

pushd libotpdb; make && make install; popd
wget ftp://ftp.freeradius.org/pub/radius/freeradius-1.1.7.tar.bz2 && tar -xvjf freeradius-1.1.7.tar.bz2
cp rlm_linotp freeradius-1.1.7/src/modules/&& echo 'rlm_linotp' >>/src/modules/stable
pushd freeradius-1.1.7; ./configure && make && make install; popd

Der Copy-Befehl sorgt für das Mergen von »rlm_linotp« in den Freeradius-Build-Tree. Das benötigte LDAP-Schema findet sich im Utils-Repository, das sich mit der Include-Direktive in ein bestehendes Open-LDAP-Verzeichnis einbinden lässt. Jetzt sind schon alle Grundkomponenten verfügbar und die Konfiguration von Lin OTP kann ihren Lauf nehmen. Nach einer erfolgreichen Konfiguration schaut der Eintrag eines Benutzeraccounts so aus wie in Listing 1.

dn: uid=mkromer,ou=otp,dc=linux-magazin,dc=de
cn: mkromer
sn: kromer
mail: medozas@medozas.de
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: LinOtpAccount
LinOtpMaxfail: 3
LinOtpIsactive: TRUE
LinOtpFailcount: 1
LinOtpCount: 151
LinOtpPinHash:: bFd5J8oDJew+NIeoiRR5t2Rsmsv8rJEG6kuX09lU48mhasdf8sd67678a998sd09d=
LinOtpPinSeed:: du4sxh8oFWQ=
LinOtpKeyEnc:: ukocZfH5CmroTpClSD8Aok60zLUhpkr4YSkoyHV8asdfjdYXVCOasdfsdfDFJlciv878659897899=
LinOtpKeyIV:: 6m4zQpstoJ4P4BCyew9HnQ==

Diese Konfiguration sperrt ab dem dritten Misslingen jeden weiteren Loginversuch (Attribut »LinOtpMaxFail«). Die für die OTP-Generierung erforderlichen Werte sind im verschlüsselten Format abrufbar. Für die Nutzung des Backends ist jedoch in jedem Falle das Erzeugen eines getrennten Freeradius-Benutzers mit korrekt limitierenden ACLs zu empfehlen. Da dies jedoch kein traditioneller Bind ist, sind in der Konfiguration für den Freeradius-Benutzer »write«-ACLs zu definieren:

access to attrs="@LinOtpAccount"
by dn="cn=root,dc=linux-magazin,dc=de" write
by dn="cn=otpadmin,dc=linux-magazin,dc=de" write
by * none

Die Hochkommata um »@LinOtpAccount« stehen so zwar nicht im Handbuch, sind aber in einigen Szenarien notwendig. Für die Absicherung des LDAP-Transportwegs erscheint TLS in jedem Fall zwingend erforderlich.

Schwächen und Stärken

Lin OTP ist momentan nur auf 32-Bit-Systemen verfügbar, selbst in der Enterprise Edition. Darüber hinaus ist es nur über Variablensubstitution des Benutzers möglich, in einem Tree nach OTP-Benutzern (»%s«) zu filtern. Dies begrenzt die Einsatz des Benutzerstamms auf nur eine Basis-DN. Eine Beispielkonfiguration der Datei »/etc/otpadm/otpadmrc« zeigt dies deutlich:

  [...]
 
--host 10.0.0.100
--binddn cn=root,dc=linux-magazin,dc=de
--filter uid=%s,ou=users,dc=linux-magazin,dc=de
--enckey 01:00:02b14ab1f3098cs3b1

 
  [...]
 

Als große Stärke von Lin OTP gilt die unkomplizierte Nutzung eines standardisierten, ungepatchten LDAP-Verzeichnisses: Mit der Einbindung des Schemas ist die Installation hier erledigt. So lassen sich bestehende LDAP-Architekturen recht einfach um die Funktionalität von OTP erweitern. Die in der Enterprise Edition verfügbaren Funktionen wie das Management, die Neusynchronisation und Sperrung von Benutzern bieten für Admins mit Shell-Kenntnissen einen angenehmen Weg der Administration.

Modulare Version 2 soll 2010 kommen

Version 2 von Lin OTP ist in Entwicklung und wird im ersten Halbjahr 2010 zumindest als Beta verfügbar sein. LSE schreibt Lin OTP 2 dabei mit dem Fokus auf die Modularität neu. Es soll den Benutzer nicht mehr in die Freeradius-LDAP-Architektur zwingen, ganz im Gegenteil: Sowohl auf der Authentifikations- wie auf der Backend-Seite werden Module an einen primären Dispatcher-Prozess angedockt. Durch den modularen Aufbau ist es ebenso denkbar, dass Drittanbieter mit eigenen Modulen Lin OTP 2 als OTP-Backend nutzen, notfalls auch unter eigener Lizenz (Abbildung 3). Auch MySQL oder eine andere Datenbank ist dann als Backend möglich.

Abbildung 3: Auf den ersten Blick deutlich komplexer, dafür aber wesentlich modularer und flexibler für Admins: Die Struktur der fürs erste Halbjahr 2010 angekündigten Version 2 von Lin OTP erlaubt auch andere Backends als LDAP, zum Beispiel eine SQL-Datenbank.

Zurzeit existiert kein alternatives Open-Source-Projekt mit dem Funktionsumfang von Lin OTP. Jedoch legen die verhältnismäßig aufwändige Installation und kleinere Limitierungen der Architektur dem Benutzer noch ein paar Steine in den Weg. Aber die Entwickler sind sich dessen durchaus bewusst und wollen die Schwächen im Softwaredesign von Version 2 berücksichtigen. Zwar gibt es schon länger freie Komponenten, zum Beispiel das Freeradius-Modul. Aber die Community-Version von Lin OTP als Ansammlung verschiedener Tools steht erst seit September 2009 unter der GPLv2 und versammelt somit noch eine recht kleine Community. Sollte die Version 2 halten, was die Entwickler ankündigen, dann dürften im Jahr 2010 aufgrund der versprochenen Alleinstellungsmerkmale wohl noch einige spannende Features dazukommen. (mfe)

Der Autor
Michael Kromer ist Mitarbeiter der Millenux GmbH und entwickelt an diversen Open-Source-Projekten (Kernel, Asterisk, Open NX, Virtualbox) mit. Seine Leidenschaft sind Open Suse und Virtualisierung. Online ist er unter [http://www.medozas.de]­ zu erreichen.