Zombie-Prozesse auf Grund von Munin

M

Mutschas1

New Member
Hallo zusammen,

seit einem Update von Apache und Munin erhalte ich in der apache 2 error.log alle 5 Minuten (wenn der Munin-Job läuft) folgende zwei Fehler:

[error] [client 127.0.0.1] client denied by server configuration: /var/www/
[error] [client 127.0.0.1] client denied by server configuration: /var/www/errors
Click to expand...

Weiß von euch jemand an was das liegen könnte?

Munin erstellt brav die Statistiken + Grafiken und die Munin-Seite ist auch im Web erreichbar.

Ich hatte den Fall vor gut zwei Jahren schon mal. Aber ich hab vergessen, wie ich den behoben habe :( Dadurch, dass Munin da irgendwas vor hat, werden Zombie-Prozesse erstellt. So lange, bis irgendwann nichts mehr geht und der Apache neugestartet werden muss. So war das auch vor gut zwei Jahren. Es war damals nur eine Kleinigkeit, meine ich, die man ändern musste.

Danke.
 
Deaktiviere die apache_* Plugins von Munin oder konfiguriere sie richtig! Eventuell ist auch nur das Status Modul beim Apache nicht aktiviert oder der Zugriff darauf nicht erlaubt.


MfG Christian
 
Welcher Client (UserAgent) ist denn im access_log zu sehen zum Zeitpunkt des Fehlers im error_log?
Du musst schon rausbekommen, wer da abruft.
 
Und jetzt musst du eben rausbekommen, warum du auf http://127.0.0.1/ bei User-Agent wget den Zugriff blockierst.
Keine Standard-index.html im Documentroot? Irgendeine .htaccess? Eine Apache-.conf, die ein Deny from drin hat?
 
Muss ich das wirklich rausbekommen? Ich meine, wäre es nicht andersherum interessanter, wieso ein Script auf /var/www direkt zugriff haben möchte, denn da gibts es doch gar nichts zu holen. Verstehe auch nicht, warum das Munin macht. Und ohne zu wissen, was er da vor hat, gebe ich ihm auch keinen Zugriff drauf.
 
Mutschas1 said:
Muss ich das wirklich rausbekommen?
Click to expand...
Nö, das ist dein Problem, was du wissen willst.

Ich meine, wäre es nicht andersherum interessanter, wieso ein Script auf /var/www direkt zugriff haben möchte, denn da gibts es doch gar nichts zu holen.
Click to expand...
Ja, ganz schrecklich interessant wäre das. :rolleyes:

Weil das vielleicht Docroot des default-Webservers ist?

Dann grep halt mal nach wget in den Munin-Plugins unter /etc/munin/plugins , dann siehst du warum sowas passiert.

Und ohne zu wissen, was er da vor hat, gebe ich ihm auch keinen Zugriff drauf.
Click to expand...
Ohne zu wissen, warum das so ist, machst du das. Auch in Ordnung.

Dann schau mal, wer dir weiter hilft. Ich scheine dir nicht sinnvoll genug zu helfen.
 
Du gibst doch auch keinem x-beliebigen Menschen deine Pinnummer der Bankkarte, nur weil es jemand haben möchte ;) So meinte ich das mit /var/www also bitte nicht falsch verstehen. Ich schätze deine Antworten und finde es gut, dass du versuchst mir zu helfen. Nur bin ich einer, der erstmal verstehen will, warum wieso und weshalb :o
 
Du vermutest, dass Munin dafür verantwortlich ist. Das wirst du ja installiert haben, da es in keiner mir bekannten Serverdistri automatisch installiert/aktiv ist.
Dann musst du deine Plugins prüfen.

Wenn es nicht Munin ist, startet ein anderer Prozess wget.
Ich nehme an, irgendein Programm überwacht dann den Webserver, ob der noch läuft.

wget ist also für dich x-beliebig, fremd. Wie kommt es dann auf den Server?
 
Eventuell interessant, um die Quelle weiter einzugrenzen:

Was tun nach Abuse Vorwurf SSH betreffend

Hallo, wir bekamen vor kurzem eine Mail vom Provider in der uns mit folgenden Logfile Auszügen ein kompromitierter Server vorgeworfen wird. Lines containing IP:11.222.33.44 in /var/log/auth.log Nov 8 03:18:39 rockthehalo sshd[5584]: Failed password for root from 11.222.33.44 port 36745 ssh2...
serversupportforum.de serversupportforum.de

Code: 
iptables -I OUTPUT -o lo -p tcp --dport 80 -d 127.0.0.1 -m state --state NEW -j LOG --log-uid --log-prefix="IPTables: "

Nachdem diese Regel hinzugefügt wurde und der Logeintrag erneut auftaucht, bei dmesg oder im Syslog nachsehen, welche UID geloggt wurde. Damit kannst du zu mindestens schon einmal den Benutzer eingrenzen, der den Befehl ausführt.


MfG Christian
 
You must log in or register to reply here.
Back
Top