Leslie Schnee – Blog

Die automatische Serverüberwachung bei PS-Webhosting hat heute Vormittag den Stopp des E-Mailversandes von sogenannten Formular-Mails gemeldet, auf Grund sehr vieler Einlieferungen in kurzer Zeit - ein Indiz für Spam über eine gehackte Kundenseite.

Ein Login auf unserem Mailrelay-Server, auf dem seit Urzeiten noch qmail läuft, offenbart das Ausmaß der Spamattacke:

turbocalculon:/home/ls# qmailctl stat
/service/qmail-send: down 677 seconds, normally up
/service/qmail-send/log: up (pid 2351) 10362937 seconds
/service/qmail-smtpd: down 77 seconds, normally up
/service/qmail-smtpd/log: up (pid 2349) 10362937 seconds
messages in queue: 212969
messages in queue but not yet preprocessed: 7813

Über zweihunderttausend E-Mails wurden in kurzer Zeit eingeliefert. Beim Betrachten einer dieser Mails in der Queue konnte man schnell den Verursacher ausfindig machen; das von uns auf den Webhosting-Servern eingesetzte Programm nullmailer, welches die durch Kontaktformulare, Gästebücher und Onlineshop-Bestellbestätigungen generierten E-Mails an das o.g. Mailrelay weiterleitet, schreibt die User-ID jeder E-Mail in den Header:

Received: (qmail 18107 invoked from network); 2 Feb 2010 12:13:44 -0000
Received: from unknown (HELO turbolrrr.planet-school.de.planet-school.de) (194.116.187.71)
by 0 with SMTP; 2 Feb 2010 12:13:44 -0000
Received: (nullmailer pid 12051 invoked by uid 1411);
Tue, 02 Feb 2010 02:51:53 -0000
To: pmriosaude@slavenet.com.br
Subject: Segurana On-line: Seu dispositivo de segurana expirou.
MIME-Version: 1.0
Content-type: text/html; charset=iso-8859-1
From: Ita Bankline <clientes.bankline@online.com.br>
Date: Tue, 02 Feb 2010 03:51:53 +0100
Message-Id: <1265079113.076354.12050.nullmailer@turbolrrr.planet-school.de.planet-school.de>

Durch die genannte User-ID 1411 kann man anhand der /etc/passwd Datei des ebenfalls genannten Webservers den Kunden ermitteln. In diesem Fall war (wie so oft) eine veraltete Installation des Content-Management-Systems Joomla für den Spamversand verantwortlich. Die "Hacker", hier offenbar aus Brasilien, suchen gezielt über Google nach Joomla-Installationen und versuchen durch Ausnutzung bekannter Sicherheitslücken Code einzuschleusen, um damit dann Spam/Phishing-Mails im großen Rahmen zu versenden. Warum nutzen die Spammer keine eigenen Server? Diese sind in der Regel sehr schnell geblacklistet und damit für die allermeisten Mailserver nicht mehr vertrauenswürdig. Man ist daher immer auf der Suche nach "sauberen" Maschinen.

Das Problem war schnell gelöst, mittels qmail-remove sucht man nach einem eindeutigen Begriff, der in jeder der Spammails vorkommt (und in keiner normalen E-Mail, die sich ebenfalls in der Queue befindet, vorkommen sollte!):

qmail-remove -p "expirou" -d

Vorher qmail anhalten (qmailctl stop).

Vorher wurde noch der nullmailer auf dem Webhosting-Server angehalten (/etc/init.d/nullmailer stop) und die Queue in /var/spool/nullmailer/queue ebenfalls bereinigt (durch einfaches löschen der Maildateien mit der User-ID des Kunden).

Hierfür genügt ein einfacher Befehl auf der Kommandozeile:

pdftoppm -f 1 -l 1 name.pdf | pnmtojpeg - > name.jpg

It pdftoppm oder pnmtojpeg nicht vorhanden, einfach mit apt-get <Paket> installieren.

Wie immer viel Erfolg!

Heute stelle ich zumindest unter dem von mir unter Kubuntu Linux verwendeten Firefox 3.0.11 fest, dass ich gelegentlich nach der Eingabe und Übermittlung von Formulardaten/Loginfeldern weitergeleitet werde auf neborin.info oder xtraroom.info. Diese Seiten wiederum übermitteln eine Vielzahl von Trojanern und Viren, die eigentlich nur auf Windows-Rechnern zum Problem werden sollten. Zunächst dachte ich, einer unserer Server sei infiziert, da ein Kunde feststellte, dass er ebenfalls bei der Eingabe seiner Daten für den PS-Webhosting Kundenbereich auf o.g. Seite weiter geleitet wurde. Dies kann aber definitiv ausgeschlossen werden.

Google gibt bei der Suche nach neborin.info (noch) nicht sonderlich viel her, lediglich eine Warnung bei Norton Safe Web.

Zur Zeit lasse ich clamav mal über mein System laufen, vielleicht gibt das ja Aufschluss. Hier nochmal die Befehle zur Installation und Ausführung unter Linux (auf der Konsole als root bzw. mit sudo davor ausführen):

apt-get install clamav
clamfresh
clamscan -r /

Sofern es ein brauchbares Ergebnis gibt, stelle ich dies hier ein.

UPDATE:

clamscan hat nichts brauchbares ergeben. In der Zwischenzeit erhielt ich aber von Howie die Mitteilung, dass er heute ebenfalls auf neborin.info umgeleitet wurde. Da es sich vermutlich um eine Sicherheitslücke in Firefox handelt, sei dringend ein Upgrade auf die Version 3.0.12 empfohlen, die seit heute erhältlich ist. Sie behebt einige kritische Lücken, die durchaus in Verbindung mit den o.g. Symptomatiken stehen könnten, siehe Artikel bei heise online. Die 3.0.11 kam mir ohnehin etwas langsam und unperformant vor.
Unter (k)ubuntu Linux sollte also baldmöglichst ein
apt-get update
und anschließend
apt-get upgrade
durchgeführt werden. Selbstverständlich sollten auch alle Windows-Nutzer dieses Update auf Firefox 3.0.12 vornehmen, sofern Sie Version 3.0.11 oder älter verwenden.

Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.12) Gecko/2009070811 Ubuntu/9.04 (jaunty) Firefox/3.0.12

UPDATE 2 - 23.07.2009, 13:00 Uhr:

Ein Update auf Firefox 3.0.12 hilft zumindest dann nicht, wenn man sich den Trojaner bereits eingefangen hat.

Mittlerweile hat sich ein anderer Webhoster aus Österreich bei mir gemeldet, der ebenfalls von Kunden Mitteilungen bekommt, dass "Server gehackt seien". Aber das kann wohl, genau wie bei uns (PS-Webhosting), ausgeschlossen werden. Hier sind zudem auch Internet Explorer 8.0.6 Versionen betroffen. Eventuell befindet und verbreitet sich der Schadcode unter anderem über gehackte Foren, so eine Vermutung des Hosters aus Österreich und so in Teilen auch in diesem Forum geäußert. Ein Kunde von uns verwendet OS X auf einem MAC, auch mit Firefox 3.0.11 und berichtet ebenfalls über die Symptomatik.

Die Suchanfragen nach den o.g. URLs häufen sich derzeit recht stark. Ich bin inzwischen jedenfalls erstmal von Kubuntu 9.04 zurückgegangen auf das vorher verwendete 8.04, was sich auf einer anderen Partition befindet. Ganz schön "old-fashioned", dieses KDE 3.5. Und die 300 MB an Updates laufen gerade..

Neulich habe ich etwas mit iptables rumgespielt, weil mich interessiert hat, wie man den Zugriff auf einen Server auf eine IP beschränken kann:

iptables -A INPUT -i eth0 -p tcp --dport 80 -s 194.116.186.99 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 80 -j DROP

Dies gestattet den Zugriff auf den Apache-Webserver (Port 80) nur von der angegebenen IP aus (ACCEPT). Alle anderen IPs werden geDROPed.

Um eine Zip-Datei eines Ordners zu erstellen, benötigt man, klar, das Programm zip. Ist es nicht vorhanden, führen wir in der Konsole unter Debian oder Ubuntu folgenden Befehl aus:

apt-get install zip

Anschließend verpacken wir einen kompletten Ordner mit Unterordnern mit:

zip -r zipfile.zip ordnername

Das war's auch schon!

Auf unserem alten Mailserver kam es immer wieder zu Überlastungen durch hängende IMAP-Prozesse. Ein einfaches killall -9 imapd immer wieder mal hat das Problem behoben.

Natürlich könnte man jetzt einen Cronjob einrichten, der diese Aufgabe in regelmäßigen Abständen erledigt. Es geht aber auch mit watch:

watch -n 120 killall -9 imapd

imapd wird so alle 120 Sekunden mit einem killall -9 beendet. Startet man das Ganze in screen, läuft es auch weiter, wenn man die SSH-Verbindung vom Server trennt. Funktioniert natürlich nicht nur mit imapd, sondern auch mit allen anderen Prozessen, denen man gelegentlich den Weg weisen muss.

Viel Erfolg!

Unter Linux benutzt man ja gerne mal den Befehl

top

um zu sehen, was so an Prozessen läuft und welche Last sie erzeugen. Doch top kann nicht nur anzeigen. Wenn man während top läuft zum Beispiel "m" drückt, werden die Prozesse nach Speicherverbrauch angezeigt (Memory usage). "t" sortiert dann wieder nach CPU-Last. Auch sehr praktisch ist die Benutzung von "k" (kill), hier gibt man einfach die in der ersten Spalte angezeigte PID (Process ID) des abzubrechenden Prozesses an, anschließend noch die "Tötungsart" ("9" hilft fast immer) und schon beendet sich der Prozess.

Mit "h" erhält man eine Liste aller möglichen Befehle.

Wie immer, viel Erfolg!

..denn ab heute Abend ziehen wir über zehntausend Domains mit zehntausenden E-Mailadressen um auf die neuen Mailserver-Systeme. Es hat sich gezeigt, dass eine Hauruck-Aktion effektiver und trotz vieler zusätzlicher Stunden Arbeit schmerzloser ist, als ein Umzug nach und nach.

Das Ganze ist nicht ganz so einfach, immerhin handelt es sich um eine Migration vom bisherigen Qmail auf Postfix, im laufenden Betrieb. Das heißt, es muss für die Kunden sichergestellt sein, dass während der Umstellungen keine E-Mails verloren gehen. Zudem sollen die Kunden möglichst wenig Aufwand haben, d.h. idealerweise in Ihrem E-Mailprogramm nichts umstellen müssen.

Die größte Problematik dabei sind die vielen auf den bisherigen Mailservern gespeicherten E-Mails in Form von kleinen Dateien. Diese Millionen von Dateien, mehrere hundert Gigabyte an Daten, benötigen vermutlich sehr lange, bis sie auf die neuen Systeme kopiert sind. Daher kopieren wir zunächst nur die Konfiguration auf die neuen Mailserver, sodass Kunden weiterhin E-Mails senden und empfangen können. Haben sie E-Mails auf dem Server gespeichert, beispielsweise weil sie IMAP oder Webmail nutzen, sind diese Mails erst einmal weg und werden dann nach und nach wieder ins Postfach kopiert. Bis Montag ist hoffentlich alles abgeschlossen. Sollte aber klappen!

Spannend wirds! Und der gute alte turbohermes, unser bisheriger primärer Mailserver, steht kurz vor seiner wohlverdienten Rente. Wobei, vermutlich wird auch dieser recycled und einer neuen Verwendung, zum Beispiel als Webhosting-Server, zugeführt.

Der Webserver eines Kunden verabschiedete sich heute nach einem Reboot mit einem klassischen Windows-Bluescreen. Windows. Natürlich Windows. Und ohne Original Windows 2000 CD geht natürlich nichts.

Aber auf das Suchen nach einer Windows 2000 Version kann man als Linux-User auch getrost verzichten. Den Server einfach mit einer aktuellen Knoppix CD booten und das durcheinander geratene Dateisystem mit dem Programm ntfsfix reparieren. Nach einem erneuten Reboot checkt Windows das Filesystem ohne lästigen Bluescreen und fährt anschließend problemlos hoch.

Linux repariert Windows. Umgekehrt ist das wirklich kaum vorstellbar..

Hier wieder mal ein kurzer Linux Tipp, um auf einem Server mit iptables eine IP auf allem Ports zu sperren, die nervt und den Betrieb beeinträchtigt. Weg damit!

iptables -I INPUT -s 82.80.252.158 -j REJECT

Oder auch direkt auf dem Router, die IP ist dann für alle dahinterliegenden Server gesperrt:

iptables -A FORWARD -s 82.80.252.158 -j DROP

Damit die Sperre greift, ist es eventuell notwendig, den entsprechenden Dienst neu zu starten, auf den die IP zugreift. Ein laufender Download über den Browser wird also nicht sofort unterbrochen. Eine Neustart des (Apache) Webservers wäre notwendig (apachectl / apache2ctl restart).

Eine Liste der gesperrten IPs (Regeln) erhält man mit

iptables -L

Um eine Regel zu löschen, muss man die entsprechende Zeilennummer ermitteln (also in der jeweiligen Kategorie, hier INPUT) und dann löschen mit:

iptables -D INPUT Zeilennummer

Falls es sehr viele Zeilen sind, iptables -L in eine Datei pipen und diese zum Beispiel mit vim öffnen, wo dann die jeweilige Zeile angezeigt wird:

iptables -L > Datei
vim Datei

Mit iptables lassen sich nicht nur einzelne IPs sperren, sondern auch ganze Netze (zum Beispiel 82.80.252.0/24). Vorher eine whois-Abfrage auf die IP machen und die Größe des Netzes ermitteln.

Wie immer viel Erfolg!