Reguläre Ausdrücke mit ipfw sperren?

W

wweiland

Master of the clicks
Ich möchte bestimmte reguläre Ausdrücke in den Netzwerkpaketen über ipfw sperren. Zweck ist es P2P-Verkehr zu unterbinden. Im Manual von ipfw ist dazu nichts zu finden. Auch hier im Forum habe ich diesbzgl. nichts gefunden,
Kann mir jemand einen Tip geben?
 
Damit würdest du wohl nicht nur reguläre Ausdrücke erwischen. Ich kenne ipfw zwar nicht, aber irgendwie bezweifle ich es, dass es das gibt. Weiterhin sind die Pakete ja so klein, das müssten ja Ausdrücke für Bitkombinationen sein.
 
IPFW unterstützt keine Regulären Ausdrücke afaik. Ich glaube auch nicht, dass so etwas so bald kommen wird, ist ja auch viel zu langsam...

Aber P2P Netzwerke zu sperren würde mich auch interessieren :)
 
@Maledictus

Das ist sehr schade. Bzgl. der Filterung von regulären Ausdrücken habe ich positive Erfahrungen mit Linux iptables gemacht, insbes. mit Kazaa. Eine Verbindungsaufnahme findet immer mit dem String "X-Kazaa" statt. Und wenn dieser String dann vom Filter entdeckt wird, ist es logischerweise um die Verbindung gelaufen. Eine Verlangsamung habe ich damals nicht festgestellt. Der einzige Nachteil war eine tierische Kernelpatcherei und zusätzliches Kompilieren erforderlicher Bibliotheken.
Als momentane Sperre veröffentliche ich hier gerne meine Regeln, die zugegebenermaße sehr primitiv sind:

# kazaa - fasttrack clones
ipfw add deny log logamount 100 all from any to www.kazaa.com
ipfw add deny log logamount 100 all from any to www.kazaa.com.edgesuite.net
ipfw add deny log logamount 100 all from any to a342.g.akamai.net
ipfw add deny log logamount 100 all from any to 145.253.66.11
ipfw add deny log logamount 100 all from any to 145.253.66.19
ipfw add deny log logamount 100 tcp from any to any 1214
ipfw add deny log logamount 100 udp from any to any 1214

# edonkey and clones
ipfw add deny log logamount 100 tcp from any to any 4661-4672
ipfw add deny log logamount 100 udp from any to any 4661-4672

# winmx and napster
ipfw add deny log logamount 100 udp from any to any 6257
ipfw add deny log logamount 100 tcp from any to any 6699
ipfw add deny log logamount 100 udp from any to any 6699

# bittorrent
ipfw add deny log logamount 100 tcp from any to any 6881-6889
ipfw add deny log logamount 100 udp from any to any 6881-6889

# gnutella
ipfw add deny log logamount 100 tcp from any to any 6346
ipfw add deny log logamount 100 udp from any to any 6346

Am problematischsten ist ja Kazaa. Angeblich soll es sich so verhalten, daß es neue Ports sucht, wenn sein Standardport 1214 nicht erreichbar ist. Dann nützt natürlich auch die Sperre nichts.
Aber aufgrund des Loggings kann ich dieses jedoch leicht feststellen. Denn, wenn mich meine bisheriger Eindruck nicht täuscht, geht es immer erst über den Port 1214 los. Und sollte sich dieses häufigen, kann man notfalls für die User einen unbeschränkten Zugriff gänzlich reduzieren auf einen Zugriff nur über einen Proxy mit bspw. squidGuard.

Konstruktive Kritik und Verbesserungsvorschläge zu den obigen Filtern sind sehr willkommen.
 
hi mal wieder,

@wweiland
dieses problem sollte sich mit IPFW nicht lösen lassen, da die IPFW bis OSI-Layer 4 arbeiten. (http://www.schwitalla-online.privat.t-online.de/netzwerke/netzwerk.htm#_Toc29907170)

du benötigst, für deinen zweck, ein system, welches die nutzlast eines paketes zerlegen und analysieren kann. für http, ftp, usw wäre das die s.g. proxys. viel spass beim suchen nach einem programm, das dir dies bei P2P ermöglicht.

wir lesen uns
 
Das ist mir klar, daß das Auffinden von regulären Ausdrücken oberhalb der 4. Schicht sein muß.
Aber gilt das auch für die Initialisierung bzw. Synchronisierung einer Verbindung? Denn m.E. müßte der String wie obiges Beispiel X-Kazaa doch in den unteren Schichten sein,
Meine Frage war ja nur, ob ipfw das kann. Das geht leider im Gegensatz zu Linux und iptables offensichtlich wohl nicht.

Bei Interesse zu iptables:
ftp://ftp.netfilter.org/pub/patch-o-matic
http://www.lowth.com/p2pwall/ftwall/docs/adding_string_match.php

Um unter FreeBSD dann die Pakete entsprechend zu zerlegen, dürfte wohl sehr aufwändig werden.
 
Und ob das mit ipfw(8) geht, du musst dir die Filterung aber per divert(4)-Socket selber bauen (auch NAT ist damit umgesetzt, siehe libalias(3)).

Du machst also nen divert(4)-Socket auf, liest alle Pakete von dem Socket, und wenn die Pakete ok sind, dann schreibst du die Pakete auf den Socket zurueck. Wenn die Pakete nicht durch sollen, dann schreibst du sie eben nicht zurueck.

Hmmm, gleich mal nen PR fuer divert(4) einschicken, da steht naemlich ein Absatz doppelt drin...
 
MrFixit schrieb:
Du machst also nen divert(4)-Socket auf, liest alle Pakete von dem Socket, und wenn die Pakete ok sind, dann schreibst du die Pakete auf den Socket zurueck. Wenn die Pakete nicht durch sollen, dann schreibst du sie eben nicht zurueck.
Zum Vergrößern anklicken....

Hier komme ich in der praktischen Umsetzung nach den manuals nicht zurecht. Baue ich zunächst eine pipe auf, ähnlich wie beim shaping mit dummynet?

Und wie werden dann die Ausdrücke -wie schon erwähnt bspw. X-Kazaa ausgelesen und entsprechend gefiltert?
 
Ohne gute C Kenntnisse hast du da sowieso verloren.

Du musst ein Programm schreiben, welches einen divert(4)-Socket oeffnet -- sagen wir Port 1234 (hat NICHTS mit tcp/upd Ports zu tun!) und das Programm liest/schreibt nun Pakete auf den Socket. Auf dem divert-Socket kommen alle Daten eines Pakets an (also auch die Payload) und die untersuchst du halt entsprechend.

Danach schickst du eben alle gewuenschten Pakete durch deinen eigenen Filter (das Programm sollte natuerlich als daemon immer laufen...)
Code: 
add divert 1234 all from any to any via tun0

Update:
http://www.faqs.org/docs/Linux-mini/Divert-Sockets-mini-HOWTO.html

hier gibts eine kleines Beispiel, welches einfach nur alle Pakete die auf dem Socket ankommen anzeigt. Das ist doch schonmal ne gute Grundlage, viel Spass beim Programmieren! (Ist wirklich nicht allzu schwer...)

PS: Was genau hast du eigentlich vor?
 
Zuletzt bearbeitet:
Nun, ich möchte den P2P-Verkehr mit den Tauschbörsen unterbinden. Und Kazaa ist besonders heikel, da es automatisch neue Ports anspricht, wenn es den 1214 -Defaultport von Kazaa- nicht ansprechen kann. Selbst die IP-Adressen der Server sollen sogar häufig wechseln, so daß angeblich eine Sperre zu www.kazaa.com unwirksam sei. Was wirklich helfen soll, ist eben auf Protokollebene nach dem Ausdruck "X-Kazaa" suchen und solche Pakete, die den Ausdruck enthalten, zu verwerfen.
Das Programm muß ich mir mal anschauen, da ich aber kein Entwickler bin, sehe ich schwarz.
 
Da darfst du aber nicht blind nach X-Kazaa filtern, das muss schon im Kontext stehen. Kazaa verwendet wohl http-Transfer, oder?

Wenn du blind nach X-Kazaa filterst, dann koenntest du diesen Thread nicht sehen, und auch nirgendswo Pakete verschicken, die irgendwo den String X-Kazaa enthalten.

Anscheinend kannst du das mit Snort bequemer loesen:
http://monkey.org/openbsd/archive/misc/0310/msg00125.html
http://64.233.183.104/search?q=cach...sd.openbsd.misc&artnum=39881+pf+x-kazaa&hl=en

Oder teuere Hardware kaufen:
http://www.informit.com/articles/article.asp?p=170451&seqNum=2
 
Zuletzt bearbeitet:
MrFixit schrieb:
Da darfst du aber nicht blind nach X-Kazaa filtern, das muss schon im Kontext stehen. Kazaa verwendet wohl http-Transfer, oder?

Wenn du blind nach X-Kazaa filterst, dann koenntest du diesen Thread nicht sehen, und auch nirgendswo Pakete verschicken, die irgendwo den String X-Kazaa enthalten.

Vom Prinzip stimmt das, aber ich könnte ja die Filterung auf bestimmte IP-Adressen oder Segmente beschränken. Allerdings habe ich auch eine andere Lösung bei Studium Deiner Links gesehen, daß eine "Sperre" durch traffic shaping möglich ist. Die Begrenzung wird so niedrig gesetzt, daß es für den Downloader sich nicht lohnt, zu downloaden. Und der Kazaa-Client fällt aufgrund des offenen Standard-Ports darauf herein.
Wäre dann folgender Weg richtig?
ipfw add pipe 1 from any to any 1214 via xl0
ipfw pipe 1 config bw 1KByte/s

Mein System meckert dann über ein unbekannte Option.
hermes# ipfw add pipe 1 from any to any 1214 via xl0
ipfw: unrecognised option [-1] from

dummynet und die übrigen ipfw-Voraussetzungen sind im Kernel konfiguriert. Denn ansonsten funktionieren die übrigen Filterregeln.
Zum Vergrößern anklicken....
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben