Technik

Die meisten administrativen Aufgaben auf unseren Servern werden von sog. Daemons übernommen. Die laufen immer und wenn nicht, werden sie bei Bedarf automatisch gestartet.

Ärgerlich bzw. ein wenig lästig war das ganze immer, wenn es Neuerungen an unserem System gab: Die entsprechenden Dienste mussten alle von Hand neu gestartet werden, was natürlich ab einer entsprechenden Anzahl an Servern keinen Spass mehr macht.

Mittlerweile - und da bin ich recht stolz drauf - ist das nicht mehr so. Die Deamons überwachen sich selbst und starten sich so zum Beispiel automatisch neu, sollte im System eine neuere Version verfügbar sein. Weiter haben sie auch immer ein Auge auf ihren aktuellen Speicherverbrauch und sollte der einmal zu hoch sein (z.B. durch Memory-Leaks) räumen sie ebenfalls durch einen automatischen Neustart auf.

Hach, was ist das doch schön

Ich bin schon den ganzen Morgen etwas kribbelig, denn wir testen heute zum ersten Mal im laufenden Betrieb unser neues Backend für unsere MySQL-Datenbanken. Man sollte erwähnen, dass "neu" in diesem Zusammenhang wirklich "neu" bedeutet und nicht etwa einen Versionssprung marktiert. Bisher hatten wir keine Automatisierung für das Datenbanken-Management im System, sondern mussten auf Kundenwunsch hin jede Datenbank manuell anlegen.

Würde es eine Statistik über die konkreten Aufgaben im Support geben, würde das wohl einen der aufwändigsten Punkte markieren.

Bei diesem neuen System hatte ich ja schon bei der Vorarbeit wahnsinnigen "Respekt", der bei den ersten Tests in unserer Sandbox etwas abgeklungen ist, der aber eigentlich nur ein Klacks im Vergleich zu dem ist was ich heute durchmache.

Vollkommen unbegründet: Alles läuft bisher hervorragend und ich bin guter Dinge das entsprechende Plugin für unser Kundeninterface noch diese Woche freizugeben. Weiterhin basiert das neue Datenbank-System auf einer recht neuen Methode alle Server bei uns auf den aktuellsten Stand zu bringen - richtig spannend!

Apropo Kundeninterface...

Wärend ich neulich ein wenig über die Webseiten einiger Marktbegleiter surfte und deren Angebote studierte, kam mir eine recht zündende Idee die mich nicht mehr los lies. (Die Idee ist zwar nur eine kleine, dennoch mag ich sie hier noch nicht erwähnen)

Grundlage dieser Idee war ein IMAP-Server, allerdings konnte ich mit gängigen Implementationen nicht direkt etwas anfangen, da ich (für die Idee eben) recht einfachen Zugriff auf jede Nachricht in der Mailbox (bzw. deren Ordner) brauche. Man hätte es sicherlich irgendwie über unsere bestehende Installation modelieren können, aber das kam mir ein wenig dreckig vor.

... und so musste ich unbedingt das Rad (mal wieder) neu erfinden und habe eine eigene, recht abstrakte IMAP-Implementation (Server, kein Client) in PHP geschrieben. Der wichtigste Teil meiner Idee funktioniert bereits und das IMAP RFC 3501 wird auch schon zu sicherlich 90% erfüllt.

Nicht, dass das etwas neues wäre: Ich habe bereits wie ich 18 Jahre alt war an meiner ersten IMAP-Implementation gearbeitet, diese allerdings niemals komplettiert. Manchmal glaube ich, dass ich gelegentlich etwas zu viel Zeit habe... (was allerdings nicht stimmt) :hmm:

Auf meinem Arbeitsgerät habe ich vor zwei Wochen mal experimentell SVN-Bindings für PHP einkompiliert.

Herausgekommen ist ein kleines "Proof-of-concept": Ein Online-Browser für SVN-Repositories.

Die PHP-SVN-Bindings haben es mittlerweile auch in die Produktiv-Version unseres Systems geschafft, sind mangels Neukompilierung auf den Webservern aber noch nicht produktiv verfügbar.

In den letzten Tagen bekam ich immer per SMS bestätigt, dass meine Sandbox nun gebootet ist.

Der Webserver hatte eines der letzten System-Updates nicht überlebt und versagte beim Starten. Da wir mittlerweile konsequent automatisch jede Maschine testen, die auch nur den Hauch eines Webservers vermuten lässt, schlug hier sofort das Monitoring zu und informierte mich über den toten Indianer.

Ich weiß nicht so recht, ob früher doch alles besser war, wo man explizit bestimmen musste, welche Maschine überwacht wird und welche nicht. Letzten Endes haben mich die SMS-Kosten, auch wenn es nur ein paar Cent waren, mich dann doch dazu beworgen den Webserver in der Sandbox mal zu reparieren.

Heute morgen habe ich in unserem internen Wiki meine aktuelle Arbeit dokumentiert und in einem Artikel zu einer neuen "Technologie" angeregt mittels einer recht kleinen Erweiterung in Zukunft alle Objekte, die wir so im System haben, zu versionieren...

Damit könnte man dann z.B. einen Webserver (resp. Virtual Host) auf den Stand vor zwei Wochen bringen - obs was bringt? :hmm:

Gestern saß ich mal wieder vor dem Bildschirm und bastelte fleißig an einer Verbesserung unseres Administrations-Backend.

Irgendwann merkte ich, dass ich gar nicht mehr so bei der Sache bin und mich eigentlich um das aktuelle Projekt herumdrücke. Anscheinend hatte ich wohl ein wenig zu viel Respekt vor der Aufgabe - zu unrecht: Menschen sterben hierbei sowieso nicht und kaputt machen konnte ich auch nichts.

Schlussendlich habe ich die Augen zu gemacht und dann alles in ca. 10 Minuten fertig gemacht - hautpsache vorher 40 Minuten verschwendet.... :eek:

Ich musste gerade schon ein wenig über mich selbst schmunzeln, wie ich in einer E-Mail schrieb:

[...] daher kann sich der gefühlte Umzug noch ein wenig [...]

Ein "gefühlter Umzug"? :hmm:

Tatsächlich ist es ja wirklich so und wurde von mir soweit ich weiß hier auch schon mal thematisiert: Ändert sich das Ziel (die IP-Adresse) einer Domain, so bekommt das im Internet nicht jeder sofort mit, da diese Einträge zwischengespeichert werden. Somit kann die Webseite bereits längst auf dem neuen Server verweilen, der Besucher "fühlt" sie aber noch auf der alten Maschine.

Wir versuchen dem immer vorweg zu greifen, indem wir bereits ein paar Stunden vor dem eigentlichen Umzug die Lebensdauer von DNS-Datensätzen (eben die Zeit, wie lange sie zwischengespeichert werden) drastisch verkürzen. Allerdings ist das bei kurzfristigen Aktionen nicht immer möglich, sodass der "gefühlte Umzug" meist weit hinter dem eigentlichen Umzug liegt. Weiterhin wird die entsprechende Webseite - sofern es denn ein interner Umzug ist - noch bis zu 24h auf der alten Maschine vorgehalten.

Besonders schlimm ist der "gefühlte Umzug" wohl immer für die Mütter und Väter der jeweiligen Webseiten, denn die haben die Seite meist erst vor kurzem aufgerufen und müssen dementsprechend viiiieeelll länger warten.

Wir haben am Wochenende unser System um eine Art "zufälliges" Monitoring erweitert, bei dem wirklich jeder Webserver teilnimmt - ganz egal, ob es nun seine Aufgabe war oder nicht. Hierbei kommt zu dem normalen Test "Laufe ich selbst noch richtig" ein neues Feature hinzu, bei dem nach dem Zufallsprinzip eine Kundenwebseite herausgesucht und getestet wird - bei einem Fehler werden wir dann umgehend benachrichtigt.

Eigentlich eine super Funktion, wäre das neue System nicht sofort hingegangen und hätte jede Karteileiche in unserer Datenbank gefunden, getestet und für (zu Recht) offline befunden. :eek: Auch gesperrte Kundenwebsites hat das System als Offline erkannt, das Problem war aber eher schnell zu beheben.

... gestern durfte ich dann dementsprechend unsere Webserver-Datenbank aufräumen. Hat ja auch was!

Neben diesem Feature gab es noch ein paar weitere (für mich interessante) Updates, allerdings sind das leider mehr internas und nichts für den Blog.

Wie ich eben unter anderem berichtete, wurde letzten Monat die eine oder andere Joomla-Installation bei uns geknackt.

Für den Kunden ist sowas natürlich immer recht tragisch und wir versuchen stets zu helfen wo wir können, aber (so böse das auch klingen mag) steht er für uns in einer solchen Situation nicht im Mittelpunkt. Viel wichtiger ist herauszufinden, ob das System selbst oder andere Kunden in Mitleidenschaft gezogen wurden, und viel Interessanter ist natürlich auch die Frage, wie es der Angreifer zu uns auf die Maschine geschafft und ob er Spuren hinterlassen hat.

In einem der zurückliegenden Fälle hatte ich richtig Glück, denn ich bekam vom Kunden die gesamte Webseite zur Verfügung gestellt, auf der sich noch vielerlei Spuren fanden, u.a. auch ein Tool Namens "r57shell".

Die r57shell ist wie der Name bereits vermuten lässt eine Art PHP-Shell, die den Webserver auf seine Fähigkeiten und mögliche Schwachstellen untersucht. Darüber hinaus gibt sie dem Angreifer - oder nennen wir ihn schlichtweg "Nutzer" - die Möglichkeit Dateitransfers zu starten, Dateien zu bearbeiten, Port-Weiterleitungen zu installieren und natürlich Programme auszuführen.

Ausgeliefert wird die r57shell in einem recht unleserlichen ("obfuscated") Zustand: Der Skript ist mehrfach mittels GZIP-komprimiert und base64-enkodiert. Wie mir die Datei in die Hände fiel habe ich es zuerst von Hand versucht, aber nach dem 5. Mal im Kreise drehen habe ich dann doch ein Programm geschrieben, dass den Skript für Menschen leserlicher erscheinen lässt.

Für uns ist es natürlich immer sehr wichtig, solche Skripte in die Hände zu bekommen, denn sie veranschaulichen recht schön, was Angreifer alles auf dem System versuchen um die Sicherheitsvorkehrungen zu umgehen. Im einfachsten Fall ist es schön zu sehen, dass alle Maßnahmen gut gegriffen haben und zu keiner Zeit Gefahr für die anderen Kunden und das System bestand - dieser Fall war so einer. So geht die r57shell nun in meine Angreifer-Skript-Sammlung ein und wird dort vermutlich einstauben. Ich glaube zwar nicht direkt, dass hier jemand um die Wahrung seiner Urheberrechte besorgt wäre, biete das Dingen aus sicherlich verständlichen Gründen aber nicht zum Download an. Für Interessierte müssten im Internet ein paar Screenshots rumgeistern ansonsten lässt sich das über eine Sandbox bestimmt nachholen

Das meiste, was diese Woche hier im Blog passiert ist, passierte natürlich nicht ohne Grund.

Manch einer mag es bereits vermutet haben, manch anderer hat es schon gemerkt, sogar unsere Webseite kennt es schon länger:

VPN Gateway Firewall

Um dies zu bewerkstelligen legt man einfach im Kundeninterface eine entsprechende Firewall-Regel an, stellt den Filter auf "Pakete anonymiseren" und startet den VPN-Tunnel neu. Voila, alles fertig!

Natürlich gibt es hier viele Kritikpunkte, die es besonders im Bezug auf Tor zu berücksichtigen gibt. So ist unsere Implementierung eine denkbar bequeme, aber niemals als eine Vollweritge zu betrachten - immerhin werden die Daten auf unserem VPN Gateway Router unverschlüsselt verarbeitet, sprich sie kommen entschlüsselt aus dem VPN-Tunnel, werden geroutet und anschließend erst über Tor wieder verschlüsselt übermittelt, bleiben für uns (und somit im weiteren Schritt auch für Strafverfolgung o.ä.) jedoch einsehbar. Auch ist noch nicht ganz klar inwieweit wir als Dienstleister hier einer Protokollierungspflicht unterliegen (Dazu mehr, sobald die Situation eindeutig geklärt ist).

Wer alle Vorteile von Tor nutzen will, wird um die Installation eines lokalen Clients nicht herum kommen. Wer aber unabhängig vom Computer an dem er sitzt (sondern nur von der VPN Gateway-Verbindung abhängig) selektiv, spontan oder allgemein Tor nutzen will, für den wird diese Erweiterung sicherlich nützlich sein...

... es kostet auch nichts extra. Und selbst, wenn ich nicht der Tor-Typ bin, bin ich der Meinung, dass es doch sehr schön ist solch "Zwischending" zu haben. Im aktuellen Marketing hat das Feature auch bereits seinen Platz gefunden.

Nachdem ich am Montag von meinem "transparenten SOCKS5-Proxy" berichtete gibt es heute nun die passenden Sourcen zu dem Projekt.

Technisch wie bereits gesagt nicht ganz ein novum, allerdings von zumindest einem Kommentator heiß erwartet. Doch wie funktioniert das Programm eigentlich? Recht simpel:

1. Aktuelle Version aus dem SVN auschecken
2. "make" ausführen (ggf. Makefile bzgl. libevent anpassen) und das Programm kompilieren
3. transocks_ev ausführen:
   
   ~#> ./transocks_ev -p 1211 -S IP-Addresse des SOCKS-Server -s Port des SOCKS-Server
   
4. iptables anpassen, z.B. so:
   
   ~#> iptables -t nat -A PREROUTING -p tcp -d 207.46.0.0/16 -j REDIRECT --to-ports 1211
   
5. Fertig! ggf. zwischendurch die README lesen...

Manchmal bin ich echt geneigt den Kopf auf den Tisch zu hauen.

In den vergangenen 2 Tagen durfte ich mich wieder mit einer .de-Domain rumplagen, die von der DeNIC partout nicht auf den aktuellsten Stand gebracht werden wollte. Alle Update-Versuch wurden stets mit einem "Nameserver Error" quittiert.

Natürlich kann das mal passieren, allerdings hatte ich die Nameserver manuell zu diesem Problem mindestens 10 Mal befragt und es wäre nicht so, dass es sowas nicht schon mal gab (allerdings war ich darmals noch wesentlich grüner ).

Heute morgen hatte ich dann die Nase voll als sich unser Robot mal wieder mit einem Fehler meldete und bin wieder von Hand an die Sache gegangen. Aber was hab ich überhaupt gemacht?

1. "Einfaches" Update von Hand - sprich die Daten wie sie aktuell sind ohne Änderungen an die DeNIC übermittelt.
   Fehler: Nameserver error [ERROR: No SOA record found on server (ns1.tiggersystems.info, ns3.tiggersystems.info)]
   
2. Aus Spass mal "ns3.tiggersystems.info" aus der Liste der Nameserver genommen.
   Fehler: Nameserver error [ERROR: No SOA record found on server (ns1.tiggersystems.info, ns2.tiggersystems.info)] :eek:
   
3. Resigniert und "ns3.tiggersystems.info" wieder auf die Liste der Nameserver gesetzt. Funktioniert! :eek:

Wohlgemerkt betreffen diese Einstellungen nur die Daten die wir an die DeNIC übermitteln, Daten auf unseren DNS-Servern wurden hierbei nicht geändert (wobei das sowieso zu kurz für das Rehash-Interval war) und somit hätte Schritt 2 so oder so fehlschlagen müssen, allerdings mit einem anderen Fehler.

Nachdem eine ehemalige Kundin mich vor ein paar Tagen wieder an "den Zwiebelrouter" (TOR, The Onion Router) erinnert hat, betreiben wir nun auch wieder ein kleiners TOR-Relay mit dem Namen "tiggersWelt" - sprich: Wir leiten Traffic innerhalb des Netzwerkes weiter, sind aber kein "Exit Node", der die Daten in das "normale" Internet überführt.

Wir hatten ein ähnliches Projekt bereits vor etwas mehr als einem Jahr, haben es aber nach ein wenig unbehagen und einem Hardware-Ausfall eingemottet. Das aktuelle Projekt bewegt sich noch in einem ähnlichen Rahmen, ist aber für mehr vorgesehen - mehr dazu später, bis dahin darf gemutmaßt werden.