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).

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!

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..

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.

apt-get install zip

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

zip -r zipfile.zip ordnername

Das war's auch schon!

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!

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!

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.

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..

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!