Apache und kein User

Lennarts und meine Blogposts zum Thema Apache-Authentifizierungen haben sich bisher eigentlich immer damit befasst wie man möglichst viele Benutzer aus einem zentralen Verzeichnisdienst durch den Webserver authentifiziert. Was aber tun wenn für bestimmte automatisierte Zugriffe keine Authentifizierung erwünscht ist? Komplett auf die Authentifizierung verzichten möchte man meist nicht, also muss eine Ausnahme her. Aber wie?
In Apache 2.2 heißt die Direktive dafür “Satisfy any”. Mit dieser lässt sich festlegen dass entweder eine Allow-Regel oder die Benutzer-Authentifzierung erfüllt werden muss. Als Konfigurationsabschnitt sieht dies dann beispielsweise so aus:

Order allow,deny
Allow from 192.168.0.23
Allow from 192.168.0.42
Include auth.inc
Satisfy any

Mit Apache 2.4 ändert dies sich zu:

<RequireAny>
Require host 192.168.0.23
Require host 192.168.0.42
Require valid-user
</RequireAny>

Damit könnte nun von die zwei Systemen ohne Authentfizierung anmelden. Handelt es sich dabei um Proxies können dies sogar noch wesentlich mehr sein. Was nun wenn aber eine Authentifizierung nötig ist um die gewünschten Rechte zu erlangen, wenn ohne Authentifizierung durch Apache der interne Authentifizierungsdialog erscheint? Muss sich nun doch überall immer und überall wer anmelden?
Auch hierfür gibt es eine Lösung, indem durch entsprechende Rewrite-Regeln automatisch ein Benutzer angemeldet wird. Einmal als Beispiel anhand von Nagvis und unseren zwei Systemen von oben:

RewriteEngine On
RewriteBase /nagvis
RewriteCond %{REMOTE_ADDR} ^192\.168\.0\.23 [OR]
RewriteCond %{REMOTE_ADDR} ^192\.168\.0\.42
RewriteRule ^(.*)$ - [E=REMOTE_USER:nagvisuser]

Diese Konfigurationszeilen in Kombination mit dem ersten Beispiel sorgen dafür, dass für die zwei Systeme die Benutzer-Authentfizierung entfällt und ihr Webseiten-Aufruf um die Umgebungsvariable REMOTE_USER mit dem Wert nagvisuser ergänzt wird. Somit wäre der Benutzer nagvisuser automatisch angemeldet.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Apache 2: Authentifizierungsmethoden über Source-IP steuern

Mit den normalen Bordmitteln des Apache2 ist es aktuell nicht möglich, zwei verschiedene Authentifizierungsmethoden zu verwenden. Gebrauchen kann man das aber beispielsweise sehr gut, wenn man einen webbasierten Dienst hat, welchen man für das interne Firmennetzwerk gegen LDAP und von extern über MOTP authentifizieren lassen möchte. Vorteil ist dabei, dass die nach außen offene Seite nicht durch Bruteforce-Attacken “gehackt” werden kann.
Um diese Unterscheidung der Netze zu realisieren, wird eine iptables-Regel eingerichtet, welche alle Anfragen einer bestimmten Quelle auf einen anderen Port umleitet. Zusätzlich muss noch ein VHost angelegt werden, welcher auf diesem Port lauscht und die gewünschte Authentifizierung anbietet.
Ein kleines Praxisbeispiel:
Ich möchte, dass alle Anfragen, welche von extern kommen, gegen MOTP authentifiziert werden. Dafür lege ich einen VHost an, der auf Port 80 lauscht und MOTP als Authentifizierung anbietet.
Mein internes Netz, welches durch NAT nur eine IP (1.2.3.4) nach außen besitzt, soll sich gegen LDAP authentifizieren. Dafür lege ich ebenfalls einen VHost an, der auf Port 81 lauscht.
Nun leite ich den Verkehr, der von meinem Router des internen Netzes (IP 1.2.3.4) kommt auf Port 81 um. Da ich nicht will, dass alle Anfragen umgeleitet werden, weil ich noch mehrere Seiten auf meinem Server betreibe, habe ich zusätzlich den “LDAP-VHost” auf die IP 127.0.0.2 gebunden.
Jetzt richte ich meine iptables-Regel ein:

iptables -t nat -A PREROUTING -s 1.2.3.4 -d 127.0.0.2 \
                -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 81

Nun werden alle Anfragen wie gewünscht umgeleitet. Mit iptables-save kann ich mir die aktuellen Einstellungen ausgeben lassen und sie später per init-Skript wieder mit aufnehmen. Somit sind die Einstellungen auch “rebootfest”. Wichtig sei noch zu erwähnen, dass pro VHost eine eigene, externe IP benötigt wird.

One Time Password Authentifizierung mit MOTP

Eine OTP Authentifizierung ist eine praktische und vor allem sichere Angelegenheit. Aus verschiedenen Daten wird ein Passphrase errechnet, welcher nur für einen kurzen Zeitraum und einmalig gültig ist und somit nicht mehrmals verwendbar.
Es gibt viele Lösungen, welche auf Hardware-Tokens setzen und entsprechende Anschaffungskosten anfallen. Als gute Alternative bietet sich das Mobile One Time Password-Projekt an, kurz MOTP. MOTP ist mehr der eigentliche Algorithmus, auf dessen Basis diverse Clients für alle gängigen Betriebssysteme und mobilen Endgeräte (J2ME, Blackberry, Android, iOS, WebOS …) sowie serverseitig viele Implementierungen entwickelt worden sind. Heut möchte ich kurz ein Apache Modul und einen iOS Client vorstellen, mit denen eine einfache OTP Authentifizierung realisiert werden kann.
MOTP berechnet seine OTPs auf Basis dreier Komponenten:

  • PIN (bleibt gleich, wird beim Client eingegeben)
  • Secret (Im Regelfall ein Hash, welcher aus Zufallsdaten vom Client generiert wird)
  • Uhrzeit (MOTP setzt auf zeitbasierte Generierung, Zeiten müssen auf Client und Server übereinstimmen! – NTP)

Das verwendete Apache Modul, mod_authn_otp, muss zunächst compiliert werden. Eine Anleitung, welche Abhängigkeiten installiert werden müssen und wie es ordnungsgemäß installiert wird, findet sich im Projektwiki.
Angesprochen wird das Modul in der Apache Config als normales Basic Auth. Hier wird auch ein UserFile angegeben, wo die jeweiligen Nutzer mit ihren Secrets und dazugehörigen Pins angegeben werden. Zu beachten ist, dass dieses File vom Apache Benutzer schreibbar sein muss, damit das Modul einen Timestamp setzen kann. Dies bietet die Funktion, dass ein Token für einen festgelegten Zeitraum gültig ist, und somit der Nutzer nicht ständig aufgefordert wird, einen neuen Token eingeben zu müssen.
Als Client habe ich mOTP aus dem AppStore genommen. Diese App ist sehr einfach in der Bedienung und generiert selbst einen Secret, welcher in das UserFile übernommen werden kann. Auf der MOTP Projektseite gibt es eine große Auswahl an weiteren Clients für diverse Systeme. Beispielsweise wurde ein Client in Python geschrieben, welcher auf jedem gängigen OS funktionieren sollte.