Verhindern von http-tunneling

wweiland

Master of the clicks
Dieses Thema ist nicht unbedingt BSD-spezifisch, paßt aber dennoch hier hin.

Ich möchte das http-tunneling unterbinden.
Neuerdings bieten die Tauschbörsen ein Filesharing über http-tunneling an. Da ich aus grundsätzlichen Gesichtspunkten gegen Raubkopiererei bin, möchte ich meinen Sohn daran hindern, auf diesem Wege doch wieder u.a. wieder an Kazaa ranzukommen.

Vorstellen könnte ich mir ein Unterbinden mit einem Filter wie squidGuard oder Danguardian. Letzteres wird von mir bereits genutzt. NAT wird nicht eingesetzt. IRC läuft über einen Proxy (tircproxy), der hoffentlich wirklich DCC und damit auch den Dateitransfer verhindert.

Eine andere Variante wäre sicherlich auch Paketfilterung mit String-Überprüfung, der Tunnelpakete einfach dropt.

Mir fehlt aber der Ansatz, wo ich anfangen soll. Welche Ausdrücke sind zu prüfen etc?

Über Ideen würde ich mich sehr freuen.
 
Original geschrieben von wweiland
Dieses Thema ist nicht unbedingt BSD-spezifisch, paßt aber dennoch hier hin.

Ich möchte das http-tunneling unterbinden.
Neuerdings bieten die Tauschbörsen ein Filesharing über http-tunneling an. Da ich aus grundsätzlichen Gesichtspunkten gegen Raubkopiererei bin, möchte ich meinen Sohn daran hindern, auf diesem Wege doch wieder u.a. wieder an Kazaa ranzukommen.

Vorstellen könnte ich mir ein Unterbinden mit einem Filter wie squidGuard oder Danguardian. Letzteres wird von mir bereits genutzt. NAT wird nicht eingesetzt. IRC läuft über einen Proxy (tircproxy), der hoffentlich wirklich DCC und damit auch den Dateitransfer verhindert.

Eine andere Variante wäre sicherlich auch Paketfilterung mit String-Überprüfung, der Tunnelpakete einfach dropt.

Mir fehlt aber der Ansatz, wo ich anfangen soll. Welche Ausdrücke sind zu prüfen etc?

Über Ideen würde ich mich sehr freuen.

Als OpenBSD-User (mit Erfahrung mit PacketFilter pf) würde ich dir natürlich empfehlen, diesen aus den Ports zu installieren und damit die betreffenden Filesharing-Ports zu filtern.

Jedoch müsstest du dich in die Materie einlesen und wenn du nach einer schnellen Lösung auf der Suche bist, dann wäre der PacketFilter (egal von welchem System) nicht die richtige Wahl, da er einfach viel zu viel Hintergrundwissen abverlangt.

Aber empfehlen kann ich ihn dir auf alle Fälle, da man mit ihm noch viel mehr machen kann. :)

Schaue bei OpenBSD.org nach. Dort findest du eine gute FAQ zum Paketfilter.

Und dieser ist auch unter FreeBSD verfügbar.

Gruß

CW
 
Hi wweiland,

man könnte es über die Browser-Identifikation probieren.

Immer wenn per Webbrowser ein HTTP-Request gestartet wird, sendet er seinen Identifikationsstring mit, z. B.
"Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)" oder
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Opera 7.10 [de]" oder
"Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5a) Gecko/20030730 Mozilla Firebird/0.6.1" usw.

Ein von Kazaa & Co. initierter Tunnel wird (hoffentlich) eine andere Identifikation bzw. garkeine mitschicken.

Jetzt müßte der Proxy, den Du einsetzt (oder was auch immer) das Feature haben, auf diese Browser-Identifikationen zu reagieren und entsprechend zu agieren.
Ein neues OS inkl. Paketfilter wäre also ein bisschen zuviel des Guten - zumal es Dir nicht weiterhilft.

Ist nur so eine fixe Idee ;)

Gruß
RW
 
so wie ich das sehe, möchte Du nur http über Port 80 lassen und verhindern, dass jemand andere Applikationen über Port 80 umleitet?


--> squid!!!! HTTP-Proxy
 
so wie ich das sehe, möchte Du nur http über Port 80 lassen und verhindern, dass jemand andere Applikationen über Port 80 umleitet
Nicht zu vergessen Port für https 443.

Anderer Vorschlag (ohne Funktions-Garantie)
Man kann beim Squid einstellen wieviel Informationen des Browsers mit übertragen werden und die auch teilweise manipulieren. ggf. ist das ein Weg, aber sicher nicht der netteste. Ausserdem hat dann der Browser evtl. beim normalen surfen Probleme.
 
Port 443 sollte geschlossen sein, denn darueber kann man _ALLES_ tunneln. Im Gegensatz zu Port 80, welches mit einem Transparenten Proxy tunneln fast unmoeglich macht. Wenn jedoch das File-Sharing Protokoll aufs http-Protokoll aufsetzt hast du auch da gelitten.

Andereseits verwendet Kazaa doch einen zentralen Server, oder nicht? Blockiere doch dessen IP.

Die beste Loesung waere aber trotzdem deinem Sohn ins Gewissen zu reden. Erziehung ist besser als Ueberwachung!
 
Original geschrieben von MrFixit
Port 443 sollte geschlossen sein, denn darueber kann man _ALLES_ tunneln. Im Gegensatz zu Port 80, welches mit einem Transparenten Proxy tunneln fast unmoeglich macht.
Ich will den Port ja nicht öffnen. Aber wenn ich schon einen Proxy verwende sollte ich auch https berücksichtigen, oder?

Die beste Loesung waere aber trotzdem deinem Sohn ins Gewissen zu reden. Erziehung ist besser als Ueberwachung!
FULL ACK!
 
Vielen Dank für die Antworten.

Aber leider helfen Diese mir nicht wirklich.

Zu cws Vorschlag:

Sicher ist ein Paketfilter auf den ersten Blick die beste Lösung. Unter Linux gibt es sogar eine neue Software (ftwall; FYIhttp://www.lowth.com/p2pwall/: ), die in Kombination mit dem stringmatch von iptables hervorragend zusammenarbeitet.
Pakete mit Ausdrücken wie X-Kazaa etc kommen in eine queue, derer sich dann dankbar ftw annimmt: Es blockiert halt für eine eingestellte Zeit die Verbindung des Kazaclients zum Router, auf dem ftw und iptables laufen. Und solange der Klient versucht, andere Clients zu erreichen, so lange gibt es immer Verlängerung. Der Anwender ist gehalten, den Client herunterzufahren. Außerdem logt es die Zugriffe.

Aber: verhindert das auch das http-tunneling? Wird nicht möglicherweise ein bestimmter header unter http mit einem bestimmten String verwendet, den man auf Filterebene droppen könnte.

Und im übrigen geht das Tunneling wohl über das normale HttP Protokoll, wenn ich die Ausführungen von anderen Quellen richtig verstanden habe.

Die anderen "menschlichen Tips" sind auch in Ordnung. Nur richtet sich der Filius nicht danach, offen sichtlich ist die Versuchung zu groß. Und noch möchte ich die harte Tour -Kein Internet- nicht fahren. Wenn man Versuchungen vermeiden kann, sollte man es auch als Elternteil tun. Insofern ist Überwachung leider nötig.
 
Original geschrieben von wweiland
Vielen Dank für die Antworten.

Aber leider helfen Diese mir nicht wirklich.

Zu cws Vorschlag:

Sicher ist ein Paketfilter auf den ersten Blick die beste Lösung. Unter Linux gibt es sogar eine neue Software (ftwall; FYIhttp://www.lowth.com/p2pwall/: ), die in Kombination mit dem stringmatch von iptables hervorragend zusammenarbeitet.
Pakete mit Ausdrücken wie X-Kazaa etc kommen in eine queue, derer sich dann dankbar ftw annimmt: Es blockiert halt für eine eingestellte Zeit die Verbindung des Kazaclients zum Router, auf dem ftw und iptables laufen. Und solange der Klient versucht, andere Clients zu erreichen, so lange gibt es immer Verlängerung. Der Anwender ist gehalten, den Client herunterzufahren. Außerdem logt es die Zugriffe.

Aber: verhindert das auch das http-tunneling? Wird nicht möglicherweise ein bestimmter header unter http mit einem bestimmten String verwendet, den man auf Filterebene droppen könnte.

Und im übrigen geht das Tunneling wohl über das normale HttP Protokoll, wenn ich die Ausführungen von anderen Quellen richtig verstanden habe.

Die anderen "menschlichen Tips" sind auch in Ordnung. Nur richtet sich der Filius nicht danach, offen sichtlich ist die Versuchung zu groß. Und noch möchte ich die harte Tour -Kein Internet- nicht fahren. Wenn man Versuchungen vermeiden kann, sollte man es auch als Elternteil tun. Insofern ist Überwachung leider nötig.

Lies dir mal diesen Thread durch: http://www.bsdforums.org/forums/showthread.php?s=710788d49d499a9a224fa167a0c123ae&threadid=13516

Vielleicht kannst du eine der Ideen verwirklichen.

Gruß

CW
 
Ja, ja, diese Probleme habe ich auch durch, wie sie beschrieben wurden. Aber ich dachte bisher, daß deshalb der Weg über einen Proxy Server der sicherste Weg sei. Und letztlich kommt in den postings ja auch zum Ausdruck, daß eine Application Layer firewall diesbzgl. wohl das sicherste ist. Vorausgesetzt, man benutzt keine NAT.
Aber, wenn der KazaaClient sogar den Port 80 benutzt. Nun weiß ich nicht, ob man beim Client einen Proxy Server einstellen kann. Ich vermute aber mal, daß squid solche offenen Anfragen nicht durchlassen würde.
Und jetzt sind wir wieder beim Tunneling angelangt. Nur über diesen Weg hätte in meiner Situation ein Client die Möglichkeit, KAzaa zu nutzen.
Und das FreeBSD Handbook schreibt zum Application Level Gateway auch nichts aufregendes.
Die einzige Chance, die ich wirklich sehe, ist, daß squid Http Anfragen mit einem gewissen Header ablehnt.
Aber dazu müßte man den Header kennen.
 
Hi,

du kennst vielleicht nicht den Header von Kazaa bzw. des http-Tunnels, aber du kennst die Header der von dir und deinem Sohn verwendeten Browser. Diese sehen in etwa alle so aus, wie in meinem ersten Posting beschrieben.

Jetzt könntest Du alles blocken, was nicht diesen "richtigen" Browser-Signaturen entspricht - wenn das in deiner verwendeten Proxy-Software geht...

Gruß
RW
 
Du hast Recht.
Manchmal sieht man vor lauter Betriebsblindheit nicht das naheliegende.
Ich werde es testen. Wenn die Filesharing Clients nun nicht einen gängigen Browser nachahmen, dürfte die Sache klar gehen.

Vielen Dank!
 
Ich hoffe, ich nerve nicht, wenn ich nochmals mit diesem Thema ankomme.

Aber ich möchte in diesem Zusammenhang auch über squid nachvollziehen, inwieweit downloads durchgeführt wurden.

Nun gibt es bei squid die Möglichkeit den mime type berichten zu lassen:
acl aclname rep_mime_type

Wenn ich jetzt zum Beispiel den Download von exe Dateien nachvollziehen will, wäre dann folgende syntax richtig:

acl download-check rep_mime_type -i ^application/octet-stream

Den Mime-Type für exe Dateien habe ich der mime.conf entnommen. Das Beispiel in der squid.conf bezieht sich auf javascript.

Könnte ich so dann aus der Log-file unter dem Suchbegriff "download-check" alle downloads nachvollziehen? Wenn ja, dann könnte ich zumindest die gängigsten Mime-types aus der Windows Welt protokollieren lassen.

Ich möchte das aus erzieherischen Gründen, um ggf. meinen Sohn zu überführen. Wir wissen ja sicherlich selbst aus der Jugendzeit, daß wir Nachweise für unsere Schandtaten haben wollten :)
 
Zurück
Oben