Vodafone und Deutsche Post passen nicht zusammen.

Vor ein paar Wochen hatten wir die fast perfekte Phisingmail im Postfach und da dachte ich schon, daß ab jetzt nur noch solche „gut“ gemachten Fälschungen kommen, aber die Hoffnung war verfrüht.

Heute schlug eine Virenemail bei uns auf, die noch schlechter als die gestrige Freenet Nachricht ist:

Return-path: <embellishmentkold@vodafone.com>
Envelope-to: XXXXXXXXXXXXXXXXXX
Delivery-date: Wed, 12 Jun 2013 10:01:54 +0200
Received: from office.sultrade.cz ([77.78.83.250])
    by XXXXXXXXXXXXXXXXXX with esmtp (Exim 4.76)
    (envelope-from <embellishmentkold@vodafone.com>)
    id 13ghtF-0330Wf-Lx
    for XXXXXXXXXXXXXXXXXX; Wed, 12 Jun 2013 10:01:54 +0200
Received: from [14.162.112.153] (helo=bpolztbxhdhvnj.repsbzunnmche.com)
    by office.sultrade.cz with esmtpa (Exim 4.69)
    (envelope-from )
    id 1MMXUA-4636xu-17
    for XXXXXXXXXXXXXXXXXX; Wed, 12 Jun 2013 09:01:53 +0100
From: "Deutsche Post" <supportpakete@deutschepost.de>
To: <XXXXXXXXXXXXXXXXXX>
Date: Wed, 12 Jun 2013 09:02:53 +0100
X-Mailer: aclovp 47
Message-ID: <23423423405.7ELTMN4234443dd9@yegcbtbuivgls.pjeyyh.tv>
Subject:  Wo ist meine Sendung 021604452

Wenn einen die Nachricht selbst nicht schon abschreckt, denn die ist im Mailprogramm eigentlich nur formloser Matschinhalt, sollten einem die Domainnamen im Header eigentlich alles sagen.

Vodafon.com und als Absender deutschepost.de, sowas kann nur ein ausländisches Scriptkid zusammenbasteln, das dem der Text egal ist.

Die Mail wird über einen gehackten oder offenen tschischen Mailserver gesendet, der seine Spams aus Vietnam bekommt.

Natürlich haben wir wieder eine ZIP Datei mit einem Virus drin. Das übliche halt.

eine billige Fälschung – freenet Breitband GmbH

Gerade erreichte uns eine Virus-EMail, die ich Ihnen nicht vorenthalten möchte,
da sie extrem schlecht gefälscht ist und damit sehr einfach für jedermann zu erkennen ist:

Return-path: <service@freenet.de>
Delivery-date: Mon, 10 Jun 2013 20:21:24 +0200
Received: from fourfuns.com.tw ([124.150.134.11])
	by XXXXXXXXXXXXXXXXXXXXXXXXXXX with smtp (Exim 4.76)
	(envelope-from <service@freenet.de>)
	id XXXXXXXXXXXXXXXXXXXXXX
	for XXXXXXXXXXXXXX; Mon, 10 Jun 2013 20:21:24 +0200
Received: from hwuiw (15.123.230.70)
	by fourfuns.com.tw; Tue, 11 Jun 2013 04:21:19 +0800
Date: Tue, 11 Jun 2013 04:21:19 +0800
From:  <service@freenet.de>
X-Mailer: The Bat! (v2.01)
Reply-To:  <personlicher-service@service.freenet.de>
To:  <xxxxxxxxxxxxxxxxxx>
Subject:  Ihre Bestellungsnummer: 23445993

Sehr geehrte Damen und Herren,

anbei erhalten Sie Ihre Rechnung fur die Dienste der freenet Breitband GmbH,
 die Sie unter Ihrer Kundennummer 24831967 genutzt haben. Einzelheiten 
entnehmen Sie bitte dem angehangten PDF-Dokument als ZIP-Datei.

Herzliche GrьЯe,
Ihr freenet Service-Team

________________________________________________________________________________

freenet Breitband GmbH, Postfach 2120, 24001 Kiel
Geschдftsfьhrung: Thorsten Meier, Andreas Sand, Claas Voigt
 Hamburg - HRB 105001, Amtsgericht Hamburg
 St.-Nr.: 27 / 001 / 01001, USt.-ID: DE259800171

Es fallen natürlich sofort die Kyrillischen Buchstaben statt der üblichen Umlaute auf.

Auch der „personliche“ Service ist ein deutlicher Hinweis auf eine unlautere Email.

„The Bat“ ist ein Emailprogramm, das ausschliesslich für private Zwecke eingesetzt wird,
also als Massenmailer für Freenet nicht taugt.

Die hier angehängte Virenemail in Form eines Zips,wird von gängigen Virenscannern nicht erkannt, es ist als höchst gefährlich diesen Anhang aufzumachen.

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.