Edonkey und Kazaa sperren

#1 Hallo

ich habe eine W2k-Rechner als Router eingerichtet. Mit Kerio will ich egentlich nur verhindern, dass die Client's mit eDonkey und Kazaa arbeiten können. Leider kann ich aber mein Regelwerk nicht so gestallten, das ich nur bestimmte Verbindungen zulassen kann. Daher muss ich eDonkey und Kazaa eplizit sperren.

Wer kann mir nun sagen, welche Ports ich für eDonkey und Kazaa sperren muss, damit man mit diesen keine Verbindung mehr aufbauen kann?


Gruß
fp

#2 http://www.bluemerlin-security.de/Netzwerk_Sicherheit_Peer_to_Peer_280303.php3
__________
°<- Vorsicht Trollköder und Trollfalle -> {_}

#3 Danke!

Genau das habe ich gesucht. Nur leider habe ich jetzt ein Problem. Da ich die Firewall (Kerio 2.1.4) auf "Is Running on Internet Gateway" stellen musste, damit DNS-Anfragen weitergeleitet werden (Internetverbindungsfreigabe), scheint die Sperrung keine Auswirkung auf die Client's zu haben. Zum Test habe ich Port 80 für beide Richtungen gesperrt, aber die Client's konnten problemlos weitersurfen.

Habe ich da ein kleines Verständnisproblem, oder mache ich etwas falsch?

Gruß
fp

#4 es ist nahezu unmöglich P2P traffic zu blocken, da aktuelle Sharing Clients es ermöglichen, sich über beliebige ports zu verbinden (http://lists.netfilter.org/pipermail/netfilter/2003-March/043048.html)

ergo macht es keinen sinn, die standardports zu sperren wenn sich die user einfach auf anderen ports verbinden

ich glaub aber, die clients müssen sich zunächst mit einer bestimmten IP connecten (serverlisten ?) und das könntest du evtl. unterbinden

dazu solltest du mit einem netzwerksniffer auf dem gateway arbeiten und den traffic untersuchen

ist ein höllen aufwand -> man sollte abschätzen, ob es den zweck damit rechtfertigt

die einstellungen in kerio müssen, wenn diese auf nem gateway arbeitet glaub ich anders aussehen

hatte es bei einem rechner mal so machen müssen

eine rule erstellen, die den incoming traffic von dem client erlaubt, der sich über den server mit einer adresse verbinden möchte

also:
client -> server rule

dann werden die verb. auf dem server ja maskiert und die nächsten rules sollten dann so aussehen

server -> IP im WAN rule

einfach gesagt:

soll sich er client nur auf port 80 verbinden dürfen, muss eine rule in etwa so aussehen

source: client IP
dest: server IP (= gateway IP !)
dest. port: 80
source port: all
proto: je nach anwendung, meist tcp
action: allow

das sollte reichen, nagel mich aber nich darauf fest, hab lang nix mehr mit der FW zu tun gehabt

greez

#5 habe gerade noch etwas nützliches gefunden für Kazaa vs. Iptables auf nem linux router

$IPTABLES -A FORWARD -p tcp -m string --string "X-Kazaa-Username:" -j REJECT
--reject-with tcp-reset

$IPTABLES -A FORWARD -p tcp -m string --string "X-Kazaa-Network:" -j REJECT
--reject-with tcp-reset

$IPTABLES -A FORWARD -p tcp -m string --string "X-Kazaa-IP:" -j REJECT
--reject-with tcp-reset

$IPTABLES -A FORWARD -p tcp -m string --string "X-Kazaa-SupernodeIP:" -j
REJECT --reject-with tcp-reset

nutze selbst kein P2P, also wenn es mal einer ausprobiert, kann er sich ja melden, ob das funzt

greez

#6 hi,

gut.

wie müsste das mit ipchains aussehen?

danke.

mfg

#7 @Emba

Interessante Sache, allerdings glaube ich das es auch einfach hilft die p2p ports zu blocken, bis auf kazzaa glaube ich haben doch alle festgelegte ports oder? Also das ganze emule net/overnet.

Edit: Deine Regeln funktionieren hier nicht, liegt wohl daran das diese Regel auf ein sogenanntes 'String' modul zurückgreift was noch experiementell ist. Auf meinem Debian Router benutz ich im moment 2.4.21 vanilla auch in 2.4.22 konnte ich dieses Modul nicht ausfindig machen. Vielleicht kannst du mir sagen wie dieses Modul genau heißt und wo ich es antreffen kann.

@schorpp

Ist eventuell mit ipchains überhaupt nicht möglich -> 'man ipchains'.
Ich denke mal für '-m string' gibt es ein extramodul. Versuch einfach die Ports zu blocken 4662(tcp,udp). Das hilft vielleicht auch - außerdem ist ipchains eh nicht mehr relewant.
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#8

Zitat

Interessante Sache, allerdings glaube ich das es auch einfach hilft die p2p ports zu blocken, bis auf kazzaa glaube ich haben doch alle festgelegte ports oder? Also das ganze E m u l e net/overnet.

Man kann durch blocken der Standardports den Traffic einschränken. Ed0nkey dürfte dadurch unbrauchbar werden.

@Lukas ich hab das böse Wort gesagt
__________
°<- Vorsicht Trollköder und Trollfalle -> {_}

#9 Also nochma kurz zu iptables:

Hab das 'string match module' ausfindig machen können allerdings ist es wie scho vermutet EXP. und daher nur in 2.5/2.6 vanilla anzutreffen (glaube ich) oder wolk etc. (patched kernels).
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#10 @xeper

sorry für die späte meldung
es geht auch mit gepatchten 2.4 kernel

bsp. können bei emule auch "dynamische" ports verwendet werden, d.h. das einfache blocken der ports reicht nicht

das problem ist nur die sinkende performance bei großen netzwerken
in kombination mit einem proxy lassen sich, wie du sicher weißt, die P2P clients aber auch einschränken

greez

#11 @Fotopunkt:

Wo liegt dein Problem? Das ganze Geheimnis ist eine "restiktive" Firewall-Administration - jede andere Admin-Philosophie ist ohnehin eher ein Feuerwehr-Job für die Fälle, wenn es schon brennt.

Aber bevor ich jetzt eine unpraktikable Lösung vorschlage, eine Frage: Wieviele Clients sind denn in deinem Netzwerk?

Wenn es sich um eine überschaubare Anzahl Clients handelt, installierst Du auf jedem Rechner die KPF. Dann erstellst Du ein Ruleset, das nur noch bestimmte Ports für bestimmte Anwendungen freigibt (z. B. Port 80, 443 etc. für den Internet-Browser; 119 für den News-Reader; 25, 110 für den E-Mail-Client; 21 für den FTP-Client etc. pp.)

Dann kannst Du natürlich an den Anfang des Rulesets eine Regel stellen, die jeden Zugriff zwischen den vertrauenswürdigen LAN-Rechnern freigibt - z. B. "erlaube alle Ports für jedes Protokoll für alle Anwendungen aller Rechner mit einer IP von 192.168.a.b bis 192.168.y.z.".

Und ans Ende des Rulesets kommt eine Regel "Blockiere alle Zugriffe über alle Protokolle für jede Anwendung zu allen IPs über alle Ports".

Dann versiehst Du die Konfiguration der Firewall mit einem netten Passwort, damit die User sich die Freigaben nicht selbst erweitern.

So kannst Du jedem User die Freigaben einrichten, die er braucht.

Ich wende diese Methode ziemlich erfolgreich in einem kleinen Firmen-Netzwerk mit 10 Clients an - seit der Einführung der KPF auf den Client-PCs gibt es dort keinerlei Filesharing-Traffic mehr.

Die brutalere und ungenauere Methode ist es, mit einem ähnlichen Ruleset nur die benötigten Ports auf dem Router freizugeben und alle Anderen zu sperren - was die User aber dann nicht daran hindern wird, sich über genau diese freigegebenen Ports mit einen P2P-Netzwerk zu verbinden, wenn die Client-Software / das P2P-Netzwerk es her gibt.

Ende der Geschichte.

Einige passable Infos zu Filesharing-Tools und den dafür benötigten Ports gibt es übrigens in der PC Professionell 10/03 ab Seite 60 - wenn die Artikel unter dem Strich auch ziemlich oberflächlich sind.


Gruss

Aahz

#12 Ups ... sorry, nachdem ich mir die ursprüngliche Frage jetzt nochmal durchgelesen habe, habe ich den Eindruck, ein bisschen an den tatsächlichen Gegebenheiten vorbei geschrieben zu haben. Sorry dafür!

Wenn ich deine Aussage "Leider kann ich aber mein Regelwerk nicht so gestallten, das ich nur bestimmte Verbindungen zulassen kann." jetzt richtig interpretiere als "Restriktive Administration unmöglich", bist Du zu bedauern. Dann rennst du deinen Usern ewig hinterher ... denn jedesmal, wenn du einen P2P-Client geblockt hast, brauchen sie eigentlich nur den Port umzustellen oder die Anwendung in ein anderes Verzeichnis neu zu installieren, und Du bist wieder der Gearschte.

Aber es ist nun mal so: die IT-Security ist immer ein Kompromiss zwischen Sicherheit auf der einen und Komfort für die Benutzer auf der anderen Seite. Erhöhst Du das Eine, schränkst Du das Andere ein.

"Meine" User schimpfen auch alle Nase lang über mich, weil Dieses oder Jenes nicht funktioniert - und der Chef hat mir kräftig auf die Schulter geklopft, als eine Nachbarfirma vom W32/Blaster "platt gemacht" wurde und ich freudestrahlend berichten konnte, dass "unser" Netzwerk sich über solche Angriffe totlachen würde, wenn die User keinen Mist bauen und selbst einen "Schädling" installieren oder ihm zumindest die Tür öffnen würden.


Gruss

AAHZ

#13 Ich habe doch noch eine "dämliche" Idee. Vielleicht würde es ausreichen, im Ruleset der Firewall bestimmte Anwendungen komplett freizugeben und alles Andere zu blocken?

Wenn das Netzwerk überschaubar ist, sollte es kein Problem sein, z. B. für die Web-Browser, für die E-Mail-Clients, für die Newsreader etc. pp. alle Ports und IPs freizugeben, also jede tatsächlich verwendete Anwendung komplett freizugeben und für alle anderen nicht "genehmigten" Anwendungen einen totalen Block zu setzen.

Das setzt natürlich nach wie vor voraus, dass die Firewall nicht (nur) auf dem Router, sondern auf jedem einzelnen Rechner installiert ist.

Gut, das ist ein bisschen mehr Arbeit und auch nicht ganz so "sicher" wie eine komplett restriktive Administration. Aber es wäre immerhin eine Möglichkeit.


Gruss

Aahz

#14 @aahz

das halte ich keine gute idee, jeder application vollste freiheiten in der verbindung zu geben
unter application verstehe ich auch alle zur netzwerkommunkation notwendigen dienste von windows...gibst du diese wieder im netzwerk frei (und sei es nur im LAN) bist du vor würmern kaum gefeit

desweiteren gibt es viele viren (und ich denke es ist nur eine frage der zeit, bis die P2P clients auch so eine funktion bieten), die sich an appl. anhängen, bzw. in deren code verstecken
lässt du den IE also zu, würde jeder dieser viren, der sich an den IE "koppelt" auch vollste freiheiten genießen

viele programme bieten zwar MD5 checksums, nur ist dies auch kein allheilmittel dagegen

greez

#15 Am einfachsten ist es doch per Gruppenrichtlinie das Ausführen solcher p2p Applikationen zu unterbinden!!
__________
Never touch a running SysOp