Schlagwort-Archive: Apache

[Gentoo] Apache 2.4.26 + WordPress: Invalid post type

Hmk? After the latest system updates on Gentoo I noticed WordPress was no longer able to open any kind of post list (“invalid post type”), edit posts (you do not have access to this kind of post) or create posts (form shown, but right sidebar missing). Not quite uncommon, but this time it was no broken plugin – I could reproduce the same behavior with several other WordPress instances with different versions – even a fresh install. That’s a new one.

After some probing around I’m fairly certain Apache 2.4.26 is the culprit, after downgrading to 2.4.25 the problem disappeared. All other downgrades like PHP 7.0.15 instead of PHP 7.0.19 didn’t show any effect. I yet have to confirm which combination ultimately triggers the error (FPM? Event-MPM?), but if you have similar errors: Here is your starting point…

BitBastelei #178 – HTTPs-Zertifikate mit Let’s Encrypt und Apache

BitBastelei #178 - HTTPs-Zertifikate mit Let's Encrypt und Apache

(33 MB) 00:15:45

2016-01-03 10:00 🛈

Über den Dienst “Let’s Encrypt” lassen sich seit einigen Wochen von allen Interessierten kostenlose X.509-Zertifikate anfordern. Diese können z.B. zum Betrieb von HTTPS-Webseiten genutzt werden. So lässt sich z.B. die heimische Owncloud-Installation schnell und einfach absichern.

Apache Reverse Proxy mit LDAP absichern

Apache als Reverse Proxy hatten wir jetzt ja schon öfter, jedoch immer nur als 1:1-Druchlass. Ab und an möchte man jedoch Systeme nur einem beschränken Nutzerkreis verfügbar machen. Der Vorteil einer Filterung auf dem Proxy selbst: Dieser ist meist sicherer als die nachgeschalteten Systeme und hat durch seine Position innerhalb der DMZ bei einem Einbruch weniger Zugriffe auf die internen Systeme als die endgültig erreichten Systeme. Als Nutzerdatenbank ist LDAP, z.B. bei der Nutzung von Microsofts “Active Directory” sehr verbreitet.

Um den Ordner /test abzusichern lässt sich folgender Codeblock nutzen, welcher das vorherige ProxyPass/ProxyPassReverse ersetzt. Ohne Proxy ist der Block natürlich auch zur Absicherungen “normaler” Webseiten nutzbar.

Hiermit dürfen alle Nutzer in der Organisationseinheit “Intern” der Domäne “Adlerweb.info” auf die Ressourcen zutreffen (valid-user).

Es sind auch spezifischere Zuweisungen möglich – über den Nutzernamen:

…über die DN

Für Gruppen gibt es mehrere Möglichkeiten:

ist die klassische Methode, macht jedoch mit Active Directory Probleme: Nutzer in der genannten Gruppe haben fehlerfrei Zugriff, sind jedoch rekursive Gruppen vorhanden schlägt die Authentifizierung fehl. Als Ausweg kann man hier einen LDAP-Filter verwenden – nicht ganz so schön, dafür funktionierend:

Quellen:
http://serverfault.com/a/424706

Outlook Anywhere & Co über Apache als Reverse Proxy

Microsoft Exchange ist ein in kleinen und mittelständischen Firmen verbreiteter Mail/Groupware-Server, welcher sich durch grafische Verwaltbarkeit und gute Integration mit den Office-Produkten des Herstellers auszeichnet. Aus Sicherheitsgründen kann es Sinn machen diesen Server nicht direkt ins Internet zu setzen, sondern die eingehenden Anfragen über ein vorgeschaltetes System zumindest grob filtern zu lassen. Ähnliches hatte ich für Webseiten bereits im Artikel “Apache als Reverse Proxy” vorgestellt.

Exchange geht natürlich wieder eigene Wege – es werden viele Hardcoded-Pfade und ungewöhnliche Protokolltricks genutzt, welche entsprechend umgesetzt werden müssen. Hier gehe ich von einem Exchange-Server aus, welcher bereits vollständig für Zugriffe eingerichtet ist. Als Reverse Proxy kommt Apache 2.4.x zum Einsatz, Clients sind verschiedene Mobilgeräte (Android, iOS, Windows Phone) sowie Outlook 2013. Extern erreichbar ist der Proxy unter “mail.adlerweb.info“, der interne Server ist als “exchange1.lan.adlerweb.info” bekannt.

Erster Schritt: OWA & Co.

OWA (Outlook Web Access) und OMA (Outlook Mobile Access) sind HTTP-basierte Browseroberflächen für den Postfachzugriff, vergleichbar mit den üblichen Webmailern vieler Anbieter. Da diese im Prinzip nur Webseiten sind ist die Konfiguration schnell erledigt. Zu beachten ist, dass Apache bei den URLs auf Groß- und Kleinschreibung achtet, wer also technikferne Benutzer hat sollte ggf. passend vorsorgen. Mit diesen Zeilen ist der Abruf per Browser schon mal möglich.

Zwieiter Schritt: Sonstiges

Es folgen weitere HTTP-Resourcen, welche keine spezielle Konfiguration benötigen. Dies umfasst z.B. öffentliche Ressourcen oder die Webseite zur Kennwortänderung

Schritt 3: Auto-Discovery

Outlook nutzt eine fixe URL um Hinweise zur Selbstkonfiguration zu erhalten. Wer dies nutzt kann auch hier eine einfache HTTP-Weiterleitung bemühen:

Schritt 4: Active Sync

Mobilgeräte verwenden häufig das “ActiveSync”-Protokoll. Im Prinzip auch HTTP, allerdings können einige Anforderungen den Exchange-Server ins Schwitzen bringen. Um hier den Apache nicht ungeduldig werden zu lassen wird der Timeout auf 5 Minuten erhöht.

Schritt 5: RPC

Zuletzt folgt “das Monster”: Outlook selbst. Der Outlook-Client ist in der Lage seine RPC-Pakete über HTTP zu tunneln. Leider hält sich Microsoft hier (wie üblich) nicht an die gängigen Standards. Normalerweise wird eine HTTP-Verbindung geöffnet, der Request übermittelt und die Antwort empfangen. Outlook hingegen baut gleich 2 Verbindungen auf – auf einer wird gesagt “ich habe 1GB Daten”, dann werden 100 Byte als Anfrage gesendet und auf der Zweiten die Antwort erwartet. Da die 100 Byte weit von den angekündigten 1GB entfernt sind und die Info, dass nur ein Teil gesendet wird, seitens Outlook fehlt, wartet der Apache brav auf den Rest, Outlook sendet aber nichts ohne Antwort. Deadlock. Timeout.

Apache selbst geht hier den Weg namens “Pech gehabt“. Da die Microsoft-Methode viel Angriffsfläche bietet und nicht den Standards entspricht ist eine Nutzung offiziell nicht vorgesehen. Auch scheint Microsoft diese Standardverletzung patentiert zu haben, wer also etwas passendes Implementiert könnte ein böses Erwachen erleben. Ist man trotzdem nicht abgeschreckt und möchte Outlook weiterhin nutzen muss ein Addon Abhilfe schaffen: mod_proxy_msrpc. Für Arch Linux ist es jetzt im aktuellen AUR zu finden, alle Anderen können es mit wenigen Zeilen bauen:

Der Zielpfad der letzten Zeile kann sich je nach Distro unterscheiden. Debian/Ubuntu und Gentoo nutzen /usr/lib/apache2/modules/. In der httpd.conf muss analog der anderen Module auch dieses geladen werden:

Im VHost selbst leiten wir den virtuellen RPC-Ordner passend weiter und weisen das neue Modul an den Protokollmurks zuzulassen:

Schritt 6: Achja, TLS

Noch ein Hinweis für alle, die auf moderne Verschlüsselung setzen: Vergesst es. Outlook 2013 unterstützt lediglich TLS1.0 sowie SHA1, entsprechend alte Algorithmen müssen also erlaubt sein.

Quellen:

“Vernünftiges” TLS (SSL/HTTPS/…) mit Apache

Langsam aber sicher setzt sich die verschlüsselte Kommunikation per TLS auch auf Internetseiten (HTTPS) durch. Gut konfiguriert verhindert sie effektiv das Mitlesen der gesendeten Informationen und Einschleusen fremder Codestücke. Wichtig hierbei ist, dass der zugehörige Webserver richtig konfiguriert ist. Ich werde hier auf den aktuellsten Ableger des Apache HTTPd, die Version 2.4, eingehen. Alle Einstellungen werden im jeweiligen virtual Host vorgenommen und sollten teilweise bereits vorhanden sein. Bei Arch Linux befindet sich die SSL-Konfiguration unter /etc/httpd/conf/extra/httpd-ssl.conf.

Zertifikatstheorie

TLS, und damit auch HTTPS, arbeiten mit einem hierarchisch organisierten System. Viele Browser und Betriebssysteme liefern eine Liste mit vertrauenswürdigen Organisationen mit – ist das eigene Zertifikat nicht, zumindest indirekt, von einer dieser Organisationen unterschrieben, so wird eine Sicherheitswarnung angezeigt. Ob dies Sinnvoll ist kann kritisch beäugt werden, vor allem wenn man bedenkt, dass z.B. auch diverse Banken, Regierungen oder Organisationen, welche in der Vergangenheit eher durch Sicherheitsmängel aufgefallen sind, auf dieser Liste stehen. Generell erstell man selbst einen Key, den privaten Schlüssel des Zertifikates, und leitet hiervon einen Request (CSR) ab. Letzterer – und nur dieser – wird an die Zertifizierungsstelle (CA) zum Unterschreiben gegeben. Nachdem die eigene Identität nachgewiesen wurde wird aus Request und Unterschrift das eigentliche, öffentliche Zertifikat, welches das eigene, zweiteilige Schlüsselpaar komplettiert. Als Betreiber hat man hier mehrere Möglichkeiten ein solches SSL-Zertifikat zu erhalten:

  • Kaufen. Die diversen Organisationen bieten ihre Unterschriften üblicherweise gegen Gebühr an. Für eine eizelne Domain ohne Zusatzfunktionen sind etwa 15€/Jahr fällig, möchte man Subdomains oder erweiterte Sicherheitsfunktionen kann der Preis schnell auf über 1000€/Jahr steigen.
  • Selber machen. “Selbstsignierte” Zertifikate sind prinzipiell auch möglich, hier wird aber eine Sicherheitswarnung angezeigt. Der Nutzer muss selbst bestätigen, dass er dem Zertifikat vertraut. Für interne Systeme, auf denen man zentral ein Zertifikatsvertrauen ausrollen kann kein Problem, ansonsten eher nur für eigene Testsysteme geeignet.
  • StartSSL. StartCom stellt mit StartSSL kostenfrei SSL-Zertifikate zur Verfügung. Die Israelische Firma wird von allen gängigen Browsern als Vertrauenswürdig eingestuft. Bedenklich ist jedoch, dass das zurückziehen im Falle eines Sicherheitsproblem Gebühren verursacht und so dazu verleitet bei Problemen die Augen zuzukneifen.
  • CACert …ist eine freie, communitybasierte Zertifizierungsstelle. Auch hier lassen sich kostenfrei Zertifikate signieren, die Qualität der Signatur steigt mit der Anzahl der Personen, welche die Identität prüfen. Leider ist CACert auf vielen Systemen nicht hinterlegt, somit werden auch hier ohne manuellen Eingriff Sicherheitswarungen angezeigt.
  • Let’s Encrypt geht einen ähnlichen, allerdings weniger Community-Zentrierten weg. Sie möchte automatisiert und kostenfrei einfache SSL-Zertifikate bereitstellen. Dahinter stehen Internetgrößen wie Mozilla, Akamai, Cisco oder die EFF, es ist also davon auszugehen, dass die Vertrauensstellungen machbar sein sollen. Warum soll? Let’s Encrypt wird erst mitte Oktober 2015 starten.

Wir basteln einen Request

Welchen weg auch immer man geht: Wir brauchen einen Key und den passenden Request. Fangen wir mit ersterem an:

Der Schlüssel nutzt den RSA-Algorithmus mit einer Länge von 4096 Bit. Empfohlen wird >=2048 Bit, wer aber nicht unbedingt auf die letzten CPU-Takte Performance schaut sollte diese zugunsten der vermutlich längeren Zukunftssicherheit investieren.

Auf Basis dieses Schlüssels wird nun der Request erstellt:

Die Attribute wie Adresse sollten passend den eigenen Angaben ausgefüllt werden. Wichtigster Punkt: Der “Common Name” (CN) muss dem Servernamen entsprechen.

Diesen Request übersendet man nun der Zertifizierungsstelle, die Antwort wird als “server.crt” im selben Verzeichnis gespeichert. Sollte man ein so genanntes “intermediate” benötigen (Das eigene Zertifikat wurde von jemandem unterschrieben welcher selbst nicht vertrauenswürdig ist aber eine Unterschrift einer anderen, vertrauenswürdigen Stelle hat), so werden diese Zertifikate einfach am Ende der Textdatei drangehangen.

Apache-Konfiguration

Erster Schritt: Wir schalten “SSL” (so hies TLS früher mal, Apache hat die Namen beibehalten) ein und geben den Pfad zum Zertifikat an.

Als Nächstes werden die möglichen Protokollversionen und Algorithmen festgelegt. Bei ersterem sollte alles mit SSL abgeschaltet werden – diese haben bekannte Sicherheitslücken. Auch zu TLSv1 gibt es einige Bedenken, jedoch noch keinen praxisrelevanten Angriff – wer auf Nummer sicher gehen will kann auch dies Abschalten, jedoch sperrt man hiermit möglicherweise ältere Geräte und Browser aus. Bei den Ciphern ist die Reigenfolge entscheidend – der erste Eintrag, welcher von Server und Client unterstützt wird, wird verwendet. Einträge mit *DHE* bieten “perfect forward secrecy” (PFS) – hierbei wird für jede Verbindung ein temporäres Passwort abgewandelt. Liest ein Bösewicht die verschlüsselten Daten mit kann er sie später, auch wenn er den Server knackt und so an die Schlüssel kommt, nicht mehr entschlüsseln. RC4 und MD5 werden wegen ihrer hohen Geschwindigkeit zwar gerne von Großkonzernen und einigen Banken verwendet, haben aber bekannte Lücken, sodass sogar das Bundesamt für Sicherheit in der Informationstechnik (BSI) vor deren Einsatz warnt. Die SSL-Kompression hat ebenfalls eine gewisse Angriffsfläche und sollte abgeschaltet werden. Wie immer gilt: Je mehr man auf Sicherheit Wert legt, desto mehr alte Geräte sperrt man aus.

Bei neueren Servern kann man die Ladezeit des Besuchers noch etwas drücken: Dessen Browser geht üblicherweise hin und fragt nach der Verbindung bei der Zertifizierungsstelle, welche die Unterschrift geleistet hat, nach, ob diese überhaupt noch gültig ist. Mit OCSP-Stapeling fordert unser Server regelmäßig eine kleine, unterschriebene “Notiz” der Zertifizierungsstelle an, in welchem die Gültigkeit mit der aktuellen Uhrzeit hinterlegt ist. Diese senden wir gleich mit – ist dem Browser diese Info aktuell genug und die Unterschrift OK muss er nicht extra nochmal nachfragen.

Letzter Punkt: HSTS – HTTP Strict Transport Security. Hiermit sagen wir dem Browser, dass wir für die nächste Zeit ausschließlich per HTTPS arbeiten wollen. Alle zukünfigen Zugriffe werden automatisch per HTTPS abgewickelt, auch wenn der Nutzer nicht per Hand https anfordert. Im Gegensatz zu den gängigen HTTP-Umleitungen spart es einen unverschlüsselten Request, welcher ggf. auch als Angriffspunkt dienen kann. Wenn man seine Webseite absichtlich per HTTP und HTTPS anbieten möchte sollte man den Header natürlich überspringen.

Der Rest
Eine gute Ressource um zwischen Sicherheit und Kompatibilität abzuwähen oder die Konfiguration für andere Webserver und Funktionen anzupassen ist der Mozilla SSL Configuration Generator, auf dessen Ausgaben auch das hiesige Beispiel basiert.

Sollen alle Anfragen über HTTPS laufen kann man den HTTP-Listener anweisen für alle Anfragen mir einer Umleitung auf die HTTPS-Seite zu antworten. Hierzu reicht folgende Zeile im zuständigen VHost:

Wer testen möchte, ob alles Funktioniert hat und welche Geräte und Browser zu alt sind um auf die Webseite zugreifen zu können, kann die SSL-Tester von SSLLabs nutzen – dieser generiert einen ausführlichen und gut verständlichen Report und gibt weitere Tipps bei möglichen Problemen.

Apache als Reverse Proxy

Apache ist als Webserver den meisten bekannt, mit der üblicherweise mitgelieferten mod_proxy_html kann er jedoch auch als reverse Proxy eingesetzt werden. Ein solcher Proxy nimmt HTTP-Anfragen entgegen und leitet sie an einen anderen Weberver weiter. Dies kann z.B. hilfreich sein um Anfragen auf mehrere Server im Hintergrund zu verteilen, eine zusätzliche Abschottung interner Server bereitstellen oder auch durch die Terminierung der HTTPS-Verbindung oder dem Vorfiltern von Headern die Belastung der nachgeschalteten Systeme zu mindern.

Zur Konfiguration stellt man erst sicher, dass das Modul geladen ist. Hierzu wird in der Apache-Konfiguration (Arch Linux: /etc/httpd/conf/httpd.conf) sichergestellt, dass die folgenden Zeilen aktiv sind:

Nun kann im gewünschten VHost eine passende Weiterleitung realisiert werden:

Wenn das interne Ziel per HTTPS angesprochen werden soll, so sollte die jeweilige Zertifizierungsstelle im System bekannt sein. Hierzu kann auch eine eigene CA-Datei verwendet werden:

Wenig Zeilen, große Wirkung: Surft man nun die angegebenen Pfade des Webservers an, so wird die Anfrage an den angegebenen Server weitergeleitet. Der Apache selbst terminiert hierbei die Clientverbindung, entsprechend werden Funktionen (z.B. externes HTTPS-Zertifikat) verwendet. Auch DoS-Angriffe oder versuche mit kaputten HTTP-Headern treffen primär den exponierten Server und schlagen nicht ohne Weiteres zum internen Webserver durch.

Update: ProxyRequests Off fehlte – wenn auf On agiert der Server als offener Proxy-Server. Default ist Off, daher sollte auch ohne explizites definieren nichts passieren, aber vorsichtshalber kann es nichts schaden hier nochmal zu definieren.

mod_scrambleip aktualisiert für Apache 2.4

Vor einigen Jahren hatte ich einen kleinen Codeschnipsel für Apache 2.x zusammenkopiert, welcher direkt in Apache die IP und den Hostname des Besuchers in Teilen entfernt um eine grobe Anonymisierung zu ermöglichen. Mit Apache 2.4 hat sich der interne Aufbau des Webservers etwas geändert, der Code wurde entsprechend angepasst, die alte Version für 2.2 ist als Branch zu finden.