DrupalCamp Essen 2015 - Security

Drop Guard Demo - 12:45 Uhr im Internetsofa

Daniel Andrisek — Sun, 25 Oct 2015 09:10:25 +0000

Wir machen eine Drop Guard Demo um 12:45 Uhr im Internetsofa Raum. Wir zeigen euch das Setup und wie ihr mit Drop Guard Updates durchführen könnt.

Sonstiges

Alle

Drop Guard, Security, Updates

NDA unterschrieben und dann Skype nutzen?

Stephan Luckow — Fri, 25 Sep 2015 17:34:54 +0000

Der gedankenlose Umgang mit bequemer, proprietärer, einfach installierbarer und weit verbreiterter Software ist nachvollziehbar. Doch sollten wir (also wir Internetauskenner) uns nicht viel stärker dafür einsetzen, dass unsere Kommunikationskanäle sichere Kommunikation sicherstellen können? Ich stelle einige Tools aus meiner Praxis vor, die die üblichen Kanäle ersetzen und berichte auf welcher Grundlage Entscheidungen für Softwaretools getroffen werden. Gerne ergänze ich die Toolsets um eure Erfahrungen.

Hinweis an die Orga: Sollte die Session auf Interesse stoßen und stattfinden, bitte ein Sessionslot ab mittags. Danke.

Diskussion

Alle

floss, Sicherheit, Security, kommunikation, tools

Drupal Updates automatisieren - Gut oder Böse?

Daniel Andrisek — Fri, 25 Sep 2015 11:22:11 +0000

Automatisierte Drupal Updates, speziell im Bereich Security, werden schon seit einiger Zeit auf Drupal.org diskutiert. Aktuell ist das „Auto Update Feature“ nicht im Drupal Core enthalten, da es nicht in den Entwicklungs- oder Deployment-Prozess integrierbar ist. Drupalgeddon hatte uns jedoch gezeigt, dass wir ein Update System benötigen, das flexibel und schnell auf solche hochkritischen Updates reagiert und unter besonderen Umständen eine Drupal Seite automatisiert updaten kann.
In meiner Session gehe ich auf die aktuelle Meinungen der Community zu diesem Thema ein. Dies wird die folgenden Punkte beinhalten:

- Was wurde bisher diskutiert und was spricht dafür und dagegen?
- Wie reagieren wir aktuell auf Updates?
- Welche Update-Typen gibt es überhaupt?
- Wie überlebe ich das nächste Drupalgeddon?
- Wie kann ein optimaler Workflow rund um Updates aussehen?
- Wie gehe ich mit gepatchten Modulen um?
- Wie kann ich ein Update testen?
- Welche Risiken gibt es bei automatisierten Updates?
- Welche Lösungen gibt es?
- Wie ist eure Meinung dazu und welche Erfahrungen habt ihr gesammelt?

Nach meiner Session möchte ich eine offene Diskussion mit euch starten und eure Fragen direkt beantworten. Diese Diskussion können wir in einer BOF weiterführen, falls die Zeit der Session nicht reicht.

Vortrag

Alle

Drupal Updates, Security, Diskussion, Best Practices

Anhang:

automatisierte_updates_-_gut_oder_boese-.pdf

Sichere Dateirechte: Wissen verbreiten und Provider überzeugen (Mitstreiter gesucht)

Carsten Logemann — Sat, 12 Sep 2015 09:11:24 +0000

Es gilt auf drupal.org als sinnvolle Sicherheitsmaßnahme, dem Webserver Schreibrechte nur in bestimmten Drupal-Ordnern (z.B. "files" und "tmp") zu geben und dort die Ausführung von PHP zu unterbinden. Leider gibt es in der Praxis massenhaft Drupal-Systeme, die nicht entsprechend abgesichert sind!
Insbesondere ist es nicht ratsam, daß der Webserver Drupal-PHP-Dateien modifizieren darf, da dies im Falle eines Einbruchs in ein System missbraucht werden kann. Des weiteren kann ein Hacker sonst Schadcode nachinstallieren und somit den Webserver z.B. in eine "SPAM-Schleuder" verwandeln. Dies war das Ziel von vielen massenhaften Angriffen im Zuge des als "Drupalgeddon" bekannt gewordenen Sicherheitsproblem (siehe Links unten), das leider zu oft von Erfolg der Hacker geprägt war.

Der Test "Safe file system permissions" des Moduls "Security Review" überprüft die Dateirechte und warnt bei schlechter Konfiguration. Ich habe mir zum Zeil gesetzt, diesen Test auf jedem Drupal-System "grün" zu bekommen. Zu diesem Zweck habe ich auf g.d.o die Gruppe "Safe file system permissions" gegründet.

Drupal Administratoren mit tiefer gehenden Konfigurationsrechten auf dem Webserver (Stichwort "Root"-Access) haben die Möglichkeit, den Empfehlungen ("Securing file permissions and ownership") zu folgen. Aber es gibt zu viele Webhosts, die von Providern als "Managed webspace" verwaltet werden, die Einschränkungen haben, ein Drupal System in der empfohlenen Weise sicher zu konfigurieren. Dies gilt auch für einige Provider, die ihre Produkte speziell für den betrieb von Drupal anpreisen. In diesem Sinne dient dieser Vortrag nicht nur der Information über die sichere Konfiguration, sondern auch der Suche nach Mitstreitern, evtl. mit Hilfe der Drupal Association und des Drupal e.V. in Deutschland, das Gespräch auch zu den großen Hostern zu suchen und diese Situation zu ändern.

Auf technischer Seite werde ich kurz aufzeigen, wie sich auch ein Apache/PHP FCGI-Setup mit Suexec (mit der Hoster oft den Kunden Projekte gegeneinander absichern ganz leicht auch mit zwei Systembenutzern und einer gemeinsamen-Gruppe gemäß der offiziellen Empfehlung auf drupal.org konfigurieren lässt. Da mir im Moment leider nur ein Positiv-Beispiel eines größeren Providers bekannt ist, kann ich nur eine Konfiguration in der Server-Veraltung dieses Providers (Hosteurope) zeigen. Daß dieser die nötige Einstellung nicht per Default konfiguriert, sollte man diesem nicht vorwerfen, da Webanwendungen sich sehr unterscheiden, an welchen Stellen, der Webserver Schreibrechte haben darf oder nicht. Ich kenne mich diesbezüglich auch nur mit Drupal aus.

Bis mir jemand ein sicheres Konzept zeigt, wie man eine Webanwendung sich selbst updaten lassen kann über den Webserver (und nicht mit drush über ssh zum Beispiel), ist diese Funktion mehr ein Bug als ein Feature für mich.

Weitere Links:

Vortrag

Alle

Security, Best Practice