Dieser Beitrag ist eine Fortsetzung der kleinen Artikelserie zur Optimierung der HTTP-Header für mehr Sicherheit auf der Webseite und für alle Webseitenbesucher. In Teil 1 ging es um die zwei noch recht einfachen Header HSTS und X-XSS-Protection. Teil 2 wird nun den recht komplexen aber mächtigen Header Content-Security-Policy behandeln.
Es benötigt vom Webmaster schon einiges an Vorbereitung und Testing, um mit diesem Header nicht auch Schaden anzurichten, aber der Zugewinn an Schutz gegenüber Angriffen oder Code Injection ist bemerkenswert.

CSP für umfangreiche Datenherkunftseinschränkung

Der Content-Security-Policy Header überprüft die Art und Herkunft von Daten und Anfragen während des Ladens und kann darauf reagieren. So können beispielsweise bestimmte Datentypen wie Skripte oder Stylesheets, die von einer anderen URL als der gerade zu ladenden Webseite angefragt werden, geblockt werden. Damit wird verhindert, dass unerwünschte, fremde oder gefährliche Inhalte geladen und ausgeführt werden. Das ist für gewöhnlich das Ziel von XSS-Angriffen, welche über zahlreiche Tricks versuchen, schädliche Inhalte in vertrauenswürdige Seiten einzubinden.
Damit das jedoch so funktioniert, muss der Webmaster für alle oder einzelne Inhaltstypen die jeweiligen vertrauenswürdigen Quellen definieren. Hier wird es knifflig. Vergisst der Admin eine vertrauenswürdige Quelle, werden Inhalte von dort nicht mehr geladen und fehlen auf der Webseite. Das kann dazu führen, dass Schriftarten oder Bilder fehlen, Skripte und somit ganze Funktionen nicht mehr laufen und die Webseite sich in andere Seiten nicht mehr einbetten lässt. 
Die vertrauenswürdigen Ursprünge sind entweder bekannt oder müssen erarbeitet werden.

1. Informieren

Eine zu restriktiv gesetzte CSP kann die Webseite wie gesagt teilweise beschädigen. Ich empfehle daher die mehrstufige Vorgehensweise: Informieren, testen, optimieren und schlussendlich aktivieren.

Ein erster Blick lohnt beispielsweise bei MDN. Hier sehen wir, welche Direktiven und welche Werte möglich sind. Ich gehe später nochmal genauer auf die einzelnen Werte ein. Erst einmal solltet ihr euch einen groben Überblick holen. Nutzt für weitere Informationen neben diesem Artikel auch die Intros von html5rocks.com, SelfHTML, den Mehrstufen-Ansatz von dareboost.com und die dort verlinkten weiteren Artikel zu CSP-Basics und auch die vielen kleineren Webseiten und Blogger mit deren CSP-Empfehlungen.

2. Testen

Wir beginnen mit Tests, die keine Schäden anrichten können. Dazu nutzen wir das Report-Only Feature der CSP. Hierfür wird eine valide CSP über Content-Security-Policy-Report-Only gesetzt, angewendet aber nicht ausgeführt. Es werden Warnungen und Fehler ausgegeben, aber keine Anfragen tatsächlich blockiert. Gesetzt wird es wie gehabt in der .htaccess der Webseite:

<IfModule mod_headers.c> 
  Header always set Content-Security-Policy-Report-Only: "default-src 'self'; img-src 'self' https://secure.gravatar.com https://s.w.org https://wordpress.org https://ps.w.org data:; font-src 'self' fonts.gstatic.com data:; object-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; connect-src 'self'; child-src 'self'; report-uri https://report-uri.de/report.php;"
</IfModule>

Der Inhalt dieser CSP ist erst einmal nur kopiert von kittpress.com und angepasst an das Report-Only Feature via .htaccess. Von hier arbeite ich mich dann weiter.

Die CSP wird nun theoretisch angewendet, aber nicht endgültig ausgeführt. Nun könnt ihr anhand der Browser-eigenen Dev-Tools und der Reports die Problemstellen identifizieren.
Wie ihr eine Report-Schnittstelle einrichtet, die beispielsweise Reports in eine Logdatei schreibt, habe ich im ersten Teil dieser Artikelserie erklärt. Ihr könnt auch genau dieselbe Reportschnittstelle hierfür nutzen, das funktioniert einwandfrei. Alternativ könnt ihr auch externe Report Services wie diesen als Ziel für eure Reports wählen.
Gegenüber euren Browsertools haben die Reports den Vorteil, dass jede CSP-Verletzung jedes Website-Besuchers an euch gemeldet wird – ohne, dass ihr dafür dann noch etwas tun müsst. Außerdem habt ihr alle Meldungen dann in einer großen und zentralen Server-Log (ggf. auch per Mail) und müsst nicht selbst rumsurfen und die Devtools abkopieren. Es geht ansonsten aber auch ohne report-uri.

3.1 Optimieren

Bei meinem ersten Test landeten weit über 100 Reports innerhalb von 1 Minute in der Report-Log – das reicht für eine erste Optimierung. Also habe ich die CSP erst einmal wieder deaktiviert/auskommentiert und die ersten Ausnahmen erstellt. Dazu habe ich mir jeden Report einzeln angesehen, wenn nötig eine Ausnahme erstellt, alle Logeinträge dieses spezifischen Problems entfernt, nächten Report angesehen. So lange, bis die Report-Log wieder leer war.
Anschließend die neue CSP wieder einkommentieren und wieder dreistellige Reports sammeln.
Diesmal dauert es länger und es kommen kleinere oder speziellere Probleme zum Vorschein: Von externen Seiten eingebundene Bilder oder Medien, alte http:// embeds von z.B. alten Google Maps Projekten, extern genutzte Services, Einbindungen von Inhalten noch über meine alte Domain hannes-schurig.de, externe Inhalte in Kommentaren usw.
Ich habe hier durchaus 2-3 Stunden verbracht, alte Blogartikel zu bearbeiten, Links zu korrigieren, meine alte Domain überall zu ersetzen, Kommentare zu korrigieren und mehr.
Nach 4-5 Iterationen über 3 Tage ist meine CSP nun ganz gut und die letzten 24 Stunden ergaben nur noch Reports, die geblockt werden können. Es verbleiben Logs von geblockten Domains wie countmake.cool, loadsource.org und eluxer.net – fragt mich nicht, was das ist. Manche Blocks kommen durch data, blob oder chrome-extension, ich denke das ist auch okay zu ignorieren.

Mit dieser Endfassung bin ich nun also ganz zufrieden und werde diese nun endgültig aktivieren:

<IfModule mod_headers.c> 
  Header always set Content-Security-Policy-Report-Only: "default-src 'self'; \
script-src 'self' 'unsafe-inline' 'unsafe-eval' www.google-analytics.com https://*.googleapis.com https://www.google.com https://www.gstatic.com https://*.vgwort.de https://*.it-stack.de; \
img-src 'self' https://*.gravatar.com https://*.w.org https://*.wordpress.org www.google-analytics.com https://*.vgwort.de https://www.gstatic.com https://*.it-stack.de data:; \
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com https://*.it-stack.de https:; \
font-src 'self' data: https:; object-src 'none'; \
child-src 'self' https://www.google.com https://*.youtube.com https://*.it-stack.de https:; \
frame-src 'self' https://www.google.com https://*.youtube.com https://*.it-stack.de https:; \
worker-src 'self' https://www.google.com https://*.youtube.com https://*.it-stack.de https; \
connect-src 'self' wss://it-stack.de www.google-analytics.com https://*.vgwort.de; \
report-uri https://report.tld/report.php"
</IfModule>

Die Backslashes am Ende der Zeilen ermöglichen Zeilenumbrüche in .htaccess Dateien zur besseren Lesbarkeit.

3.2 Verstehen

Ein paar kleinere Hinweise oder Ergänzungen dazu:

default-src ’self‘ wird angewendet, wenn eine andere Direktive, die für eine Anfrage gebraucht wird, gar nicht vergeben wurde. Ist eine Direktive gesetzt, wird default-src komplett überschrieben, dortige Werte werden nicht vererbt. Beispiel: img-src abc.com würde das ’self‘ von default-src nicht vererben, ’self‘ sollte daher fast immer mit angegeben sein.

Mir ist klar, dass unsafe-inline/-eval die größte Schwachstelle der CSP sind, allerdings auch das größte Problem bei WordPress Blogs mit etlichen Plugins, Google Analytics und mehr. Der Aufwand, diese zwei Attribute zu entfernen, kann sehr aufwändig und langwierig werden. Ich betrachte diese CSP jetzt vorerst als (wenn auch schon fortgeschrittenes) MVP – minimum viable product 😉

CSS-Stylesheets wirken eher harmlos, enthalten schließlich nur kosmetische Informationen, wieso einschränken? Es ist nicht zu unterschätzen, wieviel Spionage auch durch CSS-Angriffe wie z.B. „CSS Exfil“ möglich ist.

Ebenso Fonts, ist das nicht etwas too much? Nein, auch Fonts können zu Keyloggern umfunktioniert und müssen daher ebenso gut eingeschränkt werden.

child-src ist noch CSP Version 2 und wird angeblich (laut dieses Validators) in Version 3 durch frame-src und worker-src ersetzt. Ich habe also vorsichtshalber einfach mal alle drei Direktiven so gesetzt. Parallel am besten immer noch mit Google’s Validator testen.

4. Aktivieren

Nachdem die CSP nun definiert und einige Stunden ohne neue benötigte Regel im Testbetrieb lief, kann sie nun aktiviert werden. Dazu einfach nur Content-Security-Policy-Report-Only in Content-Security-Policy umschreiben und fertig. Beobachtet selber noch einmal die Webseite, auch das Admin Backend und wenn alles funktioniert, ist es geschafft!

Ich werde vorerst die Log noch im Blick behalten, bin aber erstmal froh, auch diesen Punkt soweit erledigt zu haben:

Es wird langsam… 3 Security Header gesetzt, CSP ist neu

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:

Ich habe leider im Sommer diesen Jahres mein Handy im See versenkt. Nein, es war kein Produkttest eines wasserfesten Telefons – „huch“, weg und futsch. Doof gelaufen. Aber dafür hat man ja schließlich Cloud-Backups, richtig? Nur doof wenn nicht… Ich habe dank Google automatisch schon viele Daten in der Cloud – Systemeinstellungen, Kontakte, WLAN-Logins, den ganzen Kleinkram eben. Aber Fotos, Videos und Whatsapp Medien habe ich aus Speicherplatzmangel und Privatsphärebedenken nicht in die Cloud gehoben. Nun ist alles weg und ich ärgere mich. Zeit für eine Lösung!

luckycloud-sicherer-deutscher-cloud-speicher-im-test-imgix-404361-unsplash

Cloud Services made in Germany

Warum also nicht ein Cloudanbieter, aus Deutschland, datenschutzrechtlich sicher und verschlüsselt, mit flexiblen Kosten, ohne Abstrichen bei den Features? Volltreffer!
luckycloud ist ein junges Berliner Unternehmen und bietet deutsche und sichere Cloud-Dienstleistungen an: Aktuell handelt es sich um sicheren Speicherplatz, E-Mails und Kollaborationstools. Außerdem bietet luckycloud schon eigenes Webhosting an (noch nicht offiziell, schreibt eine Mail bei Interesse) und arbeitet gerade an einem Kalender und einer Kontaktsynchronisation. Im Vergleich zu anderen Anbietern hat luckycloud jedoch ein Fokus auf Datenschutz und Sicherheit. Mehr dazu später. Grundsätzliches Interesse? Aktuelle Angebote ermöglichen noch bis Mitte September einen Rabatt.

Weiterlesen

Gibt es noch Privatsphäre bei Google?

Themen wie Datensammler und Privatsphäre bei Google sind immer in der Diskussion. Eines dieser Themen, wenn auch ein alter Hut, möchte ich heute als Einstieg in die Google Privatsphäre-Überprüfung nutzen. Gestern sah ich ein Video, in dem es um die „Anschuldigung“ ging, dass Google dauerhaft und heimlich alle verfügbaren Audioquellen anzapft, verarbeitet und Werbung daraufhin ausrichtet. Laptopmikro, Headset, Android Smartphone, solche Mikros als Quellen. Hier das Video:

Klarer Hinweis: Der Autor hat selbst in seinen Video-Anmerkungen darauf hingewiesen, dass der Test nicht wissenschaftlich genug war. Der Youtube Stream dieses Versuchs könnte Schuld gewesen sein. Ein anderes Video, als Antwort auf den ersten Test, geht wissenschaftlicher vor, hat aber ebenfalls Schwächen in der Ausführung. Der Autor dieses Videos bemerkt die zeitliche Verzögerung der Auswirkungen und die Art des Werbungstests und in den Kommentaren gibt es weitere Hinweise.

Daten kontrollieren und Datensammler einschränken

Google sammelt viele Daten, kein Zweifel. Trotz allem: Einige Datensammler lassen sich konfigurieren oder deaktivieren, viele von euch vorhandenen Daten zeigt euch Google ebenfalls. Dafür gibt es einige Seiten, Tools und Einstellungsdialoge, die ihr unbedingt als starker Google Nutzer kennen und benutzen solltet. Ihr müsst für die folgenden Links mit eurem Google Account angemeldet sein:

  1. Zentrale Schaltstelle ist die Seite eures Google Accounts, in diesem Artikel mit Fokus auf die Kategorie „Persönliche Daten & Privatsphäre“. Schaut euch alles mal an, gibt viel zu Entdecken.
  2. Zum Thema: Die Seite eurer Aktivitätseinstellungen. „Aktivitäten“ sind also Seite und Bereiche, in denen ihr Daten generiert. Hier konfiguriert ihr:
    1. die Unterkategorien Web- und App-Aktivitäten (Chrome-Verlauf und mehr) über alle verbundenen Geräte dieses Google Kontos hinweg,
    2. den Standortverlauf (wann wart ihr wo wie lange usw., Deaktivierung überlegungswert),
    3. die Geräteinformationen (enthält Cloud-Daten eurer Mobilgeräte, sollte aktiviert bleiben), 
    4. die Sprach- & Audioaktivitäten, vor allem mit Blick auf diesen Artikel zu überdenken, ob man Google das erlaubt – wobei es offiziell nur aktiv ist, wenn „Ok Google“ oder das Mikrofonsymbol benutzt wird, also mit Nutzerinteraktion,
    5. sowie zwei Youtube Settings, den Suchverlauf und Wiedergabeverlauf.
  3. Diesen Punkt habe ich in einem anderen Artikel schon einmal im Detail beschrieben und Tipps gegeben, aber der Vollständigkeit halber und da es leichte Änderungen gibt: Der Privatsphärecheck durchläuft 6 Schritte: Die genannten Aktivitätseinstellungen von Punkt 2, Einstellungen von Youtube Settings und Google Fotos, Erreichbarkeit/Auffindbarkeit, Google Plus sowie Werbungseinstellungen (Personalisierte Werbung usw.)
  4. Diese Übersicht enthält alle eure Aktivitäten (also von Google gesammelte und frei einsehbare Daten), schaut hier mal durch, ob ihr Inhalte findet, die ihr nicht gesammelt haben wollt. Anpassungen dann siehe Punkt 2 und 3.
  5. Weiter unten auf der „Persönliche Daten & Privatsphäre“ Seite werden weitere Informationen über euch angezeigt, damit verbunden einige weitere Einstellungsseiten. Unter anderem eure „Über mich“ Seite, Sozialen Empfehlungen und allgemeine Sucheinstellungen.
  6. Außerdem: Das Dashboad – ein großes Tool mit zentraler Bedeutung. Es enthält noch einmal alle Daten und Einstellungen eures Accounts in einer großen Übersicht, von der aus ihr schnell und einfach diese Daten einsehen könnt.
  7. Ihr könnt sehr einfach von allen Daten ein Backup erstellen – einfach so zur Sicherheit oder bevor ihr beispielsweise eure Google Einstellungen ändern oder den Google Account schließen wollt.
  8. Letzter interessanter Punkt, den ich auch noch nicht kannte: Der Kontoinaktivitäts-Manager. Diese(r) Manager, also letztlich Personen/Kontakte, erhält Zugriff auf deinen Google Account, wenn du diesen für eine definierte Zeit (3-18 Monate) nicht verwendest. Die schlüssigsten Erklärungen dafür sind: Google komplett den Rücken zugekehrt ohne vorher zu löschen, schwere Krankheit / Gedächtnisverlust o.Ä. und Tod. Ich halte es also für keine schlechte Idee, die wichtigste(n) Person(en) von euch (Eltern, Familie, Frau/Mann…) dort zu registrieren. Es könnte den „Hinterbliebenden“ (in welcher Form auch immer) in dem Moment weiterhelfen.

Soweit… Ich denke mal die wichtigsten Punkte der Privatsphäre sind angesprochen. Über den Bereich „Anmeldung & Sicherheit“ in eurem Konto lässt sich ebenfalls viel erzählen, aber das in einem gesonderten Artikel.

GMail Speicherplatz

GMail (bzw. „Google Mail“) war bereits mit dem Start der Beta Phase 2004 die Top 1 im E-Mail Speicherplatz, als GMX, web.de & Co gerade mal noch wenige Megabyte zur Verfügung stellten. GMail erhöhte den Speicherplatz in kleinen Schritten immer weiter bis 15GB im Jahre 2013 und war damit immer unangefochtener Spitzenreiter. (via) Seit 2013 gibt es jedoch keine Speicherupgrades mehr, außer durch spezielle Aktionen. Beispielsweise hat Google damals seinen neuen Sicherheitscheck (mehr zum Thema Google Sicherheit hier) angepriesen und 2GB mehr Speicherplatz für alle Anwender des Checks verteilt. Nur dank dieser Aktion bin ich noch nicht an mein Speicherlimit gelangt.

gmail-mails-aelter-als-x-tage-automatisch-loeschen-labels-speicherplatz-knapp

Nichtsdestotrotz ist es irgendwann mal soweit: Der Speicherplatz wird knapp! Sinnvoll ist es, an der Stelle anzupacken, die den größten Anteil des Speicherplatzverbrauches verursacht. Das werden die Mails mit Anhängen sein. Ausmisten befreit hier schnell einige hundert Megabyte.

Für diese Aufgabe wird das Google Sheets Addon „Save Email and Attachments“ benutzt. Das Addon kann nicht nur Anhänge und Mails herunterladen, es kann mit Hilfe von Regeln flexibel angepasst werden und die Downloads werden direkt in einen Google Drive Ordner kopiert. Anschließend lassen sich die Anhänge aus diesem Ordner einfach herunterladen und die entsprechenden Mails löschen.

Mail Anhänge aufräumen

Im ersten Schritt wird das Addon autorisiert und dann geht es auch schon los, die Regel für den Download wird definiert. Welches Label, Von, An, Betreff, Datum und ähnliche Angaben schränken die Auswahl der Mails ein. Mit der Option „Save email body“ wird jede E-Mail, die auf die Suchkriterien der Mail zutrifft, als PDF heruntergeladen. Hübsch ist diese PDF-Ansicht nicht, nutzt lieber MailStore Home oder andere Tools für einfache Mailbackups. Wichtiger dagegen die Option „Save file attachments“ – hiermit werden E-Mail-Anhänge heruntergeladen. Ohne die „email body“ Option werden hier also wirklich nur Anhänge geladen, keine Mails dazu. Am Ende wird noch der Google Drive Zielordner bestimmt – wenn ihr hier einen neuen Ordner benutzen wollt, müsst ihr den vorher über Drive händisch erstellen und dann dort auswählen.

gmail-mails-anhaenge-attachments-download-regel-anlegen

Erstellte Regeln werden stündlich automatisch im Hintergrund ausgeführt. Das Addon kann also auch als eine Art Anhang-Backup benutzt werden. Alternativ lässt sich die Regel auch direkt manuell ausführen, was zum einmaligen Aufräumen sinnvoller sein mag. Die Mails werden verarbeitet, die Anhänge zu Drive transferiert und der Fortschritt in einer Tabelle visuell festgehalten:

gmail-mails-anhaenge-attachments-download-tabelle

Die letzten zwei Schritte sind abhängig davon, ob ihr Speicherplatz freiräumen wollt. Da der Speicherplatzverbrauch von GMail und GDrive zusammengerechnet werden, müsst ihr die Anhänge aus Drive herunterladen UND die Mails mit diesen Anhängen löschen, damit der Speicherplatz final in GMail frei wird. 

Anhänge aufräumen ist eine der Möglichkeiten, den GMail Speicherplatz wieder zu befreien. Im nächsten Artikel gehe ich auf das automatische Bereinigen alter Mails ein.

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.

Amazon hat schon lange eine Größe erreicht, die sich ohne Hilfe schwer überblicken lässt. Dutzende Anbieter für ein Produkt, ständig wechselnde Preise, neu vs. gebraucht, ständig wechselnde Angebote praktisch im Minutentakt. 400 Seiten voller reduzierter Artikel – keine Suchfunktion, nur unflexible vordefinierte Filter, keine große Hilfe. Amazon möchte nicht, dass wir die preislich günstigen Angebote nach dem durchsuchen, was wir gerade brauchen?
Der Amazon Assistent ist ebenfalls ein Lacher; eine Nullnummer, mit praktisch keinen sinnvollen Funktionen. Einzig ein Einstiegstor für Amazon, das auch noch euer Surfverhalten beobachten und auswerten muss, um zu funktionieren.

Aber nicht verzagen! Es gibt Hilfe, mit der man auf Amazon richtig clever shoppen kann. Angebote durchsuchen, Preise überwachen, Benachrichtigungen und eine Menge an Daten zu jedem Produkt. keepa.com ist ein Anbieter für besagte Funktionen rund um Amazon. Auf der Webseite können alle Deals mit flexiblen Filtern, Kategorien und Suchfunktion durchsucht werden – praktisch, wenn der Einkauf sofort oder sehr zeitnah erfolgen soll. Einfach mal stöbern und mit den Filtern spielen:
amazon-deals-preise-überwachen-clever-shoppen-mit-keepa.com-deals-search

Ist der Wunsch etwas konkreter und mehr Zeit vorhanden, empfiehlt sich die Preisbeobachtung mit Benachrichtigung. Auch hier kann der Weg über keepa.com erfolgen, wobei ich hier direkt die Browser-Erweiterung empfehle. Diese baut alle wichtigen Keepa Funktionen direkt in die Amazon Seite ein. Als Vorbereitung dienen der Preisgraph und der „Data“ Tab. All die Informationen können helfen, zu bestimmen, welcher Preisabfall zeitnah geschehen könnte und welcher Preis dabei mindestens erreicht wird:
amazon-deals-preise-überwachen-clever-shoppen-mit-keepa.com-graph

Nun kann mit diesen Informationen sehr einfach ein Preisalarm gesetzt werden. Dies geht entweder als Gast, ohne Account – die Einstellungen sind dann lokal nur für den PC und bis zum nächsten Cache-Clean. Oder man registriert sich bei Keepa, ist ja kein großer Deal (:D sorry, der musste sein)… Anschließend können für diesen Preisalarm unterschiedlichste Benachrichtigungen gesetzt werden:
amazon-deals-preise-überwachen-clever-shoppen-mit-keepa.com-trackamazon-deals-preise-überwachen-clever-shoppen-mit-keepa.com-notifications

Wem das nicht reicht, es gibt auch noch einen Facebook Chat Bot, der auf Wunsch Preisinformationen und Angebote vorbeischickt, Produktfinder und Top-Listen. Praktischerweise lassen sich auch ganze Amazon Wunschlisten importieren und direkt mit Preisalarmen versehen. Für neueste Updates und Tricks kann ein Blick in die Community nicht schaden. All das wird möglich dadurch, dass Keepa über 460.000.000 Produkte auf 12 Amazon-Länder-Seiten durchsucht… irre! Auf Anfrage lässt sich diese gewaltige Datenbank über eine API anzapfen und verarbeiten.

Beeindrucken, Lesezeichen, ab jetzt cleverer Amazon shoppen!