Thomas Falkner

1&1 stellt gekündigte Domain in Rechnung

Geschrieben von Thomas Falkner - 02.10.07 um 09:10

Eines muss man 1&1 lassen: Sie wissen wie man Geld verdient. Nachdem die 1&1 Internet AG kürzlich eigenmächtig eine Domain aus meinem Vertrag gelöscht hat, mich aber weiterhin für den nun brachliegenden Webspace zu Kasse bat, stellen sie mir nun eine weitere, am 27.07.2007 per KK an die Key-Systems GmbH übergebene Domain in Rechnung. Meine telefonisch Bitte um Stornierung der Rechnung wurde von 1&1 damit beantwortet, dass ich doch bitte beweisen möge, mit der Domain tatsächlich umgezogen zu sein. Das sollte kein Problem werden, allerdings ist es eine Frechheit als Kunde in die Pflicht der Beweisführung genommen zu werden.

Wie Rene bereits so treffend kommentierte: “Alles sehr schön dort, doch wenn man mal raus will dann wird’s unangenehm.”

Geht doch – mit Signtrust-Zertifikaten E-Mails signieren

Geschrieben von Thomas Falkner - 01.10.07 um 06:10

Bislang wurden per E-Mail verschickte Rechnung in unserem Unternehmen über DATEV e:secure signiert. Die Lösung funktonierte viele Jahre problemlos. Doch leider stellt DATEV den Trustcenterbetrieb ein – soweit mir bekannt aufgrund mangelnder Nachfrage. Auf der Suche nach einer Alternative verwies DATEV uns an Signtrust, eine Tocher der Post AG.

Nachdem in der letzten Woche bereits Smartcard und PIN-Codes bei uns eingingen, wurde auch heute der neue Cardreader geliefert. Die Installation der mitgelieferten Software verlief zwar unnötig kompliziert, aber problemlos. Testweise signierten und verschlüsselten wir über die im Lieferumfang enthaltene Software OpenLimit SignCubes einige Dateien – klappte prima.

Doch die Probleme folgten stehenden Fußes, als wir versuchten das Signtrust-Zertifikat seinem primären Zweck zuzuführen: Dem Signieren von E-Mails aus Microsoft Outlook 2003 heraus. Zwar ließ sich das Zertifikat ohne Mühe einbinden, doch beim Versenden von zu signierenden E-Mails verweigerte Outlook mit der Fehlermeldung den Dienst, dass die Nachricht weder verschlüsselt noch signiert werden könne, da keine Zertifikate für das Senden von Nachrichten von der Adresse vorhanden seien.

Ein Blick auf die Details des Zertifikats bestätigten die Fehlermeldung. Tatsächlich war für den Antragssteller keine E-Mailadresse im Signtrust-Zertifikat hinterlegt.
Allerdings fordert S/MIME v2 dass in den verwendeten Zertifikaten die E-Mailadresse des Absenders hinterlegt sein muss. Darüber inwieweit es sinnvoll ist ein Zertifikat an eine E-Mailadresse zu binden, lässt sich vortrefflich streiten, aber es ist mehr als ärgerlich, dass sich die doch recht teueren Signtrust-Zertifikate nicht ohne Weiteres zum Signieren von E-Mails nutzen lassen.

Zum Glück gibt es eine, der Supportabteilung von Signtrust übrigens bislang unbekannte, Lösung für Outlook 2003.
Tatsächlich ist die Absenderadresse zur Überprüfung einer signierten E-Mail völlig unerheblich, da das Zertifikat an den Antragsteller gebunden ist und seine E-Mailadresse nur ein zusätzlich Attribut ist. Darum wird zumindest von Outlook kein Zertifikat nur aufgrund einer abweichenden E-Mailadresse als ungültig eingestuft. Lediglich der Versand bereitet Probleme, doch das lässt sich via Registry lösen.

Dazu ist im Hive HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\11.0\Outlook\Security der DWORD-Wert SupressNameChecks einzufügen und mit 1 zu belegen. Fortan lassen sich über Outlook auch mit Signtrust-Zertifikaten signierte E-Mails versenden.

Ein Supporter von Signtrust insistierte, Signtrust habe uns ausdrücklich darauf hingewiesen, dass es nicht möglich ist mit Signtrust-Zertifikaten E-Mails zu signieren. Bislang gelang es mir jedoch nicht einen entsprechenden Vermerk in den Unterlagen zu finden – außerdem geht es ja dennoch, wenn auch nur über Umwege. Allerdings wirkte die Erklärung sehr einstudiert und erfolgte schon, ehe ich unser Problem vollständig schildern konnte. Mich deucht, dass unsere Beschwerde kein Einzelfall ist.

Übrigens gab Signtrust mir die Auskunft, dass Ihnen keine Genehmigung der Bundesnetzagentur vorläge, um die E-Mailadresse des Antragsstellers ins Zertifikat zu integrieren. Weiß jemand genaueres darüber?

TurboDbAdmin, die Web 2.0 Alternative zu phpMyAdmin

Geschrieben von Thomas Falkner - 30.09.07 um 09:09

TruboDbAdmin versprich eine interessante Alternative zu phpMyAdmin zu werden. Zwar kann TurboDbAdmin noch nicht mit dem Funktionsumfang von phpMyAdmin gleichziehen, jedoch bietet es dank extensiven Einsatz von AJAX-Technologie einen wesentlich höheren Komfort.

SSH absichern

Geschrieben von Thomas Falkner - 25.09.07 um 07:09

Vor einiger Zeit schon  habe ich mir vorgenommen etwas darüber zu schreiben, wie ein Webserver abgesichert werden kann. Darum nehme ich die heute kürzlich gestellte Frage zum Anlass endlich damit zu beginnen und fange bei SSH an. Im folgenden beziehe ich mich auf die Implementierung OpenSSH. Die Konfiguration anderer Implementierung wie etwas SSH.com verläuft ähnlich, weicht jedoch im Detail ab.

Bevor wir beginnen, solltest du sicherstellen, dass du eine aktuelle SSH Version benutzt. Unter Debian genügt dazu der Einzeiler apt-get update; apt-get dist-upgrade. Unter anderen Distributionen stehen ähnliche Werkzeuge zum Update zur Verfügung wie etwas yast unter Suse.

Nun ist es an der Zeit die Konfigurationsdatei /etc/ssh/sshd_config zu bearbeiten. Ich werde im folgenden die sicherheitsrelevanten Optionen durchgehen und kurz kommentieren.

ListenAddress 217.79.182.18

Wenn ein Server mit mehr als einem Netzwerkinterface ausgestattet ist, kann es sinnvoll sein den Zugriff bestimmte Interfaces zu beschränken. Beim klassischen Webserver dürfte das allerdings nicht der Fall sein.

Port 2222

Standardmäßig lauscht der SSH-Dämon auf Port 22. Viele Bruteforceattacken gegen ganze Netzwerksegmente können durch Nutzung eines anderen Ports erfolgreich abgewehrt werden. Solche Angriffe gehen meist von Botnetzen oder bereits gekaperten Servern aus, die mit großer Bandbreite tausende Logins gegen Port 22 feuern. Dabei werden Standardbenutzernamen (admin, root, httpd, mail usw.) mit leerem Passwort oder Passwörter aus Wörterbüchern und Passwortlisten durchprobiert. Solche Angriffe können zwar einen sicher konfigurierten Server nicht gefährden, blähen aber die Logdateien auf, führen zu verminderten Reaktionszeiten und schlimmstenfalls können sich legitimierte Benutzer ob der vielen Anfragen nicht über SSH einloggen. Selbstverständlich bietet die Nutzung eines anderen Ports keinen Schutz gegen gezielte Brutforceangriffe, bei denen dem eigentlichen Angriff ein Portscan vorausgeht. Abhilfe können hier zum Beispiel sshblack schaffen oder eine Kombination von Snort, Netfilter und iptables. Da DoS-Attacken kein SSH-spezifisches Problem sind, werde ich an dieser Stelle nicht weiter darauf eingehen.

Protocol 2

Die Version 1 des SSH-Protokoll enthält Designschwächen, die einen unbefugten Login ermöglichen, und sollte darum nicht benutzt werden.

PermitRootLogin no

Es ist eine gute Idee root den Zugang über SSH zu verwehren. Denn wenn jemand gelänge sich über SSH unbefugt Zugang zum Server zu verschaffen, könnte er als unprivilegierter Nutzer nur begrenz Schaden anrichten. Da es ohnehin von Leichtsinn zeugt stets als root zu arbeiten, spricht auch wenig dafür den direkten Login als root zu erlauben. Wichtig ist auf einen frisch installierten System einen neuen Benutzer anzulegen, bevor wir über PermitRootLogin no root vom SSH-Login ausschließen.

AllowUsers tom thomasfalkner@thomas-falkner.de
AllowGroups admin

Wenn nur bestimmte Nutzer sich via SSH auf dem Server einloggen dürfen, können diese über AllowUsers bestimmt werden. Wenn Benutzer nur von einem bestimmten Host aus Zugang zum Rechner erhalten sollen, kann dass über user@host geregelt werden. Das kann sinnvoll sein, wenn ein Webdesigner sich nur aus dem Firmennetzwerk, nicht aber von zu Hause auf dem Server anmelden darf. Durch die Option AllowGroups kann der Login auf bestimmte Benutzergruppen beschränkt werden.
Sollen mehr Benutzer erlaubt als ausgeschlossen werden, ersparen die Gegenstücke zu AllowUsers und AllowGroups, DenyUsers und DenyGroups, eine Menge Tipparbeit.

Doch es ist nicht nur wichtig festzulegen, wer sich über SSH anmelden darf, sondern auch welche Authentifizierungsverfahren dazu genutzt werden sollen. Hier greift die Regle: Alles deaktivieren, was nicht benötigt wird.

Wer mit dem höchsten Sicherheitsstandard arbeiten möchten, sollte ausschließlich die PubKeyAuthentication nutzen und alle anderen Authentifizierungsverfahren ausschalten.

RhostsRSAAuthentication no
HostbasedAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
RSAAuthentication no


Obwohl die meisten Optionen wie etwa RhostsRSAAuthentication per Default abgeschaltet sind, halte ich es für sinnvoll sie explizit auf no zu setzen, um eine klare Konfiguration vor Augen zu haben. Ferner wäre es töricht davon auszugehen, dass die Defaulteinstellungen sich bei neueren Versionen nicht ändern würden. Updates sollten übrigens ohnehin nie ungeprüft eingespielt werden.

Bevor wir die Passwort basierte Anmeldung mittels PasswordAuthentication no und UsePAM no vollständig deaktivieren, muss zuerst die Anmeldung über PubKey konfiguriert und getestet werden – sonst laufen wir Gefahr uns selbst auszusperren.

Dazu ergänzen wir /etc/ssh/sshd_config wie folgt:

PubkeyAuthentication yes
Damit wird die Authentifizierungs per RSA- oder DSA-Schlüssel aktiviert.

AuthorizedKeysFile %h/.ssh/authorized_keys

Gibt an, wo die öffentlichen Schlüssel auf dem Server gespeichert werden.
Per Default im Homeverzeichnis des jeweiligen Benutzers unter .ssh/authorized_keys.

Nun sollte der der SSH-Dämon neu gestartet werden: sudo /etc/init.d/sshd restart

Damit ist der Server vorbereitet für den passwortfreien Login über Schlüssel. Was fehlt ist der Schlüssel, oder genauer gesagt das Schlüsselpaar. Da der private Teil des Schlüssels auf dem Client verbleibt und nur der öffentliche auf den Server kopiert wird, empfiehlt es sich das Schlüsselpaar auf dem Client zu erzeugen. Unter UNIX-Derivaten starten wir dazu unter dem Useraccount, der sich später auf dem Server einloggen können soll, ssh-keygen.

ssh-keygen -t dsa

Wenn die Voreinstellung bestätigt wird, legt ssh-keygen den private Schlüssel id_dsa als auch den öffentlich id_dsa_pub unter ~/.ssh ab. Die Frage nach der Passphrase kann mit 2x Return übergangen werden, wenn man den Schlüssel nicht mit einem Passwort schützen möchte. Eine generelle Empfehlung ob es sinnvoll ist den Schlüssel mit einem Passwort zu schützen oder nicht, ist schwer möglich. Wird kann Passwort vergeben, kann jeder sich auf dem Server anmelden, der in Besitz des Schlüssels ist. Soll heißen: Wird der Rechner, auf dem der private Schlüssel hinterlegt ist geknackt oder gerät in falsche Hände, steht dem Angreifer auch der Zugang zum Server offen.
Sind die Schlüssel mit einem Passwort zusätzlich geschützt, müsste der Angreifer erst das Passwort per Bruteforce knacken – was bei ausreichend starken Passwort nicht in angemessener Zeit möglich ist.
Das höhere Maß an Sicherheit erkauft man sich jedoch mit der lästigen Eingabe des Passworts beim Login über SSH.

Ist der Schlüssel je nach Gusto mit oder ohne Passpharse erzeugt, muss er auf den Server übertragen werden.

Zuerst prüfen wir, ob es in unserem Homeverzeichnis auf dem Server einen Order .ssh bereits gibt. Wenn nicht, legen wir ihn an. Dazu kann folgender Einzeiler vom Client aus abgesetzt werden:

ssh domain.tld -p2222 "test -d .ssh || mkdir .ssh && chmod 700 .ssh"

Wie oben erwähnt, gehe ich davon aus, dass der User auf dem Client den gleichen Namen trägt wie auf dem Server.
Aus Sicherheitsgründen ist es unerlässlich, dass die Zugriffsrechte des .ssh-Verzeichnisses auf 700 und die für authorized_keys auf 600. Ferner müssen sowohl Datei als auch Verzeichnis dem anzumeldenden User gehören.
Letztere Bedingung erfüllen wir, indem wir Verzeichnis und Datei selbst anlegen, die Zugriffsrechte indes sollten wir explizit setzen.
Auch das lässt sich zu einem Befehl zusammenfassen:
cat ~/.ssh/id_dsa_pub | ssh domain.tld -p2222 "cat >> .ssh/authorized_keys && chmod 600 .ssh/authorized_keys"

Der passwortlose Login sollte damit funktionieren.

Zu den Möglichkeiten von SSH lässt sich noch eine Menge schreiben. Zu gegebener Zeit an dieser Stelle mehr.

Tom goes C#

Geschrieben von Thomas Falkner - 23.09.07 um 07:09

Ich arbeite mich momentan in C# ein und bin von der Sprache begeistert. Sie bietet alle Merkmale, die ich mir von einer modernen, objektorientierten Programmiersprache wünsche und bringt in der .NET-Umgebung Standardbibliotheken für nahezu alle Probleme mit, die sich im Alltag eines Programmierers stellen.
Da ich – vor allem bedingt durch mein Studium – geübt im Umgang mit Java bin, brauchte ich nicht mehr als dieses Wochenende, um mich mit Syntax und Konzepten von C# vertraut zu machen.

1&1 löscht Domain und kassiert für brachliegenden Webspace

Geschrieben von Thomas Falkner - 12.08.07 um 12:08

Wäre es rechtens wenn ein Mobilfunkanbieter die Handynummer eines Kunden vor Ablauf des Vertrags löschen würde, aber weiterhin über Monate bis zur Wirksamkeit der Kündigung auf seine Vergütung bestünde? Was selbst die größten Raubritter unter den Mobilfunkanbietern nicht wagen, scheint bei 1&1 gängige Praxis zu sein: Eine Domain wurde durch Versagen des Kundenservice vorzeitig gelöscht. Ohne Domain kann ich den Webspace bei 1&1 nicht mehr nutzen, werde aber von 1&1 bis zum 22.11.07 monatlich mit 13,33 Euro zur Kasse gebeten. Der Support speit mich – ganz im Trend der Zeit – mit Standardantworten ab.

Derzeit überlege ich, ob ich solch ein Geschäftsgebaren ohne Widerspruch hinehmen soll oder es tatsächlich auf einen Rechtsstreit ankommen lasse. Mir geht es dabei nicht um die paar Euro, sondern vielmehr ums Prinzip. De facto entstehen 1&1 durch meinen brachliegenden Webspace, den ich ob der fehlenden Domain nicht mehr nutzen kann, keinerlei Kosten. Selbst wenn die besagte Domain auf meinen expliziten Wunsch hin rund vier Monate vor Ablauf der Kündigungsfrist gelöscht worden wären, könnte 1&1 mich als Akt der Kullanz aus dem Vertrag entlassen – zumal ich seit über 6 Jahren Kunde bin.
Doch in diesem Fall wäre es keine Kullanz, sondern eine Selbstverständlichkeit den Vertrag vorzeitig aufzuheben: Hat doch nachweislich der Kundenservice von 1&1 versagt und die Löschung der besagten Domain verursacht. Prinzipiell könnte ich sogar gegen die vorzeitige Löschung meiner Domain juristisch vorgehen, glaubte ich an die Logik von Gerichten.

Wenn der 1&1-Mitarbeiter wie in der unten abgedruckten Mail behauptet tatsächlich meine Unterlagen geprüft hat, hätte er gut daran getan meinen Wunsch auf sofortiger Kündigung des Vertrags zu entsprechen. Denn wenn ein Kunde schon keinen Schadensersatz für die vorzeitige Löschung seiner Domain geltend macht, sollte man ihn nicht durch absurde Forderungen verärgern.

Am 01.08.07 schrieb support@1und1.de :

> Die Kündigung Ihres Vertrages ist zum 22.11.2007 eingetragen. Daraus
> resultiert die Rechnung über Ihre Grundgebühr vom 01.08.2007

Meine Frage war: Welche Leistung wird mir in Rechnung gestellt. Da die
bei Ihnen gehosteten Domains bereits gelöscht wurden, kann ich
den Webspace nicht mehr nutzen.

Mit freundlichen Grüßen
Thomas Falkner

Sehr geehrter Herr Falkner,

vielen Dank für Ihre Anfrage.

Nach Überprüfung Ihrer Unterlagen darf ich Ihnen mitteilen, dass Sie den
1&1 Business 5.0 Vertrag bei uns haben, welcher zum 22.11.2007 gekündigt
wird.

Die Berechnung des Vertrages ist unabhängig von den enthaltenen Domains.
Auch wenn dieser Vertrag keine Domains enthält, die Vertragslaufzeit
aber noch läuft, wird dieser berechnet.

Wir bitten um Ihr Verständnis.

Mit freundlichen Grüßen

xxxxxx xxxxxxxxxx
Rechnungsstelle
1&1 Internet AG

a+b = a*b

Geschrieben von Thomas Falkner - 30.06.07 um 11:06

Ist es nicht bemerkenswert, dass 2+2 das gleiche wie 2×2 ergibt? Tatsächliche ist die 2 die einzige natürliche Zahl mit dieser Eigenschaft. Doch es finden sich zahlreiche Zahlen [tex]{N} \setminus \{0\}[/tex] für die gilt:

[tex]a+b = a*b[/tex]

Wer kann passende Werte für a und b nennen? Wieviele Lösungen sind möglich?
Kleiner Tip: Es gibt nicht nur natürliche Zahlen.

Mal wieder Ärger mit EVANZO

Geschrieben von Thomas Falkner - 30.06.07 um 12:06

Ich versuche für einen Kunden seit nun mehr rund zwei Wochen erfolglos Domains per KK zu übernehmen. Doch EVANZO tut wirklich alles, um seiner schlechten Reputation zu entsprechen und blockiert. Allen Anschein nach hilft es tatsächlich nur gegen EVANZO die juristische Keule auszupacken. Zwar finde ich es sehr unschön sich positiv auf Anwälte und Justiz zu beziehen, allerdings scheint es mir in unserer derzeitigen Gesellschaftsform keinen anderen Ausweg zu geben, wenn ein Anbieter eine Domain nicht freigeben möchte.

Es gibt nichts…

Geschrieben von Thomas Falkner - 21.06.07 um 11:06

was sich mit Kabelbindern nicht reparieren ließe. Selbst fehlende Lüfterklammern lassen sich mit einem Quentchen Geschick ersetzen.

Gewiss keine Lösung auf Dauer, aber um den Rechner kurzfristig wieder ans Laufen zu bekommen durchaus praktikabel.

EVANZO! – Clevere hosten woanders

Geschrieben von Thomas Falkner - 20.06.07 um 11:06

Bei Billighoster EVANZO kam es häufig zu Störungen und Ausfällen. Bei einem meiner Kunden war alleine in diesem Jahr der Mailserver zusammengerechnet einige Tage nicht erreichbar. Störungsmeldungen per E-Mail werden meiner Erfahrungen nach vom technischen Support rigoros ignoriert – ob absichtlich oder aufgrund Versagens der eigenen Mailserver, sei einmal dahingestellt. So bleibt nur der Weg über die kostenpflichtige Supporthotline. Die Qualität der Hotline lässt noch mehr zu wünschen übrig als die instabilen Server des Hosters: Die Mitarbeiter gaben sich bei meinen zahlreichen Anrufen durchweg inkompetent und unfreundlich. Doch der Dialog von heute Nachmittag stellt alles bisher dagewesene in den Schatten.

Tom: Der Mailserver mail.domain.tld* ist mal wieder nicht erreichbar.
Mitarbeiter: Da brauche ich erst einmal ihre Kundennummer.
Tom: Leider habe ich die nicht griffbereit. Das Problem ist auch nicht vertragsspezifisch. Der Server bedient auch andere Kunden und ist nicht verfügbar.
Mitarbeiter: Dann kann ich ihnen nicht helfen.
Tom: Warum können Sie nicht den Server mail.domain.tld als ausgefallen/gestört melden?
Mitarbeiter: Ok, ich werde das ausnahmsweise überprüfen. Bitte nennen Sie mir die Zugangsdaten zu einer Ihrer E-Mailadressen.
Tom: Warum das?
Mitarbeiter: Wollen Sie, dass ich Ihnen helfe?
Tom: Ja!
Mitarbeiter: Dann nennen Sie mir die Zugangsdaten.
Tom: Nein!
Mitarbeiter: Bitte nicht in diesen Ton, sonst muss ich das Gespräch beenden.
Tom: Wie bitte? Weil ich mich weigere Ihnen die Zugangsdaten zu einem E-Mailaccount zu nennen?
Mitarbeiter: Wenn ich ihnen helfen soll, müssen sie meinen Anweisungen folgen.
Tom: Sie benötigen keine Zugangsdaten um die Erreichbarkeit eines Mailserver zu überprüfen.
Mitarbeiter: Wenn Sie das so genau wissen, warum rufen Sie dann an?
Tom: Ich kann via telnet mail.domain.tld 25 feststellen, ob der Server antwortet oder nicht.
Mitarbeiter: Das ist eine unzulässige Nutzung unserer Server.
Tom: …
Mitarbeiter: Sie müssen schon ein zugelassenes E-Mailprogramm wie Outlook verwenden.
Tom: …
Mitarbeiter: Hallo?! Sind sie noch da.
Tom: Ja. Aber so kommen wir nicht weiter. Bitte melden Sie die Server als ausgefallen.
Mitarbeiter: Dazu muss ich erst überprüfen, ob sie Ihr E-Mailprogramm richtig eingestellt haben. Wenn sie kein richtiges E-Mailprogramm verwendet haben, kann ich ihnen auch nicht helfen.

*Echte Adresse ersetzt.

Ab diesem Punkt fehlten mir die Nerven diesen sinnlosen Dialog fortzuführen. Ich setzte eine Frist, um eine Lösung für den ausgefallenen Mailserver zu finden. Die Frist ist natürlich lange verstrichen und der Mailserver weiterhin nicht erreichbar. Dafür ist nun auch der Webserver ausgefallen.
Ich werde morgen meinen Kunden zu einer außerordentlichen Kündigung unter Auferlegung der Kosten für die Ausfallzeit raten.

Search