Category Archives: Anonymität

Überarbeitung der Anleitungen zur Voll-Verschlüsselung

tauchfahrt_submarine

In den letzten drei Wochen war es etwas still im Blog. Das liegt zum einen daran, dass meine Diplomarbeit mich in Beschlag nimmt, aber auch daran, dass ich die gesammelten Tauchfahrt mit Linux Anleitungen zur Voll-Verschlüsselung für euch überarbeite und neu strukturiere.

Wer Kommentare, Feedback oder Wünsche hat: Jetzt ist der Zeitpunkt dafür.

Studienarbeit “Verteidigung externer Rechnerresourcen” (mit Linux)

In den letzten Wochen ist es leider etwas still im Blog geworden, besonders zum Thema IT-Sicherheit. Das liegt zum einen daran, dass ich meine Diplomarbeit schreibe. Aber auch daran, dass ich im Wintersemester 2013/14 am Lehrstuhl 4 an der TU-Dortmund eine Studienarbeit im Themenbereich IT-Sicherheit schreiben durfte.

Der Titel lautet “Verteidigung externer Rechnerresourcen – Risiken durch die Aufgabe der physikalischen Kontrolle und Gegenmaßnahmen am Beispiel gemieteter Linux Server“.


Studienarbeit Verteidigung externer Rechnerressourcen (PDF)

Darin beschreibe ich ausführlich die auftretenden Probleme, sobald dem Provider nicht mehr vertraut wird. Im Anschluss wird eine Taktik basierend auf Anti-Forensik und einfacher Militärtaktik entwickelt, die einen voll-verschlüsselten gemieteten Server noch etwas besser schützt, indem der forensische Prozess behindert wird. Mit Implementierung für Debian Linux.

Die Arbeit löst ausdrücklich nicht das Problem, dass bei gemieteten Servern keine Vertrauenswurzel existiert, bietet aber einige Verbesserungen an. Zu diesem Vertrauensproblem gibt es einiges im Chaosradio 199 ab 1:37:00 bis 1:39:30 zu hören, falls Interesse besteht.

Proxyserver über SSH-Tunnel mit MyEnTunnel verwenden

Wer Zugriff auf einen anonymisierenden Proxyserver (Elite-Proxy) hat, kann diesen mit einem SSH-Tunnel zum Ziel-Netzwerk sicherer benutzen, als durch direkte Verwendung des Proxys. Diese Zugangsart eignet sich zum Beispiel um auf die Proxyserver von Perfect-Privacy oder OVPN.to zuzugreifen. Aber auch an meiner Universität wird ein solcher Privatsphären Proxy betrieben. Um diesen sicher zu verwenden, bietet sich ein SSH-Tunnel an. Wie dieser unter Windows eingerichtet wird, erklärt der folgende Artikel.

Unter Windows eignet sich für die Herstellung des SSH-Tunnels besonders das Programm MyEnTunnel. MyEnTunnel ist eine einfache Systemtray-Anwendung, die mit Hilfe des mitgelieferten Programms PuTTY Link (plink.exe) einen SSH-Tunnel aufbaut und aufrecht erhält.

Bildschirmfoto - 08.03.2014 - 17:14:55

MyEnTunnel im Windows-Systemtray

Die Software kann über die Herstellerseite N2 (Download befindet sich auf der Mitte der Seite) bezogen werden. Es ist empfehlenswert, die Entwicklungsversion 3.6.1 herunterzuladen, da diese trotz dem Status sehr stabil läuft und bei komplexen Passwörtern keine Fehler hat.

Nach der Installation kann der Tunnel zum Fakultätsproxy eingerichtet werden. Der Tunnel wird in der aus ssh bekannten Notation (Lokaler-Port:Zielhostname/IP:Ziel-Port) eingegeben.

Bildschirmfoto - 08.03.2014 - 17:13:43

Eingabe der SSH-Tunnel Konfiguration

Im letzten Schritt, wird der Zielserver im Fakultätsnetzwerk eingegeben. Geeignet ist zwar jeder Server, der per SSH mit einem Fakultäts-Account erreichbar ist. Um den Maximaldurchsatz der eigenen Internetanbindung zu erreichen sollte aber einer der Compute-Server der IRB verwendet werden. Der Hostname ergibt sich, indem .cs.tu-dortmund.de an den Hostnamen angehängt wird.

Bildschirmfoto - 08.03.2014 - 17:12:43

Eingabe der SSH-Server Konfiguration

Die Konfiguration aus obiger Abbildung kann 1:1 übernommen werden. Sollen statt dem Surfen im Web regelmäßig große Daten übertragen werden, sollte die Kompression deaktiviert werden.

Wer liest meinen Blog?

Manchmal möchte man als Blogger erfahren, welche Art von Leser man anzieht und ob die Ausrichtung des Blogs stimmt. Selbstzweifel nagen am Autor, der die meiste Zeit allein mit dem Texteditor und dem Blog verbringt. Wie gut, dass es Statistik-Plugins wie StatComm gibt. Dieses Plugin verrät für diesen Blog, welches Betriebssystem und Browser besonders beliebt ist.

Bildschirmfoto - 06.01.2014 - 11:19:19

Beliebtester Browser: Unbekannt.

Für diesen Blog verwenden 33% der Besucher einen unbekannten Browser auf einem unbekannten Betriebssystem. Auch IP-Adressen aus Deutschland sind weit abgeschlagen hinter der Schweiz und den Niederlanden. Besonders beliebt sind Computer in Rechenzentren mit Windows und Firefox oder Windows und unbekannten Browsern. Dabei handelt es sich höchstwahrscheinlich um Proxys.

Für mich steht damit fest, dass ich die Zielgruppe erreiche.

Und natürlich Dankeschön, dass Ihr meinen Blog lest und Anonymisierung einsetzt.

Über Fragen, Kommentare oder Themenwünsche würde ich mich trotz eurer Anonymität um so mehr freuen. Hinterlasst doch einen Kommentar!

Debian Colocation/Leased Server Full-Disk-Encryption

1. Grundsätzliches

Diese Anleitung beschreibt die Installationen von Debian Wheezy auf einem Server mittels Rettungssystem. Der Server ist nach der Installation weder gegen Angriffe aus dem Netzwerk abgesichert noch entspricht er dem Standard-Image des Providers. Durch den Einsatz einer Debian Basis-Installation fallen Überwachungsskripte und gepatchte Kernel des Providers weg. Das ist kein Zufall.

Das Ergebnis ist ein Minimalsystem für einen voll-verschlüsselten Server, der folgende Eigenschaften hat.

  • Möglichst unabhängig von der Provider-Infrastruktur
  • Minimalsystem
  • Full-Disk-Encryption (FDE) mit Entsperrung per SSH

Die Anleitung basiert auf dem Squeeze from Scratch HowTo von Sven Richter und stellt das Vorgehen zur Installation nach den Prinzipien meines Vortrags “Tauchfahrt mit Linux – Colocation Anti-Forensik” dar. Die Folien führen in die Problemsituation und meinen Lösungsansatz ein und sind hier zu finden. Es wird davon ausgegangen, dass die Installation von einem Linux-System aus durchgeführt wird.

Weiterlesen

Kali Linux Colocation/Leased Server Full-Disk-Encryption

Übersicht

Natürlich lässt sich jede Debian basierte Distribution nach dem im Artikel Debian Colocation/Leased Server Full-Disk-Encrytion vorgestellten Prinzip installieren. Dafür sind nur sehr wenige Änderungen notwendig. Hier die Anpassungen, um statt Debian Kali Linux zu installieren.

Es sind die Abschnitte 4.1 und 4.2 der Anleitung wie hier gezeigt zu ersetzen und die veränderten Paketquellen in Schritt 5.2 zu verwenden.

4.1 Debootstrap herunterladen und anpassen

mount -t tmpfs none /tmp
cd /tmp
wget http://archive.kali.org/kali/pool/main/d/debootstrap/debootstrap_1.0.48+kali1_all.deb

Sollte die debootstrap Quelle nicht mehr aktuell sein, kann der richtige Link hier eingesehen werden: http://archive.kali.org/kali/pool/main/d/debootstrap/

ar -xf debootstrap_1.0.48+kali1_all.deb
tar xzf data.tar.gz
tar xzf control.tar.gz

Jetzt muss geprüft werden, ob der Inhalt des Pakets unverändert im Rettungssystem angekommen ist. Jedes Debian Paket liefert eine Datei md5sums mit, die Prüfsummen über die enthaltenen Dateien enthält. Mit dem folgenden Einzeiler lässt sich die Integrität des debootstrap Pakets prüfen.

cat md5sums | cut -d " " -f 3 | xargs md5sum $1 > md5sums.local; diff md5sums md5sums.local

Der Befehl darf keine Ausgabe erzeugen, sonst sind Daten verändert worden.

Um jetzt per debootstrap installieren zu können, muss der Quelltext von debootstrap leicht angepasst werden.

nano usr/sbin/debootstrap

Die folgenden Zeilen entsprechend editieren

Suchen:

DEBOOTSTRAP_DIR=/usr/share/debootstrap

und ersetzen mit:

DEBOOTSTRAP_DIR=/tmp/usr/share/debootstrap

4.2 Installation durchführen

Um sicherzugehen, dass nur offizielle Pakete ohne Hintertüren auf dem neuen System installiert werden, müssen die Signaturen aller Pakete geprüft werden. Alle Debian Pakete sind durch öffentliche Schlüssel in einer Public-Key-Infrastruktur gesichert. Damit diese Signaturen geprüft werden können, muss der Hauptschlüssel des Debian Archivs wie folgt importiert werden.

wget -q -O - http://archive.kali.org/archive-key.asc | gpg --import

Mit dem Befehl gpg --list-keys wird geprüft, ob der Schlüssel erfolgreich importiert wurde. Ist das der Fall, kann das Grundsystem installiert werden.

usr/sbin/debootstrap --keyring=/root/.gnupg/pubring.gpg --arch=amd64 kali /mnt/ http://archive.kali.org/kali

Nach der Installation des Grundsystems erfolgt die Anmeldung über den chrootBefehl, um die weitere Einrichtung durchzuführen.

mount -t proc none /mnt/proc
mount -o bind /dev /mnt/dev
mount -t tmpfs none /mnt/tmp
mount -o bind /sys /mnt/sys
LANG=C chroot /mnt /bin/bash

Erzeugen die Befehle keine Fehlermeldung, wurde erfolgreich in das frisch installierte Debian gewechselt.

5.2 Ergänzung für Kali

Hier wird statt der angegebenen Quellen für Debian folgender Inhalt in die Datei /etc/apt/sources.list hinzugefügt.

deb http://http.kali.org/kali kali main non-free contrib
deb http://security.kali.org/kali-security kali/updates main contrib non-free
deb-src http://http.kali.org/kali kali main non-free contrib
deb-src http://security.kali.org/kali-security kali/updates main contrib non-free

No-Logging Elite-Proxy an der TU-Dortmund


Normalerweise berichte ich nicht über die Dienste, die ich im Rahmen meiner Arbeit bei der Informatik-Rechner-Betriebsgruppe an der Fakultät für Informatik betreue. Das liegt daran, dass ich annehme, dass jeder Leser meines Blogs mit der Administration von Server-Diensten im produktiven Betrieb vertraut ist. Nichts spannendes, also.

Seit einigen Wochen läuft aber ein Privatsphären-Proxy (ugs. “Elite Proxy”) statt des bisher betriebenen Proxys im Rechnerraum der IRB.


proxy.cs.tu-dortmund.de

(Aus dem Fakultäts-Netzwerk erreichbar)

Elite Proxy
Ein Elite Proxy ist ein Proxy-Server, der sich nicht als Proxy zu erkennen gibt und für Webserver nur mit der eigenen IP-Adresse und nicht mit der IP-Adresse des Proxy-Nutzers in Erscheinung tritt.
(Quellen hier, hier und hier.)

Die Architektur unseres Proxys an der IRB geht aber einen Schritt weiter, als einfache Elite Proxys und gesteht den Nutzern weitere Anonymität zu. Dafür betreiben wir eine Proxykaskade aus Squid und Privoxy, die im Vergleich zu einem herkömmlichen Proxy-Server wie folgt aussieht.

eliteprox_irb

Deutlich zu erkennen sind die Unterschiede im Speicher-Subsystem und dem vorgeschalteten Privoxy. Die speziellen technischen Unterschiede sind in meinem Linux Magazin Artikel (lokale Kopie, nur Fakultäts-Netzwerk) beschrieben.

Squid

Der Squid-Proxy verhält sich in Voreinstellung konform zum Pseudostandard und sendet bei jeder Anfrage einen X-Forwarded-For Header, der die IP-Adresse des anfragenden Clients enhtält. Hierdurch wird die Anonymität aufgelöst. Darum wird in unserer Proxykaskade dieser Header gelöscht, sowie weitere Header die Informationen über den anfragenden Nutzer oder die anfragende IP enthalten entweder gesperrt oder verfremdet. Squid bietet für den Zweck nur die Möglichkeit, einen Header zu sperren, oder weiterzuleiten.

Privoxy

Um Privatsphäre ohne Einbuße von Komfort bereitstellen zu können, ist Privoxy notwendig. Der Header HTTP_REFER sendet dem Webserver in einer Anfrage die vorher aufgerufene Webseite.

Wechselt der Nutzer aber von einem Webshop-System auf die Suchmaschine Google, ist die Suchmaschine dank HTTP_REFERER in der Lage, die vorher aufgerufene URL zu speichern.

Die Auswertung des Referers wird von einigen Webseiten benötigt, um korrekt zu funktionieren, darum ist eine Sperrung nicht möglich. Dazu gehören Onlinebanking- und Webshop-Systeme. Da der Referer zum Ausspähen des Nutzers mißbraucht werden kann, wenn die Domain gewechselt wird, sperrt Privoxy nur in diesem Fall den Referer und setzt ihn auf die Domain der aufgerufenen Webseite.

Speicher-Subsystem

Der Squid-Proxy speichert in Voreinstellung umfangreiche Logdaten zur Anfrage, wie zum Beispiel die komplette URL mit etwaigen GET-Parametern, sowie die anfragende IP-Adresse und den verwendeten Browser. Darüber hinaus wird über eine zweite Logdatei aufgezeichnet, welches Objekt im Cache von welcher IP-Adresse zuerst angefragt wurde. So ist mit der Voreinstellung eine lückenlose Überwachung aller Nutzer möglich. Auch dieses Verhalten ist für einen Privatsphären-Proxy nicht wünschenswert.

Darum sind Logfiles komplett deaktiviert. Es werden nur Key Performance Indicators in einer Datenstruktur im Arbeitsspeicher vorgehalten, die das verursachte Datenvolumen den IP-Adressen zuordnen.

Der Cache ist darüber hinaus mit einem Zufallschlüssel in AES verschlüsselt, der bei jedem Neustart neu erzeugt wird, um auch eine statistische Zuordnung von verursachtem Datenvolumen zu Objekten (und damit aufgerufenen Webseiten) im Cache zu verhindern.

Um trotzdem im Falle eines Missbrauchs handlungsfähig zu bleiben, kann der komplette Datenverkehr eines Nutzers bei begründetem Verdacht protokolliert werden, ohne andere Nutzer zu beeinträchtigen.

Postfix Header anonymisieren

Wird ein eigener Mailserver betrieben, ob in der Firma oder für eine Arbeitsgruppe, fügt dieser Received: Header dem Kopf der E-Mail hinzu. Diese Header können im Falle eines Penetrationstests oder eines nicht erlaubten Angriffs genutzt werden, um Informationen über das interne Netzwerk oder den Standard eines Absender zu erhalten. Auch der User-Agent: Header wird übertragen, der vom Mailclient hinzugefügt wird.

Da viele E-Mail Clients diese Information nicht anzeigen, hier ein Auszug aus dem Kopf einer E-Mail.


Received: from [172.16.xxx.xxx] (b2b-46-252-xxx-xxx.unitymedia.biz [46.252.xxx.xxx])
(Authenticated sender: josen)
by outpost.paketsequenz.de (Postfix) with ESMTPSA id 8AED91032364B;
Wed, 13 Jun 2012 16:36:27 +0200 (CEST)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

Wünschenswert ist es, dass diese Informationen anonymisiert werden. Dafür bietet Postfix die header_checks Variable in der Konfigurationsdatei main.cf an. Das Hinzufügen von Kopfzeilen-Regeln lässt sich durch Hinzufügen einer weiteren Zeile in der main.conf bewerkstelligen, die wie folgt aussieht.

header_checks = pcre:/etc/postfix/header_checks

In der angegebenen Datei können jetzt in diesem Format einfache Aktionen definiert werden. Um die Header Received und User-Agent kommplett zu entfernen reichen die folgenden Zeilen.

/^Received:/ IGNORE
/^User-Agent:/ IGNORE

Diese Lösung funktioniert, ist aber nicht elegant. Zum einen müssen Mailserver nach RFC5321 einen Received Header hinzufügen, und zum anderen werden so bearbeitete E-Mail sofort als Spam enttarnt. Wünschenswert ist eine Anonymisierung des Received Headers, ohne das RFC zu verletzen und ohne als Spam klassifiziert zu werden. Ein Received Header wie der folgende erfüllt diese Anforderungen.

Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: josen) with ESMTPSA id 23DC81017E64E

Und so gehts:

Die folgenden Zeilen in die Datei header_checks einfügen.

/^Received: from \[.*?\] \([\w-.]* \[.*?\]\)\s+\(Authenticated sender: (\w+)\)\s+by outpost.paketsequenz.de \(Postfix\) with (E?SMTPS?A?) id ([A-F\d]+);.*?/
        REPLACE Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: $1) by outpost.pakesequenz.de with $2 id $3
/^User-Agent:/ IGNORE

Zusätzlich muss ein Eintrag in der Postfix main.cf hinzugefügt werden, der wie folgt lautet.

smtpd_sasl_authenticated_header = yes