 Dann legen wir jetzt weiter mit der zweiten Runde zum Thema WordPress Security oder WordPress Sicherheit, wie auch immer. Spielt so ein bisschen auch in das Thema vom Vorgänger mit rein, weil Thema Themes und so weiter ist immer auch ein Sicherheitsrelevantes Thema, gerade wenn das Thema entsprechend umfangreich ist und entsprechend viele Plugins mitbringt, dann macht es immer sich, er macht Sinn sich um das Thema Sicherheit dann auch zu kümmern. Kurz zu meiner kurzen Agenda, also ich wollte kurz die aktuelle Lage mal aufzeigen und bisschen so die Motivationen für den ganzen Lightning Talk begründen damit, dann eben kurz aufzeigen, wie man besten automatische Updates eben fährt, ohne eben die Sicherheit zu weit einzuschränken und eben dann einen kurzen anderes zum Thema Zugriffsbeschränkungen eben auf den üblichen Web-Service-System, in dem Fall eben Apache kurz aufzeigen. Die aktuelle Lage, also warum ist es überhaupt interessant, sich mit dem Thema Sicherheit zu beschäftigen? WordPress kommt auf 26 Prozent aller Internetseiten zum Einsatz, so zumindest eine Zahl, die von 4-W3-Text veröffentlicht wurde. Es ist oftmals so, dass WordPress mit HTTPS natürlich das Backend deutlich besser abgesichert wäre, wenn man das nicht macht, ist zum Beispiel das Problem gerade zu hier, man hat ein schönes öffentliches WLAN und hat dann aber das Problem, wenn jemand eben den ganzen Traffic mitschneidet, kann es eben zu kommen, was man eben entsprechende Benutzernahme und Passwort dann an seinen Angreifer mit übergibt, deswegen macht es auf jeden Fall Sinn eben das Backend, das WP Atman eben mit einem SSL-Zertifikat über HTTPS abzusichern. Auch gern genommen ist es immer mit einem Standard-Installer, gerade wie All Inkel und Co. eben anbieten, da gibt es dann immer den gleichen Benutzahmen, das ist dann sowas wie WP-Unterstrichatmen und wenn man dann noch aus Bequemlichkeit überall das Gleiche oder ein sehr einfaches Passwort verwendet, ist auch das Potenzial immer gefährlich. Und eben wie gerade angesprochen schon, wenn einfach zu viele Plugins und vor allen Dingen zu, genau wenn einfach zu viele Plugins und vor allen Dingen zu unterschiedliche Plugins, die eben alle irgendwelche Lücken aufreißen können, wenn man die integriert hat, ist es auch nicht ganz problematisch. Aktuell gerade in vielen Büros wahrscheinlich auch schon mal Thema gewesen, oder das heißt zumindest schon mal irgendwie aufgekommen, das Thema Ransom wäre, also die schöne Erpresser-Wage, wo halt jemand wieder ein Word-Dokument geöffnet hat, Word dann fragt, da ist ein Makro drin, willst du es wirklich öffnen? Und dann kommt halt sowas wie, ja, will ich. Und da heißt danach, so jetzt haben irgendwie alle Dateien Punkt Locky oder Punkt sonst irgendwelche Dateien und dann gibt es hoffentlich ein Backup von der IT oder die IT hat ein Problem, bzw. derjenigen hat auch eins. Das Ganze gibt es mittlerweile auch schon in einer coolen Version, nämlich dass es auch auf Web Server funktioniert. Also dann ist nicht nur die heimischen Daten eben verschlüsselt, sondern wenn es gut läuft oder wenn es in dem Fall schlecht läuft, ist auch der Web Server selber betroffen, das heißt, dann sind auch irgendwelche Datenbanken, verteilen, irgendwelche Skripte betroffen und dann kriegt man diesen netten Hinweisbildschirm, wo es dann eben heißt, du kannst das Geld zahlen, dann kriegst du unter Umständen, wenn es gut läuft, deine Daten wieder zurück, oder wenn du es irgendwie falsch machst, dann sind die Daten halt weg. Zum Beispiel dieser CTP-Locker heißt das Ganze und das eben schon aufgelistet, was ihr dann eben alles verschlüsselt und mit welchen super sichern Verschlüsselungsalgorithmus. Problem ist aktuell, man kann die Daten noch nicht wieder herstellen, vielleicht gibt es irgendwann mal ein Wiederherstellungstool, dann kommt man vielleicht wieder dran, aber in dem Fall absolut wichtig ist halt einfach ein regelmäßiges Backup zu machen, weil nur dann hat man die Daten am besten abgekapselt irgendwo eben sicher und kann sie eben im Notfall wieder herstellen. Auch interessant ist der aktuelle Fall Panama Papers & Co, also der Fall Mosktak von Secker. Hier ist das Problem, die hatten auf ihrer Hauptseite oder haben auf der Hauptseite zumindest bis vor ein paar Tagen noch eine Workforce- Installation gehabt und die hatte zwei gefährliche Plugins, zum einen einen Revolution Slider in der Version 217, weil man dazusagen muss, der Revolution Slider war bis zur Version 3.095, glaube ich angreifbar und scheinbar ist da länger nicht mehr aktualisiert worden und dementsprechend war es dann möglich, also ich habe auf der Seite, die unten eingeblendet ist, kann man sich so ein Video anschauen, wie man sich über das Plug-in eigentlich bequem zugriff zum Webster verschaffen kann. Ob jetzt das Ganze eigentlich dazu geführt hat, dass da irgendwelche Dokumente veröffentlicht wurden durch diesen Hack, das kann man nicht genau sagen, aber es sind auf jeden Fall mit dem Plug-in und auch mit dem WPS und TPP Plug-in zwei Einfallstore geschaffen worden, wo man eben Zugriffsdaten definitiv abgreifen kann und wo man auch Zugriffs zum Webster bekommen kann. Was ist so jetzt die Schlussfolgung aus dem Ganzen? Also natürlich immer die Gefahr durch veraltete Plug-ins, also wenn man feststellt, hey ich habe zum Plug-in im Einsatz gesetzt und seit einem Jahr nicht mehr aktualisiert worden, dann macht es definitiv, sich danach einen neuen Plug-in umzuschauen, weil ein Plug-in, was keine Updates nötigt, ist früher oder später immer mal ein Einfalltore für irgendwelche Angriffe und gerade wenn das Plug-in irgendwelche Zugriffsdaten wie jetzt eben von SMTP Server oder für andere Dienste verwaltet, sollte man da auf jeden Fall drauf schauen. Auch eben wichtig, dass man regelmäßig WordPress Updates installiert, die Security Fixes installiert und eben, wie gesagt, die nicht mehr gepflegten Plug-ins auf Dauer entfernt. Wie löse ich das ganze Problem? Also mit automatischen Updates. Das Problem ist, WordPress selber, der Core und die Plug-ins, wie gesagt, regelmäßig aktualisieren, das kann WordPress eigentlich selber. Mit dem Problem allerdings, dass wenn man WordPress sich automatisch aktualisieren lässt, muss man es entweder zulösen, dass man im relativ viele Schreibrechte einräumt, also dem Web Server oder eben einen FDP-Zugang hinterlegt. Letzteres sollte man sowieso nicht machen, weil FDP irgendwie gefühlt aus den 90er Jahren ist und eigentlich verlängend in den meisten Fällen ohne SSL und sonst irgendwas daherkommt und deswegen eigentlich keine gute Idee ist. Auch eben gerne genommen ist dann sowas wie, ja, ich wollte das Plug-in aktualisieren, da bringt jetzt eine Fehlermeldung. Jetzt habe ich den ganzen Einfach mal alle Rechte gegeben, also die üblichen 777, wo es natürlich im ersten Moment super ist, weil es funktioniert ja dann, was aber irgendwann halt doch mal wieder einem irgendwie zurückfallen kann, wo man dann eben merkt, so, ja, gut, jetzt habe ich ihm alle Rechte gegeben, jetzt konnte ich das Plug-in, was eine Sicherheitslücke hatte, halt auch alle anderen Daten von meinem Web Server eben lesen und schreiben oder wie auch immer. Dementsprechend ist es jetzt keine optimale Lösung. Wir haben uns jetzt bei uns überlegt, eben das Ganze über die ganz rechte Verwaltung zu machen. Das haben sich ja auch schon mal einige gehört, dass man eben die Rechte natürlich einstellen kann. Die Standardwerte sind meistens für ein Ordner eben 755, findet das High 644, was kurz aufgeschlüsselt heißt, mit beinahs 7 kann ich quasi lesen, schreiben und ausführen. Bei der Stufe oder bei dem Bit 6 kann ich quasi nur lesen und schreiben und bei der 4 eben nur lesen. Was jetzt wiederum heißt, wenn ich das Ganze im Live-System betreibe, sollte ich nach Möglichkeit eben sagen, okay, auf den Ordner muss ich die 755 setzen und das kriege ich Probleme beim Web Server. Auf der Teilen reicht es mir meistens, wenn wirklich alle nur lesen können. Also sowohl der Besitzer als auch der Web Server selber reicht es für die Produktivumgebung eigentlich aus mit Ausnahme von zwei Orten. Da komme ich später noch dazu. Im Update-Modus schalte ich dann darübergehend einfach mal alles auf lesen und schreiben. Das kann ich im Prinzip machen, das kann ich zwar auch noch einschränken, aber im Prinzip reicht es, weil es ja wirklich nur für einen ganz kurzen Moment ist und kann dann eben sagen, nur für die Zeit der Updates werden eben diese Rechte entsprechend gesetzt und man könnte es auch noch weitergehen und sagen, passt noch die Benutzer entsprechend an, wobei da eben die meisten Web-Hoster oder vor allem die Shared-Hoster sagen, das erlaube ich dir nicht bzw. nicht eben über die einfachen Wege, sondern nur über ein Web-FDP teilweise. Deswegen erst mal nur der Schritt 1, ich setze die Rechte. Generell gibt es bei ungefähr allen großen Shared-Hoster, also z.B. eben All-Inkle, Domain Factory, Strato, noch einfacher ist natürlich, wenn man den Server selber verwaltet, dann hat man einfach alles in der Hand und hat einfach mehr Möglichkeiten noch. Da bietet es eben an über Cronjobs oder eben über Jenkins, also über ein Continuous Integration System zu machen. Mein Ansatz also der, ich sage für den Update-Modus, setze ich einfach mal alle Lesen und Schreibrechte, sobald ich dann im Live-Modus bin, setze ich die Rechte eben so wie vorher angesprochen, plus ich räume eben in den Uploads-Ortener und in dem Cash-Ortener eben entsprechend mehr Rechte ein. Einfach damit ich eben Dateien problemlos hochladen kann, also gerade eben Bilddateien, dass ich eben nicht extra dafür in diesen Wartungs-Modus schalten muss. Das Ganze kann ich dann ausfinden, indem ich mit der WP-CLI arbeite, das ist also den Command-Line-Interface für WorkPest, das eben hier erlaubt, den Core zu aktualisieren, die Plugins und die Streams zu aktualisieren und dadurch muss ich ja nicht zwingend mich in mein Frontend einloggen, sondern kann das eigentlich begeben über die Konsole oder eben über ein entsprechendes Shell Script dann eben machen. Wenn ich dann alles ganz toll aktualisiert habe, kann ich gleich mal mit WP Scan nach einem Sicherheitscheck laufen lassen. Das habe ich bei der letzten WorkCamp mitgenommen, hat mir eigentlich ganz gut gefallen, weil das eigentlich ein echt praktisches Tool ist, um einfach mal schnell seine Installation zu checken. Der überprüft die Version und schaut eben nach, ob es entsprechend dafür vorliegende Sicherheitsmenge gibt und ob es eben generell ein Update gibt, wo man eben sieht, okay, ich habe jetzt die Version 2.0.7 und mittlerweile gibt es die 3.0, also sollte ich wieder mal aktualisieren. Genau, wenn ich das dann gemacht habe, sollte ich noch den nächsten Punkt gehen und meine zugesprächte generell im Web-Server noch ein bisschen beschränken. Das betrifft vor allem, was ich immer wieder mal auch gesehen habe, dass eben Leute in Apache hernehmen und dann aber die Unterverzeichnisse praktisch schlistbar machen. Das verhindern manche Installationen, indem sie einfach leere Dateien anlegen, dass einfach da nichts angezeigt wird. Im ungünstigeren Fall wird auch wirklich das der komplette Ordner aufgelistet und welche einzelnen Dateien da drin liegen, wo es natürlich nicht so toll ist, weil dann sind vielleicht auch Dateien drin, die man nicht unbedingt lesen sollen, was benutzt haben. Generell kann ich dann auch einschränken. Ich erlaube eben den Systemzugriff nur auf bestimmte Dateien, also eben auf PDF-Dateien, auf JPEGs und so weiter. Auch damit kann ich wieder verhindern, dass eben PAP-Dateien direkt aufgerufen werden können. Ich sollte generell meinen WP Admin-Lock-In schützen, weil auch das ist immer ein potenzielles Einfallstor. Wenn ich eben dann doch irgendwo eine Sicherheitslücke habe, kann ich somit zumindest verhindern, dass derjenige halt ins Backend reinkommt. Und dann würde ich eben auch noch gleich die Includesordner mit schützen, dass da eben auch von da aus eben keine externen Zugriffe drauf erfolgen können. Also auch da, dass der Benutzer einfach, wenn er das Verzeichnis aufruft, einfach eine Fehlerseite kriegt, wenn er das in Verbittenheit einfach sieht. Und letztendlich würde ich halt auch noch den Zugriff auf die WP-Config blockieren, weil auch die Datei sollte nach Möglichkeit nicht aufrufen werden, auch wenn natürlich eigentlich nichts Zimmers war, was die Datei quasi darstellbar macht, aber trotzdem kann man ja wieder über diverse Vorkehrungen, dann vielleicht sich doch Zugrifte der Datei dann verschaffen. Eine harte Exzesse-Datei braucht manch generell nicht aufrufen, die überliche Persie eben auch blockieren. Gut, nun mal grob zusammengefasst. Also Instagram soll ich am Webserver möglichst wenig Rechte geben, also so viel wie nötig, so wenig wie möglich. Ich sollte das Thema Updatebarkeit eben möglichst beides Seiten betrachten. Also auf der einen Seite natürlich je besser ich mein System updatee, desto sicherer sollte es werden, weil zumindest Sicherheitslücken geschlossen werden. Auf der anderen Seite ist natürlich eine Automatisierung immer auch irgendwie kritisch, weil auch da können sich erstens Fehler einschleusen, es können sich neue Sicherheitslücken einschleusen. Also muss einfach überlegen, was einem oder das Verein selber so der richtige Weg ist, aber generell gerade die Core-Updates kann man in den meisten Fällen eigentlich gut fahren. Auch da kann es natürlich passieren, dass irgendwie ein Steam sich damit irgendwie, wenn es schlecht programmiert ist, dann irgendwie Probleme macht, aber in den meisten Fällen läuft es dann eigentlich regelmäßig Backups erstellen, vor allen Dingen eben auch externe Backups und eben Datenbank nach einfach mal eine komplette Sicherung abspeichern, weil es ist halt doch immer wieder schlecht, wenn man dann am Ende feststellt, jetzt ist da gestern was passiert und man hat leider das letzte Backup vor über einem halben Jahr gemacht und da hat man aber jetzt so viel Zeit und Herzblut reingesteckt in seine schönen Beiträge und die sind dann jetzt alle weg. Und eben wie vorher schon angesprochen, wie ich die wirklich veraltete Plakines aktualisieren, ich habe bei mir auch irgendwann mal durchgeschaut und dann festgestellt, die kriegen bei Workpast dann auch irgendwann schon so eine Strecke Warnung. Achtung, das Plakine ist schon seit über einem Jahr, glaube ich, nicht mehr aktualisiert worden. Suche doch mal nach was Neuem. Und meistens gibt es immer für alles irgendwie ein Ersatz und dann sollte ich mir lieber mal eine schöne Alternative aussuchen. Genau, das wäre es von meiner Seite. Fragen und Anregungen gerne. Ja, die ist... Sollte es sogar gehen, wenn das bei Slicer funktioniert, dass ich den Link ab genau halb zwei verfügbar mache. Ist okay. Sonst noch irgendwelche Erfahrungen, die schon mal in dem Bereich gemacht wurden. Traut sich jetzt keiner, doch. Ja, es gibt vor allem auch genug Tutorials im Internet, die ist auch für alle möglichen Websiteuer beschreiben. Ja, man merkt es jetzt bei kleinen Privaten schon relativ schnell, dass man da eben mal ein Regel voll schiebt, dass dann eben alle möglichen Log-In-Versuche mit WP-Admin und allen möglichen Vornamen-Kombinationen eigentlich sehr schnell halt komplett wegbleiben kann. Ich habe jetzt gesagt, im Upload-Ordner gebe ich halt entsprechend mehr Rechte, dass man eben als Benutzer auch drinnen schreiben kann. Ne, das hatte ich, also das... Moment. Ah, genau, und hier ist halt statt dem T, müsste da noch... Ne, das passt genau, falls... Ja, also 6 für 4. Dass ich quasi schreiben kann. Ich habe es eigentlich ja schon mal ausprobiert, das hat eigentlich erstaunlich gut funktioniert, weil ich habe versucht die Rechte noch ein bisschen weiter runterzuschrauben. Irgendwann war dann der Punkt erreicht, wo der Webserver gesagt hat, okay, ich kann das Ganze verzeichnen, dass ich ihn verlesen. Das war immer ein bisschen zu viel Diskuten dann. Und eben noch besser ist halt eigentlich, wenn man das über den Benutzer macht, dass man eben auch wirklich den Benutzer eben spezifisch eben setzt, wenn man eben das Ding aktualisiert und danach eben den Benutzer wieder ändert oder das erlauben halt die meisten Shared-Hosting-Anbieter nicht. Ich habe bei All-Inkling mal nachgefragt, weil da kann man den Benutzer z.B. generell ändern, aber nur über den Web-FTP. Wenn man das über einen SSH-Script laufen lässt, dann gibt es dieses CHO einfach nicht. Und das werden sie wohl auch in Zukunft nicht so schnell implementieren. Deswegen muss man sich dann da an der Stelle ein bisschen behelfen, einfach. Ja, es ist ja vor allem auch immer das Problem. Wenn man wirklich jetzt da serverseitig eine Sicherheitslücke vorliegt, gerade jetzt auch bei All-Inkling, glaube ich, jetzt bei 50 Leuten mit auf dem Server oder sowas, da gibt es immer so Zahlen, je nachdem wie viel man dafür zahlt, desto weniger Leute werden es dann auf dem Server. Aber auch da ist natürlich so, wenn jetzt ein anderer Nutzer irgendwie eine Sicherheitslücke hat oder generell eben der ganze Web-Server irgendwie betroffen ist, dann bin ich immer damit drin. Da bin ich natürlich wirklich nur dann raus, wenn ich mit dem Server bei mir irgendwie hinstelle oder ins Rechenzentrum stelle. Dann kann ich das verhindern. Aber letztendlich ist Shared-Hosting immer so eine Sache. Es ist quasi eine gute Web-Präsenz eben aufzeigen zu können. Wenn ich wirklich das Ding perfekt sicher durchziehen will, dann muss ich es selber in die Hand nehmen. Das muss man dann abwägen, wo man sagt, okay, da sind jetzt wirklich solche Daten auf dem Web-Server drauf, die einfach auf gar keinen Fall irgendwie einen Umlauf kommen sollten. Wenn das jetzt mein privater Block ist, wo ich irgendwelche Fotos hochlad, dann ist es so kategoriell ja gut, dann ist es mein Pech. Aber klar, sobald irgendwelche Daten von Dritten mit involviert sind, sollte man auf jeden Fall drauf schauen. Vielen Dank.