Thema: Gehackt

Zitat von j!-n

Viel schlimmer find ich unsauber programmierte Extensions, die per SQL-Injection komplette Userlisten inklusive Namen, Email und Passwort ausspucken.

PHP-Code:

index.php?option=com_unsicher&Itemid=999999&listid=-1+union+all+select+username,password+from+jos_users-- 


MD5 ist mittlerweile nicht mehr sicher (Rainbow-Tables etc), und das Verhalten vieler User, auf allen Seiten das gleiche Passwort zu nutzen, kommt sehr oft vor. Gutes Beispiel dafür war die letzte Forenhack-Aktion, die nur durch Datenbank-Hacks möglich wurde.

MD5 ist selbstverständlich ausreichend sicher. Rainbow Tables nützen dir nur dann etwas, wie du weißt, wenn jemand bereits die Datenbank geklaut (ausgelesen) hat. Dann kann er einen Abgleich mit den Rainbow Tables durchführen und auf diese Weise in den Besitz von vielen Passwörtern gelangen, falls die Ursprungspasswörter nicht ausreichend komplex waren. Das ist der Grund warum neue Passwörter in Joomla 1.5 (bei Joomla 1.0 ab Unterversion 10 glaube ich) per MD5 zusätzlich "gesalzen" werden.

Ansonsten ist MD5 sicher. Wer sich die Datenbanken klauen lässt, hat bereits ein akutes Sicherheitsproblem. Wessen Datenbank allerdings geklaut wurde, der sollte nachsehen ob die Passwörter gesalzen sind. Falls das nicht der Fall ist, müssen umgehend alle Passwörter neu vergeben werden.

Und selbst wenn die Passwörter gesalzen waren, würde ich alle Passwörter neu vergeben lassen. Es ist nämlich nicht auszuschließen, das ein Hacker mit genügend Zeit (PS3 lässt grüßen) auch ein gesalzenes Passwort knackt. Wenn er ein entsprechendes Programm nutzt und einen leistungsstarken Rechner, und wenn das Passwort kurz war bzw. nur einen Standardzeichensatz hatte, dann könnte er es in einigen Wochen knacken.

Das ist aber relativ irrelevant für normale User. Was will ein Hacker mit einem normalen User-Passwort? Problematisch wird es erst bei den Administratoren. Diese sollten stets Paswörter mit mehr als 10 Zeichen (A-Z,0-9 und einigen Sonderzeichen) verwenden, z.B. gaGe§5F6(5L.

In einem System (Joomla 1.5) mit gesalzenen Passwörtern ist das oben genannte Passwort sicher. Um das Passwort zu knacken bräuchte eine Cracker Jahre, selbst mit einer Hochleistungsmaschine. Es sei denn er findet zufällig eine einfache MD5-Kollision, was sehr sehr unwahrscheinlich ist.

Aber wie gesagt, die ganzen Joomla Hacks sind schlicht auf unvorsichtiges Handeln der Nutzer zurückzuführen. Generell sollte man maximale Sicherheit walten lassen. Das heißt PHP richtig konfigurieren (register_globals, fopen usw. deaktivieren), keine unsicheren Extensions installieren und alle geschlossenen Bereiche zusätzlich mit .htaccess (anderes Passwort) schützen. Dann kann der Hacker auch mit dem Admin-Passwort für Joomla nichts anfangen.

Außerdem bei der Statistikauswertung auf auffällige Scriptaufrufe achten. Viele Hackergruppen lassen Bots laufen, die Seiten automatisch auf Schwachstellen prüfen. Diese Botaufrufe lassen sich leicht erkennen. Merkt man das man im Visier von Hackergruppen ist, sollte man zusätzliche Sicherheitsmaßnahmen durchziehen, beispielsweise die Sperrung kompletter IP-Bereiche usw.

Zitat von cybergurk

vergibt allen 755 und 644 und dann eben per KAS gesamten Joomlaroot rekrusiv auf wwwrun stellen, je nachdem wie du am besten klar kommst, testen eben Jeder macht das anders... Die htaccess beeinflusst Docman nicht

Das könnte vieles, besonders Einsteigern erleichtern. Zu viele Dateien sind nach der Install. per Joomlainstaller auf 777. Ich glaube viele Übersehen das, lassen vllt. auch wenn die Seite noch im Aufbau oder in der Entwicklung steht die Seite Online, auch wenn sie tagelang nicht dran arbeiten oO

Vielen Dank für die tollen Tipps. Eine Sache wollte ich aber noch anmerken: wenn ich den Admin-Ordner durch htaccess etc. gesichert habe, dann erscheint beim Uplaod Docman im Frontend immer die Maske, die nach einem Passwort fragt. Klicke ich die weg, dann funktioniert der Uplaod. Muss ich aber nun allen meinen Usern, die uploaden können mitteilen, dass die Maske ignoriert bzw. einfach weggeklickt werden kann? Gibt es da elegantere Lösungen??

Sorry, noch ein Nachtrag: könnte man gerade bei all-inkl nicht genau die dateien, die im Backend die 777 verlangen auf wwwrun umstellen und all die anderen belassen?
Gruß
Rentner

Das sog. "wwwrun" Problem ist überhaupt kein Problem. Was spricht, wie auch Achim öfter schreibt, dagegen, nur dem Serversystem Rechte an Dateien zu vergeben?
Nur so, können Sicherheitslücken effektiv reduziert werden, natürlich zu Lasten der Bequemlichkeit bei Uploads und externen Editoren, welche man evtl. nutzt.

Dagegen spricht das Du Dich auf einer Multiuser/Kunden Maschiene auf solche Dinge wie open_basedir oder andere Konstrukte verlassen musst, wenn Du auschließen willst das sich die Kunden gegenseitig die Dateien manipulieren können. Das diese Mechanismen desöfteren Probleme in Form von Lücken hatten ist ein offenes Geheimniss.

Da alle Kunden den gleichen User nutzen um php Skripte auszuführen haben sie somit erstmal alle die gleichen Rechte an allen Dateien mit dem Besitzer "wwwrun" . Ich denke es sollte klar sein das dies keine Optimale Lösung darstellt. Bist Du alleine auf dem Server spielt das natürlich eine untergeordnete Rolle.

Werden die php Skripte jeweils unter einem eigenen (z.b. "FTP user") ausgeführt dann verschwinden nicht nur diese lästigen Rechteprobleme bei über FTP hochgeladenen Dateien - viel wichtiger ist, es greift das hauseigene Rechtemanagement von Linux da die Dateien unterschiedlichen usern gehören und nicht mehr alle einem einzigen.

Positiver Nebeneffekt ist je nach Ausführung des ganzen das jede Website Ihre eigene individuell angepasste php Konfiguration und sogar Version haben kann. Noch ein netter Effekt ist das die laufenden Skripte einem bestimmten User zugeordnet werden können, falls mal eines Amok läuft.