Wohnzimmerhostblogger

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.

Gestern Nacht hatte ich wieder "Programmier-Wut". Dabei ist etwas entstanden, was ich gerne als "fork" bezeichne, allerdings wäre "offener Ideenklau" hier sicherlich angebrachter, denn von 335 Zeilen Programmcode sind nur noch ca. 10 Zeilen aus dem ursprünglichen Programm - und die haben nichtmals wirklich was mit dem eigentlichen Abluaf zu tun

Herausgekommen ist dabei (wie schon in der Überschrift vermerkt) ein transparenter SOCKS5-Proxy, der komplett im Userspace läuft und bequem via IP-Tables konfigurierbar ist. Anders als sein Vorgänger verzichtet meine Implementation auf eine externe SOCKS-Library und den fork() pro eingehender Verbindung, im Gegenzug setze ich zum ersten mal libevent zur Verwaltung der Ereignisse auf den Sockets ein.

Da die ursprüngliche Version keinerlei Lizenz-Informationen beinhaltet, warte ich noch auf Rückmeldung vom Original-Author. Wenn der sein gründes Licht gibt, wird das ganze OpenSource. Bis dahin bereite ich den Einsatz auf unserer Seite als Erweiterung eines bestehenden Produkts vor

Es klingt irgendwo schon ein wenig skuril: Ein Kunde will gerne seine Webseitenzugriffe in Echtzeit auf einem eigenen System auswerten und fragte und daher nach einer Möglichkeit die Access-Logs für ihn an seine Server zu "pushen".

Es gibt hier sicherlich viele Wege so etwas zu realisieren, so war neben einer einfachen TCP-Verbindung über die die Daten in Text-Form geschickt werden auch eine direkte Anbindung an seine MySQL-Datenbank im Gespräch. Letzten Endes haben wir uns dann aber doch vorerst für einen Transport über Jabber/XMPP entschieden.

Um den Datenverkehr zu gering wie möglich zu halten, soll unser Logging-Backend direkt auf einem Jabber-Server beim Kunden einloggen und die Verbindung wird zusätzlich komprimiert. Die Daten werden dann ein einem eigenen Namespace umschlossen von eimem <message>-Block ihr Zuhause finden.

Momentan wird das Projekt noch geplant, aber ich bin jetzt schon ganz wild und gespannt was daraus wird.

Ein Kunde gab uns den Tipp, dass wir in unseren Rechnungs-E-Mails den Doppelpunkt bei

Rechnungsnummer: 20080012345

weglassen, damit es sich besser ins Online-Banking kopieren lässt. Ich erwiederte, dass es vollkommen ausreicht, wenn er nur die Rechnungsnummer im Verwendungszweck angibt. Er will es beim nächsten genau so versuchen, allerdings erst nach seiner Hochzeit.

Ich konnte nicht widerstehen:

Können wir nicht lieber vorher abrechen?
So für die nächsten 10 Jahre im voraus

... ich hab gehört so eine Hochzeit ist kostspielig... :hmm:

Wenn ich ein OpenSource-Projekt nicht wenig mag, dann ist es phpMyAdmin.

Die Projekt-Idee ist ja ganz nett und ich benutze es auch jeden Tag, aber so langsam beschleicht mich das Gefühl, es ist so buggy wie man es früher phpBB nachgesagt hat. Meines Wissens nach ist bei uns noch nie eine Installation kompromittiert worden, allerdings sind die Zyklen, in denen es Sicherheits-Updates gibt, für meinen Geschmack ein wenig kurz.

So kamen heute allein z.B. zwei Updates über die Mailinglist rein. Das zweite ist in diesem Fall ggf. etwas zu vernachlässigen (wenngleich es hier wohl auch nur an der Sorgfalt der Entwickler gescheitert ist), aber mir wird schon recht übel, wenn ich überlege, dass ich bei uns Leute dafür bezahle jedem dieser Updates hinterherzulaufen.

Webserver-Absturz

Nur einen Nachteil hat es und es war auch der erste Gedanke, der mir dazu kam:
Warum denke ich beim Anblick dieses Kleidungsstück immer an einen Webserver-Absturz?!

Wenn ich von einem Integer spreche, spreche ich in der Regel von einem ganzzahligen Datentyp, der in 4 Bytes bzw. 32 Bit dargestellt wird. Als Zweierkomplement mit Vorzeichenbit lassen sich dort also Zahlen im Bereich von [-2.147.483.648; 2.147.483.647] darstellen. Das soweit vorweg.

Nun war es so, dass in den letzten 2 Wochen regelmäßig Lastschriften mit dem Verweis "Kontonummer falsch" zu uns zurückkamen, wo die in der Datenbank hinterlegten Daten sich jedoch nach Rücksprache mit dem Kunden immer als richtig erwiesen. Ein wenig Kopfzerbrechen bereitete mir die Geschichte schon und ich war kurz davor bei unserer Bank anzurufen um dort mal nach der Fehlerursache zu suchen.

Ich habe mir dann aber doch nochmal die Dateien angeschaut, die wir zuvor mit den Lastschriften übermittelt haben, und für die Irrläufer jeweils immer die selbe Kontonummer gefunden: 2147483647

Ohne, dass es mir da schon bewusst gewesen wäre, diese Zahl kam mir so verdammt bekannt vor!

Natürlich: 2147483647 ist die maximal darstellbare Zahl eines 32-Bit Integer. Und so war alles eigentlich mein Fehler, denn aus irgendeiner Gründlichkeit heraus habe ich die Kontonummer vor dem Export nochmal aus einer Zeichenkette heraus in besagten Integer konvertiert.

Schade nur, dass dieser Fehler bares Geld gekostet hat - das ist wohl der Preis dafür, wenn man alles selbst macht

Wie ich gestern bereits schrieb bin ich momentan auf Kundenbesuch. Zwar waren die eigentlichen Störungen gestern bereits binnen einer Stunde gelöst, allerdings bin ich gleich mal eine Nacht länger geblieben und hab heute mehr oder weniger Kontakte gepflegt - zumal hier heute u.a. der Ausstand einer Mitarbeiterin gefeiert wurde. Gratis Essen kann man sich einfach nicht entgehen lassen

Heute mittag habe ich mir überlegt, dass man diese angenehme Reise doch mit einer weiteren verknüpfen könnte und einem Kunden, der noch ein Stück weit tiefer im Norden sitzt, meinen Besuch vorgeschlagen. Wir haben auch sofort einen gemeinsamen Nenner gefunden und so werde ich wohl nicht nach Stuttgart zurück sondern weiter hoch nach Hannover fahren.

Wo es von dort aus hin geht habe ich auch schon so grob im Hinterkopf, was daraus wird, verrate ich allerdings noch nicht.

Eigentlich war ich recht froh mal wieder zu Hause in Stuttgart zu sein. Genau genommen bin ich gestern Abend seit ca. 20 Uhr wieder dort gewesen und freute mich heute mal richtig auszuschlafen. Doch schon um 8:35 klingelte mein Telefon und ein Kunde aus dem bergischen Städtedreieck rief mich an und berichtete mir von seinen Netzwerk-Problemen.

So richtig deren Netzwerk warten tun wir eigentlich gar nicht - immer mal so aushilfsweise. Eigentlich wurde das Netzwerk ursprünglich von einer dritten, quasi vor Ort ansässigen Firma eingerichtet und gewartet. Allerdings war man wohl immer mal wieder unzufrieden mit deren Leistung und so sprangen wir mal ein. Auf Lange Sicht will man es dort in Zukunft nun In-House lösen mit gelegentlicher Unterstützung durch uns.

Nur wie der Zufall es will ist der Hauptzuständige im Urlaub und seine Vertretung auf Projektarbeit im hohen Norden der Republik unterwegs. Ich persönlich habe drei Wege dort ins Netzwerk zu gelangen, die zwei über das Internet sind momentan versperrt und für meinen ISDN-Dial-In habe ich in den letzten Jahren nie einen Port an der Telefonanlage bekommen. So ist der dritte Weg nur noch "vor Ort sein".

Die knapp 500 KM dort hin hätte ich mir gerne geschenkt, doch wenn schon die "Assistentin der Geschäftsführung" (wo bei die Bezeichnung nicht zu ihren Fähigkeiten passt, positiv gemeint) am Telefon sagt, sie will lieber mich im Hause haben, als irgendwen vom eigentlichen Dienstleister, und das meine Anfahrt in etwa genau so lange dauert, wenn nicht gar schneller ist, dann nehm ich doch den weiten Weg auf mich. So sitze ich nun früher als erwartet im Zug und greife nebenbei ein paar Dinge auf, die schon lange erledigt sein wollten

... zumindest theoretisch.

Ich habe gestern Nacht mit der Revision 1245 wohl etwas richtig schönes in unser Produktiv-System geworfen: Wir unterstützen ab sofort SNI.

SNI steht für "Server Name Indication" und ist eine TLS-Erweiterung, die es unseren Webservern erlaubt schon vor dem eigentlichen "HTTP-Gequatsche" herauszufinden, um welche Domain es in der Anfrage gehen wird und dem Client die entsprechenden Zertifikate auszuhändigen. Damit entfällt diese alt eingesessene Bariere des "Ein Zertifikat pro SSL-Port" und macht es somit fast gänzlich überflüssig für Kunden noch dedizierte IPs oder Ports schalten zu müssen - zumal letzteres ohnehin sehr gruselig war.

Natürlich bringt diese schöne neue Technik nichts, wenn der anfragende Client sie nicht beherrscht. Allerdings unterstützen Firefox, Opera und der Internet Explorer (letzterer ab Version 7) SNI bereits von Haus aus. Für Konqueror ist SNI-Support geplant und dementsprechend wird Safari bestimmt auch bald folgen.

Ich bin gespannt, wie sich SNI in den nächsten Monaten oder Jahren durchsetzen wird - oder auch nicht. Allerdings dürften mit dem IE, Firefox und Opera bereits ein sehr sehr großer Teil der Internet-Community kompatibel sein. Fehlt eigentlich nur noch die Server- bzw. Hoster-Landschaft.

Die Gewinner

An dieser Stelle noch einmal von uns einen herzlichen Glückwunsch an "Skein3tic" zum Sieg beim Wettbewerb!

Mit freundlicher Genehmigung des Urhebers und aller auf dem Foto abgebildeten Personen gibts dann hier ein Foto von der Siegerehrung.

Gestern fragte ich bei einem Kunden nach, dessen VPN wir ebenfalls verwalten, ob ich einem seiner Mitarbeiter der jüngst aus der Probezeit gekommen ist sein VPN-Zertifikat erneuern darf. Aufgrund der Probezeit hatte eben selbiges nur eine stark begrenzte Laufzeit.

Per E-Mail bekam ich als Antwort:

Er ist inzwischen auch stolzer Büroschlüsselbesitzer, dann sollte er
auch über eigene VPN-Schlüssel verfügen dürfen.

Leuchtet ein wenig ein... Ich konnte nicht widerstehen:

Lieber er klaut die Daten übers Internet, als das er gleich das ganze Rack mitnimmt

Anbei: Da wird niemand irgendwas klauen