vServer schreibt keine Logfiles mehr

Morgen,

ich habe leider nach wie vor das Problem, dass meine Logfiles nicht geschrieben werden.
Wie erwähnt, der Prozess sysklogd wurde mir bei dem "großen" Update entfernt.

Ein nachträgliches Installieren ist nicht möglich, da das System wichtige andere Prozesse wie Apache2 und MySQL entfernen würde. Gleiches gilt für Rsyslog.

Was würdet Ihr machen? Ich werde wohl kaum erwarten können, dass durch das Entfernen von Apache2 und MySQL meine Datenbanken und vHosts im System bleiben. Sprich selbst wenn ich durch die sysklogd Installation die Dienste entfernen lasse und danach wieder kompatible Versionen installiere, werden wohl alle Datenbanken und vHosts weg sein.

Vermutlich wäre das Beste, diesen Server erstmal so belassen und einen neuen Bereinigten aufzusetzen und die Accounts nach und nach umziehen?

Oder hat noch jemand eine Idee?

LG
 
Du könntest versuchen, die Pakete einzeln herunterzuladen und dann einzeln mit dpkg statt apt zu installieren.
 
Morgen,

bin mir nicht sicher, ob dies zum Erfolg führt. Wenn ich Server Vergleiche, hat der Server mit dem Log-Fehler z.b. Apache 2.2.22 installiert. Der andere 2.2.16.
Selbst wenn ich sysklogd installiert bekäme über dpkg, wäre wohl eine inkompatibilität zum Apache und MySQL zu erwarten. Fraglich wie der dann hierfür loggt?
Oder ist der Gedanke falsch?

Ursache des Ganzen war diese Meldung:
http://www.heise.de/newsticker/meldung/Systematische-Angriffe-auf-PHP-Luecke-2040321.html?wt_mc=rss.ho.beitrag.atom

Hier lautet es, dass ab PHP 5.3.12 das Thema gefixt ist. Auf meinen Servern war 5.3.3 installiert. Ich bekam mit den Quellen:
squeeze main contrib non-free
squeeze-updates main contrib non-free
squeeze/updates contrib non-free
keine größere Version angeboten.

Also die Quellen:
dotdeb squeeze all und
die oben genannten squeeze STABLE
aufgenommen.

Letzteres war wohl der fatale Fehler, da das System einfach auf PHP 5.4.x aktualisiert, was eigentlich nicht sein sollte. (Versionssprung)

Das anschließende Update hatte zahlreiche z.t. gravierende Änderungen am System vorgenommen, u.a. lief Apache nicht mehr korrekt. (Lieferte nur noch PHP-Daten als Quelltext) Sämtliche Korrekturen scheiterten.
Erst das deaktivieren der Stables Debian Quellen und der Neuinstallation von PHP lies Apache nun mit PHP 5.2.27~dotdeb laufen. Allerdings fiel eben nach Tagen auf, dass die Logfiles nicht mehr passten.

Nun heißt es, dass wohl in der Debian 5.3.3 PHP Version genannte Lücke bereits geschlossen wurde? War also mein Weg grundsätzlich falsch, für meine Server aktiv zu werden und Maßnahmen zu ergreifen? Eines ist klar, das WIE erzeugte einen Fehler.

Was sagt Ihr dazu? Wie geht Ihr bei solchen Meldungen vor?
Was verwendet Ihr für Quellen um eure Produktivsysteme so sicher wie möglich zu halten?

LG
 
Hast du PHP im CGI-Modus betrieben? Wenn ja, warum - weil es heutzutage eigentlich kaum noch einen Grund gibt, dies zu tun. Und nur dann wäre eine umgehende Reaktion notwendig gewesen.

Zusätzlich eigenet sich mod_security genau dafür ganz hervorragend, solche Anfragen wegzufiltern bevor sie an den Interpreter übergeben werden. Damit kann man meistens gut die Zeit überbrücken bis Patches in den stable-branches verfügbar sind.

Last but not least, die Anhebung der PHP-Version auf 5.4.x hätte vorher getestet werden und evtl. auftretende Probleme hier geklärt werden können.
 
Hallo,

auf meinen Server läuft PHP als "cgi-fcgi".
Grund hierfür waren hauptsächlich Themen wie die Dateirechte FTP <-> WWW.
Zudem benötigen manche Scripte Shell Zugriff.

Dies war vor ca. 2 Jahren und seither läuft eigentlich alles wie gewünscht. Wenn sich heute dies grundlegend geändert hat und PHP wieder besser als Modul arbeiten sollte, würde ich mich gerne des Besseren belehren lassen.

Mod-Security kannte ich bisher gar nicht, dem werde ich aber umgehend nachgehen, da das sehr intressant scheint.

Ein Versionsupgrade von PHP 5.3 auf 5.4 ist ja fast schon grob-fahrlässig. Das sage sogar ich. Da habe ich schlicht und einfach nicht gut genug aufgepasst und musste mit nachträglich investierter Zeit und heute noch inkorrekter Funktionen büßen.

LG
 
http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/

http://www.php-security.net/archives/9-New-PHP-CGI-exploit-CVE-2012-1823.html

Demnach waren FastCGI-Installationen nicht betroffen. However, du kannst auch mal einen Blick auf die Kombi mpm-itk und mod_php werfen. Hier läuft der vHost komplett unter einem gewünschten User und Du kannst alle Vorteil von PHP als Modul nutzen. Drawback ist, der Apache-Hauptprozess muss unter root laufen, d.h. wenn es eine Parsing-Vulnerabilty im Apachen gibt, die greift bevor User/Group des Child-Prozess angepasst werden konnten, ist das Scheunentor weit offen. Andererseits es läuft bereits auf Millionen Installationen ...
 
Bin gerade bezüglich dem Thema etwas am dokumentieren, um die Sache irgendwie zu verstehen.

Also aktuell läuft die Sache auch mit Rsyslog wieder.

Ich habe die Quellen:
Code: 
deb http://ftp.de.debian.org/debian/ stable main contrib non-free
deb http://security.debian.org/ stable/updates main contrib non-free
wieder einkommentiert.

Die Quellen neu geladen und nun lies sich Rsyslog ohne zicken installieren. Er startete auch gleich und schrieb die Logfiles.

Ein apt-get upgrade würde mir PHP wieder zerschießen, weshalb ich also erstmal die Zeilen wieder auskommentiert habe.

So und nun sitz ich an meinen virtuellen Servern um die genauere Ursache zu finden.

Hier waren wie auf dem Produktivserver folgende Quellen enthalten:
Code: 
deb http://ftp.de.debian.org/debian/ squeeze main
deb http://security.debian.org/ squeeze/updates main contrib
deb http://ftp.de.debian.org/debian/ squeeze-updates main contrib

Hier war vor dem Update Apache 2.2.16 mit PHP 5.3.3-7 installiert. Alles war gut.

Dann folgende Quellen eingefügt:
Code: 
deb http://ftp.de.debian.org/debian/ stable main contrib non-free
deb http://security.debian.org/ stable/updates main contrib non-free
deb http://packages.dotdeb.org squeeze all

Dabei hab ich inzwischen schon herausgefunden, dass die beiden, vor allem die erste neue Debian Stable Quelle Ursache der Fehler ist.

Ein ein apt-get dist-upgrade aktualisiert mir fast 500 Prozesse. Alle Config-Files und Passwörter bleiben unverändert.

Nach einem Restart ist nun auf der virtuellen Maschine genau wie es auf den Produktivservern war, Apache bzw. PHP nicht mehr lauffähig. Die PHP-Dateien werden stets als Quelltext zurückgegeben.
Fehler kann also in der virtuellen Maschine 1:1 nachgespielt werden.

Seh ich nun die Apache und PHP-Version an, sehe ich Apache 2.2.22 mit PHP 5.4.4-14+deb7u5??? Debian 7???

Auf dem Produktivserver habe ich die beiden Stable Quellen entfernt und mit:
Code: 
apt-get purge php5-cgi
apt-get install php5-cgi
apt-get purge php5-common
apt-get install php5-cgi
apt-get install php-pear* php-xml-parser* php5-adodb* php5-cli* php5-common* php5-curl* php5-gd* php5-imap* php5-intl* php5-mcrypt* php5-mysql*

alles wieder lauffähig installiert. Zu dem Zeitpunkt ohne Log-Funktion.

Auf der virtuellen Maschine habe ich nun die Dotdeb Quellen um SQUEEZE-PHP54 ALL erweitert und die angebotenen PHP Pakete aktualisiert.
Ohne Erfolg. PHP Daten werden immer noch als Quelltext ausgegeben.

Nachdem ich bootlogd installiert und das Bootlog aktiviert habe, fand ich ein PHP Warning dass suhosin nicht geladen werden konnte. Ein:
dpkg -P php5-suhosin
brachte abhilfe.

Dennoch. Apache liefert die Daten immer noch als Quelltext.

Jemand bis hier her ne Ahnung wo ich morgen weitermachen könnte?

LG
 
Ganz ehrlich, bei dem gesamten Paketmurks in der Vergangenheit würde ich eher tabula-rasa-Methode bevorzugen. Will heißen, aktuelles Minimal-Image Debian 7, Dienste installieren dabei entscheiden, ob du noch weiterhin auf FCGI setzen oder eher mpm-itk + mod_PHP versuchen willst (wobei ich persönlich mpm-worker + PHP-FPM bevorzuge) und dann die Domains migrieren.
 
Ja wie gesagt, bei fast 500 aktualisierten Prozessen ist es definitiv kluger, das System von Grund auf neu aufzusetzen.

Aber das wollte ich eh bereits machen.

Was sollte ich fürs nächste mal aus der aktion lernen?
Definitiv in Produktivsysteme keine STABLE Quellen?
Bei derartigen Meldungen über Heise und Co erstmal Ruhe bewahren und selbst Infos über die Tatsache besorgen, anstelle von Losmaschieren und auf den Servern Änderungen lostreten, die es evtl. gar nicht hätte gebraucht?

Die PHP Modul-Variante werde ich in jeden Fall vor den neuen Servern in Virtuellen Maschinen ausgiebig testen.

Was gebt Ihr mir noch so mit auf den Weg, damit ich in Zukunft solche "gutgemeinten Dummheiten" vermeiden kann?
Kann ich die Dotdeb Quellen verwenden oder sollte ich schlichtweg die standard Quellen der Debian Installationen unverändert lassen?

LG
 
Also wenn Du Debian im Serverbetrieb einsetzt, dann würde ich nur und wirklich nur auf die Stable-Quellen setzen und unter allen Umständen jeglichen Mix mit anderen vermeiden.

Und ja bei der Meldung von Sicherheitslücken immer erst genauer informieren anstatt sofort loszurennen. Häufig gibt es temporäre Work-Arounds und man kann auf den Fix/Patch der Distro warten. Häufig werden Sicherheitsfixes bei Debian und Co. auch für ältere Versionen rückportiert, so dass man nicht immer auf die aktuellste umsteigen/upgraden muss.

Ich persönlich würde Dotdeb meiden. Entweder will ich gerade die Stabilität und Sicherheit von Debian, welche nur mit dem stable-branch gewährleistet ist oder ich will edge-bleeding-Features, weil wenn Du anfängst Debian-Branches/-Forks zu mixen läufst Du nach meiner Erfahrung irgendwann unweigerlich in Versionskonflikte, die sauber zu beheben der Hass schlechthin sind. Dann setze ich eher auf Archlinux oder Gentoo, die beide nach dem Rolling-Release Prinzip arbeiten.

Für mich war Archlinux der perfekte Kompromiss u.a. auch deswegen, weil Pakete soweit wie möglich original belassen werden.
 
Last edited by a moderator:
TerraX said:
Also wenn Du Debian im Serverbetrieb einsetzt, dann würde ich nur und wirklich nur auf die Stable-Quellen setzen
Click to expand...

Genau das willst du nämlich nicht! Du willst in den Paketlisten die jeweilige Version explizit angeben, sonst hast du beim nächsten Major-Release nämlich wieder so eine Hirse.
 
wstuermer said:
Genau das willst du nämlich nicht! Du willst in den Paketlisten die jeweilige Version explizit angeben, sonst hast du beim nächsten Major-Release nämlich wieder so eine Hirse.
Click to expand...

eeeh??? versteh ich des grad falsch oder wiedersprechen sich die beiden Aussagen?
stable oder nicht stable?
 
5ky said:
eeeh??? versteh ich des grad falsch oder wiedersprechen sich die beiden Aussagen?
stable oder nicht stable?
Click to expand...

Die aktuelle Stable auf dem Server verwenden, aber in der sources.list die Version explizit angeben.

Zum Beispiel:
Code: 
deb http://ftp.de.debian.org/debian/ wheezy main contrib non-free
 
You must log in or register to reply here.
Back
Top