Startseite
  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche
Startseite › Forum › Drupalcenter.de › Module ›

Security & against Spam-Attacks

Eingetragen von firstlevel (519)
am 19.05.2015 - 17:34 Uhr in
  • Module
  • Drupal 7.x

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

‹ [gelöst] PHP Modul verursacht Fehlermeldung Security & against Spam-Attacks ›
  • Anmelden oder Registrieren um Kommentare zu schreiben

1, 2, 3 - Security. Und 4 und 5 ...

Eingetragen von C_Logemann (832)
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: CMS Security & Availability Operations / Wir unterstützen IT-Abteilungen, Agenturen und Freiberufler

  • Anmelden oder Registrieren um Kommentare zu schreiben

Danke für Deine Anregungen

Eingetragen von firstlevel (519)
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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Das hängt von der Server-Konfig ab

Eingetragen von C_Logemann (832)
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: CMS Security & Availability Operations / Wir unterstützen IT-Abteilungen, Agenturen und Freiberufler

  • Anmelden oder Registrieren um Kommentare zu schreiben

Benutzeranmeldung

  • Registrieren
  • Neues Passwort anfordern

Aktive Forenthemen

  • MariaDB 10.6
  • Entity Reference - Title Felder werden als Link angezeigt
  • Tokens werden in Viev als Link angezeigt
  • Drupal Website gestalten
  • [bug entdeckt & workaround gefunden] benutzerdefinierte Felder vom Userprofil tauchen ungefragt auch in den Forumtopics auf...
  • [gelöst] Mass contact Empfängerliste nach Taxonomy Term statt Rolle
  • Update V. 9.3.12 auf V. 9.4 mit Fehler: Modul mySQL fehlt. Bitte Hilfe.
  • Sprachpfad, in Drupal Korrekt einstellen, auch bei den Meta-Tags
  • Update von Drupal 9.3 auf 9.4 oder bei 9.3 bleiben
  • Terminverwaltung
  • Views in Seite einbetten
  • Hilfe! Nach Update auf 7.90 zeigt User reference (Kontrollkästchen/Auswahlknöpfe) nicht mehr vollständig an
Weiter

Neue Kommentare

  • Ah, ok. Wenn es ein Paragraph
    vor 23 Stunden 20 Minuten
  • Also kleiner Nachtrag noch:
    vor 1 Tag 9 Minuten
  • In der View gibt es einen
    vor 1 Tag 2 Stunden
  • Kann ich euch gerne mit
    vor 1 Tag 14 Stunden
  • ursache gefunden
    vor 2 Tagen 2 Stunden
  • nun wirds erst richtig lustig...
    vor 2 Tagen 2 Stunden
  • ursache weiter eingegrenzt
    vor 2 Tagen 7 Stunden
  • Nein, das war es nicht. S. o.
    vor 5 Tagen 7 Stunden
  • Eventuell hier ein Hinweis?
    vor 5 Tagen 8 Stunden
  • Lösung gefunden
    vor 3 Tagen 18 Stunden

Statistik

Beiträge im Forum: 247854
Registrierte User: 19589

Neue User:

  • Tkakah
  • JeraldFub
  • andycrestodina

» Alle User anzeigen

User nach Punkten sortiert:
wla9212
stBorchert6003
quiptime4972
Tobias Bähr4019
bv3924
ronald3845
md3717
Thoor3678
Alexander Langer3416
Exterior2903
» User nach Punkten
Zur Zeit sind 0 User und 3 Gäste online.

Hauptmenü

  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche

Quicklinks I

  • Infos
  • Drupal Showcase
  • Installation
  • Update
  • Forum
  • Team
  • Verhaltensregeln

Quicklinks II

  • Drupal Jobs
  • FAQ
  • Drupal-Kochbuch
  • Best Practice - Drupal Sites - Guidelines
  • Drupal How To's

Quicklinks III

  • Tipps & Tricks
  • Drupal Theme System
  • Theme Handbuch
  • Leitfaden zur Entwicklung von Modulen

RSS & Twitter

  • Drupal Planet deutsch
  • RSS Feed News
  • RSS Feed Planet
  • Twitter Drupalcenter
Drupalcenter Team | Impressum & Datenschutz | Kontakt
Angetrieben von Drupal | Drupal is a registered trademark of Dries Buytaert.
Drupal Initiative - Drupal Association