Drupal Updates automatisieren - Gut oder Böse?

Hinweis der Redaktion

• #2: Als ich gesehen hatte, dass meine Session direkt nach dem Mittagessen angesetzt ist, hatte ich die Beführchtung, dass nicht so viele den Weg hierher finden werden. Aber schön, dass ihr mich eines besseren belehrt!
• #3: Hallo an alle! Mein Name ist Daniel Andrisek, ich arbeite bei der Bright Solutions GmbH und heute möchte ich mich mit euch über Updates (vor allem in Drupal) sprechen. Wer von euch arbeitet mit Drupal um Webseiten zu erstellen? Wer von euch betreut Webseiten? Wer von euch hat Updates durchgeführt? Und wer von euch führt diese automatisiert durch?
• #4: Wer kennt das nicht, es ist Mittwoch Abend und der Sercurity Newsletler schickt einem die Info, dass ein Update für Chaos Tools zur Verfügung steht. Ihr würdet lieber in den Urlaub gehen jedoch beschäftigt euch der folgende Gedanke: Wie kritisches ist dieses Update überhaupt und muss ich es sofort machen?
• #5: Drupal Updates können wie folgt aufgeteilt werden: Normale Update, die zum Beispiel Bug Fixes oder neue Featuers enthalten oder Security Updates. Security Updates werden in Risikostufen aufgeteilt Drupalgeddon war zum Beispiel ein Highly Critical Update. Das Drupal Core Update diese Woche war less critical. Weiß jemand von euch wie viele Risikostufen es gibt?
• #6: 5 ist korrekt! Die Einstufung der Risikolevel erfolgt durch das Drupal Security Team. Jeden Mittwoch werden sogenannte Security Advisories verschickt, die die neusten Sicherheitsupdates beinhalten. Das Security Team besteht aktuell aus 39 ausgewählten Mitgliedern der Drupal Community. Ihre Aufgabe ist es Security Issues zu reviewen, die Maintainer zu informieren und sollte dieser nicht reagieren, das Modul auf unsupported zu setzen. Nach dem Release des Updates geben Sie die Information an uns weiter. Ein jeder kann also helfen, in dem er potentielle Sicherheitslücken an das Security Team meldet. Falls ihr euch denkt: “Das gefällt mir, dass will ich auch machen!”dann schaut euch bitte die Links in den Quellen an. Übrigens das Risikolevel wird nach unterschiedlichen Metriken definiert. https://www.drupal.org/security-team/risk-levels Code Metric Description AC Access complexity How difficult is it for the attacker to leverage the vulnerability? AC:None = None (user visits page) +4 points AC:Basic = Basic or routine (user must follow specific path) +2 points AC:Complex = Complex or highly specific (multi-step, unintuitive process with high number of dependencies) +1 point A Authentication What privilege level is required for an exploit to be successful? A:None = None (all/anonymous users) +4 points A:User = User-level access (basic/commonly assigned permissions) +2 points A:Admin = Administrator (broad permissions required where 'restrict access' is set to false) +1 point CI Confidentiality impact Does this vulnerability cause non-public data to be accessible? CI:All = All non-public data is accessible +5 points CI:Some = Certain non-public data is released +3 points CI:None = No confidentiality impact +0 points II Integrity impact Can this exploit allow system data (or data handled by the system) to be compromised? II:All = All data can be modified or deleted +5 points II:Some = Some data can be modified +3 points II:None = Data integrity remains intact +0 points E Exploit (Zero-day impact) Does a known exploit exist? E:Exploit = Exploit exists (documented or deployed exploit code already in the wild) +3 points E:Proof = Proof of concept exists (documented methods for developing exploit exist in the wild) +2 points E:Theoretical = Theoretical or white-hat (no public exploit code or documentation on development exists) +1 point TD Target distribution What percentage of users are affected? TD:All = All module configurations are exploitable TD:Default = Default or common module configurations are exploitable, but a config change can disable the exploit TD:Uncommon = Only uncommon module configurations are exploitable
• #7: Anbei ein Beispiel dazu: Je nach Auswahl ist ein Wert zum Risikofaktor hinzugefügt. Wenn ihr ein Hinweis über Twitter oder über ein PSA erhaltet wird oft eine Zahl beim Update dabei stehen. Die Skala geht bis 25. scores between 0 and 4 are considered Not Critical 5 to 9 is considered Less Critical 10 to 14 is considered Moderately Critical 15 to 19 is considered Critical 20 to 25 is considered Highly Critical
• #8: Wem sagt dieses Datum etwas? Korrekt! Es ist das Datum, als das Drupal Core Update 7.32 veröffentlicht wurde. Einigen von euch ist dieses Datum auch als Drupalgeddon bekannt. Über eine SQL Injection Lücke konnte ein direkter Zugriff auf den Server und somit auf die Seite durchgeführt werden. Nach der Veröffentlich der PSA an diesem Datum gingen kurz darauf systemtische Attacken auf Drupal Seiten los. Dies führte dazu, dass Webseiten, die nicht innerhalb von 7 Stunden geupdatet worden sind, als kompomitiert anzusehen waren. Zwar wurde empfohlen den ganzen Core upzudaten, aber es wurde auch ein Patch zur Verfügung gestellt. Dieser Patch änderte eine Zeile Code. Selbst der Maintenance Mode war nicht ausreichend, da die Seite von dort aus auch gehackt werden konnte. Wie wurde dieses Update gefunden? Durch ein Security Audit der Firma Sektion Eins aus Deutschland. Das Security Team wurde schon in der dritten Septemberwoche über dieses Update informiert. Hatte sich jedoch erst Mitte Oktober zur Veröffentlichung ausgewählt, weil Ende September die DrupalCon in Amsterdam war und viele Unternehmen somit nicht in der Lage gewesen wären das Update direkt durchzuführen. Zu diesem Update wurde auch eine FAQ vom Security Team veröffentlicht. Den Link dazu findet ihr in den Quellen. Diese FAQ hat sehr viele Kommentare, die sie zum Beispiel mit der Suche nach schadhaften Code oder aber auch automatisierten Updates beschäftigen.
• #9: Zuerst einmal: Wer von euch macht automatisierte Updates? Sehr schön! Und wie? Für die anderen: Wie macht ihr eure Updates? Genau! Karsten! Erzähl doch mal kurz wie du die Updates machst? Alles klar! Danke. Noch jemand? Ah du gehst einen anderen Weg verstehe.. Dieses Beispiel kann ich hier weiter und weiter führen und es spiegelt auch die aktuelle Meinung der Community wieder. Auf der Drupal Con hatte ich die Gelegenheit mit vielen Leuten über Ihre Art und Weise, wie Sie updates durchführen zu reden. Dabei kam vom FTP Upload, bis hin zu automatisiert über Drush alles zum Vorschein und ich glaube genau das macht auch die Diskussion über ein Auto Update Feature so kompliziert. Aktuell gibt es in Drupal keine automatisierten Updates. Viele sind der Meinung: “Automatische Updates sind gefährlich, weil die Seite kaputt machen können.” Ein sauberer Update prozess benötigt zuerst ein Test auf dem dev, danach wird es deployed Nach dem Drupalgeddon haben Sicherheitsexperten von Sophos angemerkt, dass diese Sicherheitslücke schockierend war und die Ankündigung zu einer ungünstigen Zeit kam,. Was Drupal bitter benötigt ist ein Auto Update Feature zum ausrollen von Sicherheitsupdates”. Und genau das Thema wird immer wieder in Diskussionen aufgegriffen und unterschiedlich gewichtet.In den Quellen habe ich einen Link zu einer solchen Diskussion angehänght. Diese Diskussion ist von 2009, verstummte und nach Drupalgeddon gab es hier nochmal einen gehörigen Schub. Aus dem Standpunkt der technisch nicht so versierten User ist ein Auto Update für hochkritische Fixes gewünscht. Andere wollen dies verhindern, da Sie sagen, dass ein automatisches Update eine Fülle an neuen Risiken mit sich zieht, wie z.B. das Drupal hier keine Rechte zum Schreiben bekommen sollte oder was passiert, wenn ein Update als Auto Update gekennzeichnet wird, es aber schadhaften code beinhaltet? Lösungsanätze wurden bisher vorgeschlagen und diskutiert, aber eine richtige Marschroute gibt es noch nicht. Auf die Lösungsansätze möchte ich später nochmal zu sprechen kommen. Doch schauen wir zuerst über den Tellerrand.. wie machen es andere Systeme aktuell?
• #10: Ich habe mich einmal in den anderen CMS System umgeschaut und auf den jeweiligen Seiten nachgelesen, welches Update Feature Sie anbieten: Contao: Live - Update Funktion für 10 EUR im Jahr pro ID Wordpress: Autoupdate seit 3.7. Jeweils konfigurierbar für: Core, Plugin, Themes und Sprachdateien Typo3 : Hat einen Automatic Core Update seit der Version 6.2 Joomla: Angeblich seit der Version 2.5 Todo: Logo Joomla ändern
• #11: Was gibt es allgemein bei Updates zu beachten?
• #12: Core und Contrib:
• #13: Mit welchen Lösungen können wir aktuell schon arbeiten.
• #14: Sobald wir ein Update durchführen, sollten wir dieses Testen und nach einem positivien Testergebnis erfolgt das Deployment auf unsere Live Umgebung.
• #15: Oft sieht ein Security Worklow aber so aus: Erstmal das Update durchführen. Lieber fixe ich eine kaputte Seite als mehrere Wochen danach noch nach schadhafte, Code zu suchen. Ein erstes Tool das uns bei Updates unterstützt ist der Hoster:
• #16: Acquia: Benötigt “clean” core und contrib, nutzt Drush https://docs.acquia.com/ra/automation, erstellt ein Commit pro Update, entdeckt keine patches, kein support für distris Pantheon: Update Automation? Platform.sh?
• #17: Drush: Durch drush können Updates schnell durchgeführt werden Drupal Monitor: Ein Modul um die Übersicht der Webseiten zu bewahren und zu schauen, ob Updates benötigt werden. Drupal Update Manger: Der im Core enthaltene Update Manager kann auch per Knopfdruck Updates durchführen (per FTP). DruDesk: Support nach Stunde Drupal Aid: montly module updates Drupal Console: Schaut euch die Sessions
• #19: Wer von euch hier kennt Drop Guard? Sehr schon, nicht alle Hände sind oben also möchte ich die Gelegenheit dazu nutzen euch ein paar Features von Drop Guard vorzustellen. Drop Guard wurde von uns, also Bright Solutions, für euch, also Agenturen und Dienstleister, die mit Drupal arbeiten, entwickelt. Ein weiteres Ziel war es, dass wir Drupal vor solcher negativen Presse oder auch Kundenmeinungen, wie wir es zu Drupalgeddon hatten, schützen. Wie Ihr gesehen habt gibt es aktuell schon eine Vielzahl an Lösungen und Tools, die wir für unseren Update Workflow einsetzen. Wir wollen diese Palette um ein weiteres Tool erweitern, dass flexibel auf euren Worklow anpassbar ist. Ihr könnt euch Drop Guard als ein Event Management System für Updates vorstellen, ähnlich Rules. Unser flexibler Ansatz beinhaltet die Möglichkeit, dass ihr pro Update Typ , also pro Risikostufe, definieren könnt, was passieren soll. Soll bei normalen Updates nur der Dev Branch geupdatet werden? Oder soll bei Sicherheitsupdats, der Stage Branch geupdatet und danach der Stage Server gebuilded werden? Das könnt ihr einstellen, wie ihr wollt. Ihr könnt Drop Guard entweder einsetzen um eure Webseiten zu Überwachen und danach manuell die Updates durchführen, oder Ihr könnt in Eure CI integrieren und nach dem Updaten zum Beispiel ein Deployment triggern oder einen Test aufrufen. Drop Guard ist herbei an keinen Hoster gebunden, jedoch muss ein Git Repository zu eurem Projekt vorliegen, damit ihr es einsetzen. Drop Guard erkennt Patches beim Updaten eurer Module und versucht diese nach dem Update erneut einzuspielen. Zusätzlich könnt ihr mit Drop Guard Distributionen updaten und unterschiedliche Update Modi für die Distribution einstellen. Richtig konfiguriert könnt ihr Drop Guard wie ein weiteres Teammitglied betrachten: Er kümmert sich um die Update, ohne euren Workflow zu brechen. Nur das er auch gerne noch Nachts arbeitet, während Ihr Feierabend oder sogar im Urlaub seid. Wer mehr über Drop Guard erfahren will, kann gerne nach der Präsentation zu mir kommen. Unser Service befindet sich aktuell noch in der geschlossenen Beta und wir suchen noch einige Tester.
• #21: One last thing: Drupal 8. Wie euch vorhint schon gesagt hatte wurden für Drupal 8 weitere Lösungsansätze für Auto Updates diskutiert. Diese beinhalten von einem Emergency Shutdown der Seite bis hin zu einem Vorschlag, dass Updates erst dann automatisert durchgeführt werden sollen, wenn mindestens drei Personen im Security Team das Flag für Auto Update gesetzt oder es nur ein Update nach Risikostufe geben wird. Der Task ist zumindest aktuell postponed, da erst allgemein das Problem gelöst werden muss, dass Drupal sich selbst den Core updaten kann.
• #24: Linkliste optimieren