© Aaron Amat, 123RF.com

Portscans zum Auffinden verwundbarer Dienste sind nicht neu. Auch das so genannte Port-Knocking als Abwehrmaßnahme existiert schon eine Weile. TCP Stealth versucht etwas Ähnliches, nur arbeitet es dabei raffinierter. Das Linux-Magazin hat einen genaueren Blick riskiert.

Offene UDP- oder auch TCP-Ports zu finden ist unter Linux eine leichte Fingerübung. Hartgesottene benutzen Netcat [1]. Wer es einfacher mag, greift auf Nmap [2] zurück. Neben dem Identifizieren von laufenden Diensten ist es in vielen Fällen sogar möglich, das darunterliegende Betriebssystems zu bestimmen. Alles in allem kann ein Portscan für Admins ein nützliches Mittel zur Problemanalyse sein.

Die Medaille hat aber auch eine Kehrseite. Böswillige Mitmenschen können dieselben Methoden zum Ausspionieren von IT-Systemen benutzen. Ist klar, welche Türen prinzipiell offen sind, startet der Angreifer weitere Untersuchungen. Im ungünstigen Fall erfährt er, welches Programm mit welcher Version einen bestimmten Port offen hält. Eine Internetrecherche nach möglichen Schwachstellen oder gar Exploits ist dann schnell erledigt. Diese offene Flanke lässt sich wirksam schützen, wenn der Admin verschleiert, welche Ports offen sind. Für den Ausstehenden sieht es dann so aus, als gäbe es nichts zu holen. Nur Eingeweihte wissen, wie man um Einlass bitten kann.

Die wohl bekannteste Technologie in diesem Zusammenhang ist das so genannte Port-Knocking. Es gibt eine Reihe von Implementierungen [3]. Das Linux-Magazin hat darüber auch schon mehr als einmal berichtet ([4], [5], [6]).

Was bisher geschah

In Abbildung 1 ist ein typisches Setup für Port-Knocking dargestellt. Die beteiligten Komponenten sind der Client und die Serverapplikation. Dazu kommen eine Firewall für das Blocken ungebetener Gäste und ein weiterer Prozess, der auf die vereinbarten Klopfzeichen wartet. Dieser Prozess wird oft als Port-Knock-Daemon bezeichnet. Der Daemon und der Client haben ein gemeinsames Geheimnis. Das können eine Klopfsequenz sein oder Netzwerkpakete mit einem bestimmten Inhalt.

Abbildung 1: Ein typischer Aufbau für Port-Knocking.

Der Verbindungsaufbau erfolgt in vier Schritten. Der Client versucht eine Verbindung mit dem Server aufzunehmen, die die Firewall blockiert. Im nächsten Schritt kommt das erwähnte Geheimnis zum Einsatz, also eine bestimmte Reihenfolge, in der der Client versucht weitere Ports anzusprechen, oder ein bestimmter Paketinhalt, den der Client sendet. Der Port-Knock-Daemon erkennt das und weist die Firewall an, diese Clientanfrage passieren zu lassen. Der letzte Schritt ist danach ein ganz normaler Verbindungsaufbau.

Wer das einmal praktisch ausprobieren will, sei auf die früheren Artikel im Linux-Magazin ([4], [5], [6]) verwiesen. Alternativ kann man mit dem Projekt Knockd [7] starten. Das hier beschriebene TCP-Stealth-Verfahren ist außerdem in der Knoppix-Version implementiert, die sich auf der Heft-DVD findet.

Die verschiedenen Internetprotokolle verhalten sich unterschiedlich. UDP als verbindungsloses Protokoll ist schon beim Scannen anders zu behandeln. Auf der TCP-Seite gibt es gleich mehrere Varianten zum Aufspüren von offenen Ports (Tabelle 1).

Design-bedingt hat das bekannte Port-Knocking-Setup zwei Schwachstellen. Die erste besteht darin, dass der Klopfmechanismus erkennbar ist, wenn der Angreifer auf dem Netzwerk lauscht. Dabei können die zusätzlichen Schritte für den Verbindungsaufbau auffallen, auch das ursprüngliche Abweisen der Verbindung mit der anschließenden Genehmigung wirkt suspekt.

Die zweite Schwachstelle betrifft die so genannten Man-in-the-Middle-Angriffe. Nach erfolgreichem Anklopfen sind der Port-Knock-Daemon und die Firewall außen vor. Eine nachträgliche Übernahme der einmal erfolgreich etablierten Verbindung durch einen Angreifer können sie nicht verhindern. Im Folgenden beschränkt sich der Artikel auf TCP als Transportprotokoll.

Erste Schritte auf leisen Sohlen

TCP Stealth ist eine Erweiterung des initialen Drei-Wege-Handschlags zum Aufbauen der Verbindung. Ein entsprechender Antrag [8] liegt dem IETF [9] bereits vor. Das auch als lautloses Port-Knocking bekannte Verfahren entstand als Studentenprojekt im Sommer 2013 an der TU München [10]. Der ursprüngliche Name lautete Knock, die Projekt-Webseite [11] verwendet diesen Bezeichner immer noch. Seitdem ist einiges passiert. Julian Kirsch – der Student von damals – hat im Spätsommer 2014 seine Masterarbeit [12] über TCP Stealth eingereicht.

Wer schon länger im Port-Knocking-Umfeld tätig ist, erinnert sich vielleicht an Silentknock [13]. Das Projekt nutzt die gleiche, schon über sieben Jahre alte Idee [14] wie TCP Stealth. 1997 beschrieb Craig H. Rowland, wie sich Informationen getarnt als Teil des Standard-Headers von TCP übertragen lassen.

In Listing 1 ist der TCP-Header dargestellt. Die meisten Teile sind durch ihre Funktion quasi vorbestimmt und eignen sich nicht zum Einbetten von Daten. Eine Ausnahme ist die erste Sequenznummer (Initial Sequence Number, ISN) der TCP-Verbindung. Bis zu einem gewissen Grade gilt dies auch für die Bestätigungsnummer (ACK). Die Verwendung der Zeitstempel als Trägermedium ist ebenfalls denkbar.

01 $ cat rfc793.txt
02 ...
03     0                   1                   2                   3
04     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
05    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
06    |          Source Port          |       Destination Port        |
07    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
08    |                        Sequence Number                        |
09    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10    |                    Acknowledgment Number                      |
11    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12    |  Data |           |U|A|P|R|S|F|                               |
13    | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
14    |       |           |G|K|H|T|N|N|                               |
15    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16    |           Checksum            |         Urgent Pointer        |
17    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
18    |                    Options                    |    Padding    |
19    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20    |                             data                              |
21    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
22 ...

Der RFC schreibt eine Maximalgröße von 32 Bit für die ISN vor. Das beschränkt den Platz für die zu übertragenden Daten. Als Eingabedaten für die zufällige ISN dienen das vereinbarte Geheimnis, IP-Adresse und Port des Ziels und gegebenenfalls der Zeitstempel. Das Geheimnis ist sowohl Client als auch Server bekannt und fällt damit in die Klasse der Pre Shared Keys (PSK). In der gegenwärtigen Implementierung ist dieser Schlüssel eine einfache Zeichenkette, und zwar genau eine pro Port.

Zur Generierung der ISN kommt das bekannte Hashing-Verfahren MD5 [15] zum Einsatz. Wer genau hinschaut, erkennt, dass die Zeitstempel eine wichtige Rolle spielen. Sind sie doch die einzigen Variablen bei der Berechnung – ISN, PSK, Ziel-IP und -Port sind Konstanten. Das genaue Vorgehen ist in ([8], [12]) beschrieben.

Tarn-Socken

Wie funktioniert TCP Stealth in der Praxis? Die gezielte Manipulation der ISN erfordert eine Anpassung des TCP-Stack. Bei Linux ist der im Kernel implementiert. Als dieser Artikel entstand, wusste der Vanilla-Kern aber noch gar nichts von TCP Stealth. Der neugierige Leser kommt also um das Patchen des Linux-Kerns nicht herum. Weitere Details beschreibt der Kasten “TCP Stealth im Linux-Alltag”. Das Patch verändert insgesamt nur elf Dateien und darin nur eine Handvoll Funktionen. Dazu gehören Anpassungen für die Verbindungsaufnahme im Client-Teil von TCP, beispielsweise »tcp_v4_connect()« und »tcp_v6_connect()« . Analog natürlich auf der Server-Seite. Hier betrifft es hauptsächlich »tcp_v4_do_rcv()« und »tcp_v6_do_rcv()« .

$ grep -i stealth /etc/sshd_config $HOME/.ssh/config
/etc/sshd_config:TCPStealthSecret "Too many secrets :-)"
/home/user/.ssh/config:TCPStealthSecret  "Too many secrets :-)"

Die Aktivierung von TCP Stealth im Netzwerkstack muss vor dem eigentlichen Verbindungsaufbau erfolgen. Das heißt, die notwendige Konfiguration setzt bei den Sockets an. Unter Linux erledigt das der Systemaufruf »setsockopt()« . Damit ist klar, dass das Kernelpatch auch hier Änderungen vornimmt. Zu guter Letzt hat der Kernel eine neue Konfigurationsoption (Abbildung 2) und eine erweiterte TCP-Socket-Struktur.

Abbildung 2: Unter »Networking support -> Networking options« sind im Linux-Kernel die Einstellungen zum Einschalten von TCP Stealth zu finden.

Ein Linux-Kern, der TCP Stealth beherrscht, ist aber nur ein Teil der vorbereitenden Maßnahmen. Im zweiten Schritt muss auch die Anwendung der Wahl auf die neuen Funktionen zugreifen können. Eine Beispiel-Implementierung sowohl der Client- als auch der Server-Seite findet sich in (http://11, http://12). Der entscheidende Teil ist in Listing 2 dargestellt.

01 #define TCP_STEALTH                     26
02 [...]
03 # Passwort:
04         char secret[64] = "This is my magic ID.";
05 [...]
06 [...]07 # Setsocket-Aufruf:
08         if (setsockopt(sock, IPPROTO_TCP, TCP_STEALTH, secret, sizeof(secret))) {
09                    printf("setsockopt() failed, %s\n", strerror(errno));
10                    return 1;
11                  }
09 ...$

Der neue Systemaufruf »setsockopt()« lässt sich auch mit Analysewerkzeugen wie »strace« verfolgen:

$ grep setsockopt tcp_stealth_server.strace
29392 setsockopt(3, SOL_TCP, 0x1a  /* TCP_??? */, "This is mymagic ID.\0\0 \0\0\0\0\0\0\0 ...\0\0\0\0\0\0\0\0\0\ 0\0", 64) = 0

Verfolgt man »setsockopt()« mit Strace (Listing 2), wird klar, dass TCP Stealth keine Verschlüsselung vornimmt.

Dennoch kann TCP Stealth die Datenintegrität gewährleisten – dazu später mehr. An dieser Stelle ist wichtig, dass ein lokaler Angreifer bestimmte Informationen erspähen kann, weil sie einfach im Klartext vorliegen. Zudem erfolgt die Authentisierung nur in einer Richtung. Der Server überprüft, ob der Client zum Verbindungsaufbau berechtigt ist. Als Ausweis dient ihm der PSK. Der Client kann allerdings nicht feststellen, ob er tatsächlich mit dem richtigen Server kommuniziert.

Datenintegrität

Wie bereits erwähnt bietet das übliche Port-Knocking-Setup keinen Schutz vor Man-in-the-Middle-Angriffen. Die typische Argumentation ist, dass hier die Anwendung selbst verantwortlich sei. Allerdings gibt es immer noch ein enges Zeitfenster, das eine Angriffsfläche bietet. Das betrifft den Zeitraum vom erfolgreichen Anklopfen bis zum Aufbau der Verbindung auf Protokollebene.

Im vorliegenden Fall entspricht das der Phase von der erfolgreichen Authentisierung über den PSK bis zum Abschluss des Drei-Wege-Handschlags. Aber TCP Stealth kann hier vorbeugen, indem es für eine kleine Menge von Daten die Integrität prüft. Die Idee ist, dass der Client Zusatzinformationen in das erste Datenpaket einschleust. Der Server prüft deren Richtigkeit, und die lässt die Verbindung zu oder weist sie ab.

Die Implementierung folgt dabei Ansätzen, die analog zur Authentisierung über das gemeinsame Geheimnis sind. Die Aktivierung der Integritätsprüfung erfolgt vor dem eigentlichen Verbindungsaufbau durch die entsprechende Konfiguration der Netzwerksockets per »setsockopt()« . Dazu führt das erwähnte Kernelpatch die Optionen »TCP_STEALTH_INTEGRITY« und »TCP_STEALTH_INTEGRITY_LEN« ein. Erstere ist nur für die Client-Seite relevant. Die Definition der Zusatzdaten erfolgt separat.

Die Socket-Option »TCP_STEALTH_INTEGRITY_LEN« hingegen kommt nur auf der Server-Seite zum Einsatz und gibt an, wie viele Daten für die Integritätsprüfung relevant sind. Zum gegenwärtigen Zeitpunkt ist diese Prüfung ohne Authentisierung nicht möglich.

In Abbildung 3 ist der Drei-Wege-Handschlag bei aktiviertem TCP Stealth mit Integritätsprüfung dargestellt. Im ersten Schritt beim TCP-Verbindungsaufbau übermittelt der Client Informationen über den PSK durch die ISN. Wo der Client normalerweise den Abschluss des Handschlags durchführt, initiiert er die Integritätsprüfung. TCP Stealth greift auch hier auf das Prüfsummen-Verfahren MD5 zurück. Die Eingabedaten sind der PSK und die erwähnten Zusatzinformationen – einfach aneinandergehängt.

Abbildung 3: Der Drei-Wege-Handschlag bei TCP Stealth mit eingeschalteter Integritätsprüfung.

Die 128 Bit lange Prüfsumme teilt TCP Stealth in acht gleich lange Stücke und kombiniert sie über »XOR« . Das Resultat ist dann der zweite Teil der 32 Bit langen ISN. In den ersten 16 Bit versteckt TCP Stealth den PSK (siehe oben). Sobald im dritten Schritt der TCP-Verbindungsaufnahme die Zusatzdaten übermittelt sind, kann der Server die Integritätsprüfung vornehmen. Die genauen Details lassen sich in ([8], [12]) nachlesen.

Verschlossene Türen?

Damit eine Anwendung TCP Stealth benutzen darf, muss sie die entsprechenden Socket-Optionen setzen. Das heißt, eine Änderung des Quelltextes und das Erzeugen neuen Binärcodes sind damit unumgänglich. Wer sich im Open-Source-Umfeld bewegt, sieht hier keine Probleme. Tatsache ist jedoch, dass es ausreichend viele Applikationen gibt, die dem Benutzer nur im Binärformat vorliegen und bei denen der Zugriff auf den Quelltext unmöglich ist. Doch auch dafür hat TCP Stealth einen Trick parat.

Das Zauberwort heißt »libknockify« ([11], [12]). Hierbei handelt es sich um eine Bibliothek, die der Entwickler über den »LD_PRELOAD« -Mechanismus vor dem Ausführen der eigentlichen Anwendung lädt. Zur Laufzeit des Programms überlagert »libknockify« Systemaufrufe wie »getsockopt()« , »listen()« oder »connect()« mit den Pendants von TCP Stealth (siehe auch Listing 3). Der PSK oder die notwendigen Angaben zur Integritätsprüfung konfiguriert man entweder über die Shell-Umgebungsvariablen »KNOCK_SECRET« , »KNOCK_INT_LEN« oder hinterlegt sie in »$HOME/.knockrc« .

01 $ cat $HOME/.knockrc
02 KNOCK_INTLEN=0
03 KNOCK_SECRET="Nuer fuer LM-Leser :-)"
04 KNOCK_LOGLVL=2
05 $
06 $ LD_PRELOAD=/usr/local/lib64/libknockify.so ncat 127.0.0.1 -l 4242
07 setting loglvl to 2
08 Initializing hooks ...
09 Resolving symbol socket ...
10 Resolving symbol connect ...
11 Resolving symbol listen ...
12 Resolving symbol write ...
13 Resolving symbol send ...
14 Resolving symbol sendto ...
15 Resolving symbol sendmsg ...
16 Resolving symbol getsockopt ...
17 Resolving symbol close ...
18 Resolving symbol epoll_wait ...
19 Resolving symbol select ...
20 All dynamic symbols could be resolved.
21 socket(2, 1, 6) = 3
22 Socket 3 will be Knockified.
23 Knockified.
24 listen(3, 10) = 0

In Listing 3 ist noch ein Loglevel-Parameter dargestellt. Mit dem Wert 0 verhält sich »libknockify« sehr ruhig, während der Entwickler beim Wert 3 maximale Gesprächigkeit erhält. Das ist für Problemanalysen sehr hilfreich. Die entsprechende Shellvariable heißt »KNOCK_LOGLVL« . In den Labortests kam es aber immer wieder zu Verbindungsabbrüchen. Auf Nachfrage bestätigte Julian Kirsch, dass diese Bibliothek nur ein Workaround ist und der Fokus klar auf entsprechenden Anpassungen im Quelltext der Anwendungen läge.

Was noch?

Im Kasten “TCP Stealth im Linux-Alltag” ist die Anpassung von Linux-Kernel und Open SSH zur Verwendung dieser Technologie beschrieben. Unter [11] sind Patches für den »systemd« zu finden. Wer will, kann die dort vorliegenden Codeschnipsel zum Anpassen weiterer Netzwerkdienste benutzen.

Zudem gibt es noch einen Netzwerk-Aspekt zu beachten: Es ist nicht so ungewöhnlich, dass einzelne Pakete verloren gehen. TCP trägt dann dafür Sorge, dass sie noch einmal übertragen werden. Betrifft dies aber das erste Paket des Drei-Wege-Handschlags à la TCP Stealth, ist das fatal. Wie beschrieben spielt der Zeitstempel eine Rolle bei der Berechnung der ISN. Bei einem erneut übertragenem Paket passt das dann nicht mehr.

Die Prozedur für das erneute Übertragen von Paketen ist Teil des TCP-Stack. Für Linux heißt das, dass weitere Veränderungen im Kernel notwendig sind. Das beschriebene Patch hat hier aber schon vorgesorgt. Für Sockets, die im TCP-Stealth-Modus arbeiten, nimmt der Kernel den originalen Zeitstempel und generiert keinen neuen.

Fazit und Ausblick

TCP Stealth erweist sich als vielversprechend. Auf der Webseite des Projekts gibt es ausreichende und gute Dokumentation. Beispielprogramme und vorbereitete Patches erleichtern den Einstieg. Anders als Alternativen wie Silentknock hat TCP Stealth deutlich weniger Probleme mit Network Address Translation und empfiehlt sich daher umso mehr. Die Integritätsprüfung zur Verhinderung von Man-in-the-Middle-Angriffen ist ebenfalls nicht zu verachten.

Der wissbegierige Leser könnte noch einen Blick auf die Projekte Bridge SPA [19] oder Knockknock [20] werfen. Was bleibt, das ist die Limitierung auf das Transportprotokoll TCP. Das hier vorgestellte Projekt könnte den entscheidenden Schritt tun, wenn die Aufnahme in den Linux-Kernel gelingt. (jcb)