rasierfs

Heute ruft $KUNDE an und erzählt das sein Linux-Server nach dem Booten nicht mehr hochfährt, gemacht hatte er nichts am fs. Ich konnte allerdings nur noch den Totenschein ausstellen, da es mir nicht gelungen ist das reiserfs zu reparieren. Da bliebt nur Desaster-Recovery anwerfen.

Irgendwie merkwürdig, wenn man etwas mit reiserfs zu tun hat oder etwas drüber liest ist es nix Gutes. Ich persönlich setze es nur beim News-Spool und /usr/src ein, weil reiserfs da 2-3mal schneller ist beim Zugriff auf Dateien als ext3. Ausserdem ist es nicht weiter tragisch wenn die Dateien mal weg sind. Gespannt bin ich auf XFS, das wohl mit Kernel 2.6 kommt.

Spam und offene Proxies

Viele sind heutzutage noch der Meinung Spam würde zumeist über offene Relays verschickt. Das ist aber schon lange nicht mehr der Fall, wie auch The Register richtig bemerkt. Denn vielfach haben die Hersteller/Programmierer reagiert und liefern ihre Mailserver mit recht restriktiven Voreinstellungen aus. Spam wird heute auf vielen Wegen an den unfreiwilligen Kunden gebracht.

Einen Namen, nicht nur bei Spammern, hat sich das FormMail-Script gemacht, welches durch diverse Sicherheitslücken es Spammern erlaubt ihr Handwerk nachzugehen indem sie ihre Post über dieses CGI-Script versenden. Genaue Hintergründe findet man hier.

Viel einfacher ist es sich ein paar Server bei einem ISP zu mieten und fröhlich Spam zu versenden. Das klingt zu einfach um wahr zu sein, ist aber leider Realität denn viele ISPs tolerieren soetwas, für ein paar extra Dollars versteht sich. Ein normaler Nutzer bekommt sowas auch nicht mit, denn wer schaut schon auf die Email-Header und wenn was sollte er dagegen tun? Hier helfen auf Server-Seite nur die diversen RBL-Listen wie spamhaus.org, spamcop.net oder ordb.org.

Ein vollkommen unterschätztes Problem sind offene Proxy-Server. Ein Proxy-Server ist zuersteinmal ein Stellvertreter, d.h. bei einem HTTP-Proxy sagt der Browser dem Proxy das er gerne die Seite www.foobar.baz sehen möchte. So zieht also der Proxy los und holt die Seite und gibt sie dem Browser zurück. Dazu muss man noch wissen das ein Proxy-Server immer abhängig vom Applikations-Protokoll ist, also ein FTP-Proxy nur FTP spricht und ein HTTP-Proxy nur HTTP. Es gibt auch generische Proxies, aber das würde zuweit führen. Eine gesonderte Rolle spielt hier HTTPS, dabei wird über SSL/TLS ein verschlüsselter Tunnel aufgebaut bevor die eigentliche HTTP-Verbindung beginnt. Dies ist allerdings eine Ende-Ende-Verschlüsselung, d.h. der Browser und Webserver ver- und entschlüsseln die Daten, der Proxy-Server ist dabei aussen vor. Wäre er nämlich Teil der Verbindung könnte man über dem Proxy-Server die Verschlüsselung aushebeln und die Verbindung belauschen, eine sog. Man-in-the-Middle Attacke. Um nun doch HTTPS über einen Proxy zu ermöglichen wurde der CONNECT-Befehl eingeführt, der letztlich dafür sorgt das ein Tunnel entsteht durch den man jedweden TCP-Traffic schleusen kann, auch SMTP. Ein Beispiel:

% telnet proxy.example.local 3128
Trying 192.168.12.90...
Connected to proxy.example.local.
Escape character is '^]'.
CONNECT mail.example.local:25 http:/1.0

HTTP/1.0 200 Connection established
Proxy-Agent: IJ/2.0.2

220  mail.example.local ESMTP Sendmail 8.12.3
quit
221 2.0.0 mail.example.local closing connection
Connection closed by foreign host.

Ansich stellt das ganze kein echtes Problem dar, wenn denn der Proxy-Server richtig konfiguriert ist lässt ein Proxy-Server nur ausgehende Verbindungen auf Port 443 zu, und das auch nur für bestimmte IP-Kreise (z.B. das eigene LAN), auf dem normalerweise HTTPS gemacht wird. Allerdings gibt es viele falsch oder nicht konfigurierte Systeme, die es schlichtweg jeden in der Welt erlauben den Proxy zu nutzen und genau hier gehen die Probleme los. Zuerst wurden diese offenen Proxies von Crackern eingesetzt um ihre Angriffe auf fremde Computer zu tarnen, später wurden dann IRC Chat-Netze von Kiddies mit dem gleichen Ziel heimgesucht. Allerdings haben sich das die Server-Administratoren nicht lange gefallen lassen und so scannen heute fast alle IRC-Server ihre ‘Kundschaft’ nach offenen Proxy-Servern bevor sie auf die Server kommen. Quasi als Abfall-Produkt dieser Scannerei gibt es auch eine RBL die sich nur mit offenen Proxies beschäftigt. Zu finden ist sie unter Open Proxy Monitor List und lässt sich am Mail-Server wie jede andere RBL nutzen, hier ein Beispiel für Sendmail:


FEATURE(dnsbl)dnl
FEATURE(`dnsbl’, `opm.blitzed.org’, `Mail blocked see: http://opm.blitzed.org/info/’)dnl

Sicher erhebt die Liste keinen Anspruch auf Vollständigkeit, noch scannen die Betreiber aktiv im Internet nach offenen Proxies, aber dennoch ist diese RBL sicher ein gute Ergänzung zu bereits bestehenden RBLs.

Zum Schluss noch ein Advisory des CERTs zu offenen Proxies.

Matrix 2 zu realistisch?

Die Britisch Computer Society ist beunruhigt das im Film Matrix Reloaded das Hacking zu realistisch dargestellt wird und Trittbrettfahrer und Möchtegern-Hacker einlädt es ebenfalls zu tun. Sie haben dazu eine Warnung herausgegeben in der sie vor möglichen Konsquenzen warnen. Denn in dem Film wird gezeigt (Screenshot) wie ein Computer mittels SSH CRC32 Attacke gehackt wird.

Ich kann mir schon lebhaft die britische DVD-Version von Matrix Reloaded vorstellen, wo an der betreffenden Stelle ein Laufband mit Don’t try this at home durchläuft.

Gefunden bei: Tomshardware

Steigerung von Sinnlos?

Es ist schon erstaunlich mit was die Leute ihre Freizeit vertreiben. Da gibt es welche, die schreiben sinnlose Software wie Food4Spam oder nutzen Personal Firewalls. Beide haben gemeinsam das sie schwer was her machen und einem noblen Ziel folgen, bei genauer Betrachtung sich allerdings als nutzlos erweisen. Sicher kann man die Leute darauf aufmerksam machen (hier und hier) in der Hoffnung das sie sich nochmal Gedanken machen. Ich habe da aber keinerlei missionarische Ambitionen.

Erstaunt bin allerdings vom No Spam Spam Projekt, wo es sich um eine Blacklist mit Blogs handeln soll die Fakemail-Scripte einsetzen. Mein erster Gedanke dazu war Wie heisst eigentlich die Steigerung von Sinnlos?. Warum sollte man etwas Sinnloses mit einem mindest genauso sinnlosen Projekt nochmehr Aufmerksamkeit schenken?.

Intressant finde ich auch die Wortwahl wie Seit 5.45 Uhr wird jetzt zurückgeschossen oder implementiere ich derzeit die Möglichkeit Blogs zu denunzieren die wohl auf Godwins Law ausgerichtet ist. Sicher sind kontroverse Diskussionen sehr intressant, müssen sie aber von vornherein auf ein bestimmtes Ziel ausgerichtet sein?

SMTP-Auth und TLS bei Sendmail nachrüsten Teil 2

So, wie versprochen heute der 2.Teil über SMTP-AUTH und TLS in Sendmail nachrüstenund zwar der für SuSE 8.1. Teil 1 gibt es hier

Zuerst sollte man kontrollieren ob openssl und cyrus-sasl auf dem System vorhanden ist, wenn nicht über Yast nachinstallieren. Nun müssen wir uns ein paar Schlüssel generieren und die dazugehörige Certificate Authority. (Was das alles genau ist verkneife ich mir, das kann man hier nachlesen). Normalerweise ist dafür das Script CA.pl zuständig, allerdings müssen wir es patchen. Wer weiss wie sowas funktioniert kann diesen Patch nutzen:

--- /usr/share/ssl/misc/CA.pl   2002-09-09 22:21:44.000000000 +0200
+++ ./CA.pl     2003-06-22 14:06:14.000000000 +0200
@@ -58,12 +58,12 @@
            exit 0;
        } elsif (/^-newcert$/) {
            # create a certificate
-           system ("$REQ -new -x509 -keyout newreq.pem -out newreq.pem $DAYS")
+           system ("$REQ -new -x509 -nodes -keyout newreq.pem -out newreq.pem
            $RET=$?;
            print "Certificate (and private key) is in newreq.pem\n"
        } elsif (/^-newreq$/) {
            # create a certificate request
-           system ("$REQ -new -keyout newreq.pem -out newreq.pem $DAYS");
+           system ("$REQ -new -nodes -keyout newreq.pem -out newreq.pem $DAYS"
            $RET=$?;
            print "Request (and private key) is in newreq.pem\n";
        } elsif (/^-newca$/) {

Ansonsten hier herunterladen, in CA.pl umbenennen (mv CA.txt CA.pl) und mit chmod 750 ./CA.pl wieder ausführbar ist. Ich gehe im folgenden davon aus, das sich das Script in /root/ca befindet und wir mit cd /root/ca auch dorthingehen.

Und los geht es mit:

./CA.pl -newca

Hiermit wird die sog. Root-CA initialisiert. Zu beachten gibt es hier das die erste Frage nur mit einem Return beantwortet werden sollte und das geforderte Passwort NICHT dem Root-Passwort entsprechen sollte. Wenn alles soweit beantwortet ist mit

cp demoCA/cacert.pem /etc/mail/certs/CA.cert.pem

die entsprechende Datei an die richtige Stelle kopieren. Nun erzeugen wir den Key für den Server und kopieren ihn wie gehabt an seinen Bestimmungsort.


./CA.pl -newreq

cp newreq.pem /etc/mail/certs/MYServer.key.pem

Es folgt das Zertifikat


./CA.pl -sign

cp newcert.pem /etc/mail/certs/MYServer.cert.pem

Nun löschen wir die eben erzeugten Dateien mit rm new*, weil wir nun noch ein Zertifikat erzeugen für die Funktion als Client. Das ist der Fall wenn Sendmail seine Emails über einen sog. Smarthost abliefert.


./CA.pl -newreq


cp newreq.pem /etc/mail/certs/MYClient.key.pem


./CA.pl -sign


cp newcert.pem /etc/mail/certs/MYClient.cert.pem

Abschließend wird sichergestellt das später nur root Zugriff auf die Daten hat

chmod 600 /etc/mail/certs/*

Damit hätten wir den schwierigsten Teil hinter uns. Nun noch zwei Dateien für die Sendmail-Konfiguration über SuSEConfig anpassen. Zuerst wäre da die /etc/sysconfig/mail. Der Parameter SMTPD_LISTEN_REMOTE hat mir mal eine Stunde meines Lebens gekostet, weil ich mich gewundert habe warum Sendmail nur auf localhost lauscht. Also auf no stellen, dann lauscht er wieder auf allen Interfacen.

#
# From:-Line in email and News postings
# (otherwise the FQDN is used)
#
FROM_HEADER=""
#
# If you don't want to let SuSEconfig generate your
# configuration file, set this to no
#
MAIL_CREATE_CONFIG="yes"

#
# Set this to "yes" if mail from remote should be accepted
# this is necessary for any mail server.
# If set to "no" or empty then only mail from localhost
# will be accepted.
#
SMTPD_LISTEN_REMOTE="no"

Nun noch in /etc/sysconfig/sendmail folgende Parameter anpassen.



SMTP_AUTH_MECHANISMS=”CRAM-MD5 PLAIN LOGIN”


SMTP_AUTH_SERVER=”CRAM-MD5 PLAIN LOGIN”


STARTTLS=”both”

Auf der console nochmal SuSEconfig ausführen – Fertig! Und nun sage nochmal einer SuSE wäre einfach :) Ansonsten gibt es noch anzumerken, das dies inspiriert wurde durch einen älteren Beitrag im Linuxjournal, allerdings angepasst an die Gegebenheiten einer SuSE 8.1. Für weiterführende Info ist natürlich die Sendmail-Homepage zu empfehlen, besonders die Seiten von Claus Assmann zu dem Thema.

Ohne Worte

Just a link.

Montags morgen

Kaputt

Monday, The Death of Websites

SMTP-Auth und TLS bei Sendmail nachrüsten

Update: Teil 2 über SuSE 8.1 ist hier zu finden.

Viele haben mittlerweile einen eigenen Linux-Server, sei es zuhause, als Root-Server irgendwo im Internet oder in der Firma und benutzen ihn nicht nur als Web-Server, sonder auch als Mail-Server. Solange man nur aus dem LAN Mails verschicken will ist das auch alles kein Problem, da hat man eine feste IP-Adresse und die darf Relayen. Aber was macht man nun wenn unsereins Unterwegs ist und irgendeine IP-Adresse hat? Früher wurde sog. SMTP-after-POP gemacht, dabei musste zuerst Mails abgeholt werden und durfte dann für einen bestimmten Zeitraum Mails verschicken. Diese Lösungen sind aber teilweise recht knifflig in der Installation und wenn man den Zeitraum, in dem Mails versandt werden dürfen zu gross wählt, hat man evtl. Spammer auf dem Server.

SMTP-Auth räumt mit den Problemen auf, indem man sich am Mail-Server Authentifizieren muss um seine Mails zu verschicken. TLS (der nicht mehr so neue Name für SSL) hingegen sorgt für eine Verschlüsselung, was auch recht sinnig ist da (je nach Client und Authentifizierungs-Art) Username und Passwort im Klartext (MS-Outlook) über das Internet gehen. Ich will einmal anhand Debian 3.0 ( aka Woody) und SuSE 8.1 beschreiben wie man beides nachrüstet, so das Nutzer anhand ihres normalen Logins Mails über den Server verschicken können.

Bei Debian Woody ist das recht einfach. Wenn schon sendmail auf dem Rechner vorhanden ist, ruft man /usr/share/sendmail/update_auth und /usr/share/sendmail/update_tls auf. Sollte irgendwas an Programmen fehlen sagen die Scripte schon was noch zu installieren ist. Will man dem Vorbeugen (oder sendmail erst noch installieren) kann man mit apt-get install openssl libsasl-digestmd5-plain libsasl-modules-plain sasl-bin das Nötigste installieren. Danach wieder die Scripte ausführen und wenn keine Fehlermeldungen kommen sollten die nötigen Einstellungen gemacht und die Keys für die Verschlüsselung erzeugt worden sein. Nun kann man nochmal sendmailconfig aufrufen und dann zur Kontrolle kann nachschauen ob sendmail alles erkannt hat:


example:~$ telnet localhost 25
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
220 mail.example.local ESMTP Sendmail 8.12.3/8.12.3/Debian-6.4; Sun, 22 Jun 2003 14:56:36 +0200; (No UCE/UBE) logging access from: localhost(OK)-joern@localhost [127.0.0.1]
ehlo localhost
250- mail.example.local Hello joern@localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
250-STARTTLS
250-DELIVERBY
250 HELP

Wichtig sind hier die Zeilen mit AUTH und STARTTLS, welche anzeigen das alles soweit geklappt hat. Sollte STARTTLS fehlen, so fehlt evtl. ein include(`/etc/mail/tls/starttls.m4′)dnl in der Datei /etc/mail/sendmail.mc. Nach hinzufügen (am besten vi nehmen joe hat teilweise Probleme mit dem Hochkomma) führt man in /etc/mail noch den Befehl make aus, lädt die Konfiguration von sendmail neu und das war denn auch schon.

Wenn der Mail-Server selbst einen Smarthost hat, also einen Server wo er alle seine Mail abliefert und sich dort Authentifizieren soll, schreib man die nötigen Daten in die Datei /etc/mail/access. Das sieht etwa so aus:

AuthInfo:mail.foobar.baz “U:relay” “P:relay”

Wobei U der Username und P das Passwort sind, danach das make in /etc/mail nicht vergessen.

So, und weil ich schon viel mehr getippt habe als ich eigentlich wollte kommt morgen der 2. Teil mit SuSE 8.1, weil das nämlich noch mehr zu tippen ist.

Bloggen auf Sozialhilfe?

Noch ist es nicht soweit, denn das Niedersächsische Oberverwaltungsgericht hat entschieden, das ein Sozialhilfe Empfänger keinen Anspruch auf einen Internet-PC hat.

Gefunden bei der Chip.

Wie gefährlich ist Deine IP-Adresse?

Google betreibt schon seit längeren Geo-Location um IP-Adressen bestimmten Ländern zuzuordnen und nun gab es auch das entsprechende Echo, das von aufgeregt bis egal reichte. Man kann dazu stehen wie man will, aber die Firma iDefense hat sich seine eigenen Gedanken im Lichte des 11. September dazu gemacht und Listen (Vorsicht MS-Excel) unter dem Motto IP addresses mapped to countries that the US Department of State identified as harboring terrorists herausgeben. Intressanterweise rudern sie schon ein paar Sätze weiter mit Inclusion on this list does not in any way suggest there’s terrorist or hacker activities in these countries zurück. Intressant sind die aufgeführten Netzblöcke allemal, auch wenn die Liste schon etwas angestaubt ist. Vielleicht findet sich ja der eine oder andere wieder.

Seite 227 von 228« Erste...102030...224225226227228