Frage, phishing Seiten erkennen

[Domi]

Moin Leute, ich habe mal eine kleine Frage an Euch
Auf einem VQ7 bei Hetzner ist eine Domain drauf, mit einem älteren Joomla das seit kurzer Zeit für eine Migration fertig gemacht wird. Heute habe ich wegen dieser Domain (was abzusehen war) eine Information bekommen, dass eine Datei für Phishing verwendet wird.

Im Regelfall sind es ja irgend welche .php Dateien. Mich würde mal interessieren, welche Präventionsmaßnahmen man ergreifen könnte um so etwas von Vornherein zu verhindern, ohne dass das Joomla System jetzt zu stark eingeschränkt ist

Hetzner hat mir in diesem Fall die Dateien genannt, die das phishing verursachen, aber ich würde für die Zukunft und andere Joomla, Wordpress etc. Systeme gerne eine Vorsichtsmaßnahme ergreifen und bin halt neugierig wie Ihr das macht.

Gruß, Domi

Nachtrag: Bevor ich es komplett vergesse.. ich verwende Apache, Ubuntu und auch mal Debian

 

[Terrorkarotte]

Kein älteres Joomla, oder anderes älteres einsetzen.

Dazu eine WAF.

 

[Domi]

Kein älteres Joomla, oder anderes älteres einsetzen.

Dazu eine WAF.

Das mit der Joomla oder anderen Systemen die älter sind, war mir bewusst. Aber hier handelt es sich um ein Kundenprojekt das nicht von heut auf Morgen ohne Überlegung umgestellt werden kann

Außerdem kann es ja immer mal passieren, dass es eine Sicherheitslücke etc. gibt, daher fragte ich, ob es Optionen oder Präventionsmaßnahmen gibt

Was ist WAF?

 

[infinitnet]

WAF = Web Application Firewall.

Ich kann mod_security mit dem kostenlosen ASL Ruleset empfehlen. Download der Rules: https://www6.atomicorp.com/channels/rules/delayed/modsec-2.7-free-latest.tar.gz

Es ist ausreichend, wenn nur die Datei '10_asl_rules.conf' verwendet wird, sowie die dazugehörige 'sql.txt'. Desweiteren sollte man einige Funktionen von PHP deaktivieren (shell_exec u.A.), damit bei einem Einbruch durch die Webanwendung der Schaden in Grenzen gehalten werden kann. Außerdem sollte ein PHP-Handler wie bspw. PHP-FPM oder FastCGI verwendet werden, statt mod_php.

Wenn's auch was Kommerzielles sein darf, kannst du dir das hier mal ansehen: https://www.atomicorp.com/products/asl.html

 

[Domi]

Ahh... vielen Dank für die Informationen.

PHP-FPM und FastCGI sind eingebunden und können separat für jede Domain aktiviert oder deaktiviert werden. Da ich seit einigen Wochen / Monaten ISPconfig verwende, habe ich das eine oder andere Feature schon kennen gelernt

Zwecks Web Application Firewall werde ich mir das mal anschauen und sage bis hierhin schon mal vielen vielen Dank

Was die kommerzielle Lösung angeht, da werde ich vielleicht im nächsten Jahr mal genauer nach schauen, wenn ich sehe das der Kosten / Nutzen Faktor ausreichend ist und die Erträge das auch alles zulassen.

Gruß, Domi

 

[infinitnet]

Kein Problem - viel Erfolg beim Einrichten. Falls noch Fragen auftauchen, immer raus damit.

 

[d4f]

Außerdem sollte ein PHP-Handler wie bspw. PHP-FPM oder FastCGI verwendet werden, statt mod_php.

Die kostenlosen ASL-Regeln sind definitiv nicht ausreichend bei gewerblichem Einsatz da sie über 30 Tage alt sind und somit existierende Exploits schon lange das Joomla missbraucht haben.
Bei 99$/Jahr ist es zwar nicht all zu billig aber durchaus bezahlbar die kommerziellen Regeln zu verwenden welche mehrmals täglich bei aktuellen Exploits aktualisiert werden und somit generell schneller eingesetzt werden können als die Patches der Hersteller selbst.

Außerdem sollte ein PHP-Handler wie bspw. PHP-FPM oder FastCGI verwendet werden, statt mod_php.

Ich hoffe du hast nicht nur die betroffenen Dateien gelöscht - anderer nicht entdeckter Schadcode oder Änderungen am Joomla sind durchaus bei Exploits häufig.
Zur Überprüfung der Webspaces kann ich CXS (einmalig 50$) empfehlen welches zwar offiziell nur für CPanel unterstützt wird aber mittels Konsolenaufruf auf jedem Linux-Webserver lauffähig ist. Das Programm kann sich auch in die Upload-Handler einklinken um Schadcode beim Hochladen zu erkennen, funktioniert aber natürlich nicht gegen den Exploit selbst sondern nur dadurch bedingt hochgeladene und bereits bekannte Software.

Außerdem sollte ein PHP-Handler wie bspw. PHP-FPM oder FastCGI verwendet werden, statt mod_php.

Der PHP-Handler hat nicht wirklich was mit Sicherheit zu tun wenn man die Implikationen kennt und durch andere Maßnahmen korrigiert.
Um Fastcgi/mod_php mal mit den gängigen Auto-Vergleichen dar zu stellen:
Du rätst dazu einen Porsche 911 zu verkaufen und einen Trabi zu verwenden...

und die Erträge das auch alles zulassen.

Die Regeln kosten leicht über 6€ je Monat, also weniger als 50% deiner vServer-Kosten.

 

[infinitnet]

Die kostenlosen ASL-Regeln sind definitiv nicht ausreichend bei gewerblichem Einsatz da sie über 30 Tage alt sind und somit existierende Exploits schon lange das Joomla missbraucht haben.
Bei 99$/Jahr ist es zwar nicht all zu billig aber durchaus bezahlbar die kommerziellen Regeln zu verwenden welche mehrmals täglich bei aktuellen Exploits aktualisiert werden und somit generell schneller eingesetzt werden können als die Patches der Hersteller selbst.

Richtig, daher habe ich auch ein kommerzielles Paket verlinkt. Da der OP anscheinend jedoch darauf verzichten möchte, sind die kostenlosen Regeln immer noch besser, als gar keine und blocken zumindest zum Teil auch unbekannte Exploits.

Der PHP-Handler hat nicht wirklich was mit Sicherheit zu tun wenn man die Implikationen kennt und durch andere Maßnahmen korrigiert.
Um Fastcgi/mod_php mal mit den gängigen Auto-Vergleichen dar zu stellen:
Du rätst dazu einen Porsche 911 zu verkaufen und einen Trabi zu verwenden...

FPM mit einem Trabi zu vergleichen, ist schon etwas extrem. Schneller als SuPHP oder FastCGI ist es allemal. Was würdest du denn empfehlen, um die einzelnen Scripte der Kunden besser voneinander zu isolieren, was zusammen mit ISPConfig läuft?

 

[d4f]

FPM mit einem Trabi zu vergleichen, ist schon etwas extrem.

Ich habe Fastcgi und nicht FPM verglichen. FPM in der Leistungsfähigkeit ähnlich mod_php, allerdings aufgrund der Worker-Pools für shared Hosting mit mehr als einer Handvoll Kunden absolut ungeeignet.
Bei allen nicht-mod_php Lösungen für Apache muss man entweder massive Abstriche in Punkto Leistungsfähigkeit, Stabilität und Skalierbarkeit machen, von conveniance-Features wie "php_value xxxxx yyyyy" in der .htaccess mal ganz abgesehen.

Was würdest du denn empfehlen, um die einzelnen Scripte der Kunden besser voneinander zu isolieren, was zusammen mit ISPConfig läuft?

Mit einem kleinen Patch (Einfügen einer weiteren Zeile) im vHost-Template kriegt man den MPM-ITK unter jedem Panel zum laufen, sei es WHM, Froxlor, ...
Vorteil ist dass hier ohne Hacks, Patches oder zusätzliche Module der komplette Webserver inklusive alle davon gestartete Prozesse unter dem korrekten Benutzer und nicht "nobody" läuft was Permission-Probleme, wwwrun-Komplikationen und Zugriffsrechte erheblich vereinfacht.

Leicht OT aber wenn wir schon bei Sicherheit sind, so sollte um das Auslesen anderer Benutzer und Dateien zu unterbinden folgender "Bluehost" Patch in Apache appliziert werden: http://mail-archives.apache.org/mod_mbox/httpd-dev/201210.mbox/<[email protected]>