Hacks sind verboten
Nach einem Patchtag funktionierte eine WAOJ-Installation nicht mehr. Die Ursache war eine unsaubere Installation, die beim Einspielen der Microsoft-Patches "bereinigt" wurde.
Gegeben sei ein Windowssystem mit Apache, Oracle und Java-Appserver. Das Betriebssystem macht Dienstleister A, die andere Software kommt von Dienstleister B. Nach einem Update geht die Software nicht mehr. Also werden die Patches zurückgenommen und die Software geht immer noch nicht wieder.
Damit sind alle Voraussetzungen für ein langwieriges Fingerpointing-Spiel gegeben, über die der Kunde nicht glücklich sein wird. Also schauen wir mal über den Tellerrand hinaus.
Folge den Daten!
Der Apache läuft. Er liefert aber nur 40x und 50x Fehler zurück. Das Logfile sagt, daß er keine Worker-Threads mehr hat oder diese nicht reagieren.
Der Appserver läuft ebenfalls. Er berichtet im Errorlog, daß er die Datenbank auf (hostname:1521) nicht erreichen könne. Ob die am falschen Port lausche?
Die Datenbank läuft auch. Zumindest meint das der Dienstmanager. Und auch netstat zeigt, daß der Dienst lauscht:
Z:\> netstat -an | find "1521" TCP 127.0.0.1:1521 0.0.0.0:0 ABHÖREN TCP [fe80::...]:49192 [2001:db8:...]:1521 SYN_WARTEN
Moment mal! Wieso lauscht der Dienst auf der Loopback IPv4 Adresse, während die Verbindung an die offizielle IP des Hostes geht?
In der Konfiguration des Appservers findet sich als Name der Datenbank nicht localhost sondern hostname.local.dom.ain. Und natürlich löst das lokale DNS korrekt nach IPv6 und IPv4 auf.
Da der Appserver die Datenbank nicht erreicht, beendet er sich nach Ablauf der Timeouts und restartet neu. Der Apache wechselt dann je nachdem ob er den Server gerade erreicht oder nicht zwischen 50x und 40x.
Was ist passiert?
Die Appserver-Config ist seit langer Zeit nicht mehr geändert worden. Das kann es also nicht sein.
Hat die Datenbank sich irgendwann selbst aktualisiert und ist dabei auf Defaults zurück gefallen? Auch dafür gibt es keinerlei Anhaltspunkte.
Hat sich das DNS geändert? Nein, auch dafür gibt es einen längeren Datenbestand, der eine identische Konfiguration nachweist.
Moment mal! Kann am DNS vorbei gearbeitet worden sein? Ja, mit einer etc/hosts Datei. Und siehe an, die Datei hat ein Änderungsdatum in den letzten Tagen. Sie enthält aber genau den Stand wie alle anderen Systeme: Den Windows-Default.
Trägt man das folgende in die etc/hosts eine Zeile ein, geht alles wieder:
127.0.0.1 hostname.local.dom.ain hostname
Hat ein Patch die etc/hosts Datei überschrieben? Nein.
Hat jemand absichtlich an der Datei gedreht? Da kann man weder beweisen oder widerlegen.
Hat der Virenscanner vielleicht die Datei angefaßt? Oh, das kann sein. Es gibt viele Berichte darüber, daß Virenscanner für Malware-Erkennung benutzen und unverständliche Einträge dort als Angriff auffassen. Allerdings steht im Log des Virenscanners kein entsprechender Vorfall. Also nein.
Aber auch Microsoft liefert regelmäßig Malware-Removal-Tools in den Patches mit aus. Vielleicht war es ein solcher Zugriff?
Ja, in der Knowledge-Base gibt es einen Artikel, der beschreibt, daß veränderte etc/hosts Dateien durch die Defaultwerte ersetzt werden. Die Änderung wird als SettingsModifier:Win32/PossibleHostsFileHijack klassifiziert.
Will man also dauerhafte Änderungen an der etc/hosts vornehmen, so muß man die Datei explizit ausschließen.
Lösung
Das Umbiegen der Namensauflösung ist eine dreckiger Hack. Dieser hätte nie in Produktion gehen dürfen.
Was nun zu tun ist, ist Dienstleister B davon zu überzeugen, daß in der Konfiguration des Appservers die Datenbank auf localhost geändert werden muß.