1.) Die Attacken laufen ins Leere, entsprechend brauchst Du Dir überhaupt keine Gedanken machen. Kämen sie durch, hättest Du das bereits gemerkt
2.) Bringt eine .htaccess nur 30% Schutz und zwar über GET-Anfragen. POST und COOKIE sind damit immer noch außen vor. Je nach Verarbeitung durch Dein Script (REQUEST) kann eine POST-Anfrage auch GET Lücken ausnutzen bzw. viele Lücken sind direkt in POST, daher kein Schutz per .htaccess möglich. In Deinen Logfiles steht dann z.B. nur die Domain bzw. die Unterseite und "POST". Welche Daten gesendet wurden, kannst Du auf diese Art nicht in Erfahrung bringen.
3.) Jeder Filter bedeutet Last für Deinen Server. Der Zugriff selbst wird damit aber nicht verhindert, sondern nur geblockt. D.h. der Angriff steht nach wie vor in den Logfiles und der Webserver muss sie nach wie vor verarbeiten. Der Aufruf durch den Bot lädt keine Scripte und Bilder, daher blockt man mit der .htaccess einzig und alleine das Laden des HTML-Quelltextes.
Du kannst Dich nur schützen, wenn Du Deine Scripte frei von Fehlern hälst oder wenn Du bekannte Lücken vermeidest. D.h. Du erlaubst lokal keine Einbindung von externen Scripten:
php.ini:
allow_url_fopen = OFF
Unter Umständen funktionieren manche Scripte dadurch aber nicht mehr. Besonders wenn es dynamische Scripte sind, die bei Updates "nach Hause telefonieren". Ein Test wird Dir aber zeigen, ob es was bringt.
Du verhinderst die allgemeine Wandlung von URL-Parametern in Variablen:
php.ini:
register_globals = OFF
Du verhinderst den häufigsten Bug in PHP: Buffer-Overflow:
- Suhosin auf dem Server installieren
Fehlermeldungen vermeiden (machen Banken grundsätzlich so):
- SQL-Fehler nicht ausgeben (verrät Datenbankstruktur)
- PHP-Fehler nicht ausgeben (verrät Pfade)
Passwortdiebstahl vermeiden:
- niemals das gleiche Passwort auf anderen Seiten verwenden (das wird immer in Klarschrift an den Server übertragen und dann verschlüsselt, d.h. der Seitenbetreiber kann problemlos von jedem das Passwort in Klarschrift ermitteln, wenn er das wollte)
- Passwort entsprechend schwer machen und für Social Engineering unmöglich gestalten
Jetzt musst Du Dir nur noch Sorgen wg. Session Hijacking,
Internal File Inclusion, lokale Trojaner (FTP Passwort-Diebstahl), usw. machen
Im Grunde wollen Hacker übrigens "nur" die Userdatenbanken (Passwort und Emailadresse) oder Emails (Spam) versenden. Beides kann in Geld umgewandelt werden. Für uns heißt das:
- Emails in der Datenbank per Salt verschlüsseln (z.B. AES_ENCRYPT in MySQL)
- Passwörter per MD5 oder SHA und immer mit Salt verschlüsseln
- den Server vor einem direkten Zugriff schützen, d.h. Installation von Software unmöglich machen, Mail-Traffic beobachten bzw. getrennte Warnhinweise verfassen
Die besten Hacker sind übrigens die, die eine Lücke nicht publik machen und lange Zeit für eigene Zwecke missbrauchen. Im Fall von Ebay jahrelang passiert, nur nie wirklich publik gemacht. Ebay ist es aufgefallen, nachdem zu viele Hacker sich deswegen austauschten und Mitgliedsdaten verkauften bzw. einer sogar Screenshots vom Adminbereich ins Netz stellte. Ebay weiß es seitdem sie die Bieternamen in der Gebotsliste zensiert haben (falls ihr euch wundert, warum das gemacht wurde).
