PHP Scripte werden runtergeladen ?!?

Computer: Software & Programmierung PHP
#1

Moin,

ich hab seit gestern auf einer meiner Seiten das Problem, dass manche php scripte nicht auf dem Server ausgeführt werden, sondern dem User zum download angeboten werden. Da ist dann natürlich der komplette Quellcode drin, was mir logischerweise absolut nicht passt.
Ich nehme an, dass dieser Fehler irgendwie mit dem Webserver zusammenhängt, kenne mich damit aber nich wirklich gut aus.
Es sind aber komischerweise immer andere Seiten, die nicht gehen. Frei nach dem Zufallsprinzip „heute biete ich mal datei3.php zum download an… morgen dann datei5.php“ … also am code liegts definitiv nicht (ging bis dahin ja unverändert über monate)

Hat jemand auch nur die geringste idee ?

Gruss
Michael

#2

Moin,

bist Du bei Host-Europe? Gib mir doch mal die www-Adresse.

Könnte am Browser liegen. Also dass es am Webserver liegt, kann ich mir nicht so recht vorstellen, bei Apache sowieso nicht. Denke, das ist eine Fehleinstellung am jeweiligen Webbrowser. Probiers mal mit Firefox und MS-Internet-Explorer, ob’s da Unterschiede gibt???

Gruß

de Klään (Andreas)

#3

Moin Andreas,

nee hab nen rootserver bei 1und1.
Die Domain hab ich runtergenommen sicherheitshalber…

Das Problem tritt seit gestern abend bei allen Usern der Seite auf. Willkürliche Menüpunkte (teilweise sogar das Loginscript) werden einfach runtergeladen. Das tritt mit IE, Firefox und Mozilla gleichermaßen auf und ist auch unabhängig von Client PC und dergleichen.
Deshalb irritiert es mich auch so.

Gestern hat für kurze Zeit ein server-reboot geholfen, heute das gleiche wieder…

wie gesagt… seit monaten unveränderte seiten…

#4

Also es könnte sein, dass Dein Webserver, warum auch immer, irgendwas in der httpd.conf-Datei ändert. Dort ist vereinbart, wie er mit Dateien mit der Endung .php umzugehen hat, also dass er diese parsen muss. Schau Dir mal die httpd.conf-Datei an.
Aber warum er diese ändern sollte, weiss ich auch nicht.

Wenn der Apache nämlich mit einer Datei nichts anzufangen weiss, bietet er diese zum Download an, das steht 100 % fest.
Vielleicht ist auch die maximale Anzahl möglicher Verbindungen zu niedrig eingestellt, hattest Du gestern Abend viele Besucher (mehr als sonst??)

#5

Also es könnte sein, dass Dein Webserver, warum auch immer,
irgendwas in der httpd.conf-Datei ändert. Dort ist vereinbart,
wie er mit Dateien mit der Endung .php umzugehen hat, also
dass er diese parsen muss. Schau Dir mal die httpd.conf-Datei
an.
Aber warum er diese ändern sollte, weiss ich auch nicht.

Hm… irgendwie steht in der httpd.conf Datei beim apache2 nichts, was Aufschluss darüber geben könnte, wie er mit welcher Endung umzugehen hat. Hier stehen fast ausschliesslich Includes drin…

Wenn der Apache nämlich mit einer Datei nichts anzufangen
weiss, bietet er diese zum Download an, das steht 100 % fest.

aber das würde er - würde es sich um einen Fehler in einer conf Datei handeln - ja immer machen, und nicht nur manchmal.
manche PHP seiten gehen ja, andere aber nicht. Und alle haben die Endung .php

Vielleicht ist auch die maximale Anzahl möglicher Verbindungen
zu niedrig eingestellt, hattest Du gestern Abend viele
Besucher (mehr als sonst??)

Also was mir aufgefallen ist, als ich vorhin Logfiles durchgesehen habe, dass in sekündlichem oder zweisekündlichem Abstand scheinber eine SSH verbindung requestet wird.
Jedenfalls ist das Logfiles voll mit abertausenden derartigen Zeilen:

Jun 15 10:11:23 p23478342 sshd[567]: error: Could not get shadow information for NOUSER

… und das mir, wo ich mit UNIX gar nich gut kann :frowning:

#6

Hallo,

also ich sag’s mal vorsichtig: Das gefällt mir gar nicht. SSH wird gerne von Hackern verwendet, hoffentlich versucht da keiner in Dein System einzudringen. Mehr weiss ich jetzt auch nicht mehr, leider.

Frage am Rande: Warst Du mal Dozent bei CDI??? Saarbrücken?

#7

also ich sag’s mal vorsichtig: Das gefällt mir gar nicht. SSH
wird gerne von Hackern verwendet, hoffentlich versucht da
keiner in Dein System einzudringen. Mehr weiss ich jetzt auch
nicht mehr, leider.

hab dieses Problem in nem anderen Forum (Server) auch mal gepostet, bin mal gespannt. Mir gefällt das nämlich auch absolut nicht, da ich mich selbst aber zu wenig auskenne, um unter Unix irgendwas (richtig) zu machen, lass ich lieber erstmal die Finger weg.

Frage am Rande: Warst Du mal Dozent bei CDI??? Saarbrücken?

Nee, da muss ich Dich leider enttäuschen. Ich war mal Student in der FH Würzburg :wink:

Gruss
Michael

#8

Hey Mickey

Da ist dann
natürlich der komplette Quellcode drin, was mir logischerweise
absolut nicht passt.

ist das „logischerweise“ überprüft worden?
Ab und an kommt es auch vor, dass die Datei geparst zum Download angeboten wird - sprich dass dann der html-output übertragen wird und Dein Quellcode nicht drin steht…

Ich nehme an, dass dieser Fehler irgendwie mit dem Webserver
zusammenhängt, kenne mich damit aber nich wirklich gut aus.

das denke ich eigentlich auch - falls der Quellcode drin steht…
da scheint der php parser auszufallen und der apache weiss dann nicht mehr, was er tun soll und geht davon aus, dass die Datei runtergeladen werden darf… (nachdem keine für browser gültige header zurückgegeben werden)
Kann natürlich auch sein, dass in der httpd.conf wirklich der Eintrag fehlt, der dann das parsing „übergeht“…
dass es sporadisch auftritt find ich aber sehr, sehr komisch dabei…
Solches verhalten kenne ich nur von Webservern mit Load Balancern. Würde dann bedeuten, dass die Produktivserver unsynchron laufen bzw konfiguriert sind…

Gruss
Munich

#9

Hey Munich,

ist das „logischerweise“ überprüft worden?

ja ist es :frowning:

Ab und an kommt es auch vor, dass die Datei geparst zum
Download angeboten wird - sprich dass dann der html-output
übertragen wird und Dein Quellcode nicht drin steht…

nein das ist definitiv nicht so. Das war das erste, was ich kontrolliert habe. Schön die PHP Datei mit dem kompletten Sourcecode…

das denke ich eigentlich auch - falls der Quellcode drin
steht…

steht er… nun ging es seit gestern abend gut (hatte den server komplett rebootet und nach leerung des caches war für einige Stunden ruhe, aber inzwischen klagen schon wieder die ersten Benutzer über runtergeladenen sourcecode :frowning:

da scheint der php parser auszufallen und der apache weiss
dann nicht mehr, was er tun soll und geht davon aus, dass die
Datei runtergeladen werden darf… (nachdem keine für browser
gültige header zurückgegeben werden)

Aber fällt der einfach aus?

Kann natürlich auch sein, dass in der httpd.conf wirklich der
Eintrag fehlt, der dann das parsing „übergeht“…
dass es sporadisch auftritt find ich aber sehr, sehr komisch
dabei…

Dann müsste er das Parsing ja immer übergehen, und nicht nur alle paarmal bzw. bei einzelnen Dateien. Der großteil funktioniert ja…

Solches verhalten kenne ich nur von Webservern mit Load
Balancern. Würde dann bedeuten, dass die Produktivserver
unsynchron laufen bzw konfiguriert sind…

Vielleicht könnte es aber in der Tat etwas mit Auslastung zu tun haben. Ich hab mir mal die laufenden Prozesse angesehen, hierbei kommt mir spanisch vor, dass so viele gleichartige Threads des wwwrun users laufen, die je >5% speicher fressen. Dann noch 2 Prozesse, bei denen irgendwas mit „mingetty“ steht (was ist das?), düe über tty1 und tty2 drin zu sein scheinen (haeh?)
Jedenfalls kommt es mir spanisch vor, dass der Server quasi im ruhezustand schon 70% MEM verbraucht…

hier mal die Prozesse:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 588 240 ? S Jun15 0:00 init [3]
root 2 0.0 0.0 0 0 ? S Jun15 0:00 [migration/0]
root 3 0.0 0.0 0 0 ? SN Jun15 0:00 [ksoftirqd/0]
root 4 0.0 0.0 0 0 ? S

#10

nein das ist definitiv nicht so. Das war das erste, was ich
kontrolliert habe. Schön die PHP Datei mit dem kompletten
Sourcecode…

echt doof…
den einzigen Tipp, den ich Dir auf die schnelle zum Sourcecode sichern geben kann ist der, dass Du Deine Verzeichnisstruktur nachbildest bzw eine intelligente 404 Fehlerdatei baust, die die aufgerufene URL überprüft - ist aber riskant weil Browser/Firewalls den referrer blocken können…
naja und in den aufgerufenen Dateien includierst Du dann die funktionstüchtigen, die aber in einem htaccessgeschützem Verzeichnis liegen…

da scheint der php parser auszufallen und der apache weiss
dann nicht mehr, was er tun soll und geht davon aus, dass die
Datei runtergeladen werden darf… (nachdem keine für browser
gültige header zurückgegeben werden)

Aber fällt der einfach aus?

wenn er geDoSt wird kann das durchaus passieren…
die SSH requests könnten der Grund dafür sein - aber auch Dinge, die vielleicht garnicht mitprotokolliert werden…
läuft Dein Server mit den letzten (patches/) Versionen von apache und php?

Kann natürlich auch sein, dass in der httpd.conf wirklich der
Eintrag fehlt, der dann das parsing „übergeht“…
dass es sporadisch auftritt find ich aber sehr, sehr komisch
dabei…

Dann müsste er das Parsing ja immer übergehen, und nicht nur
alle paarmal bzw. bei einzelnen Dateien. Der großteil
funktioniert ja…

eigentlich schon - ausser wenn eben wirklich ein Load Balancer oder ähnliches mit gecachten Versionen arbeitet und nicht weiss, was er da tut…

Solches verhalten kenne ich nur von Webservern mit Load
Balancern. Würde dann bedeuten, dass die Produktivserver
unsynchron laufen bzw konfiguriert sind…

Vielleicht könnte es aber in der Tat etwas mit Auslastung zu
tun haben. Ich hab mir mal die laufenden Prozesse angesehen,
hierbei kommt mir spanisch vor, dass so viele gleichartige
Threads des wwwrun users laufen, die je >5% speicher
fressen. Dann noch 2 Prozesse, bei denen irgendwas mit
„mingetty“ steht (was ist das?), düe über tty1 und tty2 drin
zu sein scheinen (haeh?)
Jedenfalls kommt es mir spanisch vor, dass der Server quasi im
ruhezustand schon 70% MEM verbraucht…

sorry - aber mit Prozessen auf Linux kenn ich mich eher weniger aus…
aber dafür gibts ja auch ein Brett…

#11

Vielleicht könnte es aber in der Tat etwas mit Auslastung zu
tun haben. Ich hab mir mal die laufenden Prozesse angesehen,
hierbei kommt mir spanisch vor, dass so viele gleichartige
Threads des wwwrun users laufen, die je >5% speicher
fressen. Dann noch 2 Prozesse, bei denen irgendwas mit
„mingetty“ steht (was ist das?), düe über tty1 und tty2 drin
zu sein scheinen (haeh?)
Jedenfalls kommt es mir spanisch vor, dass der Server quasi im
ruhezustand schon 70% MEM verbraucht…

Das mit dem angezeigten Speicherverbrauch ist normal, da gabs mal ein Artikel auf slahsdot dazu.
Wegen den beiden mingetty prozessen, die sind nicht über tty1 und tty2 drin, sondern die stellen die beiden Terminals tty1 und tty2 bereit.
Lass mich raten es handelt sich hier um einen Root server mit SuSE? Über die beiden ttys wird wahrscheinlich ein notfall zugriff per serialem Port ermöglicht.

gruß.thomas

#12

Das hat nichts mit dem Browser zu tun! Die schicken Ihre GET Requests normalerweise immer gleich ab…
gruß.thomas

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#13

  1. zum PHP Problem, versuch mal ein Update von PHP und Apache zu machen. Bei Leuten mit mit vergleichbaren Problemen hat dies geholfen. Kann sein dass die PHP Version buggy ist, und nach längerem Problem das PHP Modul abschmiert.

  2. Zu SSH, es bietet sich an auf Root Servern den SSH Zugang per Passwort zu deaktivieren, und nur noch per Public Key Verfahren darauf zugreifen. Es gibt entsprechende Artikel dazu im Netz.
    Desweiteren würd ich folgende Regeln zur Firewall hinzupacken:
    iptables -A INPUT -i eth0 -p TCP --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A INPUT -i eth0 -p TCP --dport 22 -m state --state NEW -m limit --limit 6/minute --limit-burst 3 -j ACCEPT
    iptables -A INPUT -i eth0 -p TCP --dport 22 -j LOG --log-prefix "FIREWALL SSH DROP: "
    iptables -A INPUT -i eth0 -p TCP --dport 22 -j DROP
    Die erste Rwegel erlaubt bestehende SSH Verbindungen, die zweite erlaubt eingehende SSH Verbindungen, aber nur bis zu einer gewissen Anzahl pro Minute von der gleichen IP, also werden Brute Force Attacken gleich mal abgewürgt, Regel 3 loggt eine solche Attacke, und Regel 4 verwirft diese.
    Auch hier gilt sich nähers über das Konfigurieren von Firewalls zu informieren.

gruß.thomas