Grundlagen der WordPress-Sicherheit

Dieser Beitrag richtet sich an WordPress-Webmaster, die ihre Webseite selbst erstellen und verwalten und sich um die Sicherheit ihrer WordPress-Installation Sorgen machen. Der Beitrag bietet einen -hoffentlich- verständlichen Überblick über die Grundlagen der Sicherheit einer WordPress-Installation sowie sinnvolle und weniger sinnvolle Maßnahmen, diese zu erreichen.

WordPress-Sicherheit: Was kann überhaupt passieren?

Zunächst benötigt ein Webmaster eine möglichst klare Vorstellung dessen, welchen Herausforderungen die Sicherheit einer Webseite überhaupt unterliegt. Welchen Nutzen kann ein Angreifer aus einer unsicheren Webseite ziehen?

Wenn eine Webseite einen gewissen Verbreitungsgrad erreicht hat, wird sie für eine illegitime Nutzung interessant. Grundsätzlich ist die Cyberkriminalität ein sehr lukrativer Zweig des organisierten Verbrechens mit weltweit und internetweit operierenden Banden und Spezialisten. Das betrifft die Sicherheit von Webseiten genau so wie die Sicherheit von Betriebssystemen und persönlichen Daten wie z.B. Logins für Konten.

Eine unsichere Webseite, die auf irgendeine Weise „gehackt“ wird, wie es der Internet-Volksmund nennt, kann auf vielfältige Weise missbraucht werden.

• Die Webseite kann selbst interessante Daten enthalten. Das können Datenbanken mit Kundenlisten und -konten sein und vieles mehr, z.B. Geschäftsgeheimnisse.
• Die Webseite kann benutzt werden, um Spammails zu versenden, Angriffe auf andere Systeme zu unterstützen oder um sie automatisch Schadsoftware an Besucher verteilen zu lassen.
• Die Webseite kann als Versteck für illegale Daten dienen, z.B. Download von gecrackten Programmen oder verbotener Pornographie.
• Die Webseite kann zu Zwecken der Suchmaschinenbeeinflussung (Black Hat-SEO) missbraucht werden, indem sie auf betrügerische oder auch an sich legitime Inhalte im Internet wie Shops usw. verlinkt oder weiterleitet.
• Die Webseite kann auch einfach zerstört oder mit offensichtlichen Fremdinhalten gefüllt werden (Defacing), z.B. von Crackergruppen oder terroristischen Vereinigungen oder einfach im Zuge von Vandalismus gegen ein zufälliges und einfaches Ziel oder auch einen unliebsamen Konkurrenten.
• Die weitaus meisten Webseiten werden bei großen Hostern in virtuellen Servern zusammen mit Dutzenden weiteren Webseiten betrieben. Ein erfolgreicher Einbruch in eine Webseite kann durchaus auch ein Sicherheitsrisiko für andere Webseiten auf demselben Webserver bedeuten.

Es ist also offensichtlich wichtig, sich als Webmaster grundlegend mit Sicherheitsfragen zu beschäftigen.

Wie erfolgen Angriffe auf die Sicherheit einer Webseite?

Potentiell kann jede Webseite in den Fokus von Angriffen geraten. Tatsächlich ist das so normal und unvermeidbar, dass eine Webseite, die in keiner Weise angegriffen wird, mit Sicherheit ein erfolgloses Schattendasein ohne Besucher im Internet fristet. Angriffe „adeln“ eine Webseite gewissermaßen sogar: Wenn eine Webseite angegriffen wird, heißt das, dass sie im Internet bemerkbar geworden ist.

Die weitaus meisten Angriffe auf die Sicherheit einer Webseite sind keinerlei Grund zur Beunruhigung. Es handelt sich nicht um gezielte und dauerhafte Angriffe. Ebenso wie bei den meisten Angriffen auf Betriebssysteme (Schadsoftware) oder Kontodaten (Phishing) handelt es sich um massenhafte und automatisierte Versuche, einfache Sicherheitslücken auszunutzen. Die Vorstellung, dass da jemand irgendwo auf der Welt in einem dunklen Zimmer sitzt (womöglich mit einer ins Gesicht gezogenen Kapuze), und versucht, genau Ihre Webseite zu knacken, ist völlig abwegig. Es gibt 1,83 Milliarden Webseiten und 4,7 Milliarden Internet-Benutzer (Zahlen von hier). Um jede Webseite anzugreifen, benötigt man also Automatismen, die einfach unbeaufsichtigt versuchen, Webseiten zu knacken. Hierbei wird auf Effizienz geachtet: Angriffe erfolgen möglichst auf häufige und leicht auszunutzende Sicherheitslücken. Längst nicht jede Sicherheitslücke, die es in die einschlägigen Nachrichten schafft, ist auch leicht und effizient nutzbar und weit verbreitet. Dann lohnt es sich einfach nicht, sie auszunutzen.

Soweit es die Sicherheit von Webseiten mit WordPress oder einem anderen Content Management-System betrifft, ist es wichtig zu verstehen, dass solche Webseiten nicht einfach nur statische Erzeugnisse wie z.B. eine Seite in einer Illustrierten sind, sondern in der Regel das Ergebnis einer Programmierung darstellen, also tatsächlich eher Programme als Dokumente sind. WordPress-Webseiten bestehen z.B. aus einer Vielzahl von einzelnen PHP-Dateien. PHP ist eine Programmiersprache, die aus Inhalten, die in einer Datenbank gespeichert sind, sowie aus HTML- und CSS-Angaben die Webseite erstellt, die Sie im Browser sehen. Diese Webseite existiert nicht als festes Dokument, sondern wird beim Aufruf immer wieder neu generiert. Das können Sie bereits daran sehen, dass eine Seite oder ein Beitrag in WordPress, während Sie im Editor daran arbeiten, noch in keiner Weise so aussieht, wie die fertige Webseite später im Browser erscheint -anders, als dies z.B. bei einem Brief in einer Textverarbeitung der Fall ist. Tatsächlich erfassen Sie im Editor nur Daten, die in der Datenbank gespeichert werden, und erteilen einige Darstellungsanweisungen, indem Sie z.B. etwas als Überschrift, Absatz oder Liste anlegen oder vielleicht ein Wort als fett markieren.

Programme laufen auf einem Computer ab, so auch die Webseite: teils auf dem Server, der die Webseite bereitstellt, teils im Browser und damit dem Computer des Besuchers. Es ist möglich, solche Programme zu missbrauchen. Ein einfach zu verstehendes Beispiel: als die ersten Webseiten mit PHP aufkamen, wurden in PHP z.B. auch Formulare erstellt, die Besucher der Webseite ausfüllen und abschicken konnten. Wie immer, wenn eine neue Technologie aufkommt, gibt es Menschen, die nach Wegen suchen, diese zu missbrauchen. Im Falle früher Formulare war es häufig möglich, statt dort nur die gewünschten Texteingaben vorzunehmen, einfach weiteren PHP-Code einzugeben und auf diese Weise das Programm umzuschreiben. So war es oft z.B. möglich, ein Formular mit einem eingegebenen PHP-Fragment dazu zu missbrauchen, einen Anfragetext nicht nur an den Besitzer der Webseite, sondern gleich auch noch an Tausende andere Personen zu senden. Und der Anfragetext war dann meist eine Spam-Mitteilung, vielleicht mit Links auf weitere zwielichtige Angebote.

Versuche in dieser Richtung erleben Anbieter von Formularen bis heute. Wir bezeichnen das als Formularspam.

Gravierender ist es, wenn ein Bestandteil der Webseite unsicher programmiert ist. Das kann im Falle von WordPress neben dem System selbst insbesondere Plugins und Themes betreffen, mit denen man die Möglichkeiten von WordPress erweitert. Während WordPress als am weitesten verbreitetes Content Management System im Internet selbst ein sehr etabliertes Produkt ist, welches dementsprechend über eine erprobte Sicherheit verfügt, sind viele Plugins und Themes nicht unbedingt das Ergebnis sauberer Programmierung. Wenn nun in einem weit verbreiteten Plugin oder Theme eine leicht nutzbare Sicherheitslücke gefunden wird, wird diese sehr schnell sehr interessant für den Missbrauch. Binnen Kurzem werden massenhafte Angriffe auf solche Sicherheitslücken im gesamten Internet durchgeführt.

Das lässt sich sehr leicht beobachten, wenn man einen Blick auf die Fehler vom Typ 404 wirft, die auf einer Webseite im Laufe der Zeit entstehen. Z.B. enthält das von mir eingesetzte SEO-Plugin Rank Math eine Monitor-Funktion für 404-Fehler. Ein 404-Fehler entsteht immer dann, wenn über die Adresse der Webseite ein Aufruf erfolgt, der kein Ziel besitzt, weshalb er nicht bearbeitet werden kann. Im Rahmen des SEO-Plugins hat ein solcher Monitor die Aufgabe, Fehler in der internen Verlinkung sichtbar zu machen, aber als Nebenprodukt zeigt er auch haufenweise ins Leere laufende Angriffe.

Hier ein Auszug aus meinem 404-Monitor:

Die Sicherheit des Login-Bereichs

Im oberen Bereich sieht man sehr schön, dass versucht wurde, die Datei wp-login.php an verschiedenen Orten aufzurufen. Die oberen drei Versuche liegen jeweils nur eine Sekunde auseinander. Hier hat ein Bot, also ein Automatismus, nachgeschaut, ob er in den Unterverzeichnissen wp, blog und wordpress die Datei wp-login.php findet. Das ist ihm nicht gelungen, da diese Dateien dort nicht existieren oder deren Aufruf verboten ist, weshalb ein Error 404 entstanden ist, der in diesem Log aufgeführt ist.

Wird ein Weg zum Login gefunden, probieren solche Bots meist eine Kombination aus häufigen Benutzernamen wie admin oder tatsächlichen Benutzernamen der Webseite zusammen mit schwachen Passwörtern wie 123456 aus. Die tatsächlichen Benutzernamen lassen sich aus der Webseite auslesen, Listen mit schwachen und weit verbreiteten Passwörtern gibt es im Internet. Nach ein paar hoffentlich erfolglosen Versuchen gibt so ein Bot dann auf und sucht sich ein anderes Ziel.

Häufig greifen WordPress-Benutzer zu Methoden, den Login zu verstecken, damit solche Versuche ins Leere laufen; aber das tun sie ohnehin, wenn das verwendete Passwort nicht vollkommen unsicher ist. Da sich das Passwort nicht abnutzt, spielt es keine Rolle, ob es zu Angriffen auf den Login kommt oder nicht. Insbesondere Anfänger beunruhigen sich hier oft unnötig selbst, indem sie z.B. in einem Sicherheitsplugin eine Benachrichtigung einstellen, wenn erfolglose Loginversuche stattgefunden haben. Diese Benachrichtigungen sind völlig sinnlos und nerven nur. Wer über ein vernünftiges Passwort verfügt, kann bedenkenlos jegliche Angriffe auf seinen Login ignorieren. Gefahr droht hier höchstens aus Richtung des Phishings, dass also auf irgendeine Weise versucht wird, das korrekte Passwort direkt von dessen Besitzer in Erfahrung zu bringen.

Die Sicherheit von Plugins und Themes

Zwei weitere Aufrufe in der abgebildeten Liste betreffen die Plugins Ulisting und Super-Forms. Es handelt sich hierbei um existierende und legitime Plugins – allerdings setze ich keines von beiden ein. Hier wird (ebenfalls vermutlich von einem einzelnen Bot innerhalb von zwei Sekunden) geprüft, ob diese Plugins vorhanden sind. Möglicherweise wird sogar gleich versucht, eine darin enthaltene Lücke auszunutzen – der 404 Monitor ist hier so eingestellt, dass er Parameter des Aufrufs nicht speichert. Es wäre also möglich, dass der eigentliche Aufruf noch ein ? als Zeichen des Beginns einer Parameter-Abfolge enthielt, gefolgt von einem manipulierten Aufruf, der das Ziel hat, die Sicherheitslücke auszunutzen.

Laut der Webseite wpscan.com haben Versionen des Plugins Ulisting vor Versionsnummer 1.7 eine Sicherheitslücke, die unter anderem unautorisierte Datenbankeinträge und Kontenerstellung erlaubt. Das Datum der Einträge der Sicherheitslücke ist der 28.01.2021, ist also zum Zeitpunkt des Verfassens dieses Beitrags eine knappe Woche her. Offensichtlich wird diese Lücke bereits aktiv ausgenutzt. Laut wordpress.org wurde Ulisting vor zwei Wochen auf Version 1.7 aktualisiert.

Das zeigt vor allem eines: Es ist äußerst wichtig, Updates für WordPress, Plugins und Themes so schnell wie möglich bei Verfügbarkeit einzuspielen. Insbesondere dann, wenn es sich um Updates aus Sicherheitsgründen handelt, was in der Regel angegeben wird.

Eine weitere Maßnahme gegen die Ausnutzung solcher Sicherheitslücken kann in Firewall-Regeln liegen. Ein Beispiel für solche Regeln sind die 7G-Firewallregeln von Perishable Press. Es handelt sich um Regeln, die in die .htaccess-Datei des Servers eingetragen werden. Diese Regeln definieren unerlaubte Zugriffe auf URLs mit Parametern, die aufgrund dieser Definition verboten werden. Das klingt zunächst kompliziert, aber wichtig zum Verständnis ist nur Folgendes: Wie oben bereits erwähnt, gibt es manipulierte Parameter-Abfolgen, die ein Angreifer an Webseitenadressen (eben URLs) anhängen könnte. Firewallregeln wie die genannten sind dazu da, derartige Aufrufe gleich unmöglich zu machen. Auf diese Weise können sie auch Angriffe verhindern, die noch nicht geschlossene Lücken ausnutzen. Auf der anderen Seite können bestimmte Lücken aber auch auf anderen Wegen genutzt werden, für welche die Firewall keine Bedeutung hat, so dass eine vorhandene Firewall nicht davon entbindet, Updates einzuspielen.

Firewallregeln sind Bestandteil vieler Sicherheitsplugins, so dass man sie nicht manuell eintragen muss, und es gibt auch Application Level Firewalls wie Ninja Firewall, die solche Regeln als Anwendung vorgeschaltet vor WordPress umsetzen.

Weitere Sicherheitsmaßnahmen

Drei Maßnahmen zur Steigerung der Sicherheit einer WordPress-Webseite haben wir nun schon kennengelernt:

• Sichere Passwörter
• Zeitnahe Updates
• Implementation einer Firewall

Es gibt weitere Maßnahmen, die mehr oder weniger wichtig sind, und die ich hier aufführen möchte.

Backups

Die Mutter aller Sicherheitsmaßnahmen: Backups. Kein Backup, kein Mitleid. Bei Backups einer WordPress-Webseite ist zu beachten, dass es zwei unterschiedliche Elemente gibt, die es zu sichern gilt, nämlich zum einen die Dateien auf dem Webspace, zum anderen die Datenbank. Letztere kann sogar auf einem ganz anderen Computer liegen. Sie wird durch ein Backup der Dateien auf dem Webspace daher nicht mit gesichert.

Es gibt viele Plugins für die automatisierte Sicherung von WordPress. Es ist besonders wichtig, dass ein Backup nicht nur auf dem Webspace selbst gespeichert wird, sondern auch außerhalb davon, z.B. auf einem Cloudspeicher. Sollte es jemandem gelingen, den Webspace zu kompromittieren, könnte ein dort vorhandenes Backup ebenfalls kompromittiert werden.

Unbenutztes deinstallieren

Gerade beim Auf- oder Umbau einer WordPress-Webseite installiert man möglicherweise viele unterschiedliche Themes und Plugins, die man schließlich doch nicht benötigt. Solche Elemente sollten unbedingt deinstalliert werden. Selbst nicht aktive, jedoch installierte Themes oder Plugins können über Sicherheitslücken angreifbar sein. Wer besonders gründlich sein will, kann per FTP-Zugriff auf den Webspace prüfen, ob die Dateien der Themes und Plugins tatsächlich gelöscht wurden.

Manche Plugins sind nur vorübergehend notwendig, z.B. Generatoren für Child Themes oder Importtools für Webseitenvorlagen. Auch solche Plugins sollten nach Gebrauch entfernt werden.

Ganz besonders wichtig ist es, ggfs. verwendete externe Skripte zur Bearbeitung der Datenbank umgehend zu entfernen. Sehr beliebt ist z.B. das Datenbank-Bearbeitungsskript von Interconnect/IT, welches dazu dient, Einträge in der Datenbank durch andere zu ersetzen. Dieses Skript wird üblicherweise per FTP in die WordPress-Installation auf dem Webspace kopiert und dort aufgerufen. Würde man es nach der Benutzung dort belassen (wovor der Hersteller ausdrücklich und umfassend warnt), könnte ein Außenstehender dieses Skript ohne Schwierigkeiten benutzen, um Änderungen an der Datenbank vorzunehmen. Zum Beispiel kann er einen neuen Benutzer anlegen.

Dass das ein ernstes Risiko ist, zeigt die Tatsache, dass Error404-Monitore wie der oben beschriebene Aufrufe solcher Skripte fast täglich aufzeichnen:

Ich würde sogar empfehlen, das Skript für den Zeitraum der Benutzung in einem Verzeichnis mit einem selbst gewählten und nicht sprechenden Namen zu speichern, keinesfalls in z.B. /search-replace-db, wie es im Bild an dritter Stelle ausprobiert wird. Es ist nicht unmöglich, dass solch ein Versuch ausgerechnet in dem Moment stattfindet, in dem Sie das Skript benutzen.

Alternativ gibt es diese Funktion der Bearbeitung der Datenbank übrigens auch als Plugin „Better Search Replace“. Auch dieses Plugin sollte nach Gebrauch deinstalliert werden.

Sicherheits-Plugins

Es gibt zahlreiche Sicherheits-Plugins für WordPress. Manche erfüllen eine bestimmte Aufgabe, z.B. das (weitgehend sinnlose) Verstecken des Logins, andere sind umfassende Suiten mit vielen Aufgaben. Grundsätzlich gilt, dass viele der gebotenen Funktionen nur wenig bis gar keinen sinnvollen Nutzen haben. Man kann sich dagegen bei unaufmerksamer Benutzung auch selbst aus seiner Webseite ausschließen oder sich durch Rückmeldungen der Plugins per Mail vollends verunsichern lassen. Auf keinen Fall ersetzen solche Plugins die bisher genannten Maßnahmen, und es reicht auch nicht, ein Sicherheitsplugin zu installieren und sich dann in Sicherheit zu wähnen. Sicherheitsplugins erfordern umfangreiche Einstellungen und ein grundlegendes Verständnis für die Sicherheitsproblematik, wie es dieser Beitrag vermitteln will. Zu guter Letzt kann auch ein Sicherheitsplugin selbst zu einer Sicherheitslücke werden. Im Gegensatz zu allen oben aufgeführten Maßnahmen halte ich zusätzliche Sicherheitsplugins nicht für essentiell.

Vor allem warne ich davor, die Binsenweisheit, man brauche einen Virenscanner, aus der Realität des Windows-Betriebssystems (und nur dort) in die Welt der Webseiten zu übertragen. Schadsoftware im eigentlichen Sinne stellt nur einen winzigen Bruchteil der tatsächlichen Gefahren dar, und es gibt so gut wie nichts, wonach Virenscanner scannen könnten.

Es gibt jedoch einige Plugins, die Sicherheitsmaßnahmen sinnvoll unterstützen, auch wenn sie selbst nicht im eigentlichen Sinne zu den Sicherheitsplugins zählen. Davon möchte ich schließend einige erwähnen, die ich selbst häufig verwende:

• Antispam Bee: ein Plugin gegen Kommentarspam, das im Gegensatz zu dem im Lieferumfang von WordPress befindlichen Akismet DSGVO-tauglich benutzt werden kann.
• Honeypot für Contact Form 7: im Gegensatz zu Recaptcha von Google und ähnlichen Stolperfallen für Bots, die entweder lästig sind (Matheaufgaben, Suchbildchen, Klickfeld „Ich bin kein Roboter“) oder nicht DSGVO-tauglich sind (Recaptcha 3 beobachtet das Verhalten des Benutzers auf der gesamten Webseite, um ihn als Mensch zu identifizieren), erweitert dieses Plugin für das beliebte Formular-Plugin Contact Form 7 die Formulare um Honeypot-Felder. Das sind Felder, denen man einen möglichst interessanten Namen gibt (z.B. „website“, „email“), so dass ein Bot sie ausfüllen würde, die aber in einem Browser gar nicht angezeigt werden. Sobald ein solches Feld einen Inhalt besitzt, sendet das Formular-Plugin den Formularinhalt gar nicht erst ab, weil er von einem Bot stammen muss. Es empfiehlt sich, gleich zwei oder drei Honeypotfelder zu definieren, und falls doch mal Spam durchkommt, kann man schnell ein weiteres hinzufügen.
• Mail on Update: Dieses Plugin prüft regelmäßig, ob es für eines der anderen installierten Plugins ein Update gibt, und sendet dann eine E-Mail an definierte Adressaten. Leider beobachtet das Plugin Themes und WordPress selbst nicht in gleicher Weise, um diese muss man sich weiterhin selbst kümmern.
• Vendi Abandoned Plugin Check: dieses Plugin prüft sämtliche installierten Plugins (aber ebenfalls weder WordPress noch Themes) darauf, wann es zuletzt ein Update gab. Es trägt die Zeit seit dem letzten Update in die Auflistung der Plugins ein und hebt die Zeit dort rot hervor, wo bereits ein Jahr oder mehr seit dem letzten Update vergangen ist. Bei solchen Plugins ist die Wahrscheinlichkeit hoch, dass dass keine Wartung mehr erfolgt, so dass darin entdeckte Sicherheitslücken oder auch technische Änderungen an WordPress selbst zu Problemen führen könnten. Schon vor der Installation von Plugins hebt dieses Plugin zudem auch in der Auflistung der verfügbaren Plugins solche rot hervor, die lange keine Updates erfahren haben, bevor man sie überhaupt installiert.
• wpscan: Dieses Plugin erfordert eine kostenlose Registrierung auf der gleichnamigen Webseite zum Anlegen eines Tokens. Das Plugin ermöglicht eine automatisierte Abfrage der Datenbank von wpscan.com anhand der aktuellen WordPress-Version und der Versionen der installierten Plugins und Themes. Die kostenlose Version erlaubt 25 Abfragen täglich. Man kann im Plugin definieren, welche Elemente nicht abgefragt werden sollen, falls man mehr Plugins und Themes hat oder man öfter als einmal täglich abfragen will. Natürlich kann man auch einen der bezahlten Pläne wählen, um mehr tägliche Zugriffe zu erhalten. Auch manuelle und einzelne Scans sind möglich. Das Plugin sendet eine Mail, wenn man eine Adresse darin hinterlegt, sobald eine Sicherheitslücke bekannt wird. Auf diese Weise kann man ggfs. ein Plugin abschalten, solange sein Sicherheitsproblem noch nicht behoben wurde. Es ist besser, vorübergehend auf die Funktion des Plugins zu verzichten, als ein Risiko einzugehen.

Alle genannten Plugins sind kostenlos verfügbar. Wer kennt noch nützliche Plugins zur Verbesserung der Sicherheit? Die Kommentare stehen für Vorschläge und Beschreibungen offen.

Vorsicht bei automatisierten Updates

WordPress bietet schon seit längerem die Möglichkeit automatisierter Sicherheitsupdates für WordPress selbst. Dies betrifft Versionssprünge hinter dem zweiten Punkt, also z.B. von 5.5 auf 5.5.1, nicht aber von 5.5 auf 5.6. Diese Updates sind in der Regel technisch unbedenklich und können ruhig zeitnah und auch automatisiert eingespielt werden.

Anders sieht es aus bei der seit WordPress 5.5 eingeführten Funktion der automatischen Updates von Plugins. Diese (allerdings nicht alle) lassen sich einzeln für automatische Updates konfigurieren. Dies kann aber böse enden, wenn durch einen Fehler in dem unbeaufsichtigten und automatisch erneuerten Plugin die Funktion der Webseite beeinträchtigt wird. Ich habe selbst kürzlich erlebt, dass ein Plugin-Update im Zusammenspiel mit dem Vorhandensein eines bestimmten anderen Plugins dazu führte, dass die Webseite vollständig unbenutzbar wurde. Wenn ein solcher unerwünschter Effekt eines Updates unbemerkt bleibt, kann das gravierende Folgen haben. Daher rate ich von der Benutzung dieser Funktion außer in vorübergehenden Ausnahmefällen (z.B. während des Urlaubs) ab.

Zu guter Letzt: Mein Wartungsservice

Wenn Sie nach der Lektüre dieses Beitrags unsicher sind, ob Sie sich mit der Thematik der Sicherheit Ihrer WordPress-Seite wirklich eingehender auseinandersetzen möchten, biete ich Ihnen gerne meinen Wartungsservice für WordPress-Webseiten an. Für eine kleine Monatspauschale übernehme ich die Pflege Ihrer WordPress-Webseite inkl. Updates, Backups usw. wie oben beschrieben, so dass Sie Ihre Zeit mit Ihrem Kerngeschäft verbringen können, statt sich um Ihre Webseite zu kümmern.