Security & against Spam-Attacks
Eingetragen von firstlevel (519)am 19.05.2015 - 17:34 Uhr in
Moin,
was gibt es für Möglichkeiten drupal 7 so sicher wie möglich zu machen?
Nach dem leak aus 10/2014 hat man irgendwie, irgendwo Zugriff auf einen unserer Server erhalten und sich bilderbuchhaft durch unsere Systeme gehackt und infiziert was zu infizieren war. Nach dem wir alles gelöscht und neu gemacht haben, stellt sich jetzt die Frage, wie wir die immer noch versuchten Zugriffe (auch auf nicht mehr vorhandene Datein) irgendwie Herr werden können und drupal so gut wie möglich zu schützen.Bei wordpress gibt es out of the box Lösungen um überhaupt etwas dagegen zu setzen (iThemes Security z.B.)
- .htaccess ist bereits via root activ und versucht neben IP Adressen, Netze auch ganze Länder mittlerweile zu blocken (cn,ru,ua etc.)
- pw & datenbanke sind komplett neu, ebenso alle Datein im Webspace
- Modul: Login Security, badbehavior, cbp, security_review, diff&hacked, secure_permission
Was können wir noch tun? Gibt es Module die einen weiteren Schutz bieten ? Ideen in egal welcher Richtung ?
Danke für eure Hilfe, Tipps und Tricks
- Anmelden oder Registrieren um Kommentare zu schreiben
1, 2, 3 - Security. Und 4 und 5 ...
am 20.05.2015 - 00:56 Uhr
Das Thema wurde gerade im letzten Oktober hier mehrfach behandelt:
1. Server-Konfiguration
Gerade SQL-Injection-Angriffe profitieren von schlecht konfigurierten Servern. Das betrifft andere CMS wie Wordpress auch und lässt sich nicht mit Themes oder so abschalten. Ich bin hier im Forum regelmäßig darüber schockiert wie wenig viele Leute über Basics zum Server-Betrieb wissen und das trotzdem als Dienstleistung anbieten. Dummerweise gibt es kaum Managed Webspace der getrennte System-Benutzer anbietet, um dem Webserver und das heißt Drupal das Schreibrecht nur auf bestimmte geschützte Verzeichnisse wie TMP und Files-Ordner zu begrenzen. Aber da kann weder Drupal noch Wordpress oder andere CMS was für.
2. Sicherheits-Updates
Schnelles Einspielen notwendiger Updates sollte jedem bekannt sein. Bei der Lücke im letzten Oktober kam es auf Stunden an!
3. Zusätzliche Hilfen
Mit Tools wie Tiny-IDS kann man dann z.B. verdächtige Anfragen abwehren. Dann gibt es Module zur Zwei-Faktor-Authetifizierung und vieles mehr, was hilft.
4. Selbstreflexion
Aber ganz wichtig ist das Nachdenken über die eigen ganz konkrete Anwendung und welche sich sonst noch auf dem Server rumtreiben. Auch kleine PHP-Helfer zur Datenbank-Verwaltung können Sicherheitslücken aufreissen. Alle Funktionen abschalten, die nicht benötigt werden und vieles mehr. Auf meinen selbstverwalteten Servern gibt es z.B. weder PHP-Myadmin noch FTP-Zugriff.
5. Lesen, Ausprobieren, Recherchieren, Experten engagieren ...
# DrupalCenter-Moderator # Mitglied im Drupal e.V. # https://www.drupal.org/u/c_logemann
# CTO der Nodegard GmbH: Full Maintenance Service Provider | Web Application & Server | Security & Availability
Danke für Deine Anregungen
am 20.05.2015 - 09:20 Uhr
Danke für Deine Anregungen und Hilfe. Kannst Du uns ein/zwei Infos geben wo wir uns über die richtigen Schreibrechte im Bezug auf Verzeichnisse einlesen können ?
Drupal im Einsatz: Bachblueten-Ratgeber.de - Schuessler-Salze-Ratgeber.de - Tomaten24.de
coming soon: Selbstversorger.com - Bio-Lieferdienste.de
Das hängt von der Server-Konfig ab
am 20.05.2015 - 10:49 Uhr
Es gibt verschiedene Strategien PHP auf einem Server auszuführen. In den Default-Konfigurationen gibt es meistens einen allgemein server-benutzer wie z.B. "www-data". Diesem sollte man nur das Ausführen von PHP erlauben aber nicht die Veränderung der PHP-Dateien, damit bei ein Angriff kein Schadcode im system nachinstalliert werden kann, wie bei SQL-Injection dann versucht wird und auch klappt.
Einstieg ist hierfür die Seite "Securing file permissions and ownership".
Auf Servern, bei denen mehrere Hosts/Domains usw. betrieben werden konfigurieren die Hoster gerne (f)cgi/fpm-PHP-Konfigurationen, um die Projekte/Kunden voneinander zu trennen. Jeder virtuelle Host/Kunde hat einen eigenen Benutzer zum Ausführen der PHP-Dateien/Drupal.
Das ist im Grunde auch eine gute Sache, nur kann mit nur einem Benutzer nicht obige Strategie zur "Härtung" der Webanwendung genutzt werden. Das geht aber, in dem man dem Projekt/Kunde noch einen zweiten System-Benutzer erstellt. Den kann man vllt. "File-Owner" nennen und eben diesem die Datei-Besitzrechte geben und darüber z.B. per SSH einloggen und darüber Drush ausführen zum bequemen Update von Drupal.
Auf meinen selbst konfigurierten Servern mache ich das so und mir ist zur Zeit nur ein Hoster (Hosteurope) bekannt, bei dem man das im Managed Hosting auch so konfigurieren kann. Falls jemand da andere kennt würde mich das sehr interessieren.
# DrupalCenter-Moderator # Mitglied im Drupal e.V. # https://www.drupal.org/u/c_logemann
# CTO der Nodegard GmbH: Full Maintenance Service Provider | Web Application & Server | Security & Availability