WordPress aufräumen , ein nicht alltäglicher Bericht

Was für mich als ein kleiner Exkurs in dem Aufräumen meines Blogs begonnen hatte, wurde sehr schnell ein ungewollter ernüchternder Blick in WordPress als Software. Dieser nicht alltägliche Bericht hilft vielleicht ein wenig mehr auf die Sicherheit von WordPress zu achten, ohne mit Code und einer Anleitung zu winken zu müssen

Mein Neustart meines Weblogs geschah nicht nur aus ästhetischen Gründen.  Für mich war es wichtig diesen Schritt noch vor diesem Herbst zu gehen, eigentlich vor dem Release von WordPress 4.0. Leider brachte mir dieser Umzug nicht nur ein neues Theme von Oliver Gast ein, einem Entwickler den ich auch auf Grund der Kommunikation sehr schätze, sondern auch Einsichten, welche ich bei meiner Installation nicht erwartet hatte.

Whitepages

Im Laufe der Zeit sammelt sich ja so einiges in der Installation von WordPress an.
Bei mir war die vorhergehende Installation so aus dem Häusschen, dass ich des öfteren eine Whitepage präsentiert bekam. Auch die Webmaster Tools von Google meldeten mir den einen und anderen Fehler bei einem Seitenaufruf.
Ein entspanntes Schreiben der Blogartikel war nicht wirklich möglich.

Das schlimmste an dem berühmten und gefürchteten Whitepagefehler war, dass er auch bei dem Schreiben von Blogposts auftrat und mich schier zur Weißglut trieb. Weil der Browser nicht die Daten gespeichert hatte und teilweise auch nicht eine Revision vorlag. Man kann sich bestimmt vorstellen, welchen Spaß ich am schreiben hatte. Das schreiben in vim, mit anschließendem einfügen und reformatieren in den Editor von WordPress war nicht wirklich von Freude, geschweige Spaß beflügelt. Der Wahnsinn hatte mich dann aber  endgültig, als ich auch nach dem Ändern des Themes und dem Ausschalten aller Plugins von dem Fehler nicht verschont blieb.

Aber man kann ja bekanntlich auch den Fehler auf den Webhoster schieben. Ich machte ein Backup der Datenbank und verband mein Blog mit der Datenbank meines Rootservers. Ich möchte hier den Fehler aussschließen, dass die Verbindung zu dem DBMS meines Webhosters gestört hätte sein können. Leider brachte dies auch kein Ergebnis. Das berühmte Problem der „einfachen“ Nutzer traf mich. Ich wollte schreiben und mich nicht wieder einmal um ein Stück Software kümmern.
Entspannen und nicht basteln.

Ganz pedantisch habe ich natürlich auch das Schreiben des Logs für WordPress per wp-config.php eingeschaltet, aber auch dies brachte leider keine Auskunft. Ein Henne-Eiproblem, wenn ich keine Fehlermeldungen habe, kann ich auch nicht den Fehler einkreisen und Ihn beheben.

Ein Check per md5sum auf alle Dateien brachte mich auch nicht weiter. Hier werde ich aber in Zukunft auf git zurückgreifen und kann somit Änderungen an den Dateien nachvollziehen. git ersetzt kein Backup, aber erlaubt mir doch eine erweiterte Übersicht über Dateiänderungen.

Nach all diesen Tests war für mich klar, dass ich in einer Subdomain das Blog neu aufbaue und dann einfach den Eintrag des Webservers auf das neue Verzeichnis umbiege.

WordPress aufräumen

Am Anfang hatte ich für das Design eines neuen Themes mir ein Script für Docker gebaut, welches Debian Jessie inkl Nginx, MariaDB und der letzten erhältlichen Version von WordPress installiert. Somit habe ich nun Erfahrungen mit Docker gesammelt und ein schönes Theme erstellt, aber es am Schluss nun nicht genutzt und mich für ein anderes Theme entschieden und ein Childtheme gestellt.

Um WordPress aufzuräumen bin ich folgenden Liste für mich abgelaufen:

  1. Backup der Daten
  2. Für Plugins und sichere, sowie responsive Alternativen finden
  3. Neustrukturierung der Mediendatenbank

Backup und Import der Daten

Für das Backup habe ich per Werkzeuge > Daten exportieren > Alle Inhalte exportiert und ein Backup in form eines SQL-Files gemacht.

Daten exportieren in WordPress
Alle Post und Kommentare exportieren

Für die Mediendatenbank bin ich zwei Wege gegangen.
Ich habe den Import der XML-Datei ohne den Import der Bilder vorgenommen und dafür ein Plugin benutzt, welches meiner Meinung nach den Import der Mediendateien besser vornimmt Attachment Importer:

I found the WordPress Importer plugin is good for importing posts and comments, but is lacking when it comes to importing large attachments (like images) from large sites. My import would often time out and crash. I wrote this plugin to help with my own blog migrations, but I hope you find it useful too.

Attachment Importer ignoriert Dateien, welche den selben:

  • Namen
  • Dateinamen
  • Datum des Uploads
  • Dateigröße haben

Einige Dateien sind nicht importiert worden, da sie Altlasten aus Serendipity, Jekyll, oder Drupal waren. Diese wurden dann mit dem Plugin Add from Server nachgezogen. Hier muss beachtet werden, dass das Plugin nicht die schon vorhandenen Dateien beachtet und sie einfach nochmals importiert. Man sollte sich sicher sein, dass eine Datei nicht schon in der Mediendatenbank vorhanden ist.

Bevor ich dies aber gemacht habe, hatte ich nach einem Backup der Mediendatenbank alle extra erstellten Bildgrößen über die Shell gelöscht.

find . -name *-*x*.* -exec rm {} \;

 

Welche Mediendateien nach dem Import fehlten sagte mir eines meiner Stammplugins Broken Link Checker.
Es sollte in keiner Installation von WordPress fehlen. Zu viele Links kommen und gehen und leider lassen sich alle verbloggten nicht im Auge behalten.

Falls ein fehlerhafter Link gefunden wurde, bietet Broken Link Checker automatisch an, dass ein Link von Archive.org genommen wird. Falls dies nicht möglich ist, wird der Link nach einem eigens definierten Stil per CSS markiert und auf Wunsch herausgenommen.

Für das rekomprimieren der Bildgrößen habe ich das Plugin WP Smush.it genutzt. Hier muss auf jeden Fall bei einem Import unter Einstellungen > Medien > WP Smush.it der Punkt Use Smush.it on upload? auf Do not process on upload eingestellt sein.

Nach der Installation des Themes habe ich natürlich AJAX Thumbnail Rebuild für das neugenerieren der Bildergrößen genommen, welches bei mir ein wenig länger dauert, da das vorab gewählte Theme Minimaze responsive ist und Bildgrößen für die Endgeräte aktiv unterstützt. Hoffte ich ;)

WordPress AJAX Thumbnail Rebuild Alle Miniaturbilder neu erstellen
Ich hoffe wirklich, dass mein Theme Endgeräte mit den richtigen Bildgrößen versorgt

Verlassene Plugins und Themes

Es gibt Plugins, welche nachdem sie geschrieben wurden, eigentlich eine Grundlage der Nutzung von WordPress sein sollten. Ich finde sie gehören direkt in den Kern von WordPress. Das Plugin 404 Redirect wäre so ein Plugin für mich gewesen.

Das Plugin ist in meinen Augen sehr nützlich. Es kann automatische Weiterleitungen ( 301, 302 ) generieren und fängt 404-Error auf und trägt sie in ein Log ein. Es bietet dann die Option an selbst eine Weiterleitung anlegen. Wer es einmal genutzt hat, der möchte es nicht mehr missen.

Aber leider ist das Plugin ein Zombie, eine wandelnde Zeitbombe innerhalb meiner Installation gewesen.

Warum es immer noch nicht aus dem Verzeichnis seitens des Developers gelöscht wurde ist mir immer noch nicht ganz klar. Eigentlich sollte es aus dem Verzeichnis von WordPress verschwinden. Nach meinem Kommentar, bzw. nach der Aussage und Kontaktaufnahme von caseyfern ging ich davon aus. Es wird seit 2 Jahren nicht mehr aktiv betreut und sie haben auch nicht mehr vor es zu betreuen. Ich werde es vielleicht die Tage unter meine Fittiche nehmen und neu schreiben.

WordPress Support 404 redirected
Das Plugin ist leider immer noch vorhanden

 

Mir wäre nie seit der Installation bewusst gewesen, dass jenes Plugin nicht mehr in der aktiven Entwicklung ist. Nur durch den Fehler mit den Whitepages musste ich mich mit jedem Plugin einzeln befassen und war erschreckt, dass ich wirklich ein, zwei faule Eier in meiner Installation hatte.
Dies, obwohl ich doch immer so auf Sicherheit bedacht bin.

Ich befolge die Regeln

  • nutze die minimalste Anzahl von Plugins
  • nehme aktiv in der Entwicklung stehende Plugins
  • nehme nur Plugins aus dem Verzeichnis bei WordPress und nicht aus obskuren Quellen ( Nein, nicht einmal Github nehme ich)
  • Und validiere und installiere jedes Update

Auch versuchte ich eigentlich immer per functions.php in meinem Childtheme die von manchen Plugins gestellten Funktionen auf sichere Art und weise selbst zu erstellen. Was man natürlich nicht machen sollte, wie ich durch den Artikel Why You Shouldn’t Use functions.php (And What You Should Do Instead) von wpmudev lernte. Ich habe nun mein Minimum an, für mich wichtigen, Funktionen als Plugin.

Leider scheinen diese als best practices  gepriesenen Arbeitsabläufe doch nicht wirklich die letzte Weisheit zu sein.

Für mich bedeutet dies nun, ein Script zu erstellen, welche das Datum der Datei eines Plugins per Cron immer wieder checkt, wenn sich nach einem Jahr nichts getan hat, bekomme ich eine Mail mit dem Hinweis mal in das CVS des Plugins zu schauen.  Im Fazit habe ich dann mal eine Idee grafisch umgesetzt, wie wie WordPress dies selbst ändern könnte und auch müsste.

Wie es da an der Front für die Themes aussieht kann ich nicht wirklich sagen. Ich versuche nur Themes zu verwenden, welche eine gute Codebasis haben, gepflegt werden und wenn es geht direkt zu den Standardthemes von WordPress gehören. Das momentan genutzte Theme ist war/nur die Warteschleife für das Theme Twentyfifteen auf welches ich warte und dann mir zu Nutzen mache.

Ordnung in der Datenbank, neue und alte Plugins

Da nun durch eine Neuinstallation die Datenbank aufgeräumt ist, habe ich mich an die Suche nach Plugins gemacht, welche ich absolut brauche und alles nur noch auf ein Minimum beschränkt.

Nicht wirklich eine einfache Sache und ich hatte in dem Moment Glück, dass ich in den Verzug mit dem Blog aufräumen kam. Ich konnte anhand der Zeit zwischen dem Erscheinen der neuen WordPressversion und dem Update eines Plugins, sowie der Reaktionszeit auf Supportanfragen schauen, wer da seiner selbstgewählten Arbeit wirklich nach kommt.

Jeder SEO würde bei der Frequenz der Artikel, welche dadurch die letzten Monate erschienen aufschreien und mich für den Einbruch meiner CTR schütteln. Wie ein Nikotinsüchtiger den Zigarettenautomat, wenn jener seinen letzten Euro eingezogen hatte ohne die Ware zu liefern. Gott, ich meine das ist ein Hobby und Spaß und nicht ein… :)

Da stellt sich die Frage, wie denn da große Seiten reagieren und agieren können auf Grund dieser Situation. Ich frage mich, ob es dann bei den bezahlten Plugins auch mit solchen Problematiken belegt ist. Obwohl ich da gerne Sergej Müller, der Entwickler mehrer Plugins für WordPress und auch Herausgeber eines Newsletters, als positives Beispiel nehme. Es geht, wenn man möchte.

Bis auf 10 Plugins sind viele ausgetauscht worden und es laufen aktiv nun 22 Plugins die argwöhnisch von mir beobachtet werden.

Im Bereich Maintenance möchte ich das Plugin WP Maintenance Mode , welches mir in der Subdomain vor dem Umzug sehr geholfen, empfehlen.

  • Komplett Anpassbar betreffend Farben, Text, Hintergründe
  • Abonnementsfunktion, Emailadressen lassen sich als CSV-Datei exportieren
  • Countdown bis zu dem Neustart der Seite
  • Kontaktform für Besucheremails
  • Coming soon Seite
  • Landingpagetemplates
  • Multisitefähig
  • Responsive design
  • Social media Icons
  • Arbeitet mit jedem WordPressteheme
  • SEOOptions
  • URLs vom Maintenancemode ausschließen.
  • Maintenance nicht sichtbar für angemeldete Nutzer

WordPress und das Thema Sicherheit, kurze Daten, IMO

  1. WordPress ist sicher.
    Das ist Fakt. Im Grunde genau so Sicher wie die Software unter Debian GNU/Linux, ich beziehe mich hier spaßeshalber nun auf OpenSSL und BASH.
  2. Plugins und Themes in WordPress sind unsicher.
    Und auch das ist für mich genau so ein Fakt. Für mich eines der größten Probleme bei einer Installation von WordPress und eine Sache, welche mich zur Weißglut treibt. Timthumb, Caching Plugins die Credentials zum DBMS ausplaudern, Slideshowplugins usw usf
  3. Benutzer kümmern sich absolut nicht darum was Anleitung, Hinweise, wohlgemeinte Ratschläge bezüglich der Installation betrifft. Ich habe es schon mehrmals erlebt.

Punkt 1
WordPress selbst hat seit 2004 gerade einmal 183 mal ein Sicherheitsprobleme gehabt. Zum Vergleich Joomla mit 298 seit 2005 und Drupal mit 131 seit 2002. Drupal steht sehr Gut da, aber das Bloggen mit Drupal macht keinen Spaß. Probiert es einmal aus. Ich habe es im Laufe der Zeit dreimal versucht. Ist mal einen Spaß wert, so ein Versuch, wenn man zuviel Zeit hat. Somit kann man sagen, die Kernanwendung, das System WordPress an sich, ist sicher und das Unken über die Software ist eher in einen Bereich zu schieben, damit Jemand einen Grabenkrieg heraufbeschwören könnte. Ich weiß, jede PHP-Anwendung ist schlecht ;)
Man merkt, dass ich den oberen Satz vor dem Durpalgate geschrieben hatte, welches eine Reaktionszeit des Seitenbetreibers von maximal 5 Stunden für den Fix de jour forderte, oder seine Seite war komprimitiert.

Punkt 2
90% der Plugins in dem WordPressverzeichnis sind unter aller Kanone, welches den Code und die Sicherheit anbetrifft und zum Teil auch sehr schlecht gepflegt. Gerne würde ich die Schuld hier auf WordPress als Hoster der Plugins schieben und sagen, wer minimal seit einem Jahr sein Plugin, oder Theme, nicht einem Update unterzieht, der fliegt raus. Nur geht das leider nicht, denn viele Plugins sind sauber geschrieben und brauchen nur ein Update, wenn sich etwas an der Syntax von WordPress ändert. Dies gilt auch für Themes. Andere, faule und böse Individuen, könnten ja nur ein zwei Zeilen Code ändern und ausrufen, dass etwas geändert wurde. Ein Audit ist auch nicht gerade preiswert und kann nicht immer von der Community ausgeführt werden.

Punkt 3
Wenn man sich betrachtet wie viele Hilfestellungen es im Internet zu dem Absichern von WordPress gibt, der möchte nicht glauben, dass auch größere Seite diese ignorieren. Auch von mir wohlgemeinte Ratschläge per Mail, oder auch mal per Sozialnetz inkl weiterhelfender Links führe eher zu einer Diskussion mit anschließendem Nichtstun anstelle zu einem Handeln. Ich von meiner Seite aus habe meine letzten Versuche die Tage unternommen. Hätte ich mir sparen sollen. Nicht einmal das Absichern per htaccess für die URL $DOMAIN/wp-admin wurde vorgenommen. Ich kenne mehr ungesicherte mit WordPress betriebene Seiten im Netz, als gesicherte. Und dies ist bestimmt nicht die Schuld von WordPress (Hardening WordPress). Ich zeige hier wirklich mit dem Finge auf die Nutzer und beschuldige jene, nicht wirklich das absolute dokumentierte Minimum vorzunehmen, welches sie in anderen Bereichen auch machen würden. Können sie es nicht, dann möchten sie doch bitte einen Softwaremechaniker dafür zahlen, wie sie es auch in anderen Bereichen machen.

Man kann wirklich offen sagen, wenn es bei WordPress ein Sicherheitsproblem gegeben hat, war es prozentual gesehen eher ein Plugin, ein Theme, die Serversoftware, oder der/die Bloggende. Wer WordPress sicher installiert, härtet und mit Updates versorgt, der steht auf der sichereren Seite. Es ist wie bei jeder anderen Software auch. Man muss halt die freundliche gemeinte Anleitung lesen und sich für einen Dienst, welchen man betreibt interessieren. Nicht dafür interessieren, gibt es entweder nur für Geld und Fachpersonal, oder auf Kosten der Sicherheit für die eigene und andere Installationen.

Die letzten Pluginupdates ?

WordPress hat einen maroden Fehler und ich glaubte wirklich, dass jener mit der Version 4.0 ausgemerzt wurde. Ich ging davon aus, dass nicht nur in der Übersicht das letzte Datum eines Updates eines Plugins zu erfahren wäre, sondern auch im Administrationsbereich der installierten Plugins.

Natürlich ist die Übersicht toll, ich mag sie und auch dort findet man sofort heraus, wann das letzte Update eines Plugins geschehen ist, aber es ist nicht jenes, welches ich mir wünschte.

Es sollte die gleich Information wie auf der Pluginseite von  WordPress zu sehen sein.
Wenn das Plugin seit zwei Jahren nicht einem Update unterzogen wurde, dann bitte im Backend melden. Wie bei Antispambee von Sergej zu sehen ist, wann das letzte Update des Plugins war. Der Button Dismiss erklärt sich von selbst und der Button Details kann von der Pluginsuche übernommen werden.

 

WordPress Pluginübersicht mit Meldung
So sollte die Pluginübersicht sein

 

Fazit

Unbemerkte Altlasten können leicht zu einer unterschätzten Gefahr werden und man muss für sich eine Form finden, welche die oben genannten Probleme umgeht. Auf jeden Fall bis eine Alternative gefunden ist diesen Mangel zu beheben. Bis jetzt ist mir leider kein Service bekannt, welcher dies automatisiert übernehmen kann.

Auf jeden Fall kann nun weiter gebloggt werden.

 

 

9 Comments

  1. Sicher ist nur das Bloggen über Sitegeneratoren wie Pelican – da kommen die Besucher nämlich nur an HTML ran. ;-) Mein WordPress wird „irgendwann“ mal dadurch ersetzt. Wenn das nicht so viel Umstellungsaufwand wäre!

    Zu deinem „Punkt 2“ allerdings noch Folgendes: Ich habe letztes Jahr mein WordPress entrümpelt. Viele, viele Plugins lassen sich durch Ein- bis Dreizeiler in der functions.php deines Themes ersetzen. Spart Ladezeit und du verstehst meist nicht nur, was es tut – verbessern kannst du es auch. Es gibt zum Beispiel immer noch keinen (?) wirklich zuverlässigen Anführungszeichenumwandler. Ich hab‘ mir da ein Regex gebastelt.

    1. Den Spaß mit den Seitengeneratoren habe ich schon hinter mir und konnte dank einem erfahrenen Coder das ganze wieder nach mehr als einem Jahr rückgängig machen.
      Ich nutzte Jekyll dann Octopress und habe auch mal einen Blick auf andere geworfen.
      Serendipity war mal die Wahl, aber ich hätte zuviel an Plugins selbst schreiben müssen, welche schon in WordPress vorhanden waren. Ich war ja mal WordPresshasser ;)

      Diese Art von „Spielzeugplugins“ gibt es bei mir nicht, also dieser Dreizeilerspaß. Wie Du oben nachlesen kannst, ist das Spiel mit der eigenen functions.php ein falschesaber überaus berühmtes. Ich habe es selbst immer in Childthemes benutzt und aus dem Grund zum größten Teil auch immer Childthemes angelegt. Der andere war natürlich auch das Design ;)
      Ein Entwurf meiner Lieblingsfunktionen für die functions.php ist wieder gelöscht worden und wie gesagt, ich baue dazu ein Plugin für mich selbst. Das ist gesünder.

      Aber was Du machen kannst, es gibt Plugins die Dein WordPress statisch machen und einen Upload per FTP auf den Webserver hochladen. Somit hast Du immer noch den Komfort von WordPress, aber die Sicherheit eines statischen Blogs. Natürlich gehen die Kommentare noch

      1. Octopress/Jekyll sind die bekanntesten, weil da irgendwer einen Hype gemacht hat, aber nicht die besten. Ich teste ja noch.

        s9y gefällt mir „eigentlich“ ganz gut, gefunden hatte ich es aber leider erst, als WordPress schon funktionierte und ich es halbwegs verstanden hatte, womit der Grund zum Wechsel entfallen dürfte. Sonst wäre ich vielleicht nie bei WordPress gelandet, das ja doch diverse konzeptionelle, äh, Herausforderungen mit sich bringt. – Was ließ dich enthassen?

        Der Vorteil davon, direkt im Theme herumzuprogrammieren, ist die bestmögliche Anpassung an die gegebene Umgebung. Gerade bei jQuery-Erweiterungen genügen kleine Themeänderungen, damit gar nichts mehr geht. Ein Plugin wäre da zu unflexibel.

        Ein statisches WordPress bietet keinen offensichtlichen Vorteil gegenüber Pelican/Jekyll/… – oder?

        1. Ein statisches WordPress bietet keinen offensichtlichen Vorteil gegenüber Pelican/Jekyll/… – oder?

          Das kann nur ein Selbstversuch zeigen.

          Was mich hassen lies. Kunden bei welchen das Blog nur Chaos mündete und an allen Ecken und Enden Sicherheit gefehlt hat.
          Dies hinterlies einen Eindruck, welcher dann nur noch durch „geraune“ der mir bekannten Massen bestätigt wurde.
          Thematik war dann, alles nur kein WordPress :)

          WordPress ist nicht schlecht und die Mär sollte man endlich aufheben

        2. Ich hatte mit Jekyll bzw. der Distribution Jekyll-bootstrap recht schnell ordentliche Ergebnisse, aber irgendwie war ich nie so ganz zufrieden damit und ich habe nie von WP auf Jekyll umgestellt. Mit Nikola und Pelican lief das meiste auch recht gut, aber irgendwas hat mich dann immer abgehalten.
          Mittlerweile habe ich Acrylamid für mich entdeckt und nutze das in meinem Blog und bin zufrieden.

  2. Das WP-Admin Verzeichnis per htaccess zu sperren, lässt sich ja bei einem User noch recht leicht erledigen. Bei mehreren wirds dann schon lästig.

    Dann rate ich dazu, die Login-Versuche generell mitzuloggen und dann gezielt Botnetze auszusperren. Nützlich hierfür ist das Tool: https://wordpress.org/plugins/wp-security-audit-log/

    Folgende Sperr-Liste kann ich direkt weiterempfehlen:
    https://japanesetranslator.co.uk/2013/06/wordpress-login-failure/

    Langfristig gesehen sollte man aber seine Systeme auf Two-Factor-Autorisierung oder Client-Zertifikat-Autorisierung umstellen.

    1. Wenn ich die Mölichkeit habe, dass Blog auf meinem Rootserver, bzw bei mir ist es eher der Wille, zu hosten dann gehe ich anders vor.
      Ich lasse zu 90% meinen Server die Arbeit der Sicherheit machen und den Rest nur bei WordPress.
      Es gibt genug Werkzeuge in Webbereich um das dahinter liegende CMS zu schützen.

      Eine Abfrage des Benutzers vor wp-admin ist genau so wenig lästig, wie dahinterliegende OTPs, sowie letztgenannte Authorisierung Clientzertifikate.

      Hier kann ich auch nochmals auf das Spiel mit DNS-Einträgen hinweisen:
      http://got-tty.org/archives/wordpress-sicherheit-durch-dynamisches-dns.html
      Natürlich hängt es immer von dem Nutzen ab und wohin man möchte und es würde auch in einer Multiuserumgebung funktionieren.
      Es gibt da noch mehr Tricks, aber die behalte ich mir noch als Artikel vor ;)

      Ich kann nur Raten, so viele Plugins wie nötig und nicht wie möglich, dies gilt vor allem auch im Bereich der Sicherheit.

  3. Was spätestens im Jahre 1 nach Snowden auch unbedingt dazugehört, ist die Website in TLS-Verschlüsselung auszuliefern. Und zwar ausschließlich in TLS. Heißt also: Automatische Weiterleitung von “http” auf “https”. Ein kostenloses Zertifikat dazu kann man von StartSSL bekommen.

    Ansonsten schneiden die Provider, Dienste oder sonstige Kriminelle – die sich in die Leitung einklinken – einfach die übertragenen Passwörter mit.

    1. Wäre es so schön, dann würde mein Blog per TLS 1.2 ausgeliefert werden.
      Ist es nicht, denn mein Hoster verlangt auch für ein eigenes Zertifikat einen Salar.

      Natürlich könnte ich das Blog auch auf einen meinen Rootserver mit Zertifikat laufen lassen, nur warum sollte ich mir noch einen Angriffsvektor in das Haus holen. Sprich gesehen neben den Diensten, welche die Rootserver für mich selbst schon anbieten.

      Mein Hoster ist aber so angenehm, dass ich SSH nutzen kann um sehr viele Dinge an meinem WordPress zu erledigen (http://got-tty.org/archives/wordpress-per-ssh-nutzen-und-administrieren.html) und auch einen eigenen Proxy anbietet ( https://all-inkl.com/wichtig/anleitungen/kas/domain/ssl-proxy/aktivierung_332.html ) .
      Die freien Domains mit Zugriff auf den DNSServer, nochmals Backupmöglichkeiten, das Hosten meines Blogs, die Mailserver und der SSH-Zugang haben mich zu dem Hoster gehen lassen. Da sind ein paar Dinge, welche mir Zeit abnehmen, Dinge mit welchen ich mich nicht in meiner Freizeit befassen möchte ;)

Schreibe einen Kommentar

You have to agree to the comment policy.