Apache absichern - Anfänger

[andyzz]

Hallo liebe Leute!

Betreue für einen Kunden eine Joomla Webseite, bin aber nicht der Serveradmin und habe auch nur FTP Zugriff. Die Seite wird immer wieder gehackt. Der Serveradmin meint, es ist zu 99% Joomla schuld, kann auch sein, aber...
Meine Frage, ist es möglich bei Apache Dateien und Verzeichnisse dadurch abzusichern dass man als den Besitzer der Dateien und Verzeichnisse im httdoc Verzeichnis einen neuen Benutzer nimmt und dem Benutzer unter dessen Namen der Webserver läuft nur Lese-Rechte auf die Dateien und Verzeichnisse zu geben, so dass Dateien nicht geändert und keine neuen Dateien erstellt werden können? Wo liegt mein Denkfehler?

[Nobbie]

Meine Frage, ist es möglich bei Apache Dateien und Verzeichnisse dadurch abzusichern dass man als den Besitzer der Dateien und Verzeichnisse im httdoc Verzeichnis einen neuen Benutzer nimmt und dem Benutzer unter dessen Namen der Webserver läuft nur Lese-Rechte auf die Dateien und Verzeichnisse zu geben

Das sollte funktionieren.

Ob das reicht, um das gehackte Joomla abzusichern, das kann ich Dir nicht sagen. Ich weiß ja nicht, was das heißt, "gehackt" zu sein. Joomla legt ja die meisten Daten gar nicht "offen" irgendwo in das Dateisystem, sondern in SQL Tabellen unter MySQL. Und wenn das jemand schafft, da irgendwie Käse reinzuschreiben, das wird sich nicht bessern, wenn Du nur die htdocs Dateien schützt. Das wirst Du auch nicht ändern können, denn Joomla muss ja da reinschreiben können, sonst könnte man keine neuen Seiten usw. anlegen. Das wird für andere Applikationen gelten, also dieser Leseschutz ist nur sehr sehr rudimentär und schwach. Vielleicht gibt es auch eine andere Schwachstelle, dass man von außen irgendwelche Shell Programme starten kann, die eigentlich nicht erreichbar sein dürften. Das hat mit htdocs und Leserechten gar nichts zu tun. Du merkst, Du hast doch einige Lücken in Deinem Modell (sprich: Denkfehler).

Im Grunde musst Du herausfinden, wo das Sicherheitsloch ist, einfach (sinnbildlich) irgendwo Kit hinschmieren (= nur Leserechte in htdocs) ist ein Schuss ins Blaue. Entweder ist der Server unsicher konfiguriert, oder es gibt bei Joomla eine Schwachstelle, weiß ich nicht, kann ich nichts zu sagen. Aber das ist eigentlich das, was Du herausbekommen musst.

[andyzz]

Hallo Nobbie,

vielen Dank. Mir geht es erstmal darum sicherzustellen (wenn es dann möglich ist), dass PHP keine Dateien erstellen kann, sondern nur lesen. Somit wäre in meinen Augen bewiesen, dass falls neue Dateien auf dem Server auftauchen würden, dass diese nicht durch Joomla (sprich durch Ausführung von PHP) erstellt worden sind, sondern dass es andere Probleme gibt, die Zugriff erlauben. Damit müsste sich dann der Serveradmin beschäftigen. Im Moment ist es so, ich habe zwar keinen Zugriff auf die Serverkonfiguration, bin aber allein für die gehackte Seite verantwortlich.

Das ist ja das dumme, dass man garnicht so einfach klären kann, welche Schwachstelle ausgenutzt wurde um tausende Dateien auf dem Webserver zu platzieren. Es müsste doch Hilfmittel geben, die zumindest Hinweise auf die Art und Weise auf welche eine Datei erstellt wurde geben würde. Der Serveradmin sagt er kann das auch nicht sehen. Ich bin kein Serveradmin, habe mich auch bisher nur wenig mit Serverkonfiguration beschäftigt.

[Nobbie]

Hallo, hallo, hallo!!

Du gehst irgendwie irrig davon aus, dass ich die Symptome des Hackens kenne. Das ist so nicht (woher denn auch?)! Das ist völlig wirres Zeug, was Du da schreibst. Wenn Du überhaupt irgendwie einen Hinweis bekommen möchtest (was ich nicht einmal garantieren kann), dann müßtest Du erst einmal erläutern, was denn das Problem ist. Aus diesem Buchstabenwust entnehme ich, dass da wahrscheinlich unbefugt irgendwo(?) irgendwelche(?) Dateien auftauchen, die da nichts verloren haben? Oder wie oder was?!

So geht es jedenfalls nicht, ich blicke nicht durch.

[andyzz]

Ok ok, nein ich gehe von nichts aus, es geht mir im Moment nur um diesen einen Aspekt, abzusichern dass der Webserverprozess (PHP) keine Dateien erstellen kann. Bei Joomla braucht man das auch nicht, denn wie Du schon geschrieben hast, liegt der tatsächliche Inhalt der Webseite in der Datenbank, Ausnahme sind hochgeladene Bilder und Dokumente. Also,falls auf dem Server ein schädlicher PHP-Skript liegt welcher das Uploaden oder das Erstellen von neuen Dateien ausübt, sollte durch die Benutzerrechte dieser Vorgang gestoppt werden können.

Was passiert ist. Es tauchten 7000 html Dateien im Rootverzeichnis auf. Dazu 4 PHP Dateien. Wie, was, woher - keine Ahnung. Ich habe keinen Zugriff auf die Serverlogs, somit kann ich nicht mal schauen welche IP wann welche Anfragen an den Webserver geschickt hat. Der Serveradmin sagt schuld ist Joomla, ich sage, das kann man so pauschal nicht sagen. Ohne Zugriff auf die Serverlogs und ohne Nachforschung kann ich das aber nicht klären.

[Nobbie]

Ohne Zugriff auf die Serverlogs und ohne Nachforschung kann ich das aber nicht klären.

Und damit wäre MIR das sche***egal. Wieso machst Du Dir da einen Kopf, das ist ja nicht Dein Server und was der Admin da erzählt, kann Dir auch vollkommen egal sein. In aller Regel erzählen die immer das, wo sie am wenigsten selbst Schuld sind. Aber helfen tut das keinem.

Das kann ja auch von intern kommen, das ist soviel Zeug, das muss ja auch erst einmal hochgeladen werden. Mit welcher Anbindung und welcher Geschwindigkeit? Geht das überhaupt? Außerdem würde man das im Access Log einfach wiederfinden.

Letztendlich bringt das auch nichts, was Du jetzt versuchst. Da man die Schwachstelle nicht kennt, kann ja auch sein, dass eine Lücke mit sudo existiert, dass jemand mit erhöhten Rechten irgendetwas veranstaltet. Das hat alles aber so überhaupt keinen Sinn, wenn man das herausfinden will, muss man sich damit beschäftigen, die Inhalte analysieren, die Logfiles auswerten usw. etc. pp.

[andyzz]

Danke, es ist mir schon klar das man da systematisch ran gehen sollte, doch wie gesagt, wenn ich keinen Zugriff habe, aber die Seite "sauber" halten soll, da suche ich nach Möglichkeiten aufzuzeigen dass das Problem VIELLEICHT nicht bei Joomla liegt sondern in der Serverkonfiguration oder geknackten/gestohlenen Passwörtern....

Doch vielleicht ist es wirklich sinnvoller den Hostinganbieter zu wechseln, jedoch bin ich ja nicht der Seitenbetreiber, da muss ich mal mit dem Seitenbetreiber reden...

[Nobbie]

Doch vielleicht ist es wirklich sinnvoller den Hostinganbieter zu wechseln, jedoch bin ich ja nicht der Seitenbetreiber, da muss ich mal mit dem Seitenbetreiber reden...

Ach Du Schreck, das ist eine gehostete Seite? Massenserver oder wie? Das ist ein Fass ohne Boden. Vielleicht ist ja auch gar nichts gehackt worden, vielleicht ist die Installation eines Themes oder Plugins irgendwie schief gegangen und hat das Gerümpel hinterlassen. Wer weiß das schon??

Das hat ja überhaupt keinen Sinn, ohne Analyse da irgendetwas zu vermuten. Vielleicht ist auch von einem anderen Kunden der Krempel irgendwie hängen geblieben, weil der Massenhoster den Server falsch konfiguriert hat? Es gibt unendlich viele Möglichkeiten, beim jetzigen Informationsstand ist überhaupt keine qualitative Aussage machbar.

[andyzz]

Es soll sich schon um einen 'dedicated Server' handeln, doch wer weiss schon ob es dem auch so ist. Ich werde den Admin bitten mir Zugriff auf die Serverlogs(access, error) zu geben, vielleicht kann er zumindest das organisieren. Danke nochmal.

[Altrea]

Hallo andyzz,

Wie Nobbie schon sagte versuchen Hosting-Server-Admins die Verantwortung ersteinmal auf den Kunden abzuwälzen. Das geht schnell und ist bequem und der Kunde ist ersteinmal beschäftigt.
In vielen Fällen ist es aber auch tatsächlich so, dass schwachstellen in Webanwendungen oder Drittmodulen schuld an solchen Verhaltensweisen sind. Dann es ist für jemanden viel eifacher eine bekannte Lücke in einer so bekannten Webanwendung auf viele hundert oder Tausend Server auszunutzen als umgekehrt (außer es handelt sich jetzt wirklich um eine eklatante Sicherheitslücke im Linux Core oder ähnliches, was aber bei weitem unwahrscheinlicher ist).

Die ersten Fragen die du dir selbst stellen solltest sind also:
- kannst du Zugriff auf die Logs bekommen und den Fehler dadurch eingrenzen können?
- Ist Joomla auf dem aktuellsten Stand?
- Verwendest du irgendwelche Joomla Module die nicht zum Joomla Core gehören?
- Existieren bekannte Sicherheitslücken für die eingesetzte Joomla-Version oder den eingesetzten Modulen?
- Falls ja: Kann man die bekannten Sicherheitslücken durch ein Update oder Fix stopfen?

Du kannst die meisten Dateien und Ordner von Joomla absichern. Ein paar wenige allerdings nicht, die zum Beispiel zum upload von Bildern etc vorgesehen sind.
Generell sollte es aber reichen, wenn Joomla strikt nach Anleitung installiert ist.

Und ein Webhosting Anbieter der sich so inkooperativ bei zumindest der Fehleranalyse zeigt, den hätte ich schon längst gewechselt.

[andyzz]

Hallo Altrea,

vielen Dank für deine Antwort.

Habe mittlerweile Zugriff auf was der Admin als Logs bezeichnet, doch da muss was mit dem Logging schieflaufen. Bei 530 Besuchern heute laut Google Analytics(und das sind keine Analytics Spam referrals) sind in der Access Log nur drei Zeilen eingetragen. Das selbe für die Logs der letzten 30 Tage.
Und die error.log scheint auch nicht zu funktionieren, zeigt für die letzten Monate nur eine ART von Meldung, immer das gleiche es ändert sich nur das Datum/Zeit und die ZugriffsIP, Meldungs text sonst identisch:
[Tue Dec 01 19:23:15.077869 2015] [access_compat:error] [pid 15366] [client 66.249.78.214:48068] AH01797: client denied by server configuration: /__web_root/
Werde den Admin morgen darauf ansprechen.

Joomla ist auf dem neusten Stand 3.4.5, kann natürlich aber sein, dass schon vor dem Update die Seite "infiziert" wurde, da erst das letzte Joomla Update ein kritisches SQL Injection Bug beseitigte.
Die Seite verwendet einige(5-6) nicht-Core Erweiterungen, werde schauen ob es vielleicht bei einer dieser eine neue Lücke bekanntgeworden ist.