Sicherheit

Aus wiki.archlinux.de
Version vom 18. Mai 2022, 11:12 Uhr von Dirk (Diskussion | Beiträge) (Unvollständig-Hinweise im Artikel raus, da der einzige Autor seit 5+ Jahren nicht mehr im Wiki aktiv ist)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Dieser Artikel dient als Einstiegspunkt und Zusammenfassung von Themen wie Computersicherheit, Anonymisierung und Verschlüsselung.

Allgemeines

Daten sind heute nirgends sicher, es sei denn, man sichert sie explizit.

Ziel muss sein (und bleiben!), dass unabhängig von staatlichen Maßnahmen und Garantien Daten nur von denjenigen Personen gesehen und geändert werden können, die dafür autorisiert sind. Ein Staat kann durch Definition von Grundrechten und Bereitstellung einer entsprechenden Gesetzeslage zwar dafür sorgen, dass Datenklau als Straftat verfolgt wird - das Schloss an der Tür muss man aber dennoch selbst bereitstellen und auch zuschließen und vielleicht auch noch die gute alte Türkette dazu einhängen, ganz wie im realen Leben.

Interesse an Daten und Metadaten kommt heute aus ganz verschiedenen Richtungen (alles ohne Wertung).

  • harmlose Unbefugte (neugierige Kollegen, Familienangehörige, Nachbarn usw.)
  • legale, aber unangenehme kommerzielle Datensammler (vor allem zu Werbezwecken, insbesondere Spammer)
  • Arbeitgeber, möglicherweise auch Banken, Versicherungen und Behörden
  • wirtschaftliche Konkurrenten
  • investigative Journalisten
  • in- und ausländische Geheimdienste
  • Cracker und echte Kriminelle

Selbst wenn wirksamer Schutz vor Geheimdiensten offenbar zumindest theoretisch (in Einzelfällen wahrscheinlich auch praktisch) als unzuverlässig gelten muss, so kann man allerdings vielen anderen Interessenten einen Riegel vorschieben. Dazu genügen oft schon vergleichsweise einfache Maßnahmen.

Das wesentliche Argument zum Schutz der eigenen Daten lautet, dass nicht vorhersagbar ist, was mit Daten, über die man die Hoheit verloren hat, einmal geschieht, für wen sie in irgendeinem womöglich weit in der Zukunft liegenden Augenblick einmal interessant werden könnten und was er damit anstellt. Das ist ganz unabhängig vom Dateninhalt, von ihrem heute vermeintlichen Wert bzw. ihrer Banalität. Ferner betreffen Daten (gerade Metadaten bei Kommunikation) sehr oft noch weitere Personen, die man möglicherweise mit hineinzieht oder die einen mit hineinziehen, wohinein auch immer. Man hat auch diesen gegenüber einen Teil Verantwortung.

Einige der im weiteren vorgestellten Tipps mögen banal klingen. Sehr viele werden jedoch nur allzu oft missachtet.

Verhaltensweisen

Wesentliche Aspekte des Datenschutzes hängen vom Verhalten des Benutzers ab, vor allem beim Browsen im Internet und beim Mailen. Jemand, der vielen seinen Wohnungsschlüssel gibt, braucht sich nicht zu wundern, wenn es eines Tages in seiner Wohnung anders aussieht als erwartet. Die folgenden Tipps sind als Denkanstöße gemeint.

große Netzwerkanbieter meiden
Gemeint sind die bekannten großen Internet-Konzerne: Google (mit seinen zahlreichen Derivaten: Blogger.com, YouTube, Picasa usw.), Yahoo, Amazon, Facebook, eBay, Microsoft (Bing), Twitter, Instagram u.v.a. Wer auf Webseiten solcher Anbieter unterwegs ist, muss damit rechnen, ausführlich protokolliert zu werden - Wissen über den Benutzer aufzubauen und dauerhaft zu speichern, ist ja ein wesentlicher Teil des Geschäftsmodells. Die Standardsuchmaschine zu wechseln, ist eine einfache Sache.
Anmeldungen
  • Account notwendig?
Grundsätzlich stellt sich beim Besuch von Internetseiten die Frage, ob Registrieren wirklich nötig ist. Der Sinn eines Accounts ist es, Aktivitäten auf einer Webseite einem sehr konkreten Benutzer zuzuordnen.
  • Anzahl der Accounts begrenzen und diese irgendwo festhalten
Wenn es sich nicht vermeiden lässt, sich irgendwo anzumelden, um mit einer Webseite überhaupt etwas Brauchbares anzustellen, so sollte man die Anzahl dieser Anmeldungen möglichst gering halten und irgendwo aufschreiben. Letzteres ist ohnehin eine gute Idee, wenn man Passwörter wechseln will. Tipp: Passwort Manager verwenden.
  • für verschiedene Accounts verschiedene Benutzernamen verwenden
Das erschwert die Zuordnung zu einer konkreten Person.
  • 2FA oder MFA verwenden
Die Verwendung von Zwei- oder Multi-Faktor-Authentifizierungslösung einschalten/aktivieren, wenn es der Betreiber anbietet.
  • wenn möglich, ausloggen
Wer beispielsweise einen Google-Account besitzt und damit immer angemeldet ist, erlaubt damit nicht nur Google, Zugriffe auf Google-Seiten zu protokollieren, sondern auch sehr vielen anderen, die den Google-Account zur Benutzerauthentifizierung nutzen. Ausloggen und die restlichen Cookies dieser Seite löschen, wann immer möglich, ist die beste Idee.
  • nicht mehr benötigte Accounts löschen
Wenn man sicher ist, einen Account nicht mehr zu benötigen, dann ist es zumindest eine Option, diesen auch zu löschen. Man kann vorher darin noch Daten löschen. Ob diese damit wirklich verschwinden, einmal dahingestellt. Zumindest mittelfristig werden diese wahrscheinlich irgendwann gelöscht.
  • Accounts nicht mit anderen Personen teilen
  • Accounts nicht miteinander verknüpfen
  • Passwörter
    • gleiche Passwörter nicht in mehreren Accounts verwenden
    • Passwörter regelmäßig wechseln, dabei auch deren Schema ändern
    • kompliziertere Passwörter bilden
    • Passwörter nicht weitergeben
E-Mail-Adressen
  • konsequent mehrere E-Mail-Adressen und Aliase für verschiedene Zwecke verwenden
  • sich in bestimmten Fällen temporäre E-Mail-Adressen holen
  • niemals eine E-Mail-Adresse mit anderen Personen teilen
insbesondere sind Familien-email-Adressen - die-meyers@hotmail.com - gar keine gute Idee
  • nicht andere Personen beauftragen, mal im Postfach für Ordnung zu sorgen, da stimme etwas nicht usw., und ihnen dazu das Passwort geben
  • darauf drängen, nicht in Mail-Verteilern aufzutauchen
emails per Verteiler oder langen CC-Listen zu bekommen, ist nicht nur unangenehm und lästig, es verbreitet auch unkontrolliert die eigene E-Mail-Adresse und es schafft idiotische Querverbindungen zu anderen Personen, mit denen man überhaupt nichts zu tun hat. Man muss Personen, die solche Verteiler benutzen - einige tun das notorisch - mit deutlichen Worten darauf hinweisen, dass man diesen Unsinn nicht möchte.
  • selbst nicht E-Mails "An alle" schicken
man legt dadurch auf einen Schlag einen Großteil seiner Kontakte offen
  • keine Adressbücher aufbauen
insbesondere nicht online, automatische Einträge unbekannter Adressen ins Adressbuch strikt unterbinden - Adressbücher sind goldwert
lokale Metadaten
  • Browser-Cache klein halten
Es hat generell keinen großen Sinn, einen Browser-Cache von hunderten von MB zu haben. Wer nicht häufig und viele verschiedene große Bilder anschaut, kommt bereits mit 2 oder 5 MB gut hin. Der Vorteil ist, dass generell nur wenige Daten überhaupt auf der Platte liegen und dort liegen bleiben. In Abhängigkeit von der Übertragungsrate kann man den Cache möglicherweise ohnehin komplett abschalten, man wird es vielleicht nicht einmal bemerken.
  • Browser-Cache und Temp-Verzeichnis(se) leeren
In diesen Verzeichnissen liegen sehr viele interessante Daten. Aus Sicherheitsaspekten ist es ratsam, beide möglichst oft zu leeren, den Cache am besten am Ende jeder Sitzung. Der primäre Sinn des Browser-Caches, nämlich die Geschwindigkeitssteigerung, ist im Zeitalter immer schnellerer Leitungen ohnehin im Schwinden.
  • Browserdaten aufräumen
Zusätzlich zum Webseiten-Cache speichert ein Browser zahlreiche Metadaten dauerhaft, die ebenfalls viel Interessantes enthalten, vor allem Cookies, aber auch Logins und Passwörter. Mozilla-Browser erlauben beispielsweise über den Menüpunkt "Tools|Data Manager" einen Einblick. Man gelangt dort beispielsweise an die Such-Historie und viele Formulardaten. Aus Sicherheitsgründen sollte man dort regelmäßig aufräumen und nicht mehr benötigte Daten löschen. Das Schlimmste, was dabei passieren kann, ist, dass man sie auf irgendeiner Webseite neu eingeben muss.
sensible Daten grundsätzlich nicht im Netz ablegen
Cloud hin, Dropbox her - der beste Weg, all die damit zusammenhängenden Probleme zu vermeiden, ist, Daten nicht ins Netz auszulagern, nicht einmal Adressbücher, Kontaktlisten, den Kalender und ähnliche Dinge.
wichtige Zugangsdaten nicht unverschlüsselt speichern
Zugangsdaten sind heikel. Passwörter können kompliziert sein, generierte private Schlüssel sind es ohnehin. Der sicherste Ort für solche Daten ist wahrscheinlich ein kleiner Stick, den man nur bei Bedarf hineinsteckt. Am besten verschlüsselt man diesen noch.
angebotene Browser-Software-Installationen nicht annehmen
Eigentlich selbstverständlich. Ebenso selbstverständlich ist leider das Angebot an "ganz wichtigen" Leisten und zusätzlichen Buttons. Wer sich solche Browser-Software leichtherzig installiert, holt sich Kuckuckseier ins Haus.
Sicherungsmaßnahmen ergreifen
  • PCs rundherum absichern
Ein PC, auch ein Linux-PC, besitzt mehrere, mehr oder weniger offene Tore, vor allem Browser, Mail-Client und diverse kleinere Programme (ftp, wget, Bittorrent, Multimediastreaming usw.). Einige davon lassen sich mit wenig Aufwand recht gut schließen, andere erfordern einen höheren Aufwand und einige Kenntnis. Und man zahlt wahrscheinlich noch dafür in Form von geringerer Bandbreite. Das Gute ist, dass sich Vieles recht gut skalieren lässt und man sein persönliches Sicherheitslevel gut steuern kann.
  • Mobiltelefone besser (!) absichern als PCs
Für Mobiltelefone gilt zunächst alles bisher gesagte, zudem haben sie aber im Hinblick auf Sicherheit drei weitere wesentliche Eigenschaften:
  • sie sind sehr klein und transportabel, gehen also womöglich leicht verloren!
  • sie generieren und verraten Standortdaten
  • sie bieten zwar einige, oft aber weniger Sicherungs- und Konfigurationsmöglichkeiten
Die Absicherung von Mobiltelefonen, die Daten tragen, mit denen man auch an andere Systeme geht, insbesondere Firmendaten, verdient deshalb besondere Beachtung.
als Vorbild wirken
Ein wesentlicher Punkt. Man schafft durch Vorbildwirkung Sensibilisierung und Bewusstsein. Wer HTML-Mails verschickt, braucht sich nicht zu wundern, wenn er auch welche bekommt. Behutsam auf seine Umgebung einzuwirken, ist durchaus eine gute Idee.

Sicher unterwegs im Netz

Es geht hier um clientseitige Sicherheit. Dieser Abschnitt behandelt nicht die Absicherung von Webservern u.ä. gegenüber Attacken von außen.

Browser

Tests durchführen

Einen sehr guten Test darüber, was der eigene Computer an Informationen preisgibt, mit Bewertungen und zahlreichen erläuternden Hinweisen dazu findet man auf der Website des JonDonym-Projekts. Es lohnt sich auf jeden Fall, diesen Test einmal durchzuführen, um sein Gefährdungspotential zu erkennen.

Was man beeinflussen kann

Standardsuchmaschine wechseln
Praktisch jeder Browser sucht standardmäßig mit Google und bietet zur Auswahl noch weitere problematische Suchmaschinen an, wie beispielsweise Bing oder Yahoo. Vielen Benutzern ist dabei nicht klar, dass auch Eingaben oben in der Such- oder Adressleiste an eine voreingestellte Suchmaschine gehen. Diese Suchmaschinen zeichnen das Suchverhalten auf und gewichten und filtern die Ergebnisse. Die Suchmaschine zu wechseln, ist eine sehr einfache Sache. Folgende sind zu empfehlen:
Google umgehen!
Alle „großen“ Browser (Mozilla, Opera, Chrome, Chromium, Safari) verwenden eine voreingestellte Technik, um „attackierende Webseiten“ zu erkennen. Diese Prüfung wird von Google durchgeführt. Der Browser generiert zu jeder HTTP-Anfrage zuerst einen Hash-Wert und schickt diesen an Google. Google prüft den Hash-Wert anhand einer Blacklist und sendet dann sein OK oder einen Fehlercode zurück, so dass der Browser reagieren kann, bevor er die Seite selbst vom jeweiligen Webserver holt. (Microsoft verwendet mit SmartScreen eine eigene Technik, die ebenfalls auf Hash-Werten beruht.)
Dass die generierten Hash-Werte eine Webseite tatsächlich eindeutig kennzeichnen, wird gelegentlich bestritten, nicht zuletzt von Protagonisten des Verfahrens. Es liegt jedoch sehr nahe, dass die Erkennung der Webseite hinreichend gut gewährleistet ist, sonst würde ja damit keine geeignete Überprüfung hinsichtlich attackierenden Codes oder Phishing stattfinden können. Dieses Verfahren ermöglicht Google also sehr wahrscheinlich eine lückenlose Überwachung des clientseitigen Netzverkehrs.
Ferner finden sich beispielsweise im Google Safe Browsing API Aufrufe, bei denen die zu prüfende URL direkt (!) an Google übermittelt wird, sie wird lediglich entsprechend bestimmter Notwendigkeiten für die Übertragung codiert.
Abschalten!
HTTPS verwenden
Sehr viele Anbieter von Web-Inhalten stellen für ihre Seiten zwei Zugriffsprotokolle zur Verfügung: HTTP und HTTPS. Ersteres basiert auf offen lesbaren Textnachrichten, letzteres setzt auf SSL-verschlüsselte Kommunikation zwischen Browser und Webserver, wobei der Browser durch Zertifikatsprüfung auch das Vertrauen in die Verbindung weitgehend sicherstellt. Der Benutzer hat oft die Wahl, welches Protokoll sein Browser verwendet, und oft nimmt man HTTP. Es gibt Browser Plugins, die (wenn möglich) automatisch eine sicherere HTTPS-Verbindung aufbauen, auch wenn man eine HTTP-Adresse eingibt.
Cookies eindämmen
Sehr viele Webseiten speichern Cookies, kleine lokale Datenbestände, auf die die Webseite später wieder zugreifen kann. Diese Datenmengen sind aber auch für andere interessant. Sie verraten einiges über das Benutzerverhalten, die Historie, seine Eingaben usw. Ratsam ist, das Anlegen von Cookies durch Webseiten zu kontrollieren und zu beschränken, sowohl in der Anzahl wie auch in der Dauer ihres Bestands. Alle Cookies generell zu blocken, wie Browser das anbieten, wird sich kaum machen lassen - viele Seiten funktionieren einfach nicht, ohne ein Minimum an Cookies. Aber diese wenigen kann man unter Kontrolle behalten. Es gibt für jeden Browser Plugins, die diese Aufgabe übernehmen.
JavaScript eindämmen
JavaScript ist Code auf Webseiten, der theoretisch alles kann, und zwar ohne dass der Benutzer viel davon bemerkt. Das ist sehr problematisch. Browser Plugins ermöglichen, JavaScript abzuschalten. Das Problem dabei ist, dass überraschend viele Webseiten dann fast gar nicht mehr zu bedienen sind. Man muss deshalb sehr selektiv beim Abschalten vorgehen und vielleicht in Fällen, in denen man JavaScript erlauben will, auch genau nachschauen, was dieses tut.
Browser Tracking vermeiden
Einige Browser ermöglichen das Setzen eines speziellen "Do not track"-Headers in HTTP-Anfragen. Damit soll auf dem angefragten Webserver verhindert werden, dass dieser Protokollierungen durchführt. Das beruht zwar auf Vertrauen, kostet aber auch nichts, und ist drum eine gute Idee.
Header in HTTP-Anfragen prüfen
Generell kann man sich um die Header in den vom Browser abgesetzten HTTP-Anfragen Gedanken machen. Es stehen eine ganze Reihe interessanter Informationen darin, oft der verwendete Browser, aber auch Bildschirmgröße, Betriebssystem, IP-Adresse, auch die Webseite von der man kommt u.a. Das alles gibt man stillschweigend von sich preis. Einen Überblick über diese Daten geben beispielsweise folgende Seiten: Zendas, Panopticlick, c2.com. Wer das nicht will, kann einen Proxy einsetzen, der als Filter dient und die entsprechenden, vom eigenen Browser erzeugten Zeilen aus den Anfragen herausnimmt, bevor diese hinaus ins Internet gehen.
versteckte Aktivitäten vermeiden
Webseiten bieten auch ohne Scripting einige Möglichkeiten, um im Hintergrund Dinge auszuführen, die man nicht bemerkt, in der Regel Rückmeldungen an den Webserver, z.B. Besucherzähler und andere Statistiken. Es gibt Browser Plugins, die so etwas offen legen und auch unterbinden.
binäre Inhalte abschalten
Oft sind HTML-Webseiten nur ein äußerer Rahmen. Im Innern befindet sich Flash, ActiveX oder ein ähnliches Format, was aus Sicherheitsaspekten sehr undurchsichtig ist. Wer wirklich Wert auf Sicherheit legt, muss solche Inhalte konsequent abschalten.
VPN verwenden
siehe OpenVPN
siehe ProtonVPN
Namensauflösung verschlüsseln
siehe Firefox DNS über HTTPS (DoH)
Anonymisierungsnetzwerke verwenden
Ein sehr mächtiges Instrument stellen sog. Anonymisierungsnetzwerke dar. Das bekannteste, funktionsreichste und inzwischen auch brauchbarste ist das Tor-Netzwerk. Ein anderes, allgemein verwendbares und kostenfreies Netzwerk ist I2P, das allerdings recht langsam ist. Es gibt zudem mehrere teilweise oder generell kostenpflichtige Netzwerke wie Jondonym sowie spezielle Netzwerke, die nur file sharing oder bestimmte Protokolle unterstützen wie z.B. GNUnet.
Das Prinzip dieser Netzwerke besteht darin, die vom Benutzer getätigten (HTTP-)Anfragen über genügend (aber nicht zu viele) Proxys zu leiten, so dass deren Rückverfolgung selbst mit großem Aufwand schwierig bis unmöglich wird. Das hat natürlich nur dann einen Sinn, wenn man sicher sein kann, dass die eigenen Anfragen nicht wiederum die eigene IP-Adresse in einem Header beinhalten. Das Verfahren geht einerseits erheblich auf Kosten der Geschwindigkeit, andererseits aber womöglich auch auf Kosten der Funktionalität, weil natürlich dabei der konkrete Standort des Benutzers verloren geht, Webseiten aber möglicherweise davon abhängen, z.B. Spracheinstellungen, Zugriffsrechte auf geschützte Inhalte usw. Dessen muss man sich bewusst sein. Es ist allerdings inzwischen problemlos möglich, selbst Online Banking über beispielsweise Tor abzuwickeln, ohne dass die Serverseite sich darüber beschwert.
Es ist davon auszugehen, dass diese Netzwerke inzwischen von Geheimdiensten unterwandert sind, d.h. dass Geheimdienste eigene Knoten im Netzwerk betreiben und den darüber laufenden Verkehr aufzeichnen. Es ist allerdings aufgrund der sehr dynamischen, dezentralen und internationalen Gestalt solcher Netze schwer vorstellbar, dass irgendwer die Kontrolle über das gesamte Netz oder zumindest alle Ein- und Ausgänge erlangt. Zudem senden diese Netze den internen Datenverkehr verschlüsselt. Es sollte sich also nach wie vor ein recht guter Schutz ergeben. Ein Statement dazu direkt von Tor hier.

Firefox, SeaMonkey

Firefox und SeaMonkey unterscheiden sich im Hinblick auf Sicherheitsaspekte nur wenig. Ein wesentlicher Unterschied ist, dass nicht alle Plugins (hier: AddOns) kompatibel sind. Es gibt wesentlich mehr für Firefox als für SeaMonkey, aber man findet oft für SeaMonkey ein Firefox-Plugin, das entgegen aller Warnungen durchaus funktioniert.

Folgende AddOns sind für beide interessant:

uMatrix zur ausgesprochen komfortablen Kontrolle von Cookies, CSS, Plugins, Bildern, Scripts u.a., das AddOn leert auch zyklisch Cache und DOM storage und kann Hyperlink Auditing blockieren
uBlock origin zum listengesteuerten Blocking von Webseiten, vor allem für Werbung, Malware und Tracking
CookieFast zur Kontrolle von Cookies, ein bisschen wirkungsvoller als CookieSafe und CookieSafe Lite, die lassen sehr viel durch
CookieKeeper zur Kontrolle von Cookies, erlaubt das Schützen einzelner Cookies vor dem Gelöscht werden - damit wird es möglich, das Löschen von Cookies in regelmäßigen Abständen automatisch durchzuführen, einige jedoch zu behalten
FoxyProxy Standard zum Auswählen vorkonfigurierter Proxys, sehr nützlich im Zusammenhang mit Anonymisierungsnetzwerken
Privacy Badger zum Sichtbarmachen und Abschalten versteckter Aktionen auf einer Webseite
Ghostery zum Sichtbarmachen und Abschalten versteckter Aktionen auf einer Webseite
RequestPolicy zum Sichtbarmachen und Abschalten versteckter Aktionen auf einer Webseite, weit bessere Steuermöglichkeiten im Vergleich zu Ghostery
HTTPS-Everywhere wählt (wenn möglich) automatisch HTTPS, auch wenn eine HTTP-Adresse eingegeben wurde
NoScript zum selektiven Abschalten von JavaScript
verschiedene Suchleistenplugins zum Wechsel der Standardsuchmaschine, die meisten Suchmaschinen bieten auf ihrer jeweiligen Homepage einen Link zur automatischen Installation

Folgende weitere Konfigurationen können manuell gesetzt werden:

Google umgehen bei Firefox:
in den Einstellungen, Tab Sicherheit, die beiden Häkchen bei
"Webseite blockieren, wenn sie als attackierend gemeldet wurde" und
"Webseite blockieren, wenn sie als Betrugsversuch gemeldet wurde" entfernen

bei SeaMonkey:

in den Einstellungen unter "Datenschutz & Sicherheit", dort die beiden Häkchen bei
"Als attackierend gemeldete Websites blockieren (Malware, Viren)" und
"Als Betrugsversuch gemeldete Websites blockieren (Phishing)" entfernen
"Do not track"-Header setzen bei Firefox:
in den Einstellungen, Tab Datenschutz, Verfolgung, den RadioButton auf
"Websites mitteilen, dass ich nicht verfolgt werden will" setzen

bei SeaMonkey:

in den Einstellungen und "Datenschutz & Sicherheit", dort das Häkchen bei
"Webseiten über Verfolgungs-Vorlieben informieren" entfernen
persistente Metadaten reduzieren about:config, dort dann dom.storage.enabled auf false setzen, das verhindert, dass der Browser zusätzlich zu Cookies noch weitere Metadaten dauerhaft speichert
Referer_Header abschalten about:config, dort dann network.http.sendRefererHeader auf 0 setzen

Chromium

siehe Chromium

Opera

Für Opera sind in den neueren Versionen (36ff) folgende AddOns interessant:

uMatrix zur ausgesprochen komfortablen Kontrolle von Cookies, CSS, Plugins, Bildern, Scripts u.a., das AddOn leert auch zyklisch Cache und DOM storage und kann Hyperlink Auditing blockieren
uBlock origin zum listengesteuerten Blocking von Webseiten, vor allem für Werbung, Malware und Tracking
Kanope zum An- und Abschalten des Tor-Netzwerks
Ghostery zum Sichtbarmachen und Abschalten versteckter Aktionen auf einer Webseite
HTTPS Everywhere wählt (wenn möglich) automatisch HTTPS, auch wenn eine HTTP-Adresse eingegeben wurde
Modify Header Value zum Modifizieren von HTTP-Headern
scriptweeder, NotScripts, ScriptKeeper zum selektiven Abschalten von JavaScript

Opera bietet seit einiger Zeit im Browser integrierte VPN-Zugänge an, die bereits fertig konfiguriert sind und ohne Anmeldung kostenfrei von jedermann benutzt werden können. Die Auswahl umfaßt derzeit VPNs in Kanada, Deutschland, Niederlande, Singapur und USA. Darunter gilt Singapur als sicherste Einstellung, Singapurs Datenschutzgesetz gilt weltweit als beispielhaft.

Hinweis: Opera VPN ist umstritten, siehe hier und hier

andere

siehe Liste_von_Anwendungen#Browser

Zusatzsoftware

Zum Filtern der eigenen HTTP-Headerzeilen kann das Programm Privoxy verwendet werden. Privoxy hat ein eigenes Arch-Paket, weiteres siehe hier.

Um ein Anonymisierungsnetzwerk zu verwenden, muss man die entsprechende Software installieren und starten, am besten über systemd. Anschließend läuft in der Regel ein lokaler HTTP-Proxy auf einem bestimmten Port, den man dem Browser mitteilen muss, sonst greift er weiterhin direkt auf Webserver zu. Es lohnt sich ein Plugin, um diesen Proxy bei Bedarf übergehen zu können, oder sogar ein zweiter Browser. Für Tor hat Arch ein eigenes Paket, weiteres siehe dort. Für I2P hat Arch momentan kein eigenes Paket. Die Software lässt sich allerdings zur Durchführung von Experimenten und zum Sammeln von Erfahrungen lokal im Verzeichnis des Benutzers auspacken und von dort aus starten. Man benötigt eine Java-Laufzeitumgebung.

Ggf. ist darüber nachzudenken, ob neben dem Browser auch andere Programme ein Anonymisierungsnetzwerk benutzen könnten oder sollten, beispielsweise Multimediastreamer.

Mail

Die Bezeichnung "Mail-Server" wird in diesem Abschnitt synonym für IMAP-, POP3- und SMTP-Server gebraucht. Hinsichtlich Sicherheitsaspekten haben alle drei viele Gemeinsamkeiten, obwohl sie natürlich ganz unterschiedliche Dinge tun.

Was man beeinflussen kann

Nachrichten auf dem Server löschen
Es gibt POP3-Clients, die zwar die Nachrichten vom Server abholen, diese dort aber nicht löschen, sondern nur als gelöscht markieren. Dies wäre zu prüfen und ggf. sicherzustellen, ansonsten bleiben diese Nachrichten lange Zeit auf dem Server und auch weiterhin abrufbar. - Disclaimer: IMAP-Benutzer haben ihr E-Mail-Archiv sehr wahrscheinlich und zwar bewusst auf dem Server, zahlen dafür aber in der Regel einen Preis und zwar nicht zuletzt für Sicherheit, während POP3-Server zahlreich und meistens kostenlos angeboten werden und dem Benutzer nicht klar ist, dass seine E-Mails dort liegenbleiben.
Ein ähnliches Problem gibt es auf IMAP-Servern: es gibt IMAP-Clients, die zwar das IMAP-Deleted-Flag an "gelöschten" E-Mails setzen, die E-Mails aber nicht physisch löschen (IMAP-Purge-Operation). Diese E-Mails verschwinden dann zwar meist aus dem Blickfeld des Benutzers (im Mailclient mutt z.B. bleiben sie sichtbar), jedoch nicht vom Server, und zwar möglicherweise für lange Zeit.
Klarheit schafft in beiden Fällen meist ein Blick auf den Server unter Benutzung des jeweiligen Web-Clients. Man muss ggf. mit den Optionen des verwendeten Mail-Clients experimentieren, um echtes Löschen zu erzwingen.
Papierkorb leeren
Die meisten Mail-Server arbeiten heute mit Papierkörben und Mail-Clients benutzen diese auch. Darin sammeln sich möglicherweise über Jahre E-Mails an, die man leicht vergisst. Regelmäßig leeren!
Authentifizierung am Mail-Server
Mail-Server erfordern in der Regel eine Authentifizierung mit Benutzername und Passwort. Anstelle des Benutzernamens kann auch ein Account-Name, die E-Mail-Adresse, eine Kundennummer oder etwas anderes nötig sein. Eine Frage ist, wie diese Daten vom Client zum Server übermittelt werden. Viele Mail-Server benutzen dafür einfach Klartext. Einige Mail-Server erlauben, ein paar wenige erfordern auch verschlüsselte Verfahren. Als Benutzer sollte man sich in der Dokumentation des entsprechenden Servers informieren, welche Verschlüsselungsverfahren vom Server unterstützt werden und das bestmögliche (normales Passwort, verschlüsseltes Passwort, Kerberos/GSSAPI, NTLM, TLS-Zertifikat) auswählen.
SSL/TLS beim Senden und Empfangen (sog. Verbindungssicherheit)
Die meisten Mail-Server erlauben unverschlüsselte und verschlüsselte Übertragung der gesendeten bzw. empfangenen Nachrichten. Unverschlüsselt bedeutet, dass der gesamte Datenverkehr zwischen Server und Client in lesbarem Klartext abläuft und problemlos aufgezeichnet werden kann. Der Benutzer sollte, wenn immer der Server das erlaubt, auf ein Verschlüsselungsverfahren ( SSL bzw. TLS, STARTTLS) umsteigen. Dabei findet zudem eine Zertifikatsprüfung statt, die das Vertrauen in die Verbindung zwischen Server und Client sicherstellt.
SSL ist das ältere Verfahren, TLS dessen Nachfolger. STARTTLS ist eine Methode, automatisch das bestmögliche Verfahren zu wählen, ohne dass der Benutzer eingreifen muss. Dabei kann es jedoch im bestimmten Fällen vorkommen, dass bei der Authentifizierung Klartext übertragen wird. Wer genau weiß, was der Server unterstützt, sollte sich für SSL bzw. TLS entscheiden.
Achtung: bei der Verwendung verschlüsselter Verbindungen werden andere Ports benutzt als die üblichen:
Protokoll unverschlüsselt verschlüsselt
IMAP 143 993
POP3 110 995
SMTP 25 465, 587
Diese Ports können serverspezifisch abweichen. Die Dokumentation des Servers muss darüber Auskunft geben. Der Anbieter Autistici/Inventati sagt beispielsweise, Port 587 sei bei ihnen TLS-, Port 465 hingegen SSL-verschlüsselt.
überall gleichermaßen verschlüsselte Verbindungen benutzen
Es nutzt nichts, in einem Mail-Client verschlüsselte Verbindungen zu konfigurieren und dann weiterhin, vielleicht von einem anderen Rechner per Web-Client oder vom Mobiltelefon aus unverschlüsselt auf das Postfach zuzugreifen. Wenn, dann überall verschlüsselt.
Das betrifft insbesondere auch sog. POP-Links, mit denen Mail-Server andere, vorgelagerte Mail-Server per POP3 abfragen, oft in einer mehrgliedrigen Kette - eine Konstruktion, die heute sehr häufig ist. Wer mehrere Postfächer hat und deren Nachrichten sicher am Ende zusammenführen will, muss die gesamte Kette per SSL verschlüsseln. Falls ein Server in der Kette sichere POP-Links nicht unterstützt, kann diese Funktionalität dadurch ersetzt werden, dass der vorgelagerte Server seine E-Mails an den nachgeordneten weitersendet (push statt pop).
Mails signieren und verschlüsseln
Signieren und Verschlüsseln sind Maßnahmen, die den Inhalt (und ggf. die Anhänge) einer Nachricht betreffen, nicht die Header. Das Signieren dient der Vertrauensbildung in die Vollständigkeit und Unverändertheit der Nachricht auf dem gesamten Weg vom Absender zum Empfänger. Das Verschlüsseln dient der Unlesbarmachung des Inhalts auf dem Weg und auch während der Speicherung auf Mail-Servern oder lokalen Ordnern. Eine Nachricht kann signiert, verschlüsselt, beides gleichzeitig oder im Standardfall beides nicht sein.
Für das Signieren und Verschlüsseln von E-Mail-Nachrichten haben sich zwei Quasi-Standards herausgebildet, die inkompatibel sind, PGP und S/MIME. Diese besitzen folgende Eigenschaften:
  • Während S/MIME ausschließlich für E-Mails konzipiert ist, ist PGP zunächst universell. Implementierungen des PGP-Standards, z.B. GnuPG, erlauben deshalb auch die Signierung bzw. Verschlüsselung von Dateien.
  • Beiden Verfahren ist elementar, dass zur Prüfung der Signatur bzw. zur Entschlüsselung eine kompatible Software auf der Empfängerseite nötig ist.
  • Die meisten Mail-Clients bieten heute eine eingebaute Unterstützung für S/MIME. Die Unterstützung für PGP wird in der Regel über die Installation einer PGP-Software sowie eines Plugins im Mail-Client erreicht.
  • S/MIME basiert auf Zertifikaten. Der Absender benötigt ein Zertifikat, das von einer entsprechenden Certificate Authority (CA, oft kostenpflichtig) ausgestellt sein muss. Dieses Zertifikat muss in seinem Mail-Client zur Benutzung vereinbart werden. Für die zusätzlich notwendigen öffentlichen und privaten Schlüssel existieren verschiedene Verfahren, in einigen Fällen wird der Anwender gar nicht damit konfrontiert. CA, bei denen (einfache) Zertifikate bezogen werden können, sind beispielsweise
  • PGP beruht auf öffentlichen und privaten Schlüsseln, ohne Verwendung von Zertifikaten. Der Benutzer muss sich lokal mit Hilfe seiner PGP-Software einen öffentlichen und einen privaten Schlüssel erzeugen und den öffentlichen anschließend am besten auf einen sog. Schlüsselserver (key server) hochladen. Der öffentliche Schlüssel wird dadurch potentiellen Empfängern bekanntgemacht, die ihn von dort herunterladen können. Gängige key server sind
    • pool.sks-keyservers.net
    • subkeys.pgp.net
    • sks.mit.edu
    • ldap://certserver.pgp.com
Wer seinen öffentlichen Schlüssel nicht auf einem key server speichern will, was seine E-Mail-Adresse publik macht, muss diesen bei Verwendung jedem Empfänger mitteilen. Das ist kein Problem, aber lästig.
Zu erwähnen wären noch die beiden verschiedenen Methoden, eine Nachricht mit PGP zu signieren, oft PGP und PGP/MIME genannt. Erstere schreibt die Signatur in die Nachricht hinein, diese ist dann dort mit vielen (primitiven) Mail-Clients als kryptischer, mehrzeiliger Text lesbar und löst beim Empfänger oft Verwirrung aus. Letztere erzeugt einen kleinen Anhang, der die Signatur enthält, die Originalnachricht ist darum mit den allermeisten Mail-Clients unverfälscht lesbar.
  • Achtung beim Löschen von Zertifikaten und Schlüsseln! Wer verschlüsselte Inhalte besitzt und den Schlüssel löscht, wird kaum noch eine Chance haben, an diese Inhalte zu gelangen. Es ist drum einerseits klug,
    • verschlüsselte Inhalte an bestimmten Orten zu konzentrieren, anstatt sie zu verstreuen, damit man den Überblick behält, und
    • andererseits für Notfälle auch Backups von den Schlüsseln anzulegen und diese sicher zu verwahren.
Hier ein Vergleich zwischen S/MIME und PGP.
einen vergleichsweise sicheren Mail-Server verwenden
In letzter Zeit sind vor allem im Zusammenhang mit Vorratsdatenspeicherung viele Fragen zum Vertrauen in Mail-Server aufgekommen. Viele amerikanische Mail-Provider schreiben auf ihren Homepages ganz offen darüber, was sie laut amerikanischer Gesetzgebung wie lange speichern. Auch in vielen anderen Ländern findet Vorratsdatenspeicherung statt, in wieder anderen Ländern ist sie geplant. Es geht dabei vor allem um die sog. Verbindungsdaten, also weniger die Inhalte, sondern die Header-Zeilen von E-Mails, wer wann mit wem.
Die Frage ist, ob sich Mail-Server finden lassen, die das nicht tun.
Anbieter Protokolle Serverstandort Bemerkungen
runbox.com (kostenpflichtig) IMAP, POP3, SMTP Oslo Auf der Homepage wird ausdrücklich ein hohes Sicherheitsbewusstsein hervorgehoben und erklärt, dass entsprechend norwegischer Gesetzgebung keinerlei Logs geführt werden und dies auch nach aktuell bevorstehenden EU-Beschlussfassungen der Fall sein wird. runbox.com hatte nach eigenem Bekunden einen hohen Zulauf nach Schließung des amerikanischen Anbieters Lavabit. Hervorzuheben ist die ausgezeichnete Webhosting-Funktionalität inkl. MySQL, PHP u.a.
secure-mail.biz (kostenpflichtig) IMAP, SMTP Panama und Island secure-mail.biz erlaubt vollständige Anonymität, selbst beim Bezahlen. Man kann Mails auch anonym versenden. Die Frage ist, ob man seine Mails auf einem IMAP-Server liegen haben will, dessen Betreiber nicht einmal eine Postanschrift offenlegen.

Achtung: Attention https://www.privacy-handbuch.de/handbuch_31.htm

Autistici/Inventati (spendenfinanziert) IMAP, POP3, SMTP Mailand A&I bietet eine interessante Palette von Diensten an, E-Mail ist nur ein Teil davon.
ProtonMail (frei bzw. kostenpflichtig) (unklar) Genf ProtonMail bietet echte End-zu-End-Verschlüsselung an, benötigt dafür aber einen Webbrowser auf beiden Seiten als Frontend. Zudem müssen Absender und Empfänger einen ProtonMail-Account haben, ansonsten kann die Ver- bzw. Entschlüsselung nicht vollzogen werden und die Nachricht wird wie gewöhnlich übermittelt. Offenbar gibt es bislang keine anderen Clients (insbesondere auch keine Apps für Mobiltelefone), die die notwendige Ver- bzw. Entschlüsselung durchführen. ProtonMail unterscheidet sich nach eigenen Angaben von üblichen mail-Providern dadurch, dass gar keine Angaben unverschlüsselt auf die Server gelangen. Fraglich ist, ob das auch für Metadaten gilt, die Webseite enthält darüber keine Angaben.
weitere (?) ...
Schweiz Seit Bekanntwerden des Überwachungsskandals werben einige Schweizer Mail-Provider im europäischen Umfeld mit ihren sicheren Servern vor allem um kommerzielle Kunden. Die Schweiz hat allerdings seit Jahren eine strenge Vorratsdatenspeicherung und einen sehr ambitionierten eigenen Geheimdienst zur Internetüberwachung ( Überwachung des Post- und Fernmeldeverkehrs, ÜPF).
darauf drängen, nicht in HTML oder Word- oder PowerPoint-Format angeschrieben zu werden
Die Gründe verstehen sich von selbst. Annahme verweigern, bouncen lassen, es hört dann schnell auf.

Thunderbird, SeaMonkey Mail

Zunächst wäre bei Thunderbird zu kontrollieren, ob alle beteiligten Server über verschlüsselte Verbindungen angesprochen werden. Die Konfigurationsdialoge enthalten alle nötigen Optionen, in den Mailkonten:

  • unter "Server-Einstellungen" die Optionen "Verbindungssicherheit" und "Authentifizierungsmethode".
  • unter "Server für ausgehende Nachrichten" ebenfalls die Optionen "Verbindungssicherheit" und "Authentifizierungsmethode".

Der verwendete Port richtet sich automatisch nach der Verbindungssicherheit, sollte aber kontrolliert werden.

Eine sehr gute Anleitung zur Verwendung von S/MIME in Thunderbird (wahrscheinlich auch uneingeschränkt in SeaMonkey Mail) ist diese.

Für PGP braucht man in Thunderbird und SeaMonkey Mail das Enigmail-AddOn und eine PGP-Software, am besten GnuPG, das unter Arch als Paket vorliegt. Beginnen wird man wahrscheinlich mit dem Wizard, der ein Schlüsselpaar erzeugt. Der öffentliche Schlüssel kann an einen Keyserver übertragen werden, der private Schlüssel sollte in einer Datei abgespeichert und gut gesichert werden, am besten nicht auf der Maschine, sondern einem externen Datenträger.

Emacs/Gnus

Um unter Gnus verschlüsselte Verbindungen zu den Mail-Servern aufzubauen, sind lediglich ein paar kleine Kunstgriffe in der .gnus erforderlich:

; senden
(setq message-send-mail-function 'smtpmail-send-it
  smtpmail-default-smtp-server "<SMTP-Server>"
  smtpmail-smtp-server "<SMTP-Server>"
  smtpmail-smtp-user "<Benutzername>"
  smtpmail-stream-type (quote ssl)
  smtpmail-smtp-service 465
)

; empfangen
(setq gnus-select-method '(nntp "...")
  gnus-secondary-select-methods '(
    (nnml "")
    (nnimap "<IMAP-Server>"
      (nnimap-stream ssl)
      (nnimap-server-port 993)
      (nnimap-expunge-on-close always)
    )
  )
)

Dazu ist das Paket openssl erforderlich.

Man sollte ferner nicht mehr die traditionell gänzlich unverschlüsselte Datei .authinfo verwenden und darin sämtliche Zugangsdaten speichern. Der sicherste Weg ist, Passwörter von Hand einzugeben.

Die Verwendung von PGP setzt das Paket GnuPG voraus. Auch S/MIME ist möglich, erfordert aber keine Zusatzsoftware.

Die folgenden Tastenkombinationen stammen aus dem Gnus-Handbuch, Kapitel 5.9:

`C-c C-m s s' Digitally sign current message using S/MIME.
`C-c C-m s o' Digitally sign current message using PGP.
`C-c C-m s p' Digitally sign current message using PGP/MIME.
`C-c C-m c s' Digitally encrypt current message using S/MIME.
`C-c C-m c o' Digitally encrypt current message using PGP.
`C-c C-m c p' Digitally encrypt current message using PGP/MIME.
`C-c C-m C-n' Remove security related MML tags from message.

Diese Tastenkombinationen (abgesehen von der letzten) fügen zunächst lediglich ein MML-tag in den Text ein, das dafür sorgt, dass Gnus beim Abschicken den gewünschten Vorgang ausführt. Man kann also zunächst weiterschreiben. Die letzte Tastenkombination entfernt lediglich dieses tag wieder. - Die Menüpunkte aus dem "Tools|Encryption/Decryption"-Menü hingegen, die durchaus ebenso für E-Mails verwendbar sind, signieren bzw. verschlüsseln auf der Stelle, ein Weiterschreiben ist anschließend nicht mehr möglich.

mutt

Um mutt mit verschlüsselten Verbindungen zu dem Mail-Servern arbeiten zu lassen, sind lediglich zwei "s" in der Datei .muttrc nötig:

# IMAP
set folder=imaps://<Benutzername>@<IMAP-Server>         <- imaps!
set spoolfile=+INBOX
set postponed = +INBOX/Drafts
set record = +INBOX/Sent
unset imap_passive
set imap_keepalive = 300
set mail_check = 120

# SMTP
set smtp_url=smtps://<Benutzername>@<SMTP-Server>       <- smtps!
set realname='Hugo Meier'
set from=<email-Adresse>
set hostname="<Hostname>"

Anleitungen zur Verwendung von PGP in mutt sind hier und hier zu finden. Eine sehr gute Anleitung, die auch paar Hintergründe aufzeigt, ist diese hier.

FTP

  • SFTP verwenden!
  • als Server-Betreiber: Zugriff beschränken, d.h. anonyme Zugriffe unterbinden

Sicher auf lokalen Datenträgern

einzelne Dateien

Erzeugte Schlüssel vorausgesetzt ist das Signieren bzw. Verschlüsseln einzelner Dateien mit dem Programm gpg aus dem GnuPG-Paket sehr einfach.

Signieren
gpg -s foo.txt          (auch --sign)
gpg -b foo.txt          (auch --detach-sign)
gpg wird dabei nach einem gültigen Adressaten fragen, wobei der eigene Benutzername eine brauchbare Eingabe ist. Im ersten Fall wird gpg die erzeugte Signatur in die Datei schreiben, im zweiten Fall wird dafür eine separate Datei mit der Endung .sig erzeugt.
Das Prüfen einer so erzeugten Signatur geschieht wie folgt:
gpg --verify foo.txt
gpg --verify foo.sig
Es muss immer die Datei angegeben werden, die die Signatur enthält, also ggf. die .sig-Datei, wobei dann die gleichnamige Originaldatei danebenstehen muss.
Verschlüsseln
gpg -e foo.txt          (auch --encrypt)
gpg fragt wie beim Signieren nach einem Adressaten und erzeugt dann eine verschlüsselte Binärdatei mit der Endung .gpg, die Originaldatei bleibt erhalten.
Das Entschlüsseln einer solchen Datei geschieht wie folgt:
gpg -d foo.txt.gpg      (auch --decrypt)
Der Inhalt der entschlüsselten Datei wird dabei auf die Standardausgabe geschrieben, das genügt, um mal schnell in eine verschlüsselte Datei zu schauen. Ansonsten muss man Ausgabeumleitung benutzen:
gpg -d foo.txt.gpg > foo.txt
gpg erlaubt eine ganze Reihe Optionen, die die verwendeten Algorithmen beeinflussen. Mehr Auskunft gibt
gpg --help

Sichere externe Daten

Die Sicherheit externer, d.h. mobiler Datenträger wird oft unterschätzt. Sie liegen oft frei zugänglich in Büros herum.

  • Backups
  • alle Arten von Flash-Speichern
  • CDROMS
  • Papier

Ferner stellt die Verwendung so kleiner Geräte wie Memorysticks und Micro-SD-Karten in Firmen und Behörden ein beträchtliches Sicherheitsrisiko dar.

Weblinks