Archiv für den Monat: Januar 2009

Teleos und seine Port-Sperren

Port-Sperren

Im September letzten Jahres bin ich mit meinem DSL-Anschluss zum örtlichen Telefonanbieter Teleos gewechselt. Nach einem kurzen Telefonat mit der Hotline stand fest das ich zwar kein ADSL2+ mit 16 MBit bekommen würde, aber etwa die Hälfte sollte es schon werden. Nach dem Wechsel und der Aufschaltung waren es dann ca. 14 MBit mit massiven Störungen und Leitungsabbrüchen. Diese konnten nach einem weiteren Telefonat mit der technischen Hotline beseitigt werden. Es blieben zwar nur noch 7 MBit übrig, die laufen dafür aber stabil. Mit dem Ergebnis war ich durchaus zufrieden, da mir die Telekom nur einen 3 MBit DSL-Anschluss schalten wollte.

Ich konnte also meine Rechner wieder in Betrieb nehmen und meinen Lancom-Router mit einen zweiten DSLAnschluss erweitern. Das klappt mit dem Router wunderbar und die Daten werden über beide DSL-Anschlüsse ins Netz übertragen. Zwar kann ich einen Download nicht mit mehr als 7 MBit laufen lassen, dafür habe ich aber noch ausreichend Bandbreite für andere Dinge die parallel laufen.

Der Mailserver

Als ich zum Jahreswechsel ein paar Tage frei hatte habe ich mal wieder etwas gebastelt und mit meinem Mailserver gespielt. Dieser hat darauf hin ein paar DNS-Anfragen versendet, die mein Provider Teleos zum Anlass genommen hat meinen Rechner als Viren Schleuder zu identifizieren um mir kurzer Hand den Port 25 zu sperren. Dem Unkundigen DSLNormalo wäre das egal gewesen, er hätte seine Mails weiterhin beim SMTP-Server von Teleos eingeworfen und alles hätte weiter funktioniert. Mir war dies nicht egal da ich einen anderen SMTP-Server, den meiner Domäne, benutze. Dieser war aber seit der Port Sperre für mich nicht mehr zu erreichen. Statt dessen bekam ich meine versendeten Mail nach ein paar Sekunden zurück, mit dem freundlichen Hinweis mich doch bitte bei der Hotline zu melden weil ich Viren und Trojaner verteilen würde. Der nachfolgende Text schmückte fortan alle meine Mails die ich versucht habe zu versenden:

Client host rejected: Sie sind als SPAMMER in Erscheinung getreten und
deshalb fuer SMTP gesperrt worden. Sehr wahrscheinlich ist Ihr Rechner
mit Schadsoftware (Trojaner,Virus etc.) infiziert. Bitte wenden Sie
sich zwecks weiter fuehrender Informationen an die technische
Hotline unter 01805-835367

Bei der ersten Mail dachte ich noch an ein zu scharf konfigurierten Spam Filter beim Empfänger, da mir die Telefonnummer nichts sagte, beim zweiten Mail machte ich mich auf die Suche nach einer Lösung. Einfach mal die Nummer angerufen und dort die Ansage abgehört um zu erfahren welche Firma meine Mails nicht weiterleiten will. Es war mein DSL-Provider.

Ein Mail an den Support mit der Bitte um ein Lösung für mein Problem wurde am nächsten Werktag mit der folgenden Erklärung beantwortet:“Teleos hat auf Ihrem Internetzugang den Port 25 gesperrt, da über Ihren Internetzugang Spammmails verschickt wurden. Ursache ist ein offenes Mailrelay auf Ihrem System.“ Für weitere Informationen und die Freischaltung möge ich doch bitte den technischen Support anrufen.

Suche im LOG

Natürlich habe ich erst mal auf meinem Linux System die LOG-Files durchgesehen, ob dort irgendwelche Auffälligkeiten zu sehen waren und wo ich denn Spam Mails versendet habe. Die gab es aber nicht. Hätte mich auch gewundert, wo doch nur mein Linux Rechner den Port 25 zum Senden nach Außen benutzen darf und auf diesem 2 Virenscanner alle Mails untersuchen. Alle anderen Rechner in meinem kleinen Netzwerk kommen mit dem Port 25 nicht durch die Firewall des Routers durch. Also blieb nur noch der Anruf bei der Hotline um das Problem zu klären.

Dem freundlichen Mann an der Hotline schilderte ich kurz mein Problem und er schaute in seinem System nach was dort zu meiner Kundennummer vermerkt war. Die Antwort war kurz und knapp: Er dürfe mir den Port 25 nicht wieder frei schalten, da von meinem System Spam Mails versendet worden sein. Außerdem sei es nicht vorgesehen das ich zum Versand von Mails einen anderen SMTP-Server als den von Teleos benutze. Der Hotliner empfahl mir im weiteren Gespräch noch einmal per Mail den genauen Sachverhalt darzulegen und mich damit an den Support von Teleos zu wenden.

An diesem Punkt habe ich mir die AGBs noch einmal genau durchgelesen um nach dem Passus zu suchen wo ich gegen diese verstoßen habe und wo steht das ich zwingend den SMTP-Server von Teleos benutzen muss. Ich konnte nichts von beiden finden. In einem weiteren Mail an den Support habe ich also dargelegt warum ich den Port 25 benötige um meine Mails bei dem für meine Adresse zuständigen Mailserver abzuliefern. Als eine Option habe ich auch eine Rückabwicklung des Vertrags angeboten falls mein Vorhaben nicht mit der Geschäftspolitik von Teleos vereinbar wäre.

Auslegung der AGBs

Die Antwort vom Support am nächsten Werktag war sehr ernüchternd und hat mir mehrere Zorn Falten ins Gesicht getrieben. Dort kamen Aussagen wie

  • „Eine Deaktivierung der SMTP-Sperre macht keinen Sinn“ weil sonst der gesamte IP-Bereich von Teleos auf diversen Blacklisten landen würde und dann kein Kunde mehr Mails versenden könnte.
  • „Ursache der SMTP-Sperre an Ihrem Anschluss wird sein, dass von Ihrem Internetzugang über eine dynamische IP-Adresse direkt Mails verschickt werden“
  • „Die Portsperre wurde gemäß der Geschäftsbedingungen (siehe A1.1 / A5.3 / A9.6 „missbräuchliche Nutzung“) eingerichtet.“
  • „Sie sollten dies auch nicht als Maßregelung seitens Teleos betrachten, sondern als Hinweis auf eine Schwachstelle in Ihrer Konfiguration bzw. im System bei Ihnen“

Der Support hätte doch einfach schreiben sollen das Teleos nicht möchte das über Ihre DSL-Anschlüsse Mails zu anderen Providern transportiert werden. Deshalb sei bei DNS-Anfragen zu einem MXRecord einfach pauschal der Port 25 dauerhaft zu sperrt. Das kann er aber nicht da es ja so nicht in den AGBs steht, es wird aber unter vorgehaltener Hand dem Kunden am Telefon gesagt. Dies bestätigte mir auch ein Arbeitskollege der ähnliche Erfahrungen mit dem Versenden von Mails mit seiner @t-online.de Adresse über Teleos hatte.

Nach einem weiteren ausführlichen Mail an den Support mit Richtigstellung der mir vorgeworfenen Vergehen und einem Hinweis auf Veröffentlichung in meinem Blog wurde der Port 25 wieder entsperrt mit dem Hinweis auf eine erneute Port-Sperre falls es von meiner IP zu erneuten MX-Abfragen zu DNS-Servern kommen sollte.

Damit steht für mich fest das bei dieser Beugung der AGBs meine Tage bei Teleos gezählt sind. Ich muss nur noch prüfen lassen ob der Vertrag vor Ende der Laufzeit beendet werden kann.

Kevin hat Röhrchen in die Ohren bekommen

Röhrchen in die Ohren

Röhrchen im Ohr
Röhrchen im Ohr

Heute war der Kleine zur Operation zum HNO um sich kleine Röhrchen zur Belüftung in seine Ohren setzen zu lassen. Der Eingriff hat ca. 20 Minuten unter Vollnarkose gedauert und ist ohne Komplikationen verlaufen. Seit der Operation geht es dem Kleinen wieder merklich besser und er klagt auch nicht mehr über Schmerzen im Ohr. Wie erwartet ist natürlich auch der Schnupfen weg:-) Diese Operation hat sich für Kevin wirklich gelohnt, was man von der alternativen Behandlung in den 4 Monaten davor nicht sagen konnte. Hoffentlich bleibt es so gut wie es jetzt ist.

Mit fetchmail Mails verschlüsselt abrufen

Mails verschlüsselt abrufen

Damit ich meine Mails von meinem Provider sicher abholen kann habe ich die Übertragung von POP3 auf Secure POP3 umgestellt. Das dient weniger dazu das kein anderer die Mails bei der Übertragung lesen kann sondern eher dazu das mir niemand anderer einen falschen POP3 Server unterschieben kann indem er die DNS-Einträge verändert. Sollte das passieren würde mein Rechner über das falsche Zertifikat stossen und die Übertragung abbrechen. Zweck erfüllt.

Zum Abrufen der Mails nutze ich fetchmail auf meinem Linux-System. Fetchmail lässt sich mit ein paar zusätzlichen Einträgen in der fetchmailrc soweit umstellen das die Übertragung der Mails aus POP3 und IMAP4 nicht mehr mittels TCP-Port 110 bzw. 143 sondern über die Ports 995 bzw 993 verschlüsselt erfolgen.

Das wichtigste an Änderungen ist das Hinzufügen der Zeile ssl, um die Funktionalität in fetchmail einzuschalten. Zusätzlich wird natürlich noch das Paket openssl benötigt um die notwendigen Verschlüsselungs Routinen bereit zu stellen.

Nach der Änderung sieht meine fetchmailrc so aus:

poll „pop.gmx.net“ protocol POP3 :
user „175739“ there
with password „XXXXXXXXXXXXXX“
is „carsten“ here
ssl

Für einen Test rufe ich /etc/init.d/fetchmail oneshot auf meinem Suse Linux System auf. Alternativ kann auch fetchmail -v pop.gmx.net aufgerufen werden. Der Parameter -v ist wichtig, um die entsprechenden Einträge in /var/log/fetchmail oder der Konsole sehen zu können.

fetchmail: 6.3.9-rc2 querying pop.gmx.net (protocol POP3) at Mon Jan 19 19:26:03 2009: poll started
fetchmail: Trying to connect to 213.165.64.22/995…connected.
fetchmail: Issuer Organization: Thawte Consulting cc
fetchmail: Issuer CommonName: Thawte Premium Server CA
fetchmail: Server CommonName: pop.gmx.net
fetchmail: pop.gmx.net key fingerprint: BA:03:AC:50:A9:A0:C7:AF:1E:79:3A:B7:C0:E7:19:5E
fetchmail: pop.gmx.net fingerprints do not match!20757:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:894:
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from pop.gmx.net
fetchmail: Query status=2 (SOCKET)

Als nächstes wird der gefundene Fingerabdruck der fetchmailrc hinzugefügt.

sslfingerprint „BA:03:AC:50:A9:A0:C7:AF:1E:79:3A:B7:C0:E7:19:5E“

Falls der Mailserver kein Zertifikat einer CA benutzt muss noch eine Kopie davon auf dem eigenen System hinterlegt werden. Dies kann man mit dem Befehl

root/:> openssl s_client -connect pop.gmx.net:995 -showcert

für einen POP3 Server erledigen, für IMAP4 sieht es wie folgt aus:

root/:> openssl s_client -connect pop.gmx.net:993 -showcert

erledigen. Irgendwo steht in dem Text ein Bereich, der etwa so aussieht:

—–BEGIN CERTIFICATE—–
MII[…]
—–END CERTIFICATE—–

Falls auf dem eigenen System ein entsprechendes Zertifikat einer CA fehlt, so muss unter /etc/ssl/certs eine neue Datei mit genau dem Inhalt angelegt werden.

Alle gesammelten Zertifikate müssen in ein Verzeichnis kopiert und dort gehashed werden, damit fetchmail sie verwenden kann. Der einfachste Weg dazu ist das Programm c_rehash zu benutzen, das bei apache dabei ist. c_rehash ist auch im OpenSSL-Sourcecode enthalten, dort liegt es im Unterverzeichnis tools. OpenSSL bringt jedoch auch schon von Haus aus einige der bekanntesten CA-Zertifikate mit.

Nun kommen noch zwei weitere Zeilen in die fetchmailrc hinein:

sslcertck
sslcertpath /etc/ssl/certs;

Die beiden Zeilen gehören natürlich in den selben Block wie das poll-Kommando. Sie sorgen dafür dass das Zertifikat vom Mailserver mit der eigenen Kopie verglichen wird und im Fehlerfall die Verbindung beendet wird. Die lokalen Zertifikate werden dabei in sslcertpath gesucht.

Sollte alles richtig eingestellt sein und funktionieren, dann solten folgende Zeilen in /var/log/fetchmail auftauchen:

fetchmail: 6.3.9-rc2 querying pop.gmx.net (protocol POP3) at Mon Jan 19 19:26:03 2009: poll started
fetchmail: Trying to connect to 213.165.64.22/995…connected.
fetchmail: Issuer Organization: Thawte Consulting cc
fetchmail: Issuer CommonName: Thawte Premium Server CA
fetchmail: Server CommonName: pop.gmx.net
fetchmail: pop.gmx.net key fingerprint: BA:03:AC:50:A9:A0:C7:AF:1E:79:3A:B7:C0:E7:19:5E
fetchmail: pop.gmx.net fingerprints match.
fetchmail: POP3< +OK GMX POP3 StreamProxy ready <1219.1232389566@mp069>
fetchmail: POP3> CAPA
fetchmail: POP3< +OK fetchmail: POP3<> AUTH CRAM-MD5
fetchmail: POP3< + [Hier wäre das Passwort als MD5 Hash]

fetchmail: POP3< +OK Mailbox locked and ready
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0 fetchmail: No mail for 175739 at pop.gmx.net

fetchmail: POP3> QUIT
fetchmail: POP3< +OK GMX POP3 server signing off

fetchmail: 6.3.9-rc2 querying pop.gmx.net (protocol POP3) at Mon Jan 19 19:26:16 2009: poll completed

und die Datei /etc/fetchmailrc etwa so aussehen:

poll „pop.gmx.net“ protocol POP3 :
user „175739“ there

with password „XXXXXXXXXXXXX“
is „carsten“ here
ssl
sslfingerprint „BA:03:AC:50:A9:A0:C7:AF:1E:79:3A:B7:C0:E7:19:5E“
sslcertck
sslcertpath /etc/ssl/certs;

Viel Erfolg und sicheres einsammeln von Mails 🙂