Systemd und die Limits

„Jedes System kommt irgendwann an seine Grenzen.“ Einer meiner Server hatte die Grenze heute überschritten. Die Folge, der Apache stieg mit dieser Meldung aus :

„apache (24)Too many open files: couldn’t spawn child process:“

Jetzt können Sie soviel googlen wie Sie wollen, alles was zu dem Fehler kommt ist nicht hilfreich. Alle Hinweise  von RedHat zu limitfiles auf  /etc/security/limits.conf  oder /proc/sys/fs/file-max können Sie getrost vergessen, die greifen in dem Fall gar nicht.

Wenn Sie jetzt ein System V haben, ist /etc/init.d/httpd für Sie da. Tragen Sie dort einfach ulimit -n 100000 ein und starten Sie den Apache neu. Fall erledigt.

Für den Systemd, wie ihn Fedora seit FC 16 einsetzt, sieht die Sache ähnlich einfach aus, wenn man weiß wo man suchen muß. Aber mal ehrlich, würden SIe als Linuxer darauf kommen, daß „man systemd.exec“ die Hilfeseite zum Systemd öffnet? Ich nicht, .exe oder ähnliche Erweiterungen sind Windows Extentions.

Die Manpage liefert eine Übersicht zu den Variblen  die man im Unitfile benutzen kann und eine davon ( immerhin 5 Bildschirmseiten voll davon gibt es ) ist Ihr Freund: „LimitNOFILE

Suchen Sie mit „locate httpd.service“ ihr Unitfile, das ist üblicherweise unter /usr/lib/systemd/system/httpd.service zu finden. Tragen Sie dort im Servicebereich die Variable ein :

[Service]
Type=forking
PIDFile=/var/run/httpd/httpd.pid
LimitNOFILE=1000000
EnvironmentFile=/etc/sysconfig/httpd

Führen Sie noch die zwei Zeilen aus :

systemctl –system daemon-reload
systemctl restart httpd

und Ihr Apache rennt wieder 🙂

Ursachenanalyse:

Jedes Apache Child öffnet alle Domainlogs auf dem Server. Wenn Sie nun einen Multidomainwebserver haben, so wie meine Kunden, dann kommen dort schnell 1000 Vhosts zusammen. Das macht 1000 Files pro httpd-Child und damit viel mehr offene Files als Fedora defaultmäßig bereitstellt.

Hier wäre natürlich ein Logfilebroker für Apache die richtige Lösung, aber da brauchen wir wohl seitens Apache nicht drauf hoffen.

 

eine richtig gute Virenmail: „RechnungOnline Monat April 2013“

Wir gratulieren dem glücklichen Gewinner des erstmal verliehenen Anerkennungspreises für eine gelungene Virenemail: Herzlich Glückwunsch in die Ukraine.

Da die Email  nahezu perfekt ist, keine Deutschfehler enthält und auch keine Phisinglinks auf verdächtige Webseiten, müssen wir uns den Emailheader vornehmen:

Hier der nur leicht geänderte Header ( wir möchten ja nicht zuviel über unsere Fallen verraten ):

Return-path: <fidgetingjg@telekom.de>
Envelope-to: <Unsere Spamfallen verraten wir nicht>
Delivery-date: Thu, 16 May 2013 01:22:45 +0200
Received: from 36-231-89-213.dynamic-ip.hinet.net ([36.231.89.213])
	by <Unsere Spamfallen verraten wir nicht> with esmtp (Exim 4.76)
	(envelope-from <fidgetingjg@telekom.de>)
	id 1UyvV3-0002xl-1E
	for <Unsere Spamfallen verraten wir nicht>; Thu, 16 May 2013 12:34:21 +0200
Received: from [67.99.155.25] (account carpenteredqkj7@telekom.de HELO lgumvcvdfcmhbd.cnbtwtwlo.ua)
	by 36-231-89-213.dynamic-ip.hinet.net (CommuniGate Pro SMTP 5.2.3)
	with ESMTPA id XXXXXXXXXXXXXXX for <Unsere Spamfallen verraten wir nicht>; Thu, 16 May 2013 17:14:12 +0800
From: <rechnungonline.@telekom.de>
To: <Unsere Spamfallen verraten wir nicht>
Date: Thu, 16 May 2013 16:14:12 +0800
MIME-Version: 1.0
X-Priority: 3
X-Mailer: iwmexoinn_57
Message-ID: <56S980021XX76808.SSS$DY630SXX@jaxbjxqcnxv.uxfouxpniaeskql.com>
Content-Type: multipart/mixed;
  boundary="----=a__wiye_36_38_75"
Subject:  RechnungOnline Monat April 2013

Wie man im Receivedheader schön nachlesen kann, stammt die ursprüngliche Email aus der Ukraine und damit natürlich nicht mehr von der Telekom:

lgumvcvdfcmhbd.cnbtwtwlo.ua

Der unbekannte Mailversender hatte  wohl Spaß bei der Sache:

X-Mailer: iwmexoinn_57

So könnte der Name zustande gekommen sein:

„I want my email exchanged over internet“ (Version 57)

Was es auch in Wirklichkeit bedeuten mag, es ist kein übliches Programm zum Senden von Mails.

From: <rechnungonline.@telekom.de>

Der Punkt in dem Absendernamen ist uns ja schon hinlänglich bekannt, von früheren EMails dieser kriminellen Bande. Die Rücksendeadresse:

Return-path: <fidgetingjg@telekom.de>

sieht natürlich auch verdächtig nach Fiktion aus.

Sollte man all dies übersehen haben, ist natürlich der angefügte Virus/Trojaner das beste Indiz für einen versuchten Angriff, vom Umstand, daß man gar kein Kunde bei der Telekom ist, mal ganz abgesehen.

Seriöse Unternehmen schicken Ihnen eine EMail, in der die neue Rechnung mit Betrag erwähnt wird und einem Verweis, daß Sie diese im Kundencenter einsehen und herunterladen können.  Ohne Links in den Kundencenter, den den haben Sie ja als Kunde bereits.

 

„Ihr Kreditkartenkonto wurde aus Sicherheitsgründen temporär eingeschränkt.“

Offensichtlich haben meine ständigen Reklamationen über die Verwendung der deutschen Sprache in Spams und Phisingmails doch was bewirkt, denn diese Mail :

dit kundenummer : 0087932231
din kundereference : ID9438

Ihr Kreditkartenkonto wurde aus Sicherheitsgründen temporär eingeschränkt.

Sehr geehrter Kunde,

Nach einer Identitätsprüfung können Sie Ihre Kreditkarte sofort wieder benutzen.

Bitte bedenken Sie, dass Sie ohne Freischaltung zukünftig nicht bei teilnehmenden Händlern einkaufen können.

Um die Kontobegrenzung sofort aufheben zu können, bitten wir Sie folgende Informationen zu bestätigen.

* Alle Felder sind Pflichtfelder, bitte beachten Sie dass die Genauigkeit Ihre Daten für die Überprüfung extrem wichtig ist.

> Erhalten Sie Zugang zu Ihren Bankkonten.

Herzlichen Dank für Ihr Verständnis

Harald Fischer
Mastercard Sicherheitsteam Deutschland,,

hat nur zwei deutliche Fehler : die vielen Kommata und natürlich muß es Ihrer Daten lauten.. Da kann man leider schonmal drüber wegsehen als Opfer.

Der in der Email angegebene Link, geht natürlich nicht zu Mastercard, sondern irgendwo hin in der Welt. In meinem Fall nach Korea :

www.health-mart.co.kr/hshop/ch/images/0re.html

Und jetzt kommt die Magie, ohne überhaupt auf dem gehackten Webacocunt geschaut zu haben, kann man hier einen Klassiker der Sicherheitslücken als Ursache ausmachen:

Das nicht auf den Inhalt prüfende Bildhochladescript einer Webanwendung.

Leicht zu erkennen an der URL „/images/“ und der Endung „html“ , meistens aber „php“. Bilder sollen immer .jpg, .png usw. enthalten und das prüft das Script sicher nicht. Gern wird auch mal nur geprüft, ob der Endungsstring überhaupt drin vorkommen, was z.b. „hacker.png.php“ erlaubt. Wenn man  nun den Webpfad kennt unter dem das „Bild“ hätte erreichbar sein sollen, kann man dort das PHP Script aufrufen und schon ist der Webaccount unter der Kontrolle des Angreifers.

Ich frag mich immer wieder, wieso jeder Webanwendungen schreiben darf, auch wenn er/sie keine Ahnung davon hat. Gibt doch sonst für alles ein Gesetz 😉

Natürlich werden wir den Koreaner informieren, keine Frage.