HTTP Tunneling Server

Huhu.

Würde gerne einen Tunneling Server auf meinem Root-Server installieren,
um den Dienst http://www.http-tunnel.com nicht in Anspruch nehmen zu müssen (aus Sicherheitsgründen).

Kennt einer von Euch zufällig einen freien Server für Linux und freie Clients für Linux/Windows ?
Womöglich auch “quasi-geschützt” über SSL ?

Mein Szenario ist u.a. mit SSH über so einen SOCKS Server Firewalls tunneln zu wollen, ohne Sicherheits-Einbußen in Form des HTTP-Protokolls zu haben, sondern das gleich mit HTTPS zu machen.

Bzgl. SOCKS stecke ich da nicht so sehr in der Theorie drin, kann auch sein, dass das doppelt gemoppelt formuliert ist…

TIA
Klaus

He Tek,

Zufall, oder hat Dich der Seti-Thread und mein und Beorns Post auf die Sache aufmerksam gemacht bzw Dich an solche Programme erinnert? :slight_smile:

Roi

kein Zufall. :wink:

Kannst Du nicht eine ppp-Verbindung zum Root-Server über SSH tunneln und dann dort NATen?

He Tek,

wusste ich’s doch. Kann Dir zwar bei Deinem Problem nicht weiterhelfen, vermisse Dich allerdings noch auf dem SetiQueue-Server (Werbetrommel schwing!)… :slight_smile: Ah und by the way: Welcome Doc Green mit seinem Linux Seti-Client.

Roi

Nein. :sunglasses:

Es geht explizit nur darum, einen Tunneling Server einzusetzen, und nicht darum, Alternativ-Lösungen zu schaffen, welche auch immer es geben mag.

Ich suche halt so einen HTTP-Tunnel Server, den ich nicht selber schreiben muss, der mich nichts kostet ausser dem Traffic auf meinem Server und der relativ offen ist (sourcecode-technisch); letzteres ist aber nicht sooo wichtig.

hmm ich bin mir sicher, dass der linux kernel seit urzeiten auch tunneling unterstützt… (also ist der server schon im kernel “eingebaut”)
ist opensource und verschlüssen kann man das ganze auch noch irgendwie (mehr infos kann ich dir grade nicht geben… aber die kernel documentation sollte hilfreich sein)

XMAS

http://www.nocrew.org/software/httptunnel.html

Oder auch

http://www.google.de/search?q=Linux+HTTP+Tunnel

:wink:

LOL, ja genau. :grin:

Leider grösstenteils Linux-üblich nur GPL.
Oder eben sehr prototypisch, was mir aber nicht so viel ausmacht.

Für den Anfang ganz ok, aber ich würde wenigstens LGPL benötigen, da ein kommerzieller Einsatz nicht ausgeschlossen ist.
(Reine GPL-Software disqualifiziert sich diesbezüglich leider und werde alles tun, nur nicht gegen diese Lizenzbestimmung verstossen.)

Danke erstmal, ich habe ein bisschen anders gegooglet und habe nicht alle diese Links gesehen.

:wink:

Du darfst auch GPL-Software kommerziell nutzen. Du darfst Sie sogar weiterentwickeln und verkaufen.

Einzige Einschränkung: Du musst dann den Quelltext offenlegen. Aber dann kannst Du immer noch für z.B. Installation und Support kassieren.

Wie soll die kommerzielle Nutzung bei Dir den aussehen?

Ja, stimmt schon, nur gibt es bei kommerziellem Einsatz normalerweise Grenzen für die Offenlegung, was vom Kunden abhängt; gut, soweit ich den Sourcecode nicht ändere, ist das ok.
Nur dürfte ich z.B. jedes Stückchen Software aus eigener Hand nicht als Closed Source weglegen; dass beisst sich ggf. mit Kundenverträgen, die komplette Closed Source explizit verlangen; und das kriegst Du aus den Köpfen nur sehr schwer heraus. Gerade wieder hatte ich eine nette Unterhaltung mit der Rechtsabteilung eines Kunden, der nicht verstanden hat, dass das Linux-Projekt natürlicherweise viele GPL-Teile enthält, die Linux-Distribution selbst ja auch.
Was soll ich sagen? Mein Eindruck ist, dass 90% der Anwälte in Software-Häusern nicht einmal wissen was GPL oder Open Source ist. :roll_eyes:

OK, ich sag’ Dir, was ich zunächst machen will, auch mit GPL-Projekten (ich bin eh Verfechter von Open Source und hab’ jetzt mal Mut zur Lücke):

  • Erstmal Tunnel-Server und Client testen
  • ggf. Client selbst schreiben, wenn nicht vorhanden (SOCKS4 Proxy)
    oder anderweitig nicht frei konfigurierbar verfügbar
  • Für ein kleines Firmen-Intranet einziehen, in dem IMAP, SSH, SCP
    und einige Application Server-Zugriffe getunnelt werden sollen.
  • Client und Server für HTTPS Tunneling ergänzen, sofern nötig.
    denn: SSH durch HTTP zu tunneln, erscheint mir nicht wirklich sicher.
    (oder ist das ein Trugschluss?)
  • Den Server noch schön abrunden, tunen, die Hardware ein wenig
    aufstocken, sicher machen bis zum Anschlag und nach Prüfung der
    Lizenzeinschränkung aller verwendeten Bibliotheken das Ganze für
    andere bereitstellen.
    Zunächst für lau für Beta-Tester und später günstiger als alle anderen
    Anbieter :smiley:

Das wären ja schon mal ein paar Milestones, wie falsch auch immer ich sie hier rausgerotzt haben mag.

Ja, stimmt schon, nur gibt es bei kommerziellem Einsatz normalerweise Grenzen für die Offenlegung, was vom Kunden abhängt; gut, soweit ich den Sourcecode nicht ändere, ist das ok.
Nur dürfte ich z.B. jedes Stückchen Software aus eigener Hand nicht als Closed Source weglegen; dass beisst sich ggf. mit Kundenverträgen, die komplette Closed Source explizit verlangen; und das kriegst Du aus den Köpfen nur sehr schwer heraus. Gerade wieder hatte ich eine nette Unterhaltung mit der Rechtsabteilung eines Kunden, der nicht verstanden hat, dass das Linux-Projekt natürlicherweise viele GPL-Teile enthält, die Linux-Distribution selbst ja auch.
Was soll ich sagen? Mein Eindruck ist, dass 90% der Anwälte in Software-Häusern nicht einmal wissen was GPL oder Open Source ist. > :roll_eyes: >

Eine Alternative wäre es evtl. mal nachzusehen, ob es möglich ist Schnittstellen in den Tunneling Server einzubauen (oder evtl. sogar schon da sind), die es Dir ermöglichen, weitere Funktionalitäten über separate Programme hinzuzufügen, die dann z.B. über Pipes oder Sockets mit dem Tunneling Server kommunizieren. Es sollte erlaubt sein, diese dann komplett Closed Source zu halten.

  • Für ein kleines Firmen-Intranet einziehen, in dem IMAP, SSH, SCP
    und einige Application Server-Zugriffe getunnelt werden sollen.
  • Client und Server für HTTPS Tunneling ergänzen, sofern nötig.
    denn: SSH durch HTTP zu tunneln, erscheint mir nicht wirklich sicher.
    (oder ist das ein Trugschluss?)

Den ersten Satz verstehe ich nicht ganz, letzteren schon.
SSH über HTTP zu tunneln sollte eigentlich genauso sicher sein, wie SSH über TCP/IP zu jagen, weil ja SSH selbst die Verbindung verschlüsselt. HTTPS würde es Dir allerdings erlauben “unsichere” (=ohne ausreichende Verschlüsselung) Protokolle zumindestens bis zu Deinem Tunneling Server sicher zu übertragen. Falls HTTPS keine Option ist, kann man immer noch SSH-Tunnel über Deinen HTTP-Tunnel bauen, allerdings fürchte ich, das da der Overhead doch schon ziemlich groß wird.

Ansonsten gibt es noch die Möglichkeit, auf dem Tunneling-Server gleichzeitig einen VPN-Server (z.B. FreeS/WAN oder PoPToP) aufzuziehen (ggf. dann noch NAT, je nachdem, wieviele IPs Du da belegen kannst), und die Verbindung dahin über HTTP zu tunneln. VPN-Lösungen verschlüsseln die Verbindung i.d.R. ja auch.

Den Satz, den du nicht verstanden hast, besagt nur, dass die genannten Dienste (=>Ports) trotz restriktivster Firewall per HTTP getunnelt werden sollen; sonst wollte ich nichts weiter damit ausdrücken.

Die VPN Variante ist natürlich zusammen mit IPSec (wenn, dann richtig!) genau die Sicherheitsstufe, die das Tunneln ein bisschen blöd aussehen lässt. Für ein solches Szenario muss ich doch eigentlich nicht auch noch die Firewall so dicht machen, dass nichts ausser HTTP durchkommt…
… dann lieber sauber mit IPTables arbeiten, würde ich sagen.

An dieser Stelle verlasse ich aber das Terrain, auf dem ich genügend weiss, um noch vernünftig argumentieren zu können, sorry. Steckt alles noch etwas in den Kinderschuhen.
:wink:

Mir kommt es auf die Option an, auf spezielle Konfigurationen der Netze verzichten zu können ausser der, dass eine Firewall so viel wie möglich blockt (= gut) oder ein Proxy wie Squid, den viele kleine Firmen zur Internet-Einwahl und als Quasi-Firewall “missbrauchen”, nicht wirklich viel durchlässt (was nicht zwingend schlecht, aber irgendwie ärgerlich ist).

Tja, ansonsten habe ich mich jetzt entschieden, mir 3 Tunnel-Server näher anzusehen und mehr Feeling dafür zu bekommen. Da hilft alles nichts, glaube ich.

Hi,

aus aktuellem Anlass (HTTPort bringt famose 1-2KB/Sek auf die Reise und die Downloads der Seti-WUs brechen laufend ab) hab ich doch auch direkt eine Frage zu nem eigenen Tunnelingserver:

Meinem Verstaendnis nach funktioniert das so: Ein Client verpackt Pakete in SSL-Pakete und schickt sie (und das sogar durch nen Proxy) zum Server. Der packt sie wieder aus und leitet sie entsprechend weiter. Je nachdem wie der Client konfiguriert ist koennen das beliebige Dienste (IRC, FTP, HTTP, POP3, SMTP usw) sein. Sehe ich das so richtig, oder?

So, mein Client hier im Buero ist momentan HTTPort, ohne Einstellungsmoeglichkeit des Tunnel-Servers. Oder war ich nur zu blind. Ne sicher nicht, weil wenn man das Teil fuer 5 Dollar im Monat registriert geht es ja schneller als 1-2KB/Sek und wenn ich nen eigenen Server einstellen kann wuerd ich ja die Registrierung umgehen koennen.

Ich brauche also ne Client- und nen Serversoftware, beides Win32-basierend. Kann mir da jemand spontan weiterhelfen oder soll ich direkt googlen… :slight_smile:

Danke schonmal,
Roi

Auf der GNU httptunnel Seite gibt es auch einen Link zu Windows NT bzw. Win32 Binaries. Kannst ja entweder die ausprobieren oder versuchen den Kram selbst zu compilieren, am einfachsten geht das vermutlich, wenn Du die Cygnus Tools für Windows installiert hast (http://www.cygwin.com).