apache crasht / system offen

[ElNino]

Hallo Leute,

in meiner Verzweiflung richte ich mich an euch, auch in der Hoffnungn etwas Licht ins Dunkle zu bringen.

Ich habe bei S4F seit > 1 Jahr einen Vserver laufen.
Nach der Neuinstallation vor einigen Tagen auf RH9 und Einrichtung der User und Sub-/domains musste ich mit Erschrecken feststellen, dass ein Teil(?) des http-Daemon nach kurzer Zeit crasht, bzw beendet wird.

Durch was, bzw warum kann ich nicht sagen, die log-files ergeben für mich darüber keinen Aufschluß. lastlog z.B. (mittlerweile 18MB) kann ich gar nicht lesen, inhalt ist Müll.

Der Apache lässt sich restarten, allerdings mit der "NameVirtualHost 62.75.*.*:80 has no VirtualHosts"- Fehlermeldung. Habe hierzu das Apache-Manual durchgeackert, komme allerdings auf keinen grünen Zweig, bzw finde keinen Konfigurationsfehler meinerseits.

Nach dem Restart kann ich wie üblich auf Confixx, PhpMyadmin und auf abgelegten Seiten zugreifen.

Nach einiger Zeit (?) steigt der httpd erneut aus und entsprechende Seiten sind anschliessend nicht mehr auszuführen. Hier bietet der Webbrowser (Mozilla/IE) natürlich freundlicherweise an, die entsprechende Datei(en) downzuloaden.
Die :80 Verbindung wird akzeptiert, anscheinend wurde jedoch in httpd.conf alle Include Anweisungen ignoriert. (sicherlich ist das auch für den VirtualHost Fehler verantwortlich)

Dies ist beim Zugriff auf /phpmyadmin natürlich fatal, da in der Datei "config.inc.php" das per default gesetzte root-Passwort im Klartext gespeichert ist.
Somit ist das System für jedermann offen wie ein Scheunentor. Was das zu bedeuten hat, brauche ich nicht näher zu erläutern.

Für eine x-te-Neuinstallation habe ich nun meine Daten nochmals gesichert, um von einem hoffentlich unkontaminierten System starten zu können.
Sollte der httpd oder was auch immer erneut crashen, nachdem ich über confixx etliche domains, subdomains, user, mailadressen, mailforwoarder , etc eingerichtet habe, so gebe ich mich geschlagen, sollte mich nicht jemand an der Hand nehmen.
Ich weiss ... viel verlangt, in Zeiten in denen solch interessanten Code zu lesen gibt

Gruß Tm

 

[Huschi]

Hi,
das klingt alles nach dem PHP-Bug, der bei großer Serverlast die PHP-Scripte nicht mehr parst.
In diesem Thread haben sich folgende Lösungen dafür aufgezeigt (beachte vorallem Hotte's postings):
Downgrade auf Apache 1.3 oder warten auf ein Bugfixed-PHP für Deine aktuelle Version.

PS:
lastlog kannst Du mit dem Befehl 'last' lesen.

huschi.

 

[ElNino]

Hi Huschi,

danke für deinen Antwort.

lastlog kannst Du mit dem Befehl 'last' lesen.

oha, wusste doch, dass es da einen "Trick" gibt

Nochmal zu meinem Problem. Mit RH 7.3 bestand das Problem nicht.
Zudem hatte ich in der letzten installierten Version eine ConfixxPro Version. Besteht die Möglichkeit eines kompletten Downgrade zu 7.3/Confixx Pro?

Was die Sache mit dem PHP-Bug angeht, so liegt es doch allem Anschein nach an zu hohen Resourcenbedarf der installierten Pakete/Versionen, bzw an zu geringen Zuteilung dieser an die jeweiligen virtuellen Maschinen.
Darauf habe ich als Kunde wohl den geringsten Einfluss. Was soll ich also tun? Das verlagern der Scripte mit sensiblem Inhalt nach "Ausserhalb" schützt zwar erstmal den Server, stellt aber noch keinen Betriebzustand her.

Alles in allem ist eigentlich alles schlechter geworden, bis auf die Tatsache das die Versionsnummern gestiegen sind. Und wie war die Begründung für das Update nochmal .... ach ja:

Überschrift: Neue Features bei vSERVER
Datum: 04.02.2004 - 02:36:07 Uhr

Sehr geehrte vSERVER-Kunden,
ab sofort erhalten Sie bei einer Neuinstallation Ihres vSERVER folgende Software:
- RedHat 9,
- Apache 2.0.48,
- PHP 4.3.4,
- phpMyAdmin 2.5.4,
- Confixx Light 1.7.0,
- und proftpd 1.2.8

Für abhanden gekommene Zugangsdaten benötigen Sie keine Neuinstallation mehr.

und für eine abhanden gekommene Neuinstallation??

Auch in punkto Hardware gibt es einige, neue Änderungen:
- 50% mehr Kernel Speicher,
- 33% mehr private Speicher,
- 25% mehr shared Speicher,
- und 250 TCP Sockets anstatt 80.

supi, warum wurde die nur beim benachbarten System verbaut?

Einen Reboot Ihres vSERVERS können Sie jetzt auch mit dem befehl/Kommando \'reboot\' ausführen.

besser gleich als cron Job eintragen!! 15****

Um all diese Erweiterungen - für Sie als vSERVER-Kunde natürlich kostenlos -

daaaaaaaaaaaaaaaaaanke, daaaaaaaaaaaaaaaaaanke,

zu erhalten, müssen Sie eine Neuinstallation in Ihrem Kunden-Interface beantragen.

...und ich Idiot habs auch noch gemacht.

Danach stehen Ihnen automatisch alle neuen Features zur Verfügung.

na geil, hab ja auch sonst nichts zu tun

Bitte beachten Sie zudem, dass wir auch aus Sicherheitsgründen eine
Neuinstallation dringend empfehlen. Da RedHat den Support für die Version
7.3 eingestellt hat, werden keine Sicherheits-Updates mehr veröffentlicht,
was Ihren vSERVER gegenüber Hackern zu einem leichten Ziel macht.

Muhaha muhaha muhaha muhaha ...
damit wirs den Hackern aber nicht so schwer machen, brauchen diese Ihr Passwort nur aus /phpmyadmin/config.inc.php zu greppen.

Sorry, aber ich bin echt am Boden.

Tom

 

[Huschi]

Was die Sache mit dem PHP-Bug angeht, so liegt es doch allem Anschein nach an zu hohen Resourcenbedarf der installierten Pakete/Versionen, bzw an zu geringen Zuteilung dieser an die jeweiligen virtuellen Maschinen.
Darauf habe ich als Kunde wohl den geringsten Einfluss. Was soll ich also tun?

Du hast Einfluß! Und Du hast letztendlich (als Serverbetreiber) auch die Pflicht diesen Punkt zu ändern.
Das eigendliche Problem ist lediglich Deine Apache und PHP-Version:

however the problem has not occured on any of our other 15 servers which uses versions lower than 4.3.4

D.h. ein Downgrade der PHP-Version (z.B. auf 4.3.3) könnte schon reichen das Problem zu beheben.

huschi.

 

[Nicolander]

wie ernst ist dieses problem?
ist ein downgrade wirklich zu empfehlen oder gibt es noch andere möglichkeiten?

viele grüße
nicolander

 

[turbas]

hallo,

die einzige möglichkeit ist im moment entweder ein downgrade auf php 4.3.2 (bei 4.3.3 trat dieser bug bei wenigen leider auch schon auf) oder aber ein downgrade des "apatschen" auf 1.3.x.

-Torsten

 

[Huschi]

wie ernst ist dieses problem?

So ernst, daß Fremde u.u. die Passwörter lesen können. (s.o.)

huschi.

 

[Thorsten]

Hi Tom!

Muhaha muhaha muhaha muhaha ...
damit wirs den Hackern aber nicht so schwer machen, brauchen diese Ihr Passwort nur aus /phpmyadmin/config.inc.php zu greppen.

Dein Server, deine config.inc.php - wer hindert dich dies zu ändern?

mfG
Thorsten

 

[Nicolander]

was ist den sinnvoller?
apache oder php downgrade?

 

[Huschi]

was ist den sinnvoller?
apache oder php downgrade?

Frag lieber "was ist einfacher?"

Wenn es binaries gibt, dann würde es wohl eher PHP sein.

huschi.

 

[ElNino]

Hi Thorsten,

ja hast schon recht,
nur muss man erst auch mal wissen, dass man dies tun sollte und vorallem wie es zu tun ist. (Das frage ich mich im Übrigen immernoch)

Ich bin zwar seit etlichen Jahren It´ler, habe aber erst im letzten Jahr Erfahrungen mit Linux-Servern machen dürfen. Und bisher dachte ich, dass Linux von der Basis her so sicher ist, wie ein ordentlich gepatchtes und konfiguriertes Windows.

Die Frage die sich mir stellt:

Warum sind solche Files überhaupt von aussen zugänglich, wenn es auch anders möglich ist. Es wäre nett von dir, wenn du mir ansatzweise einen Tipp geben würdest. Ein einfaches Verschieben und Anpassen der Pfade dürfte wohl nicht ausreichen.

@Huschi,

Du hast Einfluß! Und Du hast letztendlich (als Serverbetreiber) auch die Pflicht diesen Punkt zu ändern.

Ich möchte nicht mit dir streiten, aber da liegst du meiner Meinung nach völlig daneben.
Es ist für mich als Betreiber eines "virtuellen Webservers" nicht die Aufgabe, mit kastrierten Mitteln, sozusagen als Betatester eine funktionierdende Kombination von Packeten zu finden, die innerhalb von S4F zu knapp(?) bemessenen Resourcen funktioniert.
Und die Betonung liegt hier auf "virtuell", denn hier gibt einen kleinen aber entscheidenden Unterschied gegenüber einem echten Server. (Kernel)

Immerhin haben wir für diese Leistung bezahlt und bekommen nichts geschenkt.

Ich hoffe ihr nehmt mir es nicht übel, dass ich offen meine Meinung sage,
ändern wird sich dennoch nichts... wie heisst es doch so passend: "es gibt nichts gutes, ausser man tut es"

In diesem Sinne bin ich froh und dankbar dass es dieses Forum gibt.

Gruß Tom

 

[Hotte]

Deine VE wurde mit den beschriebenen Leistungsumfang neu installiert. Alle vorher genannten Pakete stehen dir zu Verfügung.
Das der PHP/ Apache2 - Bug bei dir auftritt, dürfte wohl im geringsten an S4Y liegen. Mach ein Apachedowngrade und der Bug tritt nicht mehr auf, jedoch musst du dann auch auf die Vorteile des Apache 2 verzichten.
Betatester bist du ganz sicher nicht, oder willst du lieber auf das Betahostsystem?
Die dir zur Verfügung gestellten Ressourcen reichen allemal um das eigene System in Schuss zu halten. Eigene Kernelkonfigurationen wirst du jedoch bei keinem vserver jemals wiederfinden.
Und btw... wenn es dir missfällt das jeder das Mysql-Passwort aus der phpmyadmin-config auslesen kann, solltest du dir das entsprechende Manual durchlesen. Dort werden Möglichkeiten genannt, dies zu unterbinden.

 

[Huschi]

Ich möchte nicht mit dir streiten, aber da liegst du meiner Meinung nach völlig daneben.

Da müssen wir auch nicht streiten. Denn das steht in den AGBs von Server4You:
Zitat aus der vServer-AGB, Abschnitt 'ALLGEMEINE LEISTUNGSBEDINGUNGEN'
§4d) '[...]Für die Sicherheit der von ihm ins Internet übermittelten Daten trägt der Kunde deshalb selbst Sorge.'
§5) 'Der Provider haftet für Schäden, die von ihm oder seinen Erfüllungsgehilfen grob fahrlässig oder vorsätzlich herbeigeführt wurden.'

Da es sich um einen Softwarefehler der Firma Zend Technologies Ltd. handelt, gilt dies nicht als fahrlässig oder vorsätzlich.

Ich hoffe ihr nehmt mir es nicht übel, dass ich offen meine Meinung sage,

Solange es in diesem höflichen und sachlichen Ton geschied wie hier, ist alles in Ordnung.

huschi.

 

[server4downs]

Hallo,

erstmal ist mir kräftigst das Herz in die Hose gesaust, da ich auch den neuen Apachen und PHP 4.3.4 drauf habe...
Es ist auch immer noch in der Hose, da ich nicht weiß, ob ich hiervon auch betroffen bin. Oder geschieht das mehr nach "Zufall"?
Sorry für meine Anfängerfragen!

Was ich noch gelesen habe (bugs.php.net)
Einer hatte die ganzen Probleme auch noch nach dem Downgrade des Apachen und der Php-Version.
Kann natürlich Einzelfall gewesen sein, aber ne "Schmaselei" ist es trotzdem!

Hm... echt schade, dass hier so eine riesen Sicherheitslücke in meiner Lieblingssprache herrscht. Und niemand hat eine richtige Lösung. Selbst php.net nicht. Das Downgrade ist meiner Meinung nicht eine Lösung, sondern eine "Umgehung" des Problems.

P.S.: und bis ich es auf die Reihe gebracht hätte downgrades zu vollziehen, wäre schon lange PHP5 released!

 

[Huschi]

Es ist auch immer noch in der Hose, da ich nicht weiß, ob ich hiervon auch betroffen bin. Oder geschieht das mehr nach "Zufall"?

Wie es in der Bugbeschreibung steht, tritt der Fehler bei 'hoher Last' auf. Was auch immer dann intern im PHP abgeht, bzw. was für PHP 'hohe Last' bedeutet. Ich könnte mir vorstellen, daß es sich um Speicher-Probleme (mißratener memalloc o.ä.) handelt. Das würde erklären, daß alle mir bekannten Fälle immer auf vServern auftraten.

P.S.: und bis ich es auf die Reihe gebracht hätte downgrades zu vollziehen, wäre schon lange PHP5 released!

Und wer sagt, daß dort das Problem behoben ist?
Ich hab jetzt nicht speziell gesucht, aber über meine Poll-Kanäle ist noch kein Patch für dieses Problem zu mir durchgedrungen. Und solange kein Patch existiert, würde ich sagen, ist es nicht sicher daß es in PHP5 besser ist...

PS: Wer einen Patch sieht, bitte sofort in der PHP-Sektion posten!

huschi.