BitBastelei #163 – Dell PowerConnect 2724 12V-Umbau

Und wieder ein Bauteil, welches an die Solaranlage soll: Ein alter 24-Port-Switch der Serie Dell PowerConnect-Serie. Leider intern nicht auf 12V wie der bereits umgestellte SMC-Switch, aber auch das sollte sich wohl lösen lassen.

Weitere Links:

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.

MySQL: Anlegen neuer Benutzer schlägt fehl

Dann nur noch schnell einen neuen User für die Datenbank anlegen…oder auch nicht.

Ursache ist, dass man zuvor ein MySQL-Update verpennt hat und lediglich die Binarys, nicht jedoch die Systemdatenbanken aktualisiert hat. Nachholen lässt sich dies auf der Konsole mit einem schnellen

Hierdurch werden die Tabellen auf den aktuellen Stand gebracht und das anlegen neuer Nutzer sollte wieder problemlos möglich sein.

PHP mail() – Header-Fehler in aktuellen Versionen

“Das hat aber früher funktioniert”! Exakt das dachte ich mir, als nach einem PHP-Update ein kleines “Aushilfsscript” seinen Dienst verweigerte. Das Script nimmt eine fertige E-Mail, entfernt einige Header, welche das Quellsystem nicht Standardkonform einbringt, und sendet die gesäuberte Mail weiter. Um unnötiges Parsing zu vermeiden ging die komplette Mail in den Header.

Nicht schön, da aber nur ersetzt/ergänzt wird muss nicht bei jeder Änderung der Quelle eine Anpassung erfolgen um Content und Header sauber zu trennen. Leider ist seit den letzten Versionen (vermutlich 5.4.43/5.5.26) diese Anwendung nicht mehr erlaubt. Hat man zwei Newlines (\r\n\r\n – genutzt zur Content-Trennung) im Header bricht PHP mit einer Fehlermeldung ab. Das Ganze soll dazu dienen Personen zu schützen, welche Fremddaten aus unsicheren Quellen ohne Eingabevalidierung nutzen und so ihre Anwendung verwundbar machen. Leider trifft es aber eben auch solche Anwendungen wie meine, was gerade bei solchen minor-Versions etwas unschön ist. Nunja, mein Script spricht nun direkt SMTP mit dem zuständigen Mailserver und umgeht so die PHP-mail()-Funktion. Problem solved.

Related:

Pidgin XMPP mit Selfsigned-Zertifikaten

Huh? Bei einer Neueinrichtung ließ sich Pidgin nicht dazu überzeugen eine Verbindung zu meinem XMPP(/Jabber)-Server herzustellen – SSL fehler. Ursache ist offenbar, dass das verwendete Zertifikat nicht von einer CA signiert wurde, der das System standardmäßig vertraut.

Erste Möglichkeit: Die CA bzw. das selbstsignierte Zertifikat im System importieren. Auf den meisten Systemen sind hierzu jedoch Systemverwalterrechte erforderlich, sodass diese Methode nicht immer machbar ist – also schnell weiter zu…

Zweite Möglichkeit: Per Hand. Hierzu benötigen wir ebenfalls erst mal das Zertifikat. Hat man dies nicht zu Hand kann man sich mit OpenSSL behelfen. Als Client instrutiert wird u.A. das Zertifikat in ASCII ausgegeben:

Dieses Zertifikat – inklusive der BEGIN/END CERTIFICATE-Header – kopiert man in eine Textdatei und speichert sie als *.pem-Datei auf der Festplatte ab. Um dieses Zertifikat nun in Pidgin zu erlauben öffnet man Werkzeuge->Zertifikate und wählt unter hinzufügen die zuvor gespeicherte Datei aus.

sslpidgin

Nun sollte die Verbindung korrekt funktionieren. Schade, dass hier keine einfachere Nachfrage implementiert wurde, welche beim ersten Verbinden ohne weiteren Eingriff eine Zertifikatsausnahme zulässt.

Notizzettel: Wenn mal wieder sinnlose Fehler auftreten…

Wenn man plötzlich mit recht nichtssagenden Meldungen wie

oder auch

beworfen wird, so kann die Ursache auch recht banal und im Log schnell auffindbar sein:

Eyeup, die Kiste hat recht wenig RAM und keinen SWAP eingerichtet – könnte krachen, vor allem wenn Speicherfresser wie node.js mitreden möchten. Auch kann es in diesem Fall helfen /tmp nicht als Ramdisk (tmpfs) laufen zu lassen.

BitBastelei #162 – Wir bauen ein Freifunk-Gluon

Zwischen den ganzen Chaos-Konferenzen muss auch noch etwas Hausarbeit sein: Das auf OpenWRT basierende Freifunk-Framework “Gluon” ist vor kurzem in der Version 2015.1.2 erschienen – guter Zeitpunkt um die neue Version zu kompilieren und zu zeigen, wie man selbst mit wenigen Schritten seine eigene Firmware baut und so lokale Anpassungen vornehmen kann.

Gluon: https://github.com/freifunk-gluon/gluon
Sit.conf MYK: https://github.com/FreifunkMYK/site-ffmyk

ZFS: Dateien trotz vollem Datenträger löschen

Narf – da war der Bug schneller als der Admin hinter dem Monitoring: 0k freier Speicher vermeldet ein ZFS-Storage. Na kein Problem, kaputtes Programm gestoppt und schnell mal den Schrott gelöscht. Oder auch nicht:

Really?!

Ursache wäre wohl “COW” – Copy on write. Bei Änderungen werden die neuen Daten erst mal auf die Festplatte geschrieben – erst wenn dort kein Fehler auftritt werden die entsprechenden Zeiger im Dateisystem aktualisiert und die vorherigen Daten ungültig.

Die Lösung, welche z.B. bei der Uni Freiburg zu finden ist, ist effektiv, aber mir nicht wirklich verständlich: Anstatt die Datei zu löschen wird sie erst mit /dev/null überschrieben – dies schlägt trotz COW offenbar nicht fehl. Der so freigewordene Speicherplatz, welche zuvor durch den Inhalt der Datei belegt wurde, sollte nun ausreichen um den Löschbefehl umzusetzen:

Warning: Nerd inside