Archive: Month 4, Year 2010

Riven Proxy: Theorie und Praxis

08.04.2010 yahe legacy thoughts

Bevor ich nach Mannheim gezogen bin und mein Studium begonnen habe, habe ich überlegt, was ich als Internetanschluss haben möchte. Mir war schon klar, dass ich in den folgenden drei Jahren viel unterwegs sein würde. Also entschied ich mich für einen mobilen Internetanschluss über GPRS und UMTS. In der folgenden Zeit stellte sich heraus, dass ich als Informatikstudent doch Lust habe, einen öffentlich zugänglichen Server zu hosten. Nun fing aber das Problem an: Im Gegensatz zu DSL erhält man bei GPRS/UMTS keine externe IP-Adresse, die aus dem Internet erreichbar ist. Stattdessen bekommt man nur eine interne Netzwerk-IP und die Information, über welches Gateway man Internetseiten aufrufen kann.

Das war natürlich sehr frustrierend. Deshalb begann ich, mir zu überlegen, wie ich dieses Problem lösen könnte. Die Lösung, zu der ich schlussendlich fand, taufte ich Riven Proxy. "Riven" ist Englisch und heißt übersetzt so viel wie "zerissen". Diese Bezeichnung ist auf seine Struktur zurückzuführen, die ich euch gerne erklären möchte. Heutzutage wird man es wohl eher als "split proxy" bezeichnen.

Zum besseren Verständnis habe ich ein tolles Bild gemalt, in dem die verschiedenen Teile des Puzzles inklusive ihrer Verbindung gezeigt werden. Das gezeigte Schema ist eine Ableitung von HujiStats Bild "Schematic_Proxy_Server.png" und steht, wie das ursprüngliche Bild, unter der Creative Commons Lizenz by-sa.

Riven Proxy Aufbau mit Beschriftungen

Auf dem Bild sehen wir, dass wir zum einen den Client ("C") und den Server ("S") haben. Ziel ist es, dass sich der Client mit dem Server verbinden kann. Normalerweise ist dies kein Problem. Der Server ist normalerweise so positioniert, dass der Client ihn problemlos erreichen kann. Wie ich jedoch eingangs erzählt habe, gibt es durchaus Szenarien, in denen dies nicht der Fall ist. Es kann z.B. sein, dass der Server via UMTS mit dem Internet verbunden ist, es kann aber genauso gut sein, dass sich der Server in einem Netz befindet, das über eine restriktive Firewall von außen abgeschirmt ist. In diesen Fällen ist eine direkte Verbindungsaufnahme nicht möglich (soll durch die abprallenden Verbindungspfeile "(A)" und "(B)" symbolisiert werden).

Damit trotzdem eine Verbindung aufgebaut werden kann, muss nun der angesprochene Riven Proxy eingesetzt werden. Dieser besteht aus zwei Teilen - dem Male Proxy ("M") und dem Female Proxy ("F"). Der Male Proxy befindet sich in direkter Nähe des Servers und muss in der Lage sein, sich mit dem Server und mit dem restlichen Internet verbinden zu können. Der Female Proxy hingegen befindet sich außerhalb des restriktiven Netzwerkes und aggiert als eine Art Satellit. Es ist sehr wichtig, dass der Female Proxy (der Satellit) vom Client und vom Male Proxy erreicht werden kann.

Der Aufbau funktioniert nun wie folgt: Bei der Initialisierung des Proxies verbindet sich der Male Proxy mit dem Female Proxy. Da dies eine ausgehende Verbindung ist, wird sie von der Firewall nicht blockiert. Diese Verbindung ist die sogenannte "Control Connection" ("1"). Über diese wird dem Female Proxy z.B. mitgeteilt, welcher Port für ankommende Verbindungen geöffnet werden soll. Zudem wir dem Male Proxy über diese Verbindung mitgeteilt, wann sich ein Client mit dem Female Proxy (dem Satellit) verbunden hat.

Wenn der Client sich nun mit dem Female Proxy verbindet ("2"), erhält der Male Proxy ein Signal ("3"), das ihn veranlasst, eine Datenverbindung zum Female Proxy ("4a") und eine Datenverbindung zum Server ("4b") aufzubauen. Da auch dieses Mal die Verbindung aus dem Netzwerk nach außen gerichtet ist, wird auch dieses Mal die Verbindung gestattet. Damit ist die indirekte Verbindung zwischen dem Client und dem Server hergestellt. Wenn nun der Client Daten an den Female Proxy schickt, werden diese über die neue Verbindung an den Male Proxy und von diesem an den Server geleitet. Wenn der Server Daten an den Male Proxy schickt, werden diese an den Female Proxy von diesem an den Client weitergereicht.

Dies ist die Theorie, die ich mir vor gut 3 Jahren ausgedacht habe. Wie ich nun gestern erfahren habe, gibt es so etwas sogar schon in der praktischen Anwendung. Genauer gesagt bietet SSH die Möglichkeit, eine solche Verbindung aufzubauen. Dort heißt es jedoch "Reverse Tunneling", arbeitet aber genau nach dem gerade gezeigten Prinzip. Auf dem Satelliten läuft ein SSH-Server, der seinen Benutzern erlaubt, Tunnel aufzubauen (beim Schema des Riven Proxy wäre dies der Female Proxy). Auf dem Server, der erreichbar gemacht werden soll, läuft der SSH-Client (dieser SSH-Client entspricht dem Male Proxy). Er baut eine permanente Verbindung zum SSH-Server auf und teilt diesem darüber mit, welcher Port zum SSH-Client weitgereicht werden soll. Wenn nun eine Verbindung beim SSH-Server ankommt, werden die Daten an den SSH-Client weitergereicht, der diese dann ebenfalls weitergibt.

Ich persönlich bin nun ziemlich glücklich. Zum einen, da ich den Riven Proxy nicht selber implementieren muss und zum anderen, da ich dank der SSH-Implementierung des Reverse Tunnelung gesehen habe, dass mein Konzept praxistauglich gewesen ist. Natürlich ist es ein bisschen traurig, dass ich nicht der erste war, der diese Idee hatte, aber man kann ja schließlich nicht alles haben.

P.S.: Ich habe gerade ein echtes Schmankerl ausgegraben, das ich euch nicht vorenthalten möchte. Als ich 2007 die Überlegungen zum Riven Proxy angestellt habe, habe ich einen Text darüber verfasst. Der ist nie in größeren Umlauf gekommen, aber ich denke, dass er hier in den Artikel gut hinpasst. So findet auch er endlich seine letzten Ruheort.

Riven Proxy
(Wie man einen NAT-Server überlistet)

Mit dem Zuneige-Gehen des IPv4-Adressen-Bereiches wurden Mittel und Wege gefunden, den Verbrauch von Adressen im Internet zu verringern. Eine häufig eingesetzte Variante, der NAT-Server, bringt jedoch ein Problem mit sich, das es gilt, in den Griff zu kriegen.

Wer das Pech hat, zwangsweise hinter einem NAT-Server (Network-Address-Translation-Server) sitzen zu müssen, kennt das Problem: das Anbieten eines Servers ist so gut wie unmöglich. Wenn man keinerlei Zugriff auf die Konfiguration des NAT-Servers hat und demzufolge keinen Port-Forward einrichten kann, ist es so gut wie aussichtslos - oder doch nicht?
Es kursiert die Variante, die Kommunikation zwischen dem Server, der hinter einem NAT-Server ist und dem Client über UDP ablaufen zu lassen. Jedoch gibt es bei dieser Lösung ein Problem. Damit die eigentliche Kommunikation funktioniert, muss vom Server zu Beginn ein Garbage-Package an den Client geschickt werden, um den NAT-Server in dem Glauben zu lassen, dass der Server die Verbindung zum Client initiiert hat. Woher soll der Server jedoch die Adresse des Clients kennen? Diese Methode hat also den Schwachpunkt, dass die Adresse des Clients von vorneherein bekannt sein muss. Einen Server direkt anzubieten ist demzufolge nicht möglich. Vielleicht aber indirekt?
An dieser Stelle setzt der von mir konzipierte "Riven Proxy" an ("Riven Proxy" bedeutet soviel wie "zerrissener Proxy", was auf den Aufbau des Proxys zurückzuführen ist). Bei diesem handelt es sich um eine Kombination aus einem Proxy und einem Reverse-Proxy.
Während der eigentliche Proxy (aufgrund der Form auch als weiblicher Proxy - oder "Female Proxy" - bezeichnet) außerhalb des vom NAT-Server abgetrennten Netzwerkes ist, befindet sich der Reverse-Proxy (auch männlicher Proxy oder "Male Proxy") innerhalb des Netzwerkes. Intern arbeitet der Riven Proxy durch einen Pull-Mechanismus. Das bedeutet, dass dem Server die Daten nicht zugeschickt (/gepushed) werden, sondern dass sie (über den Male Proxy) abgefragt (/gepulled) werden.

Nun aber zur genauen Funktionsweise: Damit der Proxy funktionieren kann, muss der Male Proxy (hinter dem NAT-Server) eine Kontrollverbindung ("Control Connection") zum Female Proxy (vor dem NAT-Server) aufbauen. Durch diese wird zum einen festgelegt, auf welchem Port der Female Proxy auf ankommende Verbindungen warten soll und zum anderen wird über diese Verbindung dem Male Proxy mitgeteilt, dass ein Client eine Verbindung zum Female Proxy aufgebaut hat.
Ist dies der Fall, baut der Male Proxy eine weitere Verbindung (eine "Data Connection") zum Female Proxy auf. Diese wird dann im Female Proxy zur Client-Verbindung geroutet - gleichzeitig baut der Male Proxy eine Verbindung zum eigentlichen Server auf. Wurde die Verbindung hergestellt, fragt der Male Proxy in regelmäßigen Abständenüber über die Data Connection ab, ob Daten von der Client-Verbindung eingegangen sind. Ist dies der Fall, werden die Daten über die Data Connection an den Server weitergeleitet. Antworten werden über den selben Weg an die Client-Verbindung weitergereicht.
Nun werden auch die Bezeichnungen Male Proxy und Female Proxy verständlich - während der Male Proxy an beiden Seiten Client-Verbindungen (die Verbindungen zum Server auf der einen und die Control und Data Connections auf der anderen Seite) aufbaut, besteht der Female Client auf beiden Seiten aus Servern (auf der einen Seite für die Control und Data Connections und auf der anderen für die Client-Verbindungen).

Eine berechtigte Frage möge nun sein, ob es denn überhaupt vorkommen kann, dass man einen Server hinter einem nicht-konfigurierbaren NAT-Server anbietet. Die Antwort ist jedoch ein klares "ja" - es kann sehr wohl vorkommen. Bestes Beispiel könnte die Nutzung von HSDPA und HSUPA (-> UMTS) zur Internetanbindung sein. Dieses wird vereinzelt bereits als Fallback bei Ausfall der kabelgebundenen Internetleitung genutzt und einige stützen sich bereits einzig und allein auf UMTS für die Internetverbindung. Jedoch nutzen alle großen Mobil-Anbieter (zumindest in Deutschland) NAT-Server für die Anbindung der UMTS-Nutzer an das Internet. Sicherlich lässt sich eine solche Lösung auch für andere Formen von Firewalls nutzen, die für den Geschmack des Nutzers zu streng mit Verbindungsversuchen von außen umgehen.
Desweiteren mag man fragen, weshalb man nicht anstelle des Female Proxys direkt den Server ansetzt. Zum einen mag die Zugänglichkeit zum Server selbst eine Rolle spielen und zum anderen die bereits angesprochene Nutzung von UMTS als Fallback.
Ein letzter Punkt ist sicherlich, dass es aufwendig ist, einen weiteren Server einzurichten, über den der komplette Traffic geleitet werden muss - allerdings hat sich bereits bei normalen Proxys gezeigt, dass sich zumindest dort sogar öffentlich frei nutzbare Angebote etabliert haben, das Durchleiten also wirtschaftlich nur wenig bedenklich ist.

Leider existiert bisher keine Referenzimplementierung des Konzeptes - dies soll jedoch bald nachgeholt werden.

freeSSHd Security: Work in Progress

05.04.2010 yahe administration code legacy windows

Auf meinem Heimserver laufen freeSSHd und freeFTPd eigentlich ohne Probleme, wenn da nicht die Angriffe von außen wären. Allein in den letzten 1,5 Monaten wurde eine Million mal versucht, in meinen SSH-Server einzubrechen. Nochmal knapp 500.000 Einbruchsversuche gingen auf das Konto des FTP-Servers. Bisher war das noch kein Problem, aber ich würde doch gerne Gegenmaßnahmen ergreifen. Glücklicherweise bieten beide Server eine Möglichkeit, IP-Adressen zu blocken. Zudem wird in den Log-Dateien der Server protokolliert, wenn ein Benutzer versucht hat, sich mit falschen Daten (Benutzername oder Passwort) einzuloggen. Auf dieser Basis habe ich das Tool fsshdsec gebaut, das das Erstellen der Blockliste automatisiert.

freeSSHd Oberfläche

Auf dem Screenshot kann man erkennen, wo was eingestellt sein muss, damit die IPs in dem großen Feld ausgesperrt werden. Sowohl die Einstellung "Refuse these IP addresses" als auch die eigentliche Liste können über die *.ini-Datei des Servers verwaltet werden. Im Bereich "Access filtering" der *.ini-Datei gibt es den Wert "HostRestrictions", in dem die Liste der geblockten IPs stehen. Wenn der Wert "HostRestrictionsAllow" auf null ("0") gesetzt ist, ist allen IPs der Zugriff auf den Server verboten. Zum erneuten Einlesen der Daten ist leider ein Neustart des Servers erforderlich. Den Neustart kann man am einfachsten realisieren, wenn der Server als Windows-Dienst installiert worden ist, denn dann kann man ihn über die Diensteverwaltung problemlos stoppen und wieder starten. Bei der Liste der gesperrten IP-Adressen gibt es hingegen leider ein größeres Problem.

freeSSHd \*.ini-Datei

In beiden Screenshots habe ich den letzten Eintrag in der Liste der geblockten IPs markiert. Wie man sieht, stehen in der *.ini-Datei mehr Einträge, als in der Oberfläche angezeigt werden. Wie es scheint, kann der Server nur maximal 2kb an Daten verarbeiten, der Rest wird einfach ignoriert. Wegen dieser Unzulänglichkeit habe ich vor Ostern den Entwickler der beiden Server angeschrieben. Bisher habe ich jedoch leider keine Antwort erhalten. Sollte das Problem auch zukünftig bestehen, werde ich wohl oder übel einen eigenen kleinen Proxy schreiben müssen, der an eine IP-Filtertabelle angeschlossen ist.

Trotz des Problems wollte ich euch an dieser Stelle schon einmal die bisherige Lösung zur Verfügung stellen. Sie ist noch in einem ganz frühen Alphastadium, deshalb sollte man sie nur dann einsetzen, wenn man auch wirklich weiß, was man tut. Der freeSSHd-Server muss für die Verwendung als Service installiert sein. Alle Informationen über den Server holt sich das Programm direkt aus der Diensteverwaltung, sowie der Log- und der *.ini-Datei. Das Programm ist auch als kleine Sicherung gedacht. Wenn der freeSSHd-Server also einmal unverhofft abstürzen sollte, wird er nun automatisch neu gestartet.


Search

Links

RSS feed

Categories

administration (40)
arduino (12)
calcpw (2)
code (33)
hardware (16)
java (2)
legacy (113)
linux (27)
publicity (6)
review (2)
security (58)
thoughts (21)
windows (17)
wordpress (19)