Durch den Umzug auf den Webhoster All-Inkl ergaben sich hier und da kleine Schwierigkeiten.
Ich hatte zum Beispiel ein Problem mit den Besitzerrechten der WordPress Ordner, wie zum Beispiel „wp-content/uploads/“ oder „wp-content/gt-cache“ (gehört zum Global Tranlator Plugin).
Wenn man WordPress normal installiert werden bestimmte Ordner von den automatischen WordPress Scripts angelegt und die Besitzerrechte erhalten dann die Scripts, was auch vollkommen richtig ist.
Zieht man jetzt mit dem kompletten Blog auf einen anderen Hoster muss man alle Dateien auf den neuen Webspace via FTP hochladen. Dabei werden die Besitzerrechte geändert. Nun hat der FTP User die Besitzerrechte, nicht mehr das Script.
Das resultiert in verschiedensten Fehlermeldungen, die alle „Permission Denied“ ausgeben. Die normalen Berechtigungen von „755“ auf Ordnern und „644“ auf Dateien, wie es bei WordPress normal wäre, reichen hier nicht mehr aus. Abhilfe würde chmod „777“ schaffen aber es sollte jeder halbwegs gescheite Webmaster wissen, dass es sowas niemals geben sollte.

Also an alle All-Inkl Besitzer, die Probleme mit Besitzerrechten haben.
Prüft in eurem FTP Programm ob der Ordner, der Probleme macht (entnommen aus der Fehlermeldung natürlich), die richtigen Berechtigungen (755 z.B.) besitzt. Sollte es so sein und es gibt Fehlermeldungen dann ist der Besitzer dieses Ordners sicher euer All-Inkl Benutzername (z.B. w00b3a24).
Um das zu beheben geht in das KAS und dort unter Tools->Besitzrechte findet ihr Abhilfe.
Wählt den Nutzer „PHP-User“ und dann den Ordner (z.B. wp-content). Setzt das Häkchen von Rekursiv und bestätigt den Prozess.
all-inkl-besitzrechte-wordpress
Nach einigen Sekunden sollte Prozess abgeschlossen sein. Der gewählte Ordner gehört nun dem PHP User. Testet kurz, ob Updates/Installation von Plugins oder die benötigte Funktionalität damit korrigiert wurde. Wenn ja, Glückwunsch.
Nun solltet ihr wieder denselben Ordner (z.B. wp-content) zurück auf euren FTP-Benutzer zurückzustellen, damit die Rechte innerhalb von WordPress nicht durcheinandergewürfelt sind. Die WordPress-Funktionen sollten auch nach dem Reset zurück auf den FTP-Benutzer erhalten bleiben.

Ich habe den Fehler wahrscheinlich gefunden, das PlugIn Tweet This scheint mir den Blog unerreichbar gemacht zu haben.
Trotzdem war ich mit der Stabilität meines bisherigen Webhosters nicht zufrieden und werde daher dieses Event als Anlass nehmen, endgültig den Umstieg auf einen anderen Provider durchzuziehen.
Ich habe mich daher heute bei All-Inkl angemeldet und werde heut Abend die KK-Anträge nachschicken. Hoffentlich bin ich schnell wieder online.

mehr-website-sicherheit-mit-http-header-hsts-xss-protection-banner

Zum Start dieser kleinen Serie, inspiriert durch einen Sicherheitsreport meines Blogs von enginsight.com (dazu mehr im November), erst einmal die Grundlagen der HTTP-Header:

Was sind HTTP-Header und wofür brauche ich sie?

HTTP-Header, oder in diesem Artikel vor allem die HTTP-Header-Respond-Felder, sind ein Teil der Antwort eines Webservers an den anfragenden Client (mehr dazu). Sie enthalten Anweisungen, Informationen und Einschränkungen der Verbindung zwischen Browser und Server, aufgebaut als eine Vielzahl an Schlüssel-Wert-Paaren.
Der Betreiber einer Webseite oder eines Webservers kann diese Antwortfelder teilweise konfigurieren und damit die Sicherheit der Webseite und des Verbindungsaufbaus erhöhen. Die Felder, die speziell für mehr Sicherheit entwickelt wurden, werden auch kurz HTTP-Security-Header genannt.

Die Anpassung der Header kann unterschiedlich erfolgen und ist vom Webserver oder der Webhosting Umgebung abhängig. Webserver bieten für HTTP gewöhnlich Konfigurationsdateien an, teilweise gibt es diesen Zugriff auch in root-Webhosting-Lösungen. Für „normales“ Webhosting geht das größtenteils auch über eine .htaccess in der obersten Ebene. Das könnte im Falle meines Webhosters All-Inklusive beispielsweise sein:
/www/htdocs/w00bxxxx/.htaccess

Mögliche Probleme mit .htaccess bei Shared Webhosting

Achtung: Eventuell werden Header Anpassungen von eurem Hoster geblockt/entfernt. Das liegt dann an der Art und Weise der Webserver-Konfiguration.
Sidestory: Bei meinem Hoster All-Inklusive, dessen Shared Hosting Server größtenteils PHP über FPM/FastCGI realisieren, ist das beispielsweise der Fall. Hier müssten die Einstellungen direkt im VHost gesetzt werden, das kann nur der Hoster selbst. Freundlicherweise hat mich All-Inkl nach einer Nachfrage auf eine moderne Serverfarm umgezogen, wo ich mittels .htaccess auch Header setzen kann.
Sollte das für euch nicht möglich sein, funktioniert für WordPress auch der Workaround über die functions.php, den ihr auf dieser Seite ganz unten im letzten Absatz findet. 
Teilweise kann es auch sein, dass die Einträge durch Einstellungen im Admin-Backend überschrieben werden. So kann es sein, dass HSTS, „Enforce SSL“ und ähnliche Domain-basierte Eigenschaften in der Domänenverwaltung angepasst werden und die .htaccess Angaben überschreiben.

Hier die Analyse meines Blogs von securityheaders.com vor der Optimierung der Security Header:

mehr-website-sicherheit-mit-http-header-hsts-xss-protection-header-analyse-davor
Security Header Analyse vorher mit der Endwertung D, nicht so vorteilhaft…

Kein sehr gutes Bild. Wird Zeit, daran zu arbeiten! Wir beginnen mit zwei recht unkomplizierten Security Feldern, HSTS und XSS-Protection. Sie bieten einen guten Einstieg in das Themengebiet und benötigen jeweils nur 1 Zeile in der .htaccess. Aber nun in die Details:

HTTP Strict Transport Security – SSL & HTTPS, bis dass der Tod uns scheidet

HSTS (HTTP Strict Transport Security) sollte ausschließlich aber unbedingt dann konfiguriert werden, wenn die Webseite SSL verschlüsselt (über https) erreichbar ist und nicht mehr über unverschlüsseltes HTTP erreichbar sein soll. HSTS gibt vor, dass und für welchen Zeitraum in der Zukunft alle Anfragen über SSL vom Client zum Server geschickt werden müssen.

<IfModule mod_headers.c>
  # Die einfache HSTS Variante, halbes Jahr Zeitfenster
  # Header always set Strict-Transport-Security "max-age=15778463"
  # oder noch sicherer mit Subdomains, preload und allen Subdomains
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

Zwei Werte sind hier wichtig: max-age und der optionale Parameter includeSubDomains. max-age ist die Zeitangabe in Sekunden, wie lange der Zugriff in Zukunft für diesen gerade aufrufenden Client ausschließlich über SSL erfolgen muss. Der Wert 31536000 steht demnach für 1 Jahr. Ist die Webseite innerhalb dieser Zeit nicht über https erreichbar, weil beispielsweise das Zertifikat abgelaufen ist, kann sie nicht mehr geöffnet werden. Browser geben dann diese Art von Fehlermeldung und für den Nutzer ist hier Endstation. Das kann jetzt für den Nutzer doof sein, sorgt aber für ein hohes Sicherheitsminimum, das nicht unterschritten werden darf. Eigentlich ein Plus.

Ein Blick in die weiteren Eigenschaften von HSTS lohnt sich

Die zusätzliche Angabe includeSubDomains erweitert dieses Verfahren auf alle Subdomains, ein Wildcard-Zertifikat ist hier also von Nöten. 
Zu guter Letzt gibt es noch die preload-Eigenschaft, die noch nicht Teil des offiziellen Standards ist. Es ist die Crème de la Crème der HSTS-Absicherung und implementiert den HSTS-Schutz für eure Domain explizit und direkt in alle modernen Browser (akt: Chr, FF, Opr, Saf, IE11, Edg). Dafür muss die Seite jedoch HSTS ordentlich eingebunden haben und auf dieser Seite registriert werden. Dieser Artikel beschreibt sehr ausführlich und einfach dieses Attribut und all seine Details.
Prüft die HSTS-Eigenschaften eurer Seite beispielsweise hier. Mehr Informationen zu HSTS auch hier. Einen ausführlichen Check eurer SSL-Servereigenschaften könnt ihr hier initiieren – das dauert 2, 3 Minuten, ist aber sehr ausführlich und informativ.

X-XSS-Protection – steckt mehr drin als gedacht

Als nächste Eigenschaft schauen wir auf das Feld X-XSS-Protection. Dieses steuert Browser-Features, welche XSS-Attacken erkennen und verhindern. Diese Mechanismen sind normalerweise aktiviert, können aber von Servern oder vom Nutzer deaktiviert werden; X-XSS-Protection erzwingt die Nutzung dann entsprechend der Angabe. Oft lese ich, dass der Header nur von IE und Chrome, teilweise auch von Safari ausgewertet wird. Laut MDN wird der Header jedoch von allen Browsern bis auf Firefox unterstützt. Folgende Umsetzung via .htaccess:

<IfModule mod_headers.c> 
  # Schutz aktivieren und Rendern verhindern bei einem Angriff
  # Header always set X-XSS-Protection "1; mode=block" 
  # oder noch besser: Seite aufräumen, rendern und Angriff melden:
  Header always set X-XSS-Protection "1; report=http://reportingserver.com/reporting_URI.php
</IfModule>

Relativ einfach: Der erste Wert 1 erzwingt-aktiviert den Schutz, mode=block stoppt das Rendering der Seite und blockiert sie komplett. Ohne mode=block wird die Anfrage gereinigt und dann ausgeführt. Soweit so einfach.

XSS-Protection Reporting – Mitlesen der Angriffe

Nun kommt jedoch noch eine spannendere Anweisung, die leider auf kaum einer Infoseite beschrieben wird; vermutlich, weil es etwas mehr Text brauch. Denn die report-Anweisung ermöglicht die Angabe einer Reporting-URI, an die ein Bericht des Angriffs geschickt wird. Das dortige Skript kann nun beispielsweise loggen, benachrichtigen oder beliebig anders reagieren. Das finde ich besonders wert- und sinnvoll, daher hier noch der Aufbau:
Beginnen wir mit dem beispielhaften Aufbau eines XSS-Protection Report Requests, welcher mittels POST an die URI geschickt wird:

POST http://test.local/foo HTTP/1.1
Host: test.local
Connection: keep-alive
Content-Length: 116
Pragma: no-cache
Cache-Control: no-cache
Origin: http://test.local
X-FirePHP-Version: 0.0.6
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36
Content-Type: application/json
Accept: */*
DNT: 1
Referer: http://test.local/test.php?foo=%3Cscript%3Ealert(1);%3C/script%3E
Accept-Encoding: gzip, deflate
Accept-Language: cs,en-US;q=0.8,en;q=0.6

{"xss-report":{"request-url":"http://test.local/test.php?foo=%3Cscript%3Ealert(1);%3C/script%3E","request-body":""}}

Nun wird der Request gegen ein PHP-Skript geschickt und dort empfangen, in eine Datei geloggt und per Mail an den Admin geschickt. Dazu habe ich diesen MDN-Code etwas erweitert: Es gibt jetzt mehr Mailing-Optionen und die Möglichkeit, eine E-Mail bei jedem Angriff zu senden, statt nur beim ersten:

<?php
// Start configure
$log_file = dirname(__FILE__) . '/xss-report.log';
$log_file_size_limit = 10000000; // in bytes = 10MB - once exceeded no further entries are added
$email_every_attack = true;
$email_sender = 'phpmailer@mysite.de';
$email_recipient = 'admin@mysite.de';
$email_subject = 'XSS Violation';
$email_charset = 'utf-8';
// End configuration

$current_domain = preg_replace('/www\./i', '', $_SERVER['SERVER_NAME']);
$email_subject = $email_subject . ' on ' . $current_domain;
http_response_code(204); // HTTP 204 No Content
$json_data = file_get_contents('php://input');

// We pretty print the JSON before adding it to the log file
if ($json_data = json_decode($json_data)) {
  $json_data = json_encode($json_data, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES);
  if ($email_every_attack) {
    // Send an email
    $message = "XSS violation on " . $current_domain . ":\n\n" .
      $json_data . "\n\n" .
      "Logfile:" . $log_file;
    $headers =  "From: ".$email_sender."\r\n".
                "Content-Type: text/plain;charset=".$email_charset;
    mail($email_recipient, $email_subject, $message, $headers);
  } else if (filesize($log_file) > $log_file_size_limit) {
    exit(0);
  }
  file_put_contents($log_file, $json_data."\n", FILE_APPEND | LOCK_EX);
}
?>

Am besten testet ihr die Reporting-Funktion vorher, beispielsweise über einen online API-Tester. Baut euch einfach den Request zusammen und schickt ihn an eure Report-URI. Das funktioniert gut und dient mir nun als Informationsquelle, welche XSS-Angriffsversuche mit exakt welchen Anfragen gegen meine Seite gefahren werden. Hier nochmal das Setup visuell:

mehr-website-sicherheit-mit-http-header-hsts-xss-protection-report-setup_thumb
XSS-Protection Reporting Setup mit Logging und Mailing

Es sei erwähnt, dass die X-XSS-Protection durch die neuere und komplexere Content Security Policy (CSP) ersetzt wird. Das schauen wir uns im nächsten Artikel genauer an. Solange dieses Feld aber noch nicht komplett von allen Browsern unterstützt wird, empfiehlt es sich weiterhin, XSS-Protection zu verbauen (zumal es so einfach ist).

Abschluss der ersten Optimierung

Die ersten zwei Security Header sind damit optimiert, ein erster Schritt:

anti-spam-basics-fuer-versender-spf-dkim-dmarc-samuel-zeller-367977-unsplash

Spam? Gut oder Böse?

Spam-Mails gehören mittlerweile zum Alltag eines jeden Nutzers und Empfängers und in den meisten Fällen wird der Spam-Ordner nicht einmal mehr eines Blickes gewürdigt. Dabei kann es passieren, dass wichtige und legitime Mails aus Versehen als Spam eingestuft werden. Im weiteren Verlauf des Artikels wird sicher deutlicher, dass dies keinesfalls „Versehen“ oder „Zufall“ ist, sondern aus einer Menge an Gründen und Faktoren durch Algorithmen kalkuliert wird. So kann es passieren, dass Reservierungsbestätigungen oder die legitime Lotto-Gewinnbenachrichtigung nicht im Posteingang eintrifft – Millionengewinn verpasst, schade.
Falsch eingestufter Spam ist also nicht nur ärgerlich für Empfänger, sondern vor allem auch ein Problem für Absender. Der Kunde wird nicht erreicht, wichtige Nachrichten nicht übermittelt, Umsatz geht verloren, Vertrauen und Image wird beschädigt. Die direkten und undirekten Kosten für ein Unternehmen mit Spam-Problemen können enorm sein.
Im Folgenden schreibe ich über ein paar Basics im Bereich Anti-Spam-Maßnahmen für Versender. Ziel ist es, dass versandte Mails seltener fälschlicherweise als Spam erkannt werden.

Wie funktioniert Anti-Spam für Versender?

Wenn E-Mails beim Mailserver des Empfängers eintreffen, versucht dieser Server einzuschätzen, ob die Mail tatsächlich vom angegebenen Absender stammt und der Inhalt legitim und relevant für den Empfänger ist. Ein Großteil der technischen Anti-Spam-Maßnahmen betreffen die Validierung des Absenders im Schritt 1, hier gibt es viel Potential für Optimierung. Bei Schritt 2, dem Inhalt, gibt es eher ein paar formale und syntaktische Richtlinien.
Ich schreibe das How-To aus meiner Sicht als Webhosting-Kunde von All-Inkl. Bei anderen Webhostern sowie bei eigenen Root Servern können die nötigen Schritte abweichen. Schaut bitte in die FAQ/Hilfe eures Anbieters oder fragt hier in den Kommentaren, wenn ihr nicht weiter kommt. Für Root Server gibt es hier eine Anleitung, die recht ausführlich Hilfestellung gibt.

Überprüfung der Maßnahmen

anti-spam-basics-fuer-versender-spf-dkim-dmarc-gsuite-mx-check-toolboxEs ist unbedingt empfehlenswert wenn nicht sogar kritisch erforderlich, vor UND nach den folgenden Maßnahmen die Einstellungen zu überprüfen. Wie ist der aktuelle Zustand, wie sieht es danach aus? DNS-Änderungen sind für gewöhnlich innerhalb von Sekunden aktiv und extern sichtbar, kein Warten nötig.
Zum Testen eignen sich besonders die Online Tools MxToolBox und die GSuite Toolbox MX-Check. Prüft damit direkt nach jeder DNS Änderung nach – für gewöhnlich werden diese innerhalb von Sekunden übernommen und sind von extern sichtbar, ebenso die Resultate.
Nun aber zu den Maßnahmen:

#1 – SPF

SPF, Sender Policy Framework (Wikipedia, Standard), ist ein Standard zur Überprüfung des Absenders einer E-Mail und vermutlich der wichtigste Anti-Spam-Indikator. SPF ist eine TXT-Einstellung im DNS der Absender-Domain und leicht zu setzen. Etwas mehr Wissen erfordert unter Umständen das Generieren des TXT Eintrags. Hier muss beachtet werden, welche Mailserver und Maildienste für das Versenden der Mails benutzt werden. Wenn ich den Mailserver meines Webhosters nutze, jedoch Mails über die Googlemail Weboberfläche schicke (E-Mail über SMTP eingebunden), muss ich das im SPF-Eintrag beachten. Hierzu gibt es von fast allen Anbietern entsprechende Infos/Hilfeseiten, etwas googeln hilft hier schnell.
Ein beispielhafter SPF-Eintrag, der Google als Relay inkludiert, könnte so aussehen:
v=spf1 a mx include:_spf.google.com ~all
Kein ptr im SPF, wenn MX gesetzt ist, auch wenn das viele Generatoren immernoch machen. Überprüfung mit SPF Check der MXToolBox. Weitere Infos findet ihr bestimmt in der Hilfe eures Maildienstleisters/Hosters mit der Suche nach „SPF“.
anti-spam-basics-fuer-versender-spf-dkim-dmarc-spf-setup

#2 – DKIM

DKIM, DomainKeys Identified Mail (Standard, Wikipedia), ist wie SPF ebenfalls ein Protokoll zur Überprüfung von eingehenden Mails und deren unverändertem Inhalt.
DKIM nutzt zur Überprüfung eine asymmetrische Verschlüsselungstechnik mit zwei Schlüsseln – einem privaten Schlüssel, der Mails unsichtbar angehängt wird und einem öffentlichen Schlüssel, abgelegt im DNS des Absenders. Somit kann der Empfänger-Mailserver die Schlüssel aus dem Absender DNS und der Mail-Signatur gegeneinander prüfen und validieren. Das Hinzufügen des privaten Schlüssels in den Mailserver, damit dieser unsichtbar alle ausgehenden Mails damit signiert, erfordert eine fortgeschrittene Anpassung des Mailservers bzw. Konfiguration des Mailers und übersteigt den Rahmen dieses Artikels. Für GMail-Nutzer hilft die Google DKIM Step-by-Step-Anleitung, ansonsten wieder beim Anbieter/Hoster in der Hilfe schauen bzw. Support fragen.
Der zweite Teil besteht aus einem TXT DNS Record, der zuvor generiert werden muss. Benötigt wird dafür die Domain und ein „Selektor“; eine beliebige Zeichenkette, z.B. „meindkim1“. Der Record sollte immer mit v=DKIM1;k=rsa;p= anfangen! Selbst wenn die Generatoren gerne einen der Parameter v oder k weglassen, oder diese als optional angeben, sollten beide gesetzt sein. Info: Beide Überprüfungs-Tools (MxToolBox und GSuite MX-Check) bestätigen einen validen DKIM übrigens nur mit Parametern v UND k, Warnungen falls einer fehlt. Die Überprüfung von DKIM erfordert dann ebenfalls Domain und Selektor und sollte anschließend positiv ausfallen:
anti-spam-basics-fuer-versender-spf-dkim-dmarc-dkim-check
Aber Achtung: Ausschließlich den DKIM DNS Eintrag zu setzen, ohne die Mails zu signieren, hat keine weiteren positiven Auswirkungen (meistens aber auch keine negativen) und ist daher nicht zu empfehlen.

#3 – DMARC

DMARC, Domain-based Message Authentication, Reporting, and Conformance (Standard, Wikipedia):Was wie die deutsche alte Währung klingt, ist eine Technologie zur Erweiterung von SPF und DKIM. Geliefert werden zusätzliche Informationen, wie der Empfängerserver mit geprüften Mails umgehen soll sowie die Möglichkeit von Reports der Überprüfungen. Auch hier ein DNS TXT Eintrag, der die Infos liefert. Zwei grundlegende Fragen müsst ihr euch stellen:
1. Wie sollen Mails behandelt werden, deren SPF/DKIM-Überprüfung fehlschlägt? Ignorieren / Spam / Abweisen.
2. Sollen Daten und fehlgeschlagene Überprüfungen als Reports verschickt werden und an welche Mail-Adresse?
Solltet ihr mit „Ignorieren“ dem Empfangsserver kein Verhalten vorschreiben wollen und auch keinerlei Reporting wünschen (v=DMARC1;p=none;), erfüllt DMARC keinen Zweck und hat auch keine weiteren Effekte auf den Mailempfang, kann also ausgelassen werden.
Restriktiveres Verhalten oder Reporting gewünscht? Dann wird einer der vielen existierenden Generatoren aus den gewählten Optionen einen einfachen bis recht komplexen TXT Record erstellen:
v=DMARC1; p=none; rua=mailto:admin@it-stack.de; ruf=mailto:admin@it-stack.de; fo=1;
Dieser Eintrag schickt Reportings an mich, wenn SPF oder DKIM fehlschlägt sowie generelle Reports, der Mailserver soll die Fehlschläge jedoch wie gewohnt behandeln, ich gebe kein strikteres Vorgehen vor.
anti-spam-basics-fuer-versender-spf-dkim-dmarc-check

#4 – Blacklists

Es gibt eine Vielzahl von professionell betriebenen Anti-Spam-Listen, also Blacklists, die von Mailservern zur weiteren Überprüfung abgefragt werden können. Ob mein Mailserver auf einer Blacklist steht, kann ich beispielsweise mit der MxToolBox Blacklist Suche herausfinden. Gebt hier eure Domain ein und eine Auswertung von über 100 Blackslists wird eventuelle Funde aufzeigen. Solltet euer Mailserver nicht die IP eurer Domain teilen oder weitere in das Mailing involvierten MX-Server-IPs bekannt sein, diese am besten auch noch testen.
Eure Domain/IP ist in einer Blacklist gefunden worden? Das ist unpraktisch, kann aber mal passieren. Geblacklistet werden für gewöhnlich ganze Server. Auf einem Shared Server, wie das bei Webhosting fast immer der Fall ist, sind, je nach Vertrag, 20 bis 100 weitere Kunden untergebracht. Die Chance, dass ein anderer Kunde für das Blacklisting verantwortlich ist, ist hoch.
Was tun? Auf der Betreiberseite der Blacklist gibt es meistens Suchen/Informationsportale, in denen Blacklist-Kandidaten, teilweise mit mehr Details und Begründung, gesucht werden können. Ich empfehle zwei Recherchen: Suche nach der Domain und nach der/den IPs.
So kann es sein, dass die IP-Adresse des Servers in mehreren Einträgen gefunden wird (Reportfunde bei Spamhaus ZEN: Link1, Link2, in welchen wiederum eure Domain nicht erwähnt wird), für die Domain jedoch kein Eintrag vorhanden ist. Das sind weitere Hinweise darauf, dass nicht ihr, sondern ein anderer Kunde des Servers Schuld hat.
Unabhängig von diesen Recherchen könnt ihr vermutlich wenig gegen das Blacklisting tun. Manche Betreiber bieten Unblock Formulare an, andere nicht. Informiert auf jeden Fall euren Webhoster/Mailing-Anbieter mit allen herausgefundenen Informationen über das Blacklisting – dieser hat für gewöhnlich andere Optionen und kann direkt selbst in die Behandlung der Problemursache, also gegen entsprechende Kunden, vorgehen.
anti-spam-basics-fuer-versender-spf-dkim-dmarc-blacklist-check

#5 – User Trust

Desweiteren hilft es, sich zusätzlich Trust über den User/Empfänger zu holen – beispielsweise durch das Hinzufügen eurer Absenderadresse zu den Kontakten, das Markieren der Nachrichten als „Wichtig“ oder Versehen mit Sternchen/Markern (je nach Client heißt das anders), den Absender „Nie als Spam markieren“ (ebenfalls je Client anders) und mehr. Alles, was man mit einer Mail oder einem Absender bei dem jeweiligen Anbieter des Empfängers tun kann, dass letztlich einen positiven Effekt hat. Die Anbieter speichern solche Informationen (wie oft wurde eine Mail mit Inhalt X positiv behandelt, wie oft der Absender usw.) und behandeln Mails dieses Absenders zukünftig besser. Diese Maßnahme kann man bis zu einer gewissen Anzahl mit den eigenen Mitarbeitern starten – Mails an ihre private Mailadresse schicken, bestenfalls bei unterschiedlichen Anbietern, und die Mails von ihnen „positiv behandeln“ lassen.

1und1 Webhosting

In meinem Blog kann man es an vielen Posts erkennen: Ich bin eigentlich Fan vom Webhoster All-Inklusive und dort seit über einem Jahrzehnt sehr zufrieden. Man muss aber dazusagen, dass sich an den Features, dem Design, dem Backend und auch allgemein wenig verändert hat – All-Inklusive fährt wohl das „never change a running system“ Prinzip. In der heutigen Zeit, in der Konkurrenz in Massen aus dem Boden sprießt und binnen kürzester Zeit stark aufblühen kann, ein riskantes Unterfangen.
Vor All-Inklusive hatte ich auch mal ein 1und1 Webspace, damals (so um 2009 rum) noch für ganz statische HTML Seiten, fancy erstellt mit Microsoft Frontpage … das waren Zeiten 😀 Das 1und1 Webhosting war damals schon recht funktional und modern vom Design her:
1und1 Webhosting 1und1-webhosting-test-2018-history-2009
Damals waren Stabilität und Support allerdings mein Grund zu wechseln. Ich wollte mal schauen, was 1und1 in der Zeit so gemacht hat, wie sich das Webhosting dort entwickelt hat und wie es meinen aktuellen Needs entsprechen würde.

Weiterlesen

Es stimmt mich schon fast ein wenig traurig aber es war höchste Zeit…

…mein Blog bekommt ein Facelifting!

Seit 2009 gibt es den Blog nun, das ist schon eine Weile. Seither hat sich jedoch nicht soo viel getan, vom Inhalt abgesehen. Es hat seinen Zweck immer gut erfüllt.

HAT , Vergangenheit, wohlgemerkt. Mittlerweile kann ein (erster) Besuch auf der Seite schon überraschen, nicht nur im positiven Sinne, wenn man sich – wie ich – nicht über Jahre daran gewöhnt hat. Es wirkt dunkel, zu eng, überladen, oldschool.

Also, in die Hände gespuckt, angepackt, Zeit investiert … und …
Neues Design, neuer Name, neue Domain, neue Extras.
Weiterlesen

Fehler

Folgender Fehler kann bei WordPress auftreten, vermutlich nur bei bestimmten Hostern, nachdem es installiert oder hosterübergreifend umgezogen wurde:
Das Bild zeigt den WordPress Dialog, bei dem FTP Verbindungsinformationen benötigt werden sowie den Fehler, dass diese nicht korrekt seien - egal, welche Daten man eingibt. Das liegt an fehlerhaften Besitzrechten nach der WordPress Installation auf einigen Hostern wie beispielsweise auch All-Inkl und Hosteurope.
Der Fehler erscheint vermutlich bei der Installation oder Aktualisierung von Plugins oder Themes.

Erklärung

Das Bild zeigt den WordPress Dialog, bei dem FTP Verbindungsinformationen benötigt werden. Das Phänomen tritt auf, wenn ihr WordPress von Hand auf euren FTP hochgeladen und danach die Installation ausgeführt habt. Dadurch ist das WordPress Core mit den Besitzerrechten eures FTP Nutzers, mit dem ihr die WordPress Dateien hochgeladen habt, versehen. Alle Tätigkeiten aus dem WordPress System heraus, also beispielweise das Installieren von Plugins über die WordPress „Plugins“ Oberfläche, werden jedoch server-intern von einem anderen Nutzer ausgeführt. Dieser Nutzer heißt je nach System oftmals PHP-User, www-User, www-data oder ähnlich. Nun fehlen dem Nutzer aber die Zugriffsrechte auf die entsprechenden Ordner.

Lösungen

Es gibt mehrere mögliche Lösungen:

1)
Gebt bei der WordPress Nachfrage die FTP-Nutzerdaten ein, mit denen ihr WordPress hochgeladen habt. Den Nutzer könnt ihr, falls ihr es nicht mehr genau wisst, vielleicht mit dem WebFTP-Tool eures Hosters auslesen:
Das Bild zeigt die Oberfläche eines WebFTP Programms mit markierten Besitzerinformationen eines Ordners
Im besten Falle führt WordPress danach alle Plugin Aktionen ohne Klagen aus und ihr hört nie wieder von dem Problem. Aber dann wärt ihr wahrscheinlich auch gar nicht hier gelandet.

2)
Ändert die Besitzrechte von wp-content. Nutzt dafür vom Hoster zur Verfügung gestellte Möglichkeiten der Besitzrechteveränderung (Adminbackend -> Tools).
Zuerst wird der Ordner wp-content auf den PHP-User gestellt, die benötigte WordPress Funktion getestet (z.B. Plugin-Update, sollte jetzt gehen) und dann stellt ihr den Besitzer wieder zurück auf den FTP-User. Bei mir hat das die Probleme dauerhaft behoben und die Besitzrechte sind einheitlich weiterhin auf dem FTP-Nutzer.

3)
Mein zweiter Tipp ist eigentlich der langfristig sicherste: installiert WordPress nicht von Hand sondern über die 1-Click-Install-Methode eures Hosters. Praktisch jeder Webhoster bietet die Installation von bekannter Software auf seinem System an, WordPress ebenfalls. Dabei richtet der Hoster ein fertig installiertes und eingerichtetes System für euch ein, meistens mit nur wenigen Klicks. Dieses System hat definitiv keine Rechteprobleme, ist nun aber frisch installiert. Je nachdem, wie jung oder alt euer Blog ist, kostet es nun weniger oder mehr Aufwand, die Inhalte in das neu installierte System zu transferieren. Aber diese Lösung ist am sichersten und wird keine zukünftigen Probleme mehr machen, ich empfehle das also.
Export/Import: Der Export besteht im Grundlegenden aus 2 Typen: Daten (Beiträge, Kommentare usw), Plugins und Themes.
Daten: Benutzt entweder die WordPress eigene Export-Funktion unter „Werkzeuge -> Daten exportieren“ oder exportiert eure komplette WordPress Datenbank (SQL Export via phpMyAdmin). Diesen Export dann im neuen WordPress bzw. dessen Datenbank.
Plugins/Themes: Entweder ihr installiert im neuen WordPress die Komponenten von Hand (je nachdem wieviele es sind), oder ihr zieht euch direkt vom FTP die Ordner „plugins“ und „themes“ und überschreibt einfach diese Ordner in eurem neuen WordPress System.
Anschließend müsste der neue WordPress Blog die Plugins, Themes (die beide ggf. noch aktiviert werden müssen) und Daten enthalten.
Ich werde aber demnächst nochmal einen ausführlichen Beitrag über gute WordPress Backup Methoden schreiben und eine komplette Backup Lösung konzipieren.

4)
Tragt in eure .htaccess Datei in der Root eures WordPress Blogs (also direkt im obersten Ordner, beispielsweise „/blog/“) folgende Zeile ein:

AddHandler php5-cgi .php

Hintergrund: Link