Strato - bin verzweifelt PHPNuke

[Anonymous]

Hi an alle fleisigen schreiben in diesem forum hier...
ich bin noch ein Newbie und hab seit 2 Wochen immer das gleiche Problem nur dass ich jeden Tag dazulerne aber jetzt vollkommen am ende meines wissens bin.. Unszwar geht es um meine Homepage... Ich will meine Homepage mit PHPNuke installieren und hab auch alles so gemacht wie es in der anleitung von PHPNUKE stand.. Ich hab aber das problem, dass die domain http://www.meine-domain.de (nat. nicht die richtige) immer auf visas zugreift was ich nicht will.. ich muss auf die admin.php datei von PHPnuke zugreifen und hab auch schon in den visas ordner die ganzen files die man für nuke braucht draufgespielt... nur kommt bei mir wenn ich immer http://www.meine-homepage.de/homepage/html/admin.php eingebe eine weiße Seite mit dem
Error 500 : Serverfehler!

Die Anfrage kann nicht beantwortet werden, da im Server ein interner Fehler aufgetreten ist.

Fehlermeldung:
Premature end of script headers: admin.php

Sofern Sie dies für eine Fehlfunktion des Servers halten, informieren Sie bitte den Webmaster hierüber.
Error 500 ......

wie kann ich dies beheben bin wirklich am ende und gleichzeitig auch verzweifelt schonmal Danke an jede weiterführende hilfe ....

Euer Dorado :-D

[Anonymous]

eine zweite frage wäre ja auch wo man im Strato linux server die php.ini findet??

[Joe User]

Die wichtigste Frage hast Du vergessen: Warum liest Du nicht ersteinmal die verfügbare (Visas-)Dokumentation?

[Anonymous]

wo find ich das?

[timeless2]

Das Problem gab es hier schon öfter (Forensuche: http://www.rootforum.org/forum/search.php). Meistens hing das mit den Berechtigungen zusammen. Wenn dein PHP mit Suexec läuft, dann kannst du dir die Konfiguration mal anschauen. Ansonsten Logfiles, ...

[captaincrunch]

Sei doch froh, dass das Zeugs nicht läuft. Umso weniger Sorgen hast du später mit "ungebetenen Gästen"...

[frameboy]

Mag jetzt etwas böse klingen, aber es gibt hier n00bs (wie mich!), die gar nicht wissen, wonach sie suchen sollen!
Also wäre ein konkreter Link schon etwas hilfreicher!

[wgot]

Hallo,

Mag jetzt etwas böse klingen, aber es gibt hier n00bs (wie mich!),

für die ist dieses Forum nicht gedacht, die Betreiber wollen es als Forum für User die schon einige Erfahrung haben und die Grundlagen im Schlaf beherrschen. Es gibt auch andere Foren die das anders sehen.

die gar nicht wissen, wonach sie suchen sollen!

Nach der Fehlermeldung suchen ist meistens ein guter Start. Dazu ein oder zwei Stichworte um was es überhaupt geht, beim aktuellen Problem also z.B. Premature end of script headers PHP und Pünktchen bei "nach allen Wörtern suchen". Gibt haufenweise Beiträge zum Durcharbeiten. :lol:

Außerdem sollte man vor jeder Frage die Logfiles lesen, den Fehler frisch nochmal auslösen (damit die entsprechenden Einträge am Ende des Logfiles stehen) und dann das zuständige Logfile lesen, wenn man nicht weis welches das ist, dann eben alle. Die Fehlermeldung aus dem Logfile ist auch ein guter Ansatzpunkt für die Forensuche.

Bei Fragen zu PHP ist es immer wichtig, ob PHP als Modul oder CGI, falls letzteres ob zusammen mit suexec und / oder suPHP.

Gruß, Wolfgang

[mr_vista]

hatte heute selbiges problem mit meinem strato server... nach ner halben stunde googlen und lesen dann strato angerufen... ein überraschend kompetenter supporter (der begriff support kannte ich bis dahin nur als synonym für "kann dir nicht helfen lass mich in ruhe") konnte mir weiterhelfen. zwar konnte er mir auch nicht die ursache nennen (das problem trat auf einmal auf ohne änderungen am server getätigt zu haben) aber einen lösungsweg...

(strato server suse 9.3 mit serveradmin 24)
in die datei "/etc/sysconfig/apache2" gehen.

die zeile "apache_modules=" ... " suchen und dort den eintrag "mod_suphp" entfernen. danach apache neustarten (eventuell mal /tmp leeren falls es probleme mit der seite geben sollte)

achtung er sagte durch das entfernen ist php nicht mehr ganz so sicher, bringt aber neben dem effekt dass die seite wieder läuft auch moch 20% mehr performance da der php interpreter nun nicht mehr jedes mal neu geladen wird)

lg

[rootsvr]

Gute Idee.. damit hast Du die Auswirkung beseitigt, gleichzeitig eine der Hürden gegen Angreifer vernichtet.

normalerweise kann man bei nem 500 immer im Errorlog gucken was er den hat, bei dem User hier ist allerdings so wenig wissen vorhanden das man ihn vielleicht besser in ein anderes Forum abschiebt *g*

naja ist eh Perlen für die Säue ohne eine gebt mir eine Zeile die ich per Copy paste ausführen kann, wird es wohl nicht gehen.

[elch_mg]

*kopfauftastaturhaut*

ab sofort heisst Support "Ich tu so als würd ich dir helfen lass mich in Ruhe"

[mr_vista]

nun ja könnt ihr denn mal ein beispiel nennen wie angreifer das jetzt ausnutzen können?

[duergner]

Kurz gesagt: alle deine PHP Skripte laufen jetzt unter der UID/GID des Apache und koennen somit auf alle Dateien zugreifen (theoretisch) auf die auch der Apache Zugriff hat.

[Jeff]

Meistens liegt es bei den Systemen an den Rechten..
Die Verzeichnisse und Dateien sollten max 755 als Rechte bekommen, dann klappts auch. Wenn 777 zum Beispiel für das dazugehörige Verzeichnis gesetzt wird, wird das Script mit 500 beendet.
Nähere Informationen liefert wie immer das suexec log ;)

Gruß,
Chris

[mr_vista]

nun ja das problem war, dass alles funktioniert hat und der fehler auf einmal auftauchte ohne das was am server gemacht wurde, sofern kann ich nicht nachvollziehen, dass was mit den rechten nicht in ordnung gewesen sein soll.
was für mich aber noch vorteilhaft ist, ist die performance. die php binary muss jetzt nicht mehr bei jedem aufruf neu gestartet werden.

ok also kann php jetzt auf alle daten zugreifen auf die apache auch zugreifen kann, kann mir trotzdem jemand sagen wie angreifer das jetzt ausnutzen können? :)

(so weit ich gelesen hab spielt suphp eigentlich nur eine rolle wenn mehrere accounts auf einem server vorhanden sind - das kann natürlich auch falsch sein)

lg

[Roger Wilco]

ok also kann php jetzt auf alle daten zugreifen auf die apache auch zugreifen kann, kann mir trotzdem jemand sagen wie angreifer das jetzt ausnutzen können? :)

Ein Angreifer kann durch ein unsicheres Skript alle Dateien verändern, auf die der Apache httpd schreibenden Zugriff hat, also z. B. alle Dateien, die durch ein PHP-Skript hochgeladen wurden.

(so weit ich gelesen hab spielt suphp eigentlich nur eine rolle wenn mehrere accounts auf einem server vorhanden sind - das kann natürlich auch falsch sein)

Wenn du wirklich nur einen einzigen Benutzer auf dem Server hast, ist es relativ egal. Da bringt dir SuPHP nicht viel, weil die Dateien schon einem einzigen Benutzer gehören.

[mr_vista]

ahhh ok das meinte ich... dann wird mir wohl nich gleich morgen jemand den server kaputt hacken ;) vielen dank für die auskunft

lg

[cybi82]

bei error 500 musste ich eben mein documentRoot anpassen.
das war in der httpd.conf global für port80-anfragen auf n dir im srv.... gelenkt.
habs nu auf homes umgestellt und alles läuft. (auf home, da mehrere user mit jeweils einer eigenen hp)

mfg
Cybi

[squize]

Das Problem mit den Nukes liegt oft daran, dass die Bearbeitungszeit der Skripte für die PHP-Einstellungen zu lange dauert oder zuviel Speicher beansprucht wird.

Wenn es ein Rootserver ist, lässt sich dies durch Anpassen des memory limits und der max execution time beheben.

Bei Hostingpaketen kannst du nichts anderes machen, als dir ein anderes System als Nuke zu nehmen oder dir einen Server zuzulegen, der weniger eingeschränkt ist.

Gruss

Marc