Bernds Blog

Heute fiel mir eine sehr unschöne Sache bei .org-Domains auf. Registriert man eine solche Domain und setzt Nameserver-Einträge, die ebenfalls unter .org laufen, dann ruft die .org-Registry die IP-Adressen dieser Nameserver ab und speichert die. Diese werden dann zusammen mit der NS-Antwort als "Additional Section" an den anfragenden Client übertragen.

Das Ganze ist eine eigentlich nette Service-Leistung und klingt auf den ersten Blick plausibel.

Das Problem beginnt allerdings dann, wenn sich die IP-Adressen der Nameserver ändern. Bei uns wurde einer der drei Name-Server vor über einem halben Jahr entfernt und ein zweiter letzte Woche. Die .org-nameserver liefern aber noch immer unbeeindruckt die alten Adressen aus. Das führt dazu, dass unsere .org-Domains ohne unser Wissen jetzt nicht mehr nur schlecht sondern sogar sehr schlecht erreichbar waren.
Durch eine Änderung der Nameserver kann man erreichen, dass diese IP-Adressen neu angefragt werden. Wie man diesen Vorgang für die einmal irgendwann eingetragenen DNS-Server-Namen macht, ist mir schleierhaft.

Ich hatte mir heute den Tag über Gedanken über ein mögliches DoS-Angriffs-Szenario gemacht, aber kein wirkliches gefunden. Ich hab aber immer noch das Gefühl, dass man das DoS'en kann.

Die Webhostlist (ja, ohne Link. Jeder kann .de dahinter setzen, wenn er will) ist ein Web-Portal, auf dem Angebote von Providern und Gesuche von zukünftigen Kunden zusammen finden sollen. Ein ganz normaler Preisvergleich bzw. Kleinanzeigenmarkt.

Dafür gibt es zwei Kanäle: Das Angebotlisting, in dem jeder Provider seine Angebote einstellt und Kunden nach diversen Kriterien suchen können auf der einen Seite und das Forum auf der anderen Seite. Im Forum stellt ein Kunde seine Anforderungen ein und Provider können mit einem Angebot antworten. nicht selten führt das zu skurrilen Dingen wie "Suche Webspace mit Feature foobar." mit der Antwort "biete das zwar nicht an, aber vielleicht ja was anderes was dich interessiert".

Als wichtige Bemerkung sei noch eingeführt, dass Provider bei Webhostlist unterschiedlichen Status haben können. Ungeprüft ist man immer als erstes. Wenn man dann viel Geld zahlt (ich weiß viel ist relativ), wird man Geprüfter Provider. Dazu muss man eigentlich nichts weiter machen als Geld zu zahlen. Zahlt man dann noch mehr Geld, wird man sogar Premium-Provider. Bisher war der Mehrwert darauf begrenzt, dass neben den Angeboten ein hübsches goldenes Emblem gezeigt wurde, das dem Kunden versichert, dass der Provider auch wirklich Geld an Webhostlist gezahlt hat.

Die zahlenden Provider haben sich (mittlerweile erfolgreich) beschwert, dass das Geldausgeben nur für ein hübsches Bildchen vielleicht nicht ganz gerechtfertigt ist.

Daraufhin wurde folgendes Umgestellt:
Wer ein Gesuch in das Forum einstellt, muss Daten-Striptease betreiben. Webhostlist fordert eine vollständige Adressangabe, anfangs sogar zwingend mit Telefonnummer. Gleichzeitig kann der Suchende auswählen, welcher Provider-Typus seine Daten und sein Gesuch sehen kann. Standardeinstellung ist (*Tusch*) zahlender Geprüfter Provider.
Die Webhostlist begründet das unter dem Applaus einiger zahlender Provider damit, dass man ja auf seriöse Geschäftsbeziehungen setze und daher die Angabe einer Identität verlangt werden könne. Zudem möchten Anbieter auch wissen, wem sie eventuell kein Angebot mehr machen möchten, wenn die den Namen schon kennen. Nun ja.
Ein Foren-Teilnehmer hat das treffend umschrieben mit der Pflicht, bei jedem Geschäft einer Einkaufspassage immer vor jedem Betrachten des Schaufensters eine Visitenkarte abgeben zu müssen.

Klar, so schlägt man zwei Fliegen mit einer Klappe: Es wird für alle Datenkraken-Provider sehr interessant, viel oder sehr viel Geld an Webhostlist zu zahlen, denn dafür bekommt man jetzt zuverlässig neue Adressen für seine Verbraucherinformationen. Webhostlist bekommt also mehr zahlende Kunden. Auf der anderen Seite werden die Adressen ja gespeichert und somit reiht sich Webhostlist nahtlos in die Liste der in den letzten Jahren stark an Wert gestiegenen Unternehmen mit vielen "Benutzerprofilen", in welcher Form auch immer.

Die vielen Forums-Beiträge, die diese Regelung als kompletten Unsinn bezeichnet haben, wurden konsequent ignoriert, was natürlich auch irgendwie aussagt, dass diese Regelung wohl nicht mit guten Argumenten belegt werden kann.

Die komplett sinnbefreite Kompromisslösung, die jetzt angestrebt wird (oder schon implementiert ist), sieht vor, dass der Anbieter erst nach Abgabe eines Angebots die Kontaktdaten des Interessenden sieht. Wie man das überhaupt irgendwie begründen kann, ist mir noch nicht eingefallen.



Als weitere Veränderung (da weiß ich aber nicht seit wann) gibt es bei der Suche nach Webhosting-Tarifen jetzt auch keine Möglichkeit, die nicht-zahlenden Provider überhaupt anzuzeigen. Erst nach Erhalt der Ergebnis-Liste kann man die Suchergebnisse auf nicht-zahlende Provider ausdehnen. Und diese Einstellung springt meiner Erfahrung nach manchmal etwas willkürlich wieder auf die Standardeinstellung zurück.

Was ich damit sagen will: Jeder, der über Webhostlist einen Provider sucht, sollte sich darüber im Klaren sein, dass er immer erstmal nur Angebote von Firmen bekommt, die der Webhostlist Geld bezahlt haben. Auch wenn die Webhostlist sich nach außen als kostenlos für beide Seiten kommuniziert. Und dass im Forum nun die Angabe falscher Daten zur Regel wird, ist (denke ich) auch klar.

Nachdem ich jetzt doch von einigen Leuten weiß, die meinen greylisting-Filter bei sich einsetzen, kann ich das auch grade mal hier announcen... ;-)

Es gibt davon eine neue Version. Es gibt einen ziemlichen Bruch, es wird jetzt MySQL anstelle von SQLite als Backend benutzt. Das liegt daran, dass ich vor habe, eine selektive Whitelist (»Mails an diese Adresse bitte in den nächsten 10 Minuten nicht greylisten«) für unsere Kunden zu ermöglichen. Dazu muss es eine gemeinsame Datenbank für das webinterface und das greylisting geben, was hiermit geschehen ist.

Die offizielle Release-Seite enthält auch ein detaillierteres Change-Log.

Peinlicherweise habe ich erst ein paar Minuten nach dem Release festgestellt, dass die neue Version von courier, für die ich grade ein ebuild erstellt habe, eine kleine API-Änderung hat. ich habe mit einem Bugfix-Release der Version 2.0.1 darauf reagiert.

Wer einen Account auf einem Server hat, dem kommt ab und zu das Verlangen, sich in der Fremde einfach mal dort einzuloggen um eine vertraute Umgebung vorzufinden. Seit es um den perfekt konfigurierten »mutt« zu benutzen, schnell im »screen« dem laufenden »irssi« zu zu schauen oder einfach um eine vorher dort hinterlegte Datei zu lesen.

Praktisch ist es natürlich gefährlich, sich von einem nicht vertrauenswürdigen Rechner auf einem Server einzuloggen. Bei der Eingabe des Passwortes auf einem fremden Rechner besteht immer die Gefahr, dass ein böswilliger Admin, ein Schäuble oder die Werbeindustrie einfach alle Tastendrücke aufzeichnet und damit sehr einfach das Passwort für den sicher geglaubten Account erhält.

Um diesem Problem generisch, also für alle fremden Rechner brauchbar zu begegnen, gibt es Einmalpasswörter. Mit diesem Verfahren (das in etwa den TANs vom PIN/TAN-Onlinebanking nahe kommt), gibt es eine Liste von Passwörtern, die jeweils nur einmal gültig sind. Sind die verbraucht, sind sie ungültig.

Unter unixoiden Systemen hat sich dafür das S/Key-System einen Namen gemacht. Es läuft auf den meisten Plattformen und lässt sich sauber z.B. mit PAM einbinden. Das Verfahren ist sehr transparent und die Einmalpasswörter lassen sich mit dem challenge, das vom Server beim Login genannt wird auch extern berechnen. So braucht man keine Papier-Liste mitnehmen sondern kann z.B. mit einem Java-fähigen Handy die Einmalpasswörter (auf einem vertrauenwürdigen Gerät) errechnen lassen.

Sehr edel das ganze, daher haben wir das auch gleich auf schokokeks.org eingebaut. Als Anleitung verweise ich hier mal auf unseren Wiki-Artikel zu Einmalpasswörtern.

Sei noch erwähnt, dass es mehrere Möglichkeiten gibt, S/Key unter SSH zu benutzen. SSH bringt eine solche Funktionalität selbst mit (Gentoo-USE-Flag skey) und es gibt alternativ dazu das PAM-Modul pam_skey.

Wir haben uns für letztere Variante entschieden, da die SSH-Lösung für den Benutzer weniger transparent ist. Bei SSH wird erst nach dem normalen Passwort gefragt und wenn dies leer oder falsch ist, dann wird nach dem S/Key-Einmalpasswort gefragt.

Bei pam_skey dagegen wird, sofern der Benutzer skey für sich aktiviert hat, gleich nach »S/Key response or system password« gefragt. Ist skey für den Benutzer nicht aktiviert, wird das PAM-Modul einfach übergangen und das normale Passwort abgefragt.

Mit unserer Firma bin auch ich direkt von der Vorratsdatenspeicheurng betroffen. Bei allem Aktivismus und berechtigter Kritik an der ganzen Sache, darf man aber meines Erachtens trotzdem die geltenden Gesetze nicht einfach ignorieren sondern jetzt, da das alles gilt, muss man es auch erst einmal beachten. Natürlich in der Hoffnung, dass das Bundesverfassungsgericht das alles wieder kippt.

Ich habe heute ungelogen einen Tag damit verbracht, das "Gesetz zur Neuregelung der Telekommunikationsüberwachung und anderer verdeckter Ermittlungsmaßnahmen sowie zur Umsetzung der Richtlinie 2006/24/EG vom 21. Dezember 2007" zu finden, zu lesen, die Bezüge zu recherchieren, herauszufunden was uns als E-Mail-Provider betrifft und das alles zu verstehen.

Ich möchte gerne die stellen aus den Gesetzen zitieren, die ich persönlich als einschlägig betrachte. ausdrücklich möchte ich darum bitten, dass jeder, der irgend etwas anders verstanden hat, also denkt, ich hätte etwas falsch aufgefasst oder übersehen, mir das bitte mitteilt. Zudem ist hoffentlich klar, dass von mir zu diesem Thema gegebene Kommentare jeglicher juristischer Sachkunde entbehren und die Gesetzes-Auszüge sich nicht eignen um sich darauf zu verlassen. das ist hier keine Rechtsberatung und so, klar.

ich verlinke an einigen Stellen zu www.gesetze-im-internet.de. Dort ist jetzt momentan noch die alte, nicht mehr gültige Version der Gesetze zu begutachten, das eignet sich aber gut um das Fließtext-Diff in oben verlinkter PDF-Datei darauf anzuwenden.

*pust* [...] *hust*, *röchel*
Wow, ist das eingestaubt hier. Sorry, war anderweitig beschäftigt.

Fabians Blog-Eintrag von neulich möchte ich glatt mal aufgreifen.

Wenn mein Jabber-Status (der auch meistens stimmt!) auf Away bzw. N/A steht, dann bin ich nicht da. Manchmal setze ich den den Status auch von Hand auf DnD oder N/A. Auch dann bin ich zwar oft physisch am Rechner aber eben nicht gewillt, mich mental auf leichte Konversation einzustellen. Meistens arbeite ich irgend etwas. :)

Wenn mein Status also nicht auf Online steht, dann steht es jedem frei, mir dennoch Nachrichten zukommen zu lassen. Ob ich gleich oder später darauf antworte, hängt aber maßgeblich vom Inhalt ab. Auf ein »hi« ohne weiteren Content werde ich in der Regel 3 Stunden später nicht mehr antworten. Auch wenn ich beschäftigt bin, unterbreche ich meine Arbeit normal frühestens für eine Antwort auf die Nachricht nach dem »hi«. Und wer einen komplexen oder wichtigen Sachverhalt zu sagen hat, der ist in der Regel sowieso mit E-Mail oder gar Bugtracker besser bedient, denn nur da sind die Sachen eine gewisse Zeit später immer noch da.

Das jetzt nicht akut auf einen oder wenige Fälle bezogen, ich denke viele könnten sich angesprochen fühlen. Es ist eher eine allgemeine Feststellung, dass sich Leute offenbar wenig Gedanken machen, wie das auf mich wirkt, wenn ich zurück an den Rechner komme und 10 mal »hi« ohne weiteren Inhalt vorfinde.