[quote=“avenger”]http://www.ip-adress.com/whois/91.211.117.25 Daher kommt der Mistkerl… Unsere neuen Freunde aus Osteuropa…[/quote] Paar Tage vorher war der (mit gleicher IP) schon mal da. Entweder ist es seine oder er verwendet den gleichen Anonymous Server… Wenn es gelingt, eine solche Shell einzuschmuggeln, hat man ja wirklich alles, was der Hacker so braucht: File-Manager (um die config-Daten zu lesen => DB-Zugriffs daten) und einen DB-Manager, um die DB zu manipulieren…
[quote=“avenger”]Wenn es gelingt, eine solche Shell einzuschmuggeln, hat man ja wirklich alles, was der Hacker so braucht: File-Manager (um die config-Daten zu lesen => DB-Zugriffs daten) und einen DB-Manager, um die DB zu manipulieren…[/quote] Um das zu vermeiden, sollte in jedem Verzeichnis, in das man mit Shop-Möglichkeiten ein Upload vornehmen kann, sicherheitshalber eine “htacces”-Datei folgenden Inhalts legen:
Order Deny,Allow
Deny from all
Damit wird die Ausführung von PHP-Dateien verhindert. So dass, selbst wenn es wieder mal jemandem gelingen sollte, den Shop zu überlisten, die Ausführung von Shells verhindert wird.
Moin, die Frage ist ja immer, wo genau der Angriff stattgefunden hat. Dabei gibt es ja primär folgende Möglichkeiten: 1. Fehler in der Software (wurde das letzte xtcommerce-Update eingespielt, da gab es vor kurzem eine Lücke => mehr Info bei Heise) 2. Schlechte Passworte 3. Schlechte Serverkonfiguration 4. Unachtsame Software Drittanbieter (Gerne wird das komplette Verzeichnis von Tinymce hochgeladen, da gibts nen schönen ungeschützten Filemanager) Die Frage ist natürlich auch wie gut man für die eigene Sicherheit vorsorgt. Finden tägliche Backups statt, wechselt man regelmäßig sein Passwort und informiert man sich regelmäßig über Sicherheitsprobleme? Die IP dürfte ein schlecht gesicherter dedizierter oder virtueller Server sein. Echte Angreifer machen sich nicht die Mühe so leicht aufzufliegen. Könnte auch eine IP einer Schule oder öffentlichen Einrichtung sein. Der Erpressungs-Versuch baut wahrscheinlich darauf, dass der Shopbetreiber kein oder zu alte Backups seiner Datenbank hat. Die abgebildete .htaccess-Datei ist sehr sinnvoll, sofern man auch kein Upload-Verzeichnis vergisst. Viele Grüße, Michael
[quote=„avenger“][quote=„avenger“]Wenn es gelingt, eine solche Shell einzuschmuggeln, hat man ja wirklich alles, was der Hacker so braucht: File-Manager (um die config-Daten zu lesen => DB-Zugriffs daten) und einen DB-Manager, um die DB zu manipulieren…[/quote] Um das zu vermeiden, sollte in jedem Verzeichnis, in das man mit Shop-Möglichkeiten ein Upload vornehmen kann, sicherheitshalber eine „htacces“-Datei folgenden Inhalts legen:
Order Deny,Allow
Deny from all
Damit wird die Ausführung von PHP-Dateien verhindert. So dass, selbst wenn es wieder mal jemandem gelingen sollte, den Shop zu überlisten, die Ausführung von Shells verhindert wird.[/quote] Das müsste man dann aber auch für alle Skriptsprachen machen, die auf dem jeweilgen Server laufen, z.B. Python, Ruby, etc.
[quote=“radox”]Das müsste man dann aber auch für alle Skriptsprachen machen, die auf dem jeweilgen Server laufen, z.B. Python, Ruby, etc.[/quote] Ja, guter Punkt… Perl=pl Was haben die andern Sprachen denn so für Endungen? Was gibt es noch unter “etc.”?
Noch ein paar Dateiendungen (Skripte). AddHandler cgi-script .php .php3 .php4 .php5 .phtml .pl .py .jsp .asp .shtml .sh .cgi .rb .tcl Options -ExecCGI Die Ausführung von Skripten so zu verhindern scheint sicherer zu sein, da Files und FilesMatch case sensitive sind.
[quote=“radox”]Noch ein paar Dateiendungen (Skripte). AddHandler cgi-script .php .php3 .php4 .php5 .phtml .pl .py .jsp .asp .shtml .sh .cgi .rb .tcl Options -ExecCGI Die Ausführung von Skripten so zu verhindern scheint sicherer zu sein, da Files und FilesMatch case sensitive sind.[/quote] Verhindert man damit aber nicht die Ausführung von PHP als CGI-Modul? Kann man das nicht auch so lösen?<files .php .php3 .php4 .php5 .phtml .pl .py .jsp .asp .shtml .sh .cgi .rb .tcl>
Order Deny,Allow
Deny from all
Die Anweisung soll ja in der .htaccess-Datei des Upload-Ordners stehen. Hab extra noch mal nachgeschaut. Das Problem mit Files ist, dass man z.B. ‚shell.Php‘ ausführen könnte. Aber ich glaube es gibt auch eine Möglichkeit das mit Files in der .htaccess zu erreichen (Groß-/Kleinschreibung zu ignorieren).
So, gerade noch mal nachgeschaut. Das müsste funktionieren. Groß-/Kleinschreibung egal (*.php, *.PhP). Evtl. kennt ja jemand noch weitere Dateiendungen? <filesmatch>
Deny from All
</filesmatch>
[quote=“radox”]So, gerade noch mal nachgeschaut. Das müsste funktionieren. Groß-/Kleinschreibung egal (*.php, *.PhP). Evtl. kennt ja jemand noch weitere Dateiendungen? <filesmatch>
Deny from All
</filesmatch>[/quote] Für “php” und “PhP” funktioniert es schon mal…