Schlagwort: security

Ein Versuch #Heartbleed fuer nicht-Techniker verstaendlich zu machen

prego Ein Kommentar

heartbleed

Eigentlich sollte ich keine Zeit haben zu schreiben, aber das ist die mit Abstand krasseste Sicherheitsluecke die es seit langem gegeben hat. Das Ausmass kann man nur erahnen, im Prinzip muessen alle persoenlichen Daten auf einem System das den Fehler hatte als unsicher erachtet werden. Es reicht nicht die gepatchte Version von OpenSSL einzuspielen und die betroffenen Prozesse wie Apache, Postfix, Dovecot oder OpenVPN neu zu starten. Es muessen private Schluessel und Zertifikate erneuert werden und wer den Konsequenzen der Luecke klar ins Gesicht schaut wird auch ueberall Passwoerter neu setzen muessen.

Heute beim Kaffee und Kuchen fragte unsere Nachbarin wie man sich das vorstellen koennte und ich habe versucht es wie folgt zu erklaeren:

Stell Dir vor auf dieser Welt gibt es einen Hersteller fuer Haustuerschloesser. Dieser Hersteller baut sehr sichere Schloesser und man kann sich darauf verlassen, dass wenn man seine Haustuer mit einem Schloss dieser Marke schuetzt, dass dort nicht eingebrochen werden kann. Das Schloss ist in diesen Fall OpenSSL, und das Haus der Server selbst.

Vor ein paar Jahren gab es dann den Trend zu sogenannter Perfect Forward Secrecy. Im uebertragenen Sinne kann man sich das so vorstellen, dass das Schloss kontinuierlich neue Schluessel generiert die jedes mal anders sind. Gelangt also mal ein Haustuerschluessel in die falschen Haende, dann kann man damit trotzdem nichts mehr anfangen, weil das Schloss sich geaendert hat.

Die Sicherheitsluecke in OpenSSL erlaubt es, das man von extern, ohne, dass man auf den Server einbrechen muss, an sehr sehr private Daten gelangen kann. Das koennen Zugangsdaten sein oder auch der private Key, mit dem man sich dann fuer den Server ausgeben kann ohne eben dieser zu sein.

Wenn man das wieder auf den Schlosshersteller und das Haus zurueckbringt, dann stelle man sich vor, das man zu jedem Haus mit einem Schloss von diesem Schlosshersteller hingehen kann, und ohne einzubrechen bekommt man die Information wie das Schloss jetzt Schluessel generiert. Man muss nichts stehlen, man muss nichts kaputt machen, man geht einfach hin und fragt und das Schloss sagt es einem.

Auch wenn in dem Beispiel viele Dinge vielleicht als Vergleich hinken, es zeigt ziemlich einfach welche Tragweite die Sicherheitsluecke hat. Man kann ja von aussen nicht sehen „ob jemand vorbeigekommen ist und gefragt hat wie sich das Schloss aendert oder nicht“. Aus diesem Grund muss man alle Server auf denen OpenSSL in der betroffenen Version eingesetzt wurde als unsicher betrachten. Der Fehler existiert seit dem 14. Maerz 2012 und man muss also davon ausgehen, dass es Menschen / Organisationen gibt, die seit zwei Jahren in alles rein gucken konnten was man irgendwie sichern wollte.

Fuer Sysadmins ist das der Supergau…

Eine ganz gute Zusammenfassung zu dem Thema gibt es bei Golem:

Weitere Infos:

Wer seine eigene Infrastruktur testen moechte (Router, NAS, Drucket etc) kann mit dem heartbleeder lokale IP Adressen probieren und findet dann auf einschlaegigen Seiten wie Packetstormsecurity die entsprechenden Exploits…

HSTS – Was es ist, wie es funktioniert und wie man es in Apache einrichtet

prego 3 Kommentare

HSTS steht für HTTP Strict Transport Security und ist ein HTTP-Header bei dem der Webserver dem anfragenden Browser mitteilt, das alle Verbindungen nur ueber SSL/TLS aufgebaut werden sollen.
HSTS soll „Man-in-the-middle“ Attacken abwehren oder erschweren. Das Angriffsszenario besteht darin, dass Nutzer in der Regel nie

https

in den Webbrowser eingeben, sondern immer nur

example.net

Die Weiterleitung von http:// zu https:// macht der Webserver. Das sieht dann zum Beispiel so aus:
ohne_hsts

Man kann sehen, dass die erste GET Anfrage mit einem HTTP 302 Weitergeleitet wird und die zweite dann ein 200 OK zurueck liefert. Der Webserver ist in diesem Fall so konfiguriert, das alles was per HTTP reinkommt, automatisch auf HTTPS umgeleitet wird:

<VirtualHost *:80>
        ServerAdmin webmaster@jan-von.de
        ServerName mail.jan-von.de
        DocumentRoot /var/www/empty
 
        RewriteEngine on
        RewriteCond %{HTTP:X-Forwarded-Proto} !https
        RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
 
        CustomLog /var/log/apache2/mail.jan-von.de-access.log combined
</VirtualHost>

Genau hier liegt auch das Problem. Man kann sich in einem fremden Netz befinden, zum Beispiel einem unbekannten oeffentichen WLAN, dort kann die HTTP Anfrage abgefangen und der HTTPS Aufruf auf einen alternativen Server weitergeleitet werden.

Hier kommt HSTS ins Spiel. Der Server teilt dem Webbrowser mit, dass er sich bitte fuer eine bestimmte Zeit (zum Beispiel ein Jahr) daran erinnern soll, das diese Webseite nur noch ueber HTTPS aufgerufen werden soll.

In Apache muss dafuer das Headers-Modul aktiviert sein:

a2enmod headers

und anschliessend fuegt man in den HTTPS vhost die folgende Zeile ein:

Header always set Strict-Transport-Security "max-age=31556926"

Der Parameter max-age wird in Sekunden gesetzt. 31556926 Sekunden sind 365 Tage. Ein weiterer Parameter den man optional noch mit Komma Semikolon separiert dahinter haengen kann ist includeSubDomains. Dafuer muss aber sichergestellt sein, dass auch alle Subdomains per HTTPS erreichbar sind.
Weiter muss man aufpassen, dass die entsprechenden vhosts auch die angegebene Zeit, also zum Beispiel ein Jahr lang per HTTPS erreichbar sind, ansonsten kann es zu Fehlermeldungen kommen.

Wenn man dann HSTS aktiviert hat und eine Webseite aufruft die es unterstuetzt, dann kann man schoen sehen, wie der Browser gleich HTTPS nimmt und gar nicht erst HTTP probiert.

mit_hsts

Weiteres zu dem Thema z.B. unter:

Mehr Sicherheit fuer die eigenen Daten: Groupware ohne Google

prego Schreib einen Kommentar

Dieses ist der zehnte Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Links zu den ersten neun Artikeln befinden sich am Ende des Blogposts. Im zehnten Teil moechte ich meine Loesung zum Thema Groupware ohne vorstellen.

Wir leben in der Cloud. 24 Stunden vom Tag ist der Router mit dem Internet verbunden. Das Smartphone ist nur noch bei schlechter Netzabdeckung offline und die wird auch immer seltener. Es ist bequem auf dem Smartphone eine Telefonnummer ins Adressbuch hinzuzufuegen, und der Eintrag auf dem DECT Telefon Zuhause aktualisiert sich auch automatisch. Es ist bequem auf dem stationaeren Arbeitsplatz PC eine Emailadresse ins Adressbuch zu uebernehmen und spaeter ist sie auch auf dem Adressbuch des Laptops. Koennen wir uns eine Welt in der die Mails NICHT auf einem Server liegen und gleichermassen von Arbeitsplatz PC, Laptop, Smartphone, Tablet oder Webinterface bei Bekannten abgerufen werden koennen vorstellen? Ich nicht.

Google macht es einem da sehr einfach. Mit Diensten wie GMail, dessen Adressbuch, Google Calendar oder auch Google Drive gibt es fuer alles Loesungen. Sie sind kostenlos und das Erstellen eines Google Kontos dauert gerade mal zwei Minuten. Auf fast allen Geraeten kann man es sehr einfach einbinden. Wenn man ein Android Smartphone oder Tablet besitzt, ist die Integration perfekt!

Ich war auch in der Google Abhaengigkeit und mich davon zu loesen war schwerer als gedacht. Ich werde hier in diesen Blogpost keine Anleitungen schreiben wie alles eingerichtet ist, das ist definitiv zu kompliziert. Wenn jemand das Setup nachbauen moechte kann er mich gerne kontaktieren und ich helfe dabei oder gebe Tipps. Deswegen hier meine Loesung nur grob umrissen.

Grunsaetzlich liegt alles auf einem eigenen Server. Dieser ist voll verschluesselt. Fuer Emailempfang und Versand sowie den Zugriff via IMAP ist Postfix als MTA und Dovecot als MDA installiert. Bei beiden Diensten ist Perfect Forward Secrecy eingerichtet. Bei Dovecot wurde weiter das managesieve Plugin aktiviert. Postfix akzeptiert Verbindungen mit STARTTLS auf Port 25 und 465; letzterer damit man auch aus restriktiven Netzen bei denen Port 25 gesperrt ist wie z.B. be vielen WLANs in Hotels oder Gastnetzen von Universitaeten Emails versenden kann. Dovecot wurde so konfiguriert, dass nur Verbindungen ueber IMAPS auf Port 993 akzeptiert werden.

Als Groupware kommt bei mir Tine20.org zum Einsatz. Installiert habe ich es aus den bereitgestellten Debian Repositories. Apache ist so konfiguriert, dass der vhost auf Port 80 automatisch auf den vhost auf Port 443 weiterleitet. Tine20 wurde mit Postfix und Dovecot Backend eingerichtet. So kann ich die komplette Konfiguration der User und der Virtual Mailboxes aus dem Tine20 Adminmodul machen.

Als MUA auf dem Desktop verwende ich Thunderbird. Fuer Email ist alles mit den Standard Boardmitteln konfiguriert. Kalender, Adressbuch und Aufgaben werden mit Hilfe der Kombination aus Lightning Plugin und SOGo Connector synchronisiert.

Als Mailclient auf dem Smartphone verwende ich Kaiten Mail. Zur Synchronisation von Kalender, Adressbuch und Aufgaben nutze ich die Apps CalDAV-Sync, CardDAV-Sync und Tasks. Die Android eigene Kalenderapplikation habe ich gegen aCalendar getauscht.

Dieses Setup ermoeglicht es mir die Synchronisation meines Google Kontos in den Android Einstellungen komplett zu deaktivieren.

Seit dem neusten Release von Tine20.org – Collin – kann Tine auch als Server fuer OwnCloud Clients fungieren. Das funktioniert prinzipiell auch schon ganz gut, aber gerade auf dem Smartphone gibt es immer nochmal wieder Synchronisierungsprobleme. Ob das nun an der App, Tine20, Android 4.4 oder an meiner Serverkonfiguration liegt habe ich noch nicht herausgefunden.

Vorherige Blogposts:

  • Der erste Teil war fuer mich das Aufraeumen, einen Ueberblick zu bekommen sowie Strukturen zu schaffen, auf denen ich aufbauen kann.
  • Der zweite Teil bestand darin einen Ort zu schaffen, in dem ich Keys und Passwoerter sicher aufbewahren und gleichzeitig alles in ein vernuenftiges Backup schieben kann.
  • Der dritte Teil bezog sich auf das erzeugen von Zertifikaten und Einrichten von verschluesselten Verbindungen zu Apache vHosts.
  • Der vierte Teil drehte sich um das Thema Komfort im Webbrowser und verwies in dem Kontext auf einen Artikel zum selbst gehosteten Firefox Sync Server.
  • Im fuenften Teil habe ich etwas zu meinen Ueberlegungen zu sicheren Zugangsdaten und Passwoertern geschrieben.
  • Im sechsten Teil dreht es sich darum, wie man sich auf seinen Servern mit SSH aber ohne Passwort sicher authentifizieren kann.
  • Der siebte Teil behandelt das Thema Backup und zeigt eine Moeglichkeit wie man selbiges einfach konfiguriert und verschluesselt auf einem externen Speicher ablegen kann.
  • Der achte Teil stellt webbasierte Dienste vor, die man selber hosten kann und dadurch die eigenen Daten unter mehr Kontrolle hat.
  • Der neunten Teil stellt meine Ueberlegungen zu selbstgehosteten Servern und deren Sicherheit im Kontext Verschluesselung der Festplatten vor.

Mehr Sicherheit fuer die eigenen Daten – Einleitung und Aufraeumen

prego Schreib einen Kommentar

Im Kontext der NSA Affaere ist viel ueber Sicherheit und Verschluesselung geschrieben worden. Etwas zu aendern ist schwer, denn es koennen sich nur die Menschen aendern, die Dienste werden es nicht tun. Die Nutzer muessen das Thema Verschluesselung selbst in die Hand nehmen. Fuer viele ist das eigentlich unmoeglich, weil sie schlichtweg keine Ahnung haben. Fuer Menschen wie Dich und mich, die eigene Server betreiben, ist es jedoch machbar. Ich werde in der kommenden Zeit und in unregelmaessigen Abstaenden hier auf meinem Blog verschiedene Dinge vorstellen, die als direkte Reaktion aus diesen Ueberlegungen hervorgegangen sind.

Eine 100%tige Unabhaengigkeit ist nicht zu erreichen. Aber jeder kleine Schritt dahin ist richtig. Wir wollen alle kommunizieren ueber die Netze, und in der Regel bezahlen wir mit unseren Daten fuer die Services die wir nutzen. Das bedeutet im Umkehrschluss, dass wenn wir nicht mit unseren Daten bezahlen, wir auch keine Premiumdienste erwarten koennen die super einfach von der Hand gehen.

Der erste Schritt war fuer mich das Aufraeumen. Ich bin meine Rootserver durchgegangen und habe folgendes gemacht:

  1. Alle Zugaenge von mir und fuer Freunde ueberprueft die existierten und gegebenfalls gesperrt.
  2. Ich bin die Prozesstabelle durchgegangen und habe sichergestellt, dass ich keine Dienste laufen habe, die ich nicht laufen haben moechte. Gegebenenfalls habe ich diese deinstalliert.
  3. Ich bin im Apache alle vHosts durchgegangen und habe dort aufgeraeumt. Nicht mehr benoetigte deaktiviert und Konfigurationen angeglichen
  4. Ich habe meine DNS Konfigurationen durchgeschaut und sichergestellt, dass keine verwaisten Subdomains existieren etc.
  5. Ich bin das Dateisystem durchgegangen, habe mein Homeverzeichnis aufgeraeumt, die DocumentRoots der vHosts usw.

Kurz: Aufraeumen um eine gute Grundlage, einen Ueberblick, eine gute Struktur zu schaffen fuer die naechsten Arbeiten im Kontext Verschluesselung, die ich machen wollte. Stay tuned….