Archiv der Kategorie: Restmüll

Alles, was sonst nicht passt

Yubikey: Nicht ganz unkaputtbar

tl;dr: YubiKeys nicht am Schlüsselbund festmachen

Wenn es um Security-Tokens geht, hat YubiCo mit seinem YubiKey klar die Nase vorn. Nicht zuletzt, da diese so ziemlich die ersten Geräte waren, welche die gängigsten Sicherheitsmechanismen in einem Gerät vereinen konnten. Vor allem U2F, TOTP (aka Google Authenticator) und PGP sind bei mir fast dauerhaft im Einsatz. Mit dieser Kombination kann ich 2-Faktor-Anmeldung auf Webseiten nutzen, E-Mails signieren und entschlüsseln, mich auf SSH-Servern anmelden und Zugriff auf lokale Dateien und Programme absichern. Auch Zertifikate, aka X.509, sind eine praktische Sache, können sie doch für Logins in Windows-Netzen, S/MIME oder das signieren von Dokumenten unter Windows genutzt werden. Zwar lassen sich all diese Mechanismen auch ohne Dongle nutzen, dieser bringt jedoch zwei wichtige Sicherheitsverbesserungen mit sich: Der Zugriff ist nur möglich, wenn das Gerät eingesteckt ist, sodass eine “versehentliche” Nutzung erschwert wird. Zudem sind die privaten Schlüssel auf einem – vorzugsweise sicheren – Microcontroller gespeichert und können das Gerät nicht mehr verlassen.

Ich selbst bin Ende 2016 auf den YubiKey NEO * umgestiegen. Dieser kann per USB oder NFC genutzt werden. Letzteres ist z.B. für Logins oder Mailverkehr am Handy interessant. Etwas bedenken hatte ich, da USB-Sticks bei mir selten lange überleben und ein YK nicht gerade günstig ist. Das Werbesersprechen “unkaputtbar”, die robust aussehende Form und Empfehlungen aus dem Bekanntenkreis überzeugten jedoch am Ende. Seit dem ist er Stammgast an meinem Schlüsselbund, somit ständiger Begleiter und wird entsprechend viel genutzt.

YubiKey NEO an Schlüsselbund
YubiKey Neo an Schlüsselband

Schnellvorlauf November letzten Jahres, also 2 Jahre nach dem Kauf. Einiges hatte sich getan, aber der YK verrichtete noch anstandslos seine Dienste. Also fast. Von einem Tag auf den Anderen war NFC nicht mehr nutzbar und ich somit auf die Nutzung am PC beschränkt. Kein Beinbruch, Handy-Logins nutze ich eher selten, allerdings auch kein Pluspunkt für mein Vertrauen in die Haltbarkeit. Ich vermutete einen Softwarefehler, alternativ eine Einwirkung durch statische Aufladung. Beides Dinge, die nicht passieren sollten. Auch sonst zeigten sich Schwächen: Aus Sicherheitsgründen ist es nicht möglich die Firmware der Geräte zu aktualisieren. Hierdurch war ich bei PGP auf Keys mit maximal 2048 Bit limitiert. Noch OK, aber auch nicht toll. Einzige Möglichkeit auch in den Genuss neuerer Verfahren zu kommen wäre ein neueres Modell, diese hatten zum damaligen Zeitpunkt jedoch kein NFC und nutzten für PGP nun statt einer Open-Source-Lösung eine Eigenentwicklung des Herstellers, welcher sich nicht einsehen ließ.

Meh. Roughly 2 years after I bought my @yubico #Yubikey Neo it already failed. USB luckily still OK, but NFC completely dead. Really hoped these things would be more durable :<

adlerweb|BitBastelei@adlerweb, 2018-11-21

Da die neueren Modelle für mich keine Option waren wandte ich mich via Twitter an den Hersteller. Unter “unkaputtbar” verstehe ich etwas Anderes, als 2 Jahre und somit knapp über den regulären Gewährleistungen. Meine Intention: Ich wollte wissen was da schief gelaufen ist, ob es eventuell durch einen Reset o.Ä. behoben werden kann, wie man das verhindern kann und ob bei zukünftigen Modellen dieses Problem umgangen werden kann. Man verwies mich auf das Ticketsystem, antwortete dort jedoch nur mit Textblöcken. Nach meiner Info, dass ich die Diskusion in dem Fall für Sinnlos hielt bot man mir den Austausch gegen einen neuen Neo an. Da auf Grund der alternden PGP-Unterstützung und der unbekannten Fehlerursache das Modell eher auf meiner Abschussliste war lehnte ich dankend ab und nutzte mein Modell per USB weiter.

10 Monate später sprach mich ein Mitglied des lokalen Hackerspace auf den YubiKey an. Ein Arbeitskollege hätte da einen unschönen Ausfall mit seinem Key gehabt. Das ABS-Gehäuse wäre durch den Schlüsselring durchgescheuert und das Gerät hätte den Dienst versagt. Könnte das mit meinem Problem zu tun haben? Sure enough: Auch bei mir ist das Plastik im Bereich des Schlüsselrings schon sehr abgenutzt. Dass das ein technisches Problem verursachen könnte hatte ich gar nicht auf dem Schirm.

Abgenutzter Bereich am Schlüsselring-Loch eines YubiKey NEO

Zudem: ABS? Durchscheuern? Ich hatte vermutet, dass unter der Plastik-Packung noch ein Metallring eingearbeitet wäre, welche das ganze etwas verstärkt. Aber jetzt, wo ich das höre – hm, ja, da reflektiert ja etwas. Ein Blick unter dem Mikroskop verrät recht schnell, was mein NFC getötet hat: die Antenne ist um das Schlüsselring-Loch gelegt und inzwischen durchgescheuert. WTF.

Beschädigte NFC-Antenne an einem YubiKey NEO

Erinnert Ihr euch dran, dass ich ABS sagte? ABS kennt man ja auch von 3D-Druckern, hier ist es üblich mit Aceton das Plastik nach dem Druck anzulösen und zu glätten. Mit entsprechenden Konzentrationen kann man das Plastik aber auch einfach wegschmelzen. Exakt dies hat HexView mit einem YubiKey Neo gemacht, sodass sich das Innenleben in voller Pracht bewundern lässt. Glücklicherweise sieht es so aus, als ob hier wirklich nur die Antennen vorbeilaufen und ein Ausfall eher nicht wahrscheinlich ist. Trotzdem würde ich jedem mit YubiKey NEO raten, an dieser Stelle mit Aceton das Plastik anzulösen und mit mehr ABS oder gar einem Metallring zu verstärken um Ausfälle durch Abnutzung zu vermeiden.

Ich selbst bin etwa an selber Stelle wie vorher: Ich werde den NEO wohl weiter nutzen. Zwar hat man inzwischen den YubiKey 5 NFC * herausgebracht, welcher wieder NFC kann, auch längere Keys für PGP unterstützt und das bei mir ursächliche Schlüsselring-Loch verstärkt hat, allerdings sind mir sowohl die fehlenden Quellen als auch die unschöne Reaktion des Supports doch eher sauer aufgestoßen. Hätte man mir bei meiner Nachfrage geantwortet, dass es vermutlich ein bekanntes Problem wäre und man das in der nächsten Produktversion angehen würde – ich hätte sie vermutlich direkt nach dem Release hier liegen gehabt. Leider mangelt es aber auch an Konkurrenz. Viele Keys wie z.B. Thetis oder Googles TitanKey nutzen ausschließlich U2F. Toll für’s Web, aber meine Hauptanwendung ist eher PGP. TOTP sucht man bei allen vergeblich, ließe sich mit etwas Gebastel aber halbwegs brauchbar in Software nachbilden – freie Standards haben so ihre Vorteile. Etwas besser sieht es bei NitroKey aus, hier ist GPG, TOTP und X.509 verfügbar. Leider ist U2F nur als separates Gerät erhältlich und TOTP mit 15 Einträgen etwas knapp (YubiKey Neo 28, YubiKey 5: 32). Da es sich um einen freien Algorithmus handelt könnte man aber, zumindest bei der TOTP-Limitierung, mit etwas Software nachhelfen. Ein Auge habe ich zudem noch auf Somu. Dieses Crowdfunding-Projekt dreht sich primär um einen U2F und FIDO2-Stick, als Stretch-Goal hat man jedoch GPG und SSH auf dem Plan. Alles soll am Ende Open Source sein, was sich auch eher positiv anhört. Ob sie am Ende liefern können, was sie versprechen, werde ich dann ja sehen.

In eine vorherigen Variante des Artikels wurde angegeben, dass NitroKey kein TOTP könne. Dies ist nicht korrekt, sowohl Nitrokey Pro 2 und Nitrokey Storage 2 können jeweils 15 TOTP-Einträge speichern.

Nginx: allow mit dynamic DNS

Wenn man Webseiten mit Backend betreibt ist es oft eine gute Idee die Verwaltungsbereiche nur von bestimmten IPs oder Netzen zuzulassen. Unter nginx gibt es hierzu den allow-Befehl, mit welchem man IPs und Netze angeben kann. Ich verwende dies z.B. häufig um nur interne IP-Bereiche oder per VPN angebundene Clients zuzulassen. Für ein aktuelles Projekt sollte jedoch auf ein VPN verzichtet werden. Theoretisch kein Problem – externe IP rein und fertig, aber leider ist es auch 2019 noch in Deutschland für viele Anschlussarten üblich bei Trennung und erneutem Verbinden eine andere IP-Adresse zuzuweisen. Für eingehende Verbindungen lässt sich dies mittels dynamischen DNS-Einträgen schnell in den Griff bekommen, jedoch ist das für das hiesige Konstrukt keine Option, da nginx mit solchen Einträgen nicht sinnvoll umgehen kann. Im Netz finden sich einige Helper-Scripte, welche den DNS regelmäßig Prüfen, die Konfiguration anpassen und den Webserver passend umkonfigurieren. Leider sind diese oft eher alt und nur auf das schon seit Jahrzehnten veraltete IPv4 ausgelegt. Als Abhilfe habe ich meine Anforderungen in ein kleines Python-Script gegossen. Für IPv6 wird von der aufgefundenen IP auf ein /48er Netz geschlossen und dieses freigegeben, sollte euer Provider nur ein /56er oder gar /64er rausrücken muss dass ggf. angepasst werden.

Vorbedingung ist, dass nginx die neue Konfiguration findet. Um es einfach zu halten stehen die dynamischen Einträge in einer separaten Textdatei, welche an passender Stelle per include eingebunden wird. Statische Einträge können, sofern vorhanden, an der üblichen Stelle bleiben.

Das eigentliche Script nutzt nach meinem Wissen keine externen Module und sollte somit auf jedem System mit Python 3 laufen. Es werden alle IPv4- und IPv6-Adressen abgerufen. Der angegebene Port (80) ist irrelevant, da nur die IPs genutzt werden. Die Konfiguration wird mittels MD5 auf Änderungen geprüft, liegt eine solche vor wird per Systemd eine reload ausgelöst. Ich habe die Datei mit in den nginx-Konfigurationsordner als /etc/nginx/dyndns.py gepackt – nicht schön, aber passte besser in die bereits vorhandene Struktur und Verwaltung.

Das Script muss regelmäßig gestartet werden um Änderungen zu prüfen. Wenn der zugehörige DNS-Dienst auf dem selben System läuft kann man möglicherweise auf Hooks zurückgreifen, andernfalls muss es zeitbasiert über Cron oder Timer laufen. Für letzteres mit einem Intervall von 5 Minuten legt man die Datei /etc/systemd/system/nginx-dyndns.timer an und füllt sie wie folgt:

Dazu benötigt man noch einen passenden Service, welcher unter /etc/systemd/system/nginx-dyndns.service definiert wird:

Last but not least wird der Timer eingeschaltet:

[ICStation.com] BitBastelei #276 – Door Magnet Relay Module

[ICStation.com] BitBastelei #276 - Door Magnet Relay Module

(231 MB) 00:17:39

2018-03-18 10:00 🛈
Magnetschalter, auch Reedschalter genannt, bieten eine Möglichkeit ohne direkten Kontakt bei Präsenz eines Magneten Dinge zu schalten. Häufig wird dies eingesetzt um zu erkennen ob eine Tür oder ein Fenster geschlossen ist. Auf Grund ihres Aufbaus können die Magnetschalter meist nur wenige Milliampere schalten, zudem möchte man nicht gerade Netzspannung durch dünne Kabel und Glasröhrchen am Türrahmen baumeln haben. Abhilfe soll dieses Modul von ICStation schaffen, welches einen solchen Magnetschalter mit einem Relais kombiniert, welches wesentlich höhere Lasten schalten kann.

Links:

Hinweise:

Das Modul wurde mir von ICStation.com für dieses Video kostenfrei zur Verfügung gestellt.

BitBastelei #247 – PC-Lüfter per Arduino auslesen und steuern

BitBastelei #247 - PC-Lüfter per Arduino auslesen und steuern

(81 MB) 00:19:34

2017-07-16 10:00 🛈
Lüfter sind laut und nervig – aber auch nicht so ganz unwichtig. Praktischerweise kann man PC-Lüfter recht einfach selbst nutzen. Schauen wir mal, welche Arten von Lüftern es so gibt und wie man diese per Arduino auslesen und steuern kann.

Korrekturen & Hinweise

  • 10:58 OZI und Arduino haben über USB den selben GND
  • 13:22 FALLING wäre bei diesem Signal besser
  • 16:25 Laut Spezifikation sind 21-28kHz zulässig

Links zum Thema

Code

Linux: Gerät wacht nach Suspend sofort wieder auf

Narf. Akku leer. Nur warum?
Tja, mein Laptop hatte sich entschieden nach meinem Klick auf “Suspend” sofort wieder aus dem Standby-Modus aufzuwachen. Reproduzierbar. Erste Vermutung: Die GUI ist Schuld. Wie immer. Aber auch ein systemctl suspend zeigt nicht wirklich eine Besserung. Auch die Logs zeigen nichts verwertbares. Na dann graben wir etwas tiefer:

Erst mal zur Klarstellung: Standby funktioniert – der Laptop schaltet die Geräte aus, die Power-LED blinkt wie erwartet, doch nach knapp einer Sekunde wacht wer direkt wieder auf. Entsprechend des Fehlers dürfte also die Aufwachquelle am ehesten Verantwortlich sein. Eine Liste aller Quellen findet sich in /proc/acpi/wakeup:

Die Liste sieht natürlich je nach Verbauter Hardware anders aus, hier die Zuordnung meines Gerätes:

Wie wir sehen können diverse Geräte ein Aufwachen verursachen, lediglich EXP2 ist nicht aktiv. Um das Ganze einzugrenzen heißt es also nun: Aufwachquelle abschalten, Suspend testen und hoffen, dass es was bringt. Über ein gezieltes echo kann der Zustand zwischen enabled und disabled gewechselt werden:

In meinem Fall stellte sich USB als Fehlerteufel heraus. Offenbar störte sich das System an einem USB-Stick – egal ob gemountet oder nicht. Wie auch immer, USB brauche ich ohnehin nicht zum aufwachen, Deckel und/oder Power-Button sollten ausreichen. Den “bösen” USB schalte ich beim Boot per Script nun ab.

Otto Waalkes – Grund zum feiern, Lyrics in Englisch

Da aktuell durch ein für viele wohl eher unverständliches Video das Interesse am Klassiker “Grund zum feiern” von “Otto Waalkes” geweckt wurde wollte ich die Bedeutung der “weisen Worte” auch den Mitbürgern, welche nur englisch sprechen, nicht vorenthalten. Da das Netz keine brauchbare Übersetzung lieferte dann halt hier…

Currently the classic “Grund zum feiern” by “Otto Waalkes” is getting some interes because of a for most people somewhat incomprehensible video.  I liked to share these wise words also with people not speaking German but could not find a descend translation – so here it is…

  • Faber Krönung (sparkling wine)
  • Deinhard Lila (sparkling wine)
  • Grappa (pomace brandy)
  • Calvados (apple brandy)
  • tequila
  • Asbach Uralt (brandy)
  • Spätburgunder (Pinot Noir, red wine)
  • Vermouth (fortified wine) and
  • Pernod (distilled anise beverage).
  • Poire Williams (brandy)
  • Dujardin (Cognac)
  • Hennessy (Cognac)
  • Rémy Martin (Cognac)
  • Fernet Branca (bitter herbal liqueur)
  • Underberg (digestif bitter)
  • Port Wine (fortified wine) and
  • Bordeaux (wine)
  • Johnnie Walker (whiskey)
  • Jägermeister (liquor)
  • Amaretto (liquor)
  • Keller Geister (sparkling wine)
  • Scharlachberg (wine) and
  • Doppelkorn (liquor).
  • The whole thing now again from the start.
  • We have reason to celebrate.
  • No one can still run but we can still booze.
  • We have reason to celebrate.
  • Even if we feel like vomiting, bring the next bucket.
  • Bommerlunder (Akvavit)
  • Ballentine’s (scotch whiskey)
  • today it’s all the same to us.
  • Pear brandy and
  • cider
  • We really pour in everything.

 

  • whiskey sweet and
  • whiskey sour
  • main thing is we’re getting more drunk
  • Rammazotti (amaro)
  • Ratzeputz (Schnaps) and
  • a bottle of rum
  • Gin (spirit)
  • Campari (liqueur)
  • Grand Marnier (liqueur)
  • finally the skull hurts
  • With Doornkaat (liquor) and
  • Mariacron (brandy)
  • into delirium.
  • Klosterfrau Melissengeist (kind of high-alcohol-medicine)
  • or however the stuff is called
  • Kölnisch Wasser (aka 4711, perfume)
  • Pitralon (aftershave)
  • we do not burp it, we are vomiting it already.
  • We have reasons to puke
  • even if it erodes the guts
  • it spends us warmth
  • We have reason to celebrate
  • Our death-bed will:
  • Even higher alcohol level.

SSD-Killer: Another one bites the dust

Es ist wieder so weit: Ich habe die nächste Cache-SSD meines Speichersystems getötet. Nach etwas über einem Jahr (375 Tage) hat nun eine Toshiba THNSNJ128GCSU das Zeitliche gesegnet und damit den Wert der Vorherigen Mushkin Chronos sogar unterboten. Etwas überraschend, da Toshiba eher im Business-Umfeld aktiv ist und Mushkin eher ins Low-Cost-Umfeld zielt. Interessanterweise sind Raw_Read_Error_Rate und Reallocated_Sector_Ct beide auf 0, lediglich der nur spärlich dokumentierte Wert 169 (Total bad block count?) meldet FAILING_NOW – nachdem er sich von 0 auf 1 änderte, also komplett ohne Ankündigung. Positiv: Immerhin blockiert die SSD nur Schreibzugriffe, das Lesen/Sichern der bestehenden Daten ist also noch problemlos möglich.

Nächster Kandidat ist eine 850 Evo – mal schauen, ob diese das nächste Jahr durchhält.

CTS-Eventim: Offenes WLAN? Dann verkaufen wir nichts.

In öffentlichen WLAN surfen ist praktisch: Man kann unterwegs schnell noch $Dinge erledigen oder Wartezeiten produktiv nutzen. Da an diesen Einrichtungen jedoch viele Menschen gleichzeitig den selben Anschluss nutzen haben viele Anbieter solche Einrichtungen genauer im Blick: Um automatisierten Missbrauch zu vermeiden müssen häufig CAPTCHAS ausgefüllt werden (hallo, CloudFlare) oder die Nutzung von Seitenteilen (oder auch der ganzen Seite) ist nur noch mit einem bestehenden Benutzerkonto möglich. Diese Gängeleien sind ärgerlich, aber dazu werde ich später noch einen Artikel schreiben.

Wie oben schon geschrieben: Gängeleien. Man ist genervt, löst das CAPTCHA oder meldet sich an und weiter geht es. Bisher. Im ewigen Kampf Verkäufer gegen mögliche Kunden setzt der “Eintrittskartenverkauf” CTS-Eventim einen drauf: Deren Webseite liefert bei der Nutzung von Diensten wie öffentlichen WLANs – oder auch einigen Internetprovidern mit DSLite – nur ein formloses “Access Denied”. Keine Erklärung, kein CAPTCHA, kein Weiterkommen.

Da dies kaum im Sinne des Verkäufers sein konnte kontaktierte ich den Betreiber. Mal davon abgesehen, dass eine Erklärung wohl keinem weh täte sollte ich als registrierter Kunde, der in der Vergangenheit schon öfter bestellte, doch mein Geld loswerden können, oder?

Weit gefehlt: Um Fairness zu waren müsse man diese Blockade beibehalten. Es können ja Bots kommen.

wir verfolgen eine Politik der Gerechtigkeit für unsere Kunden: Der gerechten Verteilung von Tickets sowie der Sicherheit unserer Portale räumen wir höchste Priorität ein. Daher möchten wir Reservierungs- und Buchungsbots, die für gewöhnlich Anonymisierungsdienste nutzen, von unseren Portalen fern halten. Wenn Sie also Ticketreservierungen und Buchungen ohne Aufwand und Störung durchführen möchten, bitten wir Sie, keine Anonymisierungsdienste dafür zu verwenden. Wir danken für Ihr Verständnis.

Warum man dann jedoch alle ausschließt und nicht nur versucht Bots zu verhindern bleibt wohl ein Geheimnis. Da ich die  verallgemeinerung und damit generelle Gleichstellung von gemeinsam genutzten Internetanschlüssen und “bösen” Anonymisierungsdiensten aber ohnehin sehr zweifelhaft finde werde ich zukünftige Bestellungen an andere Dienstleister vergeben.

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:

Der Hacker und die sieben Admins

Es war einmal eine Gruppe von Admins, welche sich morgens um 11 nach langer Nacht zum Ruhen ins Büro begaben. Sie setzten sich und sahen gleich, dass jemand da gewesen war. Der Erste fing an zu fragen:

“Wer hat auf meinem Program Files geschrieben?”

Der Zweite fragte:

“Wer hat von meiner password.txt gelesen?”

Der Dritte fragte.

“Wer hat mein CD-Laufwerk geöffnet?”

Der Vierte:

“Wer hat meinen Desktophintergrund geändert?”

Der Fünfte:

“Wer hat meinen Admin-Konto genutzt?”

Der Sechste:

“Wer hat meinen Postausgang gefüllt?”

und der Siebente fragte:

“Wer hat das Trollface gedruckt?”

Wie die Admins also gefragt hatten, sahen sie sich nach ihren Gehaltszahlungen um, und fragten:

“Wer hat sich auf unseren Banken angemeldet?”

bis auf den Siebenten, der fragte nicht so, sondern:

“Wo ist mein Geld?”,

denn da bediente sich der Hacker.

So, neuer Kernel fertig – weiter im Programm 😉