Alle Beiträge von adlerweb

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.

SSLProxyCACertificateFile /etc/ssl/private/interneca.crt

ProxyPreserveHost On
SSLProxyEngine on

# http://stackoverflow.com/questions/3889574/apache-and-mod-proxy-not-handling-http-100-continue-from-client-http-417
RequestHeader unset Expect early

# Rewrite the WWW-Authenticate header to strip out Windows Integrated Authentication (NTLM) and only use Basic-Auth -> http://social.technet.microsoft.com/Forums/exchange/en-US/7eb1f39f-c53f-49aa-9038-6962bfc386ca/autodiscover
SetEnvIf user-Agent ".*MSIE.*" value BrowserMSIE
 Header unset WWW-Authenticate
 Header add WWW-Authenticate "Basic realm=DomainLogon"

RequestHeader unset accept-encoding
ProxyPreserveHost On

#Outlook Web Access (Exchange >=2007)
ProxyPass /owa https://exchange1.lan.adlerweb.info/owa
ProxyPassReverse /owa https://exchange1.lan.adlerweb.info/owa
ProxyPass /OWA https://exchange1.lan.adlerweb.info/owa
ProxyPassReverse /OWA https://exchange1.lan.adlerweb.info/owa

#WAP Zugriff (Exchange=2003)
#ProxyPass /oma https://exchange1.lan.adlerweb.info/oma
#ProxyPassReverse /oma https://exchange1.lan.adlerweb.info/oma
#ProxyPass /OMA https://exchange1.lan.adlerweb.info/oma
#ProxyPassReverse /OMA https://exchange1.lan.adlerweb.info/oma

#Falls zuvor ein ISA/TMG im Einsatz war haben evtl einige User die HTML-Loginseite
#gespeichert - leiten wir passend weiter.
RewriteEngine on
RewriteRule   "^/CookieAuth.dll(.*)"  "/OWA/"  [R,L]

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

# OWA-URL fuer Exchange < =2007
ProxyPass /exchange https://exchange1.lan.adlerweb.info/exchange
ProxyPassReverse /exchange https://exchange1.lan.adlerweb.info/exchange
ProxyPass /Exchange https://exchange1.lan.adlerweb.info/exchange
ProxyPassReverse /Exchange https://exchange1.lan.adlerweb.info/exchange

# OWA Icons, CSS, JS, etc (Exchange >=2000 < =2007)
ProxyPass /exchweb https://exchange1.lan.adlerweb.info/exchweb
ProxyPassReverse /exchweb https://exchange1.lan.adlerweb.info/exchweb
ProxyPass /ExchWeb https://exchange1.lan.adlerweb.info/exchweb
ProxyPassReverse /ExchWeb https://exchange1.lan.adlerweb.info/exchweb

# Öffentliche Ordner (Exchange <=2003, >=2007 interne Umleitung auf /OWA)
ProxyPass /public https://exchange1.lan.adlerweb.info/public
ProxyPassReverse /public https://exchange1.lan.adlerweb.info/public
ProxyPass /Public https://exchange1.lan.adlerweb.info/public
ProxyPassReverse /Public https://exchange1.lan.adlerweb.info/public

# Einstellungen um per OWA das Kennwort zu aendern
ProxyPass /iisadmpwd https://exchange1.lan.adlerweb.info/iisadmpwd
ProxyPassReverse /iisadmpwd https://exchange1.lan.adlerweb.info/iisadmpwd

# Out of Office & Free/Busy-Infos (Exchange >=2007)
ProxyPass /EWS https://exchange1.lan.adlerweb.info/EWS
ProxyPassReverse /EWS https://exchange1.lan.adlerweb.info/EWS
ProxyPass /ews https://exchange1.lan.adlerweb.info/EWS
ProxyPassReverse /ews https://exchange1.lan.adlerweb.info/EWS

# Offline-Adressbuecher (Exchange >=2007)
ProxyPass /OAB https://exchange1.lan.adlerweb.info/OAB
ProxyPassReverse /OAB https://exchange1.lan.adlerweb.info/OAB
ProxyPass /oab https://exchange1.lan.adlerweb.info/OAB
ProxyPassReverse /oab https://exchange1.lan.adlerweb.info/OAB

# Unified Messaging (Exchange >=2007)
#ProxyPass /UnifiedMessaging https://exchange1.lan.adlerweb.info/UnifiedMessaging
#ProxyPassReverse /UnifiedMessaging https://exchange1.lan.adlerweb.info/UnifiedMessaging
#ProxyPass /unifiedmessaging https://exchange1.lan.adlerweb.info/UnifiedMessaging
#ProxyPassReverse /unifiedmessaging https://exchange1.lan.adlerweb.info/UnifiedMessaging

# Exchange Control Panel (Exchange >=2010)
ProxyPass /ECP https://exchange1.lan.adlerweb.info/ECP
ProxyPassReverse /ECP https://exchange1.lan.adlerweb.info/ECP
ProxyPass /ecp https://exchange1.lan.adlerweb.info/ECP
ProxyPassReverse /ecp https://exchange1.lan.adlerweb.info/ECP

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:

# AutoDiscover externer Outlook-Client
ProxyPass /autodiscover https://exchange1.lan.adlerweb.info/autodiscover
ProxyPassReverse /autodiscover https://exchange1.lan.adlerweb.info/autodiscover
ProxyPass /Autodiscover https://exchange1.lan.adlerweb.info/Autodiscover
ProxyPassReverse /Autodiscover https://exchange1.lan.adlerweb.info/Autodiscover
ProxyPass /AutoDiscover https://exchange1.lan.adlerweb.info/AutoDiscover
ProxyPassReverse /AutoDiscover https://exchange1.lan.adlerweb.info/AutoDiscover

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.

# ActiveSync - PDA/Mobilsync & Push (Exchange >=2003)
# Timeout 5Min um dem Exchange etwas zeit zu geben
ProxyPass /Microsoft-Server-ActiveSync https://exchange1.lan.adlerweb.info/Microsoft-Server-ActiveSync connectiontimeout=600
ProxyPassReverse /Microsoft-Server-ActiveSync https://exchange1.lan.adlerweb.info/Microsoft-Server-ActiveSync

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:

cd /tmp
git clone git://github.com/bombadil/mod_proxy_msrpc
cd mod_proxy_msrpc/
./configure
make
cp src/.libs/mod_proxy_msrpc.so /usr/lib/httpd/modules/

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:

LoadModule proxy_msrpc_module modules/mod_proxy_msrpc.so

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

OutlookAnywherePassthrough On

ProxyPass /rpc https://exchange1.lan.adlerweb.info/rpc/
ProxyPassReverse /rpc https://exchange1.lan.adlerweb.info/rpc/

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:

cd /etc/ssl/private
openssl genrsa -out server.key 4096

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:

openssl req -new -key server.key -out server.csr -sha512

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.

SSLEngine on
    SSLCertificateFile      /etc/ssl/private/server.crt
    SSLCertificateKeyFile   /etc/ssl/private/server.crt

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.

    SSLProtocol             all -SSLv3 -TLSv1
    SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
    SSLHonorCipherOrder     on
    SSLCompression          off

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.

    SSLUseStapling          on
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors off

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.

    # HSTS (mod_headers is required) (15768000 seconds = 6 months)
    Header always set Strict-Transport-Security "max-age=15768000"

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:

Redirect / https://testserver.adlerweb.info/

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.

Unknown column 'plugin' in 'mysql.user'

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

mysql_upgrade -u root -p

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.

$headers[] = 'From: Test <test@adlerweb.info>';
$headers[] = 'Cc: Test2 <test2@adlerweb.info>';
$headers[] = 'X-cleaned: cleaned';
//[…]
$headers[] = '  boundary="'.$boundary.'"';

//Neue Header und Content zusammenführen
$content = implode("\r\n", $headers)."\r\n\r\n".'-----'.implode('-----',$content);

//Mailversand
$check = mail($receiver, NULL, NULL, $content);

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:

openssl s_client -host myjabber.server -port 5222  -starttls xmpp

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

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.

Bild: https://adlerweb.info/blog/wp-content/uploads/2015/08/sslpidgin-300×120.png

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

Version: 2.1.1, Linux Version: 2.1.1, Package Iteration: 
go get -v github.com/tools/godep
github.com/tools/godep
go build github.com/tools/godep: /usr/lib/go/pkg/tool/linux_amd64/link: signal: killed
exit status 1
exit status 1

oder auch

remote: Counting objects: 56476, done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 56476 (delta 0), reused 0 (delta 0), pack-reused 56464
Receiving objects: 100% (56476/56476), 94.21 MiB | 6.98 MiB/s, done.
error: index-pack died of signal 92)   
fatal: index-pack failed

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

Out of memory: Kill process 2308 (git)

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.

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:

rm: cannot remove file: Disk quota exceeded

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:

rm test
#rm: cannot remove file `test': Disk quota exceeded
cp /dev/null test
rm test
stat test
stat: der Aufruf von stat fuer "test" ist nicht moeglich: Datei oder Verzeichnis nicht gefunden

Arduino® Pro Mini Pinout Cheat-Sheet

Ich arbeite auf Grund des geringen Preises häufig mit Arduino®-kompatiblen Boards der „Pro Mini“-Serie. Leider sind die Pins auf diesen Boards nicht nach der CPU sondern dem Standard der Arduino-IDE beschriftet. Bisher nutzte ich diverse Pinout Cheat-Sheets aus dem Netz, jedoch haben viele dieser Diagramme vertauschte Pins, welches bei mir in den letzten Wochen zu einigen fehlerhaften Aufbauten führten. Lange Rede kurzer Sinn: Ich werfe ein weiteres Cheat-Sheet in den Raum – hoffentlich mit weniger fehlerhaft beschrifteten Pins. Wenn doch etwas auffällt: Die Kommentare sind offen.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/08/prominipinout-1.2-300×212.png
[DA]

s3cmd: Instabile Verbindung bei PUT

s3cmd ist ein kleines CLI-Tool, welches die Verwaltung von Amazon S3 ermöglicht. Beim hochladen von Dateien mit der Version 1.0.1 aus dem Paketmanager zeigte sich jedoch folgendes Bild:

WARNING: Upload failed: test ([Errno 32] Broken pipe)
WARNING: Retrying on lower speed (throttle=1.25)
WARNING: Waiting 15 sec...
test -> s3://testbucket/test  [1 of 1]
       1234 of 5678     0% in    1s     1.23 kB/s  failed
ERROR: Upload of 'test' failed too many times. Skipping that file.

Ursache ist in meinem Fall, dass mein Bucket nicht in „USA Standard“ liegt. Ältere Versionen von s3cmd greifen jedoch immer dort zu. Zwar leitet Amazon den Request passend um, hierbei scheint sich das Tool jedoch zu verschlucken.

Beheben lässt sich der Fehler auf 2 Arten: Entwerden man nutzt eine neuere Version des Tools, z.B. 1.5.2, diese müssen jedoch meist manuell installiert werden und sind nicht in den Quellen der Paketmanager zu finden. Alternativ kann man der alten Version auf die Sprünge helfen, in dem man die Server direkt richtig hinterlegt, für Irland z.B.:

[default]
...
bucket_location = IE
...
host_base = s3-eu-west-1.amazonaws.com
host_bucket = %(bucket)s.s3-eu-west-1.amazonaws.com
...
use_https = True
    

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:

LoadModule xml2enc_module modules/mod_xml2enc.so
LoadModule proxy_html_module modules/mod_proxy_html.so

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

#Nur definierte Requests annehmen
ProxyRequests Off

#Fileshare
ProxyPass /dateiserver http://publicfiles.lan.adlerweb.info/upload
ProxyPassReverse /dateiserver http://publicfiles.lan.adlerweb.info/upload

#Requestform
ProxyPass /request https://http.lan.adlerweb.info/request
ProxyPassReverse /request https://http.lan.adlerweb.info/request

#Buildimg
ProxyPass /autobuild https://inferno.lan.adlerweb.info/results
ProxyPassReverse /autobuild https://inferno.lan.adlerweb.info/results

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:

SSLProxyCACertificateFile /etc/ssl/private/interneca.crt

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.