Case Study: PHP-System aus 2008 - wie wir es stabilisiert und gesichert haben
Ein legacy PHP System stabilisieren ist selten glamourös. Es gibt kein Grünfeld, keine saubere Architektur, keine Tests. Es gibt Code der läuft, den niemand vollständig versteht, und einen Betrieb der davon abhängt.
Dieser Artikel beschreibt ein echtes Projekt aus unserer Praxis. Das Unternehmen bleibt anonymisiert, die technischen Details und die Chronologie sind real.
Das System: Was wir vorgefunden haben
Der Anruf kam Anfang 2024. Ein mittelständisches Unternehmen, rund 45 Mitarbeiter. Die Kerngeschäftssoftware lief seit 2008 in Produktion. Niemand konnte uns sagen, wer sie zuletzt angefasst hatte.
Das Unternehmen hatte im Laufe der Jahre drei Entwickler beschäftigt. Alle drei waren gegangen. Unterlagen hatten sie keine hinterlassen.
Keine Dokumentation, kein Git
Es gab kein Versionskontrollsystem. Keine Git-Historie, kein SVN, nichts. Änderungen wurden per FTP direkt auf den Server hochgeladen. Die Dateien trugen Namen wie rechnung_neu.php, rechnung_neu2.php, rechnung_final.php, rechnung_FINAL_v2.php.
Das klingt nach schlechter Praxis. Das stimmt auch. Aber es ist kein Einzelfall. In vielen Betrieben entstanden Softwareprojekte genau so: schnell, pragmatisch, ohne Struktur.
PHP 4 auf einem Server aus dem Jahr 2007
Die PHP-Version war 4.4.9. PHP 4 hat seinen Support bereits im August 2008 eingestellt. Also fast 16 Jahre vor unserem Einsatz.
Der Server war ein dedizierter Server in einem deutschen Rechenzentrum. Das Betriebssystem: Debian Etch, veröffentlicht 2007. Die Datenbank: MySQL 4.1, ebenfalls seit 2009 ohne Support.
Die Ausgangslage vor Projektbeginn
Das System lief. Es verarbeitete täglich Bestellungen, generierte Rechnungen und synchronisierte Kundendaten. Für das Unternehmen war es unverzichtbar.
In den letzten sechs Monaten hatte es allerdings zweimal unerklärliche Ausfälle gegeben. Jeweils nachmittags, jeweils ohne erkennbaren Grund. Beide Male hatte sich das System nach einigen Stunden von selbst erholt.
Das Unternehmen wollte wissen: Was ist los? Und was tun wir?
Schritt 1: Bestandsaufnahme vor jeder Maßnahme
Wir haben nicht sofort angefangen zu reparieren. Das ist ein häufiger Fehler. Wer in ein unbekanntes System eingreift, ohne es zu verstehen, verursacht neue Probleme.
Der erste Schritt war eine vollständige Bestandsaufnahme. Dazu gehörten vier Bereiche:
Code-Analyse: Wie viele PHP-Dateien gibt es? Welche Funktionen sind kritisch? Gibt es Datenbankzugriffe ohne Prüfung der Eingaben?
Server-Analyse: Welche Dienste laufen? Welche Ports sind offen? Gibt es unbekannte Cronjobs oder Prozesse?
Datenbank-Analyse: Wie ist die Datenbankstruktur aufgebaut? Welche Tabellen sind kritisch?
Log-Analyse: Was steht in den Server-Logs, Apache-Logs und PHP-Fehler-Logs der letzten Monate?
Diese Bestandsaufnahme hat vier Tage gedauert. Das ist keine Ineffizienz. Das ist Pflicht.
Die Log-Analyse erklärte die Ausfälle sofort. An den betroffenen Tagen liefen zwei Cronjobs für Rechnungs-Export und Datensynchronisation gleichzeitig. Die Datenbank konnte die Last nicht bewältigen. Kein Angriff, kein Mysterium. Nur ein fehlendes Scheduling.
Das ist das Erste, was beim legacy PHP System stabilisieren oft übersehen wird: Der Fehler liegt meist im Betrieb, nicht im Code.
Schritt 2: Dringlichkeiten priorisieren
Nach der Bestandsaufnahme hatten wir eine Liste mit Problemen. Nicht alle hatten die gleiche Priorität.
Wir haben sie in drei Kategorien eingeteilt:
Sofortig: Probleme, die das System gefährden oder Daten kompromittieren könnten. Dazu zählten offene Ports, unverschlüsselte Datenbankverbindungen und ein FTP-Zugang ohne ausreichende Passwortbeschränkung.
Mittelfristig: Strukturprobleme, die langfristig die Wartung erschweren. Doppelte Dateien, unkontrollierte Cronjob-Überschneidungen, fehlende Fehlerbehandlung.
Langfristig: Technologische Altlasten, die keinen sofortigen Handlungsbedarf haben, aber auf einem Modernisierungspfad liegen müssen. Dazu zählten PHP 4 selbst, MySQL 4.1 und der veraltete Betriebssystem-Stand.
Diese Priorisierung ist wichtig. Ein legacy PHP System stabilisieren bedeutet nicht, alles auf einmal zu reparieren. Es bedeutet, zuerst das zu tun, was am meisten schadet, wenn man es nicht tut.
Schritt 3: Sofortmaßnahmen umsetzen
In den ersten zwei Wochen haben wir die kritischsten Punkte abgearbeitet.
FTP deaktiviert, SSH gesichert
Der FTP-Zugang war ohne ausreichende Zugangskontrolle. Wir haben FTP deaktiviert und SSH mit Key-basierter Authentifizierung eingerichtet. Kein Passwort, nur kryptografische Schlüssel.
Datenbankverbindungen verschlüsselt
Alle Verbindungen zwischen Anwendung und Datenbank liefen unverschlüsselt. In einem Rechenzentrum mit mehreren Kunden auf gleicher Hardware ist das ein vermeidbares Risiko. Wir haben das geändert.
Cronjobs entflochten
Wir haben alle Cronjobs inventarisiert. Es gab 14 davon, vier ohne erkennbare Funktion. Diese vier haben wir deaktiviert und eine Woche beobachtet. Es ist nichts kaputtgegangen.
Die aktiven Cronjobs haben wir so entflochten, dass sie sich nicht mehr überschneiden. Das dauerte einen Tag. Die Ausfälle hörten danach auf.
Backup eingerichtet
Es gab kein automatisches Backup. Der Hoster machte wöchentliche Snapshots, aber davon wusste das Unternehmen nichts. Wir haben tägliche Datenbank-Backups und wöchentliche Server-Backups eingerichtet. Auf einem externen System.
Schritt 4: Ordnung schaffen ohne das System zu brechen
Nach den Sofortmaßnahmen kamen strukturelle Verbesserungen. Hier ist Vorsicht geboten. Wer zu schnell zu viel ändert, riskiert neue Ausfälle.
Git einführen
Wir haben den aktuellen Stand des Systems in ein Git-Repository überführt. Das klingt einfach. Ist es aber nicht, wenn die Dateistruktur mit _neu, _final, _v2 gespickt ist.
Wir haben zunächst nur die Dateien einbezogen, die tatsächlich in Benutzung waren. Dazu haben wir die Apache-Logs analysiert: Welche PHP-Dateien werden tatsächlich aufgerufen? Welche nie?
Nicht aufgerufene Dateien haben wir archiviert und aus dem aktiven Verzeichnis entfernt. Das reduzierte die Codebase um 38 Prozent.
SQL-Injection-Schwachstellen schließen
Die Code-Analyse hatte mehrere SQL-Injection-Schwachstellen ergeben. Das sind Stellen im Code, an denen Benutzereingaben direkt in Datenbankabfragen eingebaut werden, ohne Prüfung.
Ein Angreifer könnte darüber Daten auslesen oder löschen. Diese Lücken sind gut dokumentiert, weit verbreitet in altem Code und vermeidbar.
Wir haben alle gefundenen Stellen manuell bereinigt und durch vorbereitete Datenbankabfragen ersetzt. In PHP 4 ist das aufwendiger als in modernen Versionen. Es geht aber.
PHP-Version anheben
PHP 4 auf einem modernen System zum Laufen zu bringen ist möglich, aber keine Dauerlösung. Wir haben geprüft, ob die Anwendung auf PHP 5.6 lauffähig ist.
Die meisten Funktionen waren kompatibel. Drei Stellen mussten angepasst werden. Dann lief das System auf PHP 5.6.
PHP 5.6 ist selbst seit Ende 2018 ohne Support. Es ist aber ein wesentlicher Schritt besser als PHP 4. Und es war auf dem vorhandenen Server möglich, ohne ein vollständiges Server-Upgrade.
Den weiteren Pfad, von PHP 5.6 auf PHP 8, haben wir dem Unternehmen als Folgeprojekt empfohlen. Das gehört zu den technischen Schulden, die sich über Jahre angesammelt haben und jetzt schrittweise abgebaut werden.
Was wir gelernt haben
Dieses Projekt hat Muster bestätigt, die wir bei vielen ähnlichen Einsätzen sehen.
Systeme laufen länger als sie sollten. Nicht aus Nachlässigkeit, sondern weil es kein Budget und keinen Anlass gab, sie anzufassen, solange sie funktionierten. Das ist menschlich.
Die Probleme liegen selten dort, wo man sie vermutet. Die Ausfälle hatten eine banale Ursache. Die wirklichen Risiken lagen an anderer Stelle: unsichere Verbindungen, fehlende Backups, offene Datei-Zugänge.
Respekt vor altem Code zahlt sich aus. Wir haben nichts übereilt verworfen. Jede Änderung war begründet und minimierte das Risiko für den laufenden Betrieb. Das System sollte nach unserem Einsatz besser dastehen, nicht anders kaputt sein.
Ein Modernisierungspfad ist besser als ein Rewrite-Versprechen. Das Unternehmen bekommt schrittweise modernere Software. Ohne Betriebsausfall. Ohne das Risiko einer Neuentwicklung, die Monate dauert und das Geschäft gefährdet.
Fazit
In sechs Wochen haben wir eine PHP-Anwendung aus 2008 von einem kritischen Zustand in einen stabilen und kontrollierten Betrieb überführt. Die Ausfälle sind Geschichte. Das Backup läuft täglich. Der Code liegt in einer Versionskontrolle. Die kritischsten Sicherheitslücken sind geschlossen.
Was folgt, ist ein geordneter Modernisierungspfad, den das Unternehmen eigenständig steuern kann.
Haben Sie ein ähnliches System? Eines das läuft, aber niemand so richtig kennt? Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihr System an und sagen Ihnen ehrlich, wo Sie stehen.