[Born-IT] WordPress: PHP 5 hat End of Support erreicht

iele Webseiten sind auf PHP angewiesen. Administratoren der Webseiten sollten sicherstellen, dass dort kein PHP 5, sondern eine der Nachfolgeversion verwendet wird. Denn der Support für PHP 5 ist ausgelaufen. WordPress, Joomla, Drupal und viele andere beliebte Webseiten-CMS sind in




Autor: Günter Born
 
Ich bin auch letztens auf eine Seite gestoßen, die nicht mehr unter PHP 7 zum laufen zu bekommen war, weil sie noch mysql_connect nutzte. Bin aber dann auf ein Github Projekt gestoßen, dass alle calls in mysqli_connect umwandelte. Seitdem habe ich ruhe :D
 
Jupp, musste vor ein paar Tagen auch ein Projekt an MySQLi anpassen. Zum Glück hatten die in einer Config-Datei die Auswahlmöglichkeit, welchen Treiber (mysql, mysqli, mysqlnd) man nutzen möchte.

Wenn ich an meine PHP-Zeit vor 15 Jahren zurückdenk, bin ich damals schon von myql auf mysqli umgestiegen. Wurde irgendwo auch Zeit, dass mal die alten Zöpfe abgeschnitten wurden. Und wenn dann haufenweise Seiten deswegen nicht mehr funktionieren, ist das durchaus nicht schlecht. Könnte man als darwinistische Auslese betrachten.
 
Aus technischer Sicht freu ich mich über PHP5 eol. ich frag mich aber, wie mit Kunden umgehen, die ein altes CMS nutzen, das zB nur innerhalb des firmennetzwerks zugänglich ist und bei dem nicht nur mysqli ein Problem ist. denen ist ein Umstieg auf ein neues System zu teuer weil der Fokus nicht auf security sondern Gewinn liegt und argumentiert wird, dass das system eh nicht von "fremden" genutzt wird. Mach ich für die einen gejailten webspace auf einem lokalen webserver mit phpfpm und PHP5? Wie lange kann man so noch weiter “leben“?
 
Das Argument zählt nur dann wenn ausgeschlossen werden kann das ein beliebiges Gerät innerhalb des Netzwerkes kompromitiert wird (Oder ein fremdes Gerät innerhalb der Firma angesteckt wird).
Wenn das nicht garantiert werden kann (Oder unwahrscheinlich genug ist) dann ist das "nur innerhalb der Firma" kein valides Argument da es dann faktisch nur geringen Unterschied macht.

Selbst wenn ein System das nach extern offen ist kompromitiert wird - sucht man von dort aus erst mal nach den schwächsten Zielen um sich einzunisten.


So einer Firma könnte man mal die Informationen über den Angriff bei Domainfactory schicken. Also die die der Hacker nicht Domainfactory erzählt hat...

Da waren auch veraltete php-Versionen innerhalb des Netzwerks das Problem - das es sehr einfach war an Kundendaten in großem Umfang zu kommen. Ein Angriff geht ja quasie nie gezielt auf ein System sondern ich versuche von außen rein zu kommen, dann suche ich schwache Ziele um dann "interessante" Informationen zu suchen.

Und je nach Unternehmen muss man dann die Frage stellen wie der Gewinn so aussieht wenn in der Zeitung etwas über geklaute Kunden/Blaupausen/Finanz/whatever Daten steht. Oder was das Unternehmen kostet mal sagen wir 5 Tage die IT abzuschalten um diese zu reinigen.

Bei den meisten CMS sollte eine Portierung auf eine aktuelle Version auch nicht die Welt kosten - außer es ist sehr viel selber geschriebenes drin....
 
ich frag mich aber, wie mit Kunden umgehen, die ein altes CMS nutzen, das zB nur innerhalb des firmennetzwerks zugänglich ist
Das ist ein Scheinargument. Wenn das Firmennetzwerk irgendwie mit dem Internet verbunden ist, dann kann das auch kompromitiert werden. De Einstiegspunkt muss ja nicht mal das veraltete CMS/PHP sein.

denen ist ein Umstieg auf ein neues System zu teuer weil der Fokus nicht auf security sondern Gewinn liegt
Dann ist das System auch nicht soviel wert, dass man es nicht auch abschalten könnte.

Wie lange kann man so noch weiter “leben“?
Ewig. Frag mal die Leute, die in Firmen noch den IE6 nutzen müssen.
 
@drfuture: Alte CMS Versionen sind da schon ein Problem, oft, weil es dann eben nicht nur die Laufzeitumgebung ist, die keine Updates mehr bekommt. Würde das CMS aktualisiert, wäre es ja PHP7 kompatibel. Da stellt sich dann die Frage: altes nicht mehr aktualisierte CMS inklusive dessen Lücken portieren, oder gleich zur neuen Version migrieren? Das ist dann meist aber noch teurer, weil sich die Strukturen geändert haben und die Daten und Plugins nicht mehr passen.

@electric.larry: "Das ist doch nur im internen Netz" klingt für mich so wie "Im Büro brauche ich keine Hose, da wird doch geheizt." Die Metapher hinkt natürlich, die Hose hat mehrere Funktionen und die IT-Sicherheit mehrere Layer ("Security in Depth") und das ist nur fast vergleichbar ;-) Das ist aber nicht wichtig, der relevante Punkt ist, dass die Message ankommt.

Weitere gute Punkte für PHP7: deutlich verbesserte Performance
 
Mir muss ja keiner erklären, dass man nichts im EOL nutzen sollte und die meisten größeren Kunden/Institutionen sind da inzwischen auch schon sensibilisiert.

Aber grad im KMU Bereich kommen dir selbst gestrickte Anwendungen unter, die seit 15 Jahren im Einsatz sind und von einem Ende-50er Typ seither bedient werden. Wenn du dem oder seinem Boss sagst, er muss 20 K in die Hand nehmen, um ein Ding neu zu machen, das aus seiner Sicht ja noch immer tadellos funktioniert, dann freut sich der mal zuerst nicht so sehr.

Und auch für größere Unternehmen oder sogar Regierungen sind Umstiege auf etwas Neues kein Spaziergang. Erinnert euch an das EOL von Window$ XP. Da haben nicht wenige lieber für verlängerten XP Support eine Stange Geld hingelegt, als "einfach" auf was Neues umzusteigen. Oder schau dir die STRABAG an, wo noch immer auf AS/400 gearbeitet wird, weil ein europaweiter Umstieg auf z. B. SAP so ein Monster-Projekt ist/wäre.

Wenn also für einen Techniker klar ist, steig ASAP auf was Neues um, heißt das nicht, dass das auch für einen Betriebswirt die beste/effizienteste Lösung ist. Nicht selten bekomme ich die Frage, wie hoch denn das Risiko sei, gehackt zu werden und was da im schlimmsten Fall passieren könnte. Solche Leute wägen eben ab, was kann ein Angriff im schlimmsten Fall kosten bzw. kostet ein Umstieg.
 
Zurück
Oben