Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
tm-107
Anmeldedatum: 24.03.2005 Beiträge: 1130 Wohnort: Panketal - OT Schwanebeck
|
Verfasst am: 04.06.2006, 14:02 Titel: |
|
|
Hallo nochmal,
wenn ich in der Konfig-Datei IPP2P_AUTOBLOCK='yes' setze, dann wird zwar wieder alles geblockt (auch mein privates LAN), aber dafür kann ich mich per WLan auch nicht mehr connecten. Nun sieht der Screenshot so aus:
Es muss also irgendwo in der Syntax liegen. Kann es evtl an der 4. Zeile in meinem Screenshot liegen?
UPDATE: Ja, es liegt an dieser Zeile. Wenn die erste Regel nicht existiert, werden hier Verbindungen erlaubt bevor sie von IPP2P gefiltert werden können.
Ich benötige leider eine Verbindung mit einem speziellen edk-Clienten (AkteMule falls es jemandem was sagt), sonst wäre mir das ganze relativ egal.
Eine andere Lösung wäre das ganze auf den WRT zu installieren. Das soll ja ab FFF 1.3 im Gateway-Plugin drin sein. Ich weiss nur nicht ob da nur die Standardports geblockt werden oder ein Paketfilter wie IPP2P eingesetzt wird.
gruss
tm-107
PS: Dem genauen Betrachter wird ein Unterschied in der Zuordnung der IP-Netze aufgefallen sein:
Das .107.x-Netz ist weiterhin mein privates LAN
Das .108.x-Netz ist weiterhin das Netz in dem der WRT hängt
Das .109.x-Netz ist jetzt mein privates WLan (ehemals .1.x)
Zuletzt bearbeitet von tm-107 am 05.06.2006, 19:40, insgesamt 2-mal bearbeitet |
|
Nach oben |
|
|
gockelhahn
Anmeldedatum: 07.12.2005 Beiträge: 184 Wohnort: Berliner Allee / Smetanastraße (104.13.13.13)
|
Verfasst am: 04.06.2006, 15:27 Titel: |
|
|
im neuen gateway plugin für fff 1.3 soll wohl ein ipp2p modul enthalten sein
Marek Lindner hat Folgendes geschrieben: | Hi,
die neue Version des Gateway-Plugins hat nun das Teststadium erreicht.
Folgende Neuerungen könnt ihr erwarten:
* P2P-Filter über ipp2p iptables Modul. Es analysiert den
durchgehenden Traffic auf P2P-Kommandos und blockt dann die
entsprechenden Verbindungen. Folgende P2P-Protokolle werden
erkannt: eDonkey, eMule, Kademlia, KaZaA, FastTrack, Gnutella,
Direct Connect, BitTorrent, extended BT, AppleJuice, WinMX,
SoulSeek, Ares, AresLite. Mehr Infos unter: http://www.ipp2p.org/ .
* WebUI hat ein Facelifting bekommen (danke an die vielen Hinweisgeber).
* Das Laden der Whitelist wurde verbessert, um die Performance zu
steigern (Anregungen von Stefan Pirwitz und MM).
* Alle Seiten sind nun übersetzt (Dank an Wulf).
* Viele Bugfixes. |
quelle _________________ jabber: gockelhahn @ dernico.no-ip.org |
|
Nach oben |
|
|
tm-107
Anmeldedatum: 24.03.2005 Beiträge: 1130 Wohnort: Panketal - OT Schwanebeck
|
Verfasst am: 05.06.2006, 16:19 Titel: |
|
|
Na dann könnten sich einige meiner Probleme ja von selbst lösen ... jetzt muss ich den Filter nur noch für mein privates WLan einrichten.
gruss
tm-107 |
|
Nach oben |
|
|
tm-107
Anmeldedatum: 24.03.2005 Beiträge: 1130 Wohnort: Panketal - OT Schwanebeck
|
Verfasst am: 05.06.2006, 19:35 Titel: |
|
|
Sooo,
jetzt habe ich es endlich hinbekommen!!! Gefiltert werden jetzt nur noch die Verbindungen ins OLSR-Netz und mein privates WLan. Derzeit versucht mein Notebook seit über 30 min eine Verbindung zum edk-Netz aufzubauen ...
Nach unzähligen Versuchen habe ich mich wieder für die unfeine Methode entschieden und in den Startscripten des OPT_IPP2P rumgefummelt.
Aus
Code: | /usr/local/bin/colecho "Auto-Blocking common known P2P Traffic"
iptables -I FORWARD -m ipp2p --ipp2p -j DROP |
wurde jetzt
Code: | /usr/local/bin/colecho "Auto-Blocking common known P2P Traffic"
iptables -I FORWARD -p tcp -s 192.168.109.0/24 -m ipp2p --ares -j DROP
iptables -I FORWARD -p tcp -s 192.168.109.0/24 -m ipp2p --soul -j DROP
iptables -I FORWARD -p tcp -s 192.168.109.0/24 -m ipp2p --soul -j DROP
iptables -I FORWARD -p tcp -s 192.168.109.0/24 -m ipp2p --apple -j DROP
iptables -I FORWARD -p tcp -s 192.168.109.0/24 -m ipp2p --winmx -j DROP
iptables -I FORWARD -s 192.168.109.0/24 -m ipp2p --bit -j DROP
iptables -I FORWARD -s 192.168.109.0/24 -m ipp2p --gnu -j DROP
iptables -I FORWARD -s 192.168.109.0/24 -m ipp2p --gnu -j DROP
iptables -I FORWARD -s 192.168.109.0/24 -m ipp2p --kazaa -j DROP
iptables -I FORWARD -s 192.168.109.0/24 -m ipp2p --edk -j DROP
iptables -I FORWARD -p tcp -s 192.168.108.0/24 -m ipp2p --ares -j DROP
iptables -I FORWARD -p tcp -s 192.168.108.0/24 -m ipp2p --soul -j DROP
iptables -I FORWARD -p tcp -s 192.168.108.0/24 -m ipp2p --apple -j DROP
iptables -I FORWARD -p tcp -s 192.168.108.0/24 -m ipp2p --winmx -j DROP
iptables -I FORWARD -s 192.168.108.0/24 -m ipp2p --bit -j DROP
iptables -I FORWARD -s 192.168.108.0/24 -m ipp2p --gnu -j DROP
iptables -I FORWARD -s 192.168.108.0/24 -m ipp2p --kazaa -j DROP
iptables -I FORWARD -s 192.168.108.0/24 -m ipp2p --edk -j DROP |
Falls jetzt jemand fragt warum ich die Reihenfolge umgedreht habe ... damit im Webinterface wieder die richtige Reihenfolge entsteht. Die Befehle werden immer vorne angestellt.
Damit sieht der Screenshot dann folgendermassen aus:
So langsam wird mein Fli4l immer mehr zu dem was ich mir vorgestellt habe. Jetzt müsste das BIOS nur noch eine 2te 80GB-HDD akzeptieren ... aber das ist ein anderes Thema
gruss
tm-107 |
|
Nach oben |
|
|
wusel
Anmeldedatum: 28.05.2006 Beiträge: 43
|
Verfasst am: 06.06.2006, 09:25 Titel: |
|
|
Na super. Hätte mich auch gewundert, wenn es nicht geht. Da hast Du also in dem Paket einen Fehler entdeckt. Werde ich dann bei meinem berücksichtigen, wenn ich ipp2p einbaue.
Uli |
|
Nach oben |
|
|
glockman
Anmeldedatum: 21.09.2004 Beiträge: 2097 Wohnort: suermondtstr/degnerstr ... ohne AP
|
Verfasst am: 06.06.2006, 12:12 Titel: |
|
|
ahauaha ... was haste da gemacht??
Code: | iptables -A FORWARD -s 192.168.108.0/24 -p tcp -m ipp2p --ipp2p -j DROP
iptables -A FORWARD -s 192.168.109.0/24 -p tcp -m ipp2p --ipp2p -j DROP |
reicht vollkommen aus ... ich würde die filterung auf tcp beschränken, weil ipp2p auf udp-pakete eine heftiges overmatching, gerade bei voip, erzeugt ... deswegen "-p tcp" ... wenn du das in kauf nehmen möchtest, dann lass es weg ... könnte den gefilterten aber probleme beim onlinezocken und viop-telefonieren bereiten.
das "-m ipp2p --ipp2p" deckt alle netzwerke ab, die ipp2p zuverlässig unterstützt ... die einzelnen netzwerke müssen nicht extra angegeben werden .. und wenn, dann in einer zeile:
Code: | iptables -I FORWARD -p tcp -s 192.168.109.0/24 -m ipp2p --ares --apple --winmx -j DROP
iptables -I FORWARD -s 192.168.109.0/24 -m ipp2p --bit --gnu --kazaa --ed2k -j DROP |
das sieht sauberer aus und senkt die benötigte rechenzeit ... |
|
Nach oben |
|
|
wusel
Anmeldedatum: 28.05.2006 Beiträge: 43
|
Verfasst am: 06.06.2006, 21:03 Titel: |
|
|
Wenn ich tm-107 richtig verstanden habe, dann braucht er ja einen dieser Dienste und kann daher nicht alle mit einem Befehl erschlagen.
Bin mir auch nicht sicher, ob man wirklich auf UDP verzichten kann.
Hinweise darauf habe ich gefunden unter:
http://www.gulli.com/filesharing/programme/emule/
Muss man die Protokolle noch mal genauer unter die Lupe nehmen.
Vielleicht kann ich mal mit Ethereal tracen.
Vielleicht reicht ja wirklich nur TCP zu filtern, wenn immer wichtige Nachrichten dabei sind, die nur mit TCP übertragen werden. Wie gesagt, muss man untersuchen.
Uli |
|
Nach oben |
|
|
tm-107
Anmeldedatum: 24.03.2005 Beiträge: 1130 Wohnort: Panketal - OT Schwanebeck
|
Verfasst am: 06.06.2006, 22:56 Titel: |
|
|
Hi,
also der Standardbefehl --ipp2p deckt nur 3 p2p-Protokolle ab (edonkey, kazaa, gnutella). Alle anderen werden in dem Paket immer extra gefiltert.
Die einzelne Auflistung habe ich aus rein informatorischen Gründen gewählt ... so kann ich sehen mit welchen Clienten es versucht wurde. Meinst Du das macht solche Probleme?
Die von mir verwendete Syntax (inkl. UDP-Filterung) habe ich an anderer Stelle in dem Paket in genau dieser Form gefunden (nur halt ohne Source-Angabe), also dachte ich mir das passt schon:
Code: | /usr/local/bin/colecho "Auto-Blocking ALL known P2P Traffic"
iptables -I FORWARD -m ipp2p --ipp2p -j DROP
iptables -I FORWARD -m ipp2p --bit -j DROP
iptables -I FORWARD -p tcp -m ipp2p --winmx -j DROP
iptables -I FORWARD -p tcp -m ipp2p --apple -j DROP
iptables -I FORWARD -p tcp -m ipp2p --soul -j DROP
iptables -I FORWARD -p tcp -m ipp2p --ares -j DROP |
Die UDP-Filterung soll ja wohl nur bei den Beta-Protokollen Probleme bereiten ... bei den 4 wichtigen funktioniert es laut IPP2P-Homepage ja recht zuverlässig.
Nebenbei bemerkt: VoIP funktioniert ohne Probleme über meinen WRT ...
@wusel: Ich habe derzeit alle Netze "erschlagen", aber halt nicht in meinem LAN ... dort ist alles erlaubt.
gruss
tm-107 |
|
Nach oben |
|
|
wusel
Anmeldedatum: 28.05.2006 Beiträge: 43
|
Verfasst am: 07.06.2006, 00:09 Titel: |
|
|
Habe nochmal auf der Webside von IPP2P nachgeschaut.
Wenn man der Beschreibung dort folgt dann sind die Regeln von tm-107 OK.
Allerdings steht dort noch, dass "Direct Connect" von der Standard- Option mit abgedeckt wird.
Habe bei mir auch nochmal meine Einstellungen von
IPP2P_AUTOBLOCK = yes
auf
IPP2P_AUTOBLOCK = all
geändert und siehe da die benötigten Regeln landen alle vor dem Rest und das ganz ohne Modifikation des Standard- Paketes.
So sieht dann meine "Forward- chain" aus:
Code: | Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.8.0 --ares
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.8.0 --soul
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.8.0 --apple
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.8.0 --winmx
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.8.0 --bit
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.8.0 --ipp2p
1103 642K accin all -- * * 0.0.0.0/0 0.0.0.0/0
1103 642K accout all -- * * 0.0.0.0/0 0.0.0.0/0
25 1500 TCPMSS tcp -- * ppp0 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
1078 640K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED /* FORWARD_ACCEPT_DEF */
0 0 DROP all -- * * 127.0.0.1 0.0.0.0/0 state NEW /* FORWARD_ACCEPT_DEF */
0 0 DROP all -- * * 0.0.0.0/0 127.0.0.1 state NEW /* FORWARD_ACCEPT_DEF */
25 1500 PORTFWACCESS all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW /* state:NEW PORTFWACCESS */
0 0 ACCEPT all -- * * 192.168.250.0/24 192.168.252.0/24 /* FORWARD_LIST_1='IP_NET_1 192.168.252.1/24 ACCEPT BIDIRECTIONAL' */
0 0 ACCEPT all -- * * 192.168.252.0/24 192.168.250.0/24 /* FORWARD_LIST_1='IP_NET_1 192.168.252.1/24 ACCEPT BIDIRECTIONAL' */
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:139 /* FORWARD_LIST_2='tmpl:samba DROP' */
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445 /* FORWARD_LIST_2='tmpl:samba DROP' */
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:137:138 /* FORWARD_LIST_2='tmpl:samba DROP' */
25 1500 ACCEPT all -- * * 192.168.250.0/24 0.0.0.0/0 /* FORWARD_LIST_3='IP_NET_1 ACCEPT' */
0 0 fw-rej tcp -- * * 104.0.0.0/8 104.15.15.15 tcp dpt:81 /* FORWARD_LIST_4='IP_NET_2 IP_NET_2_IPADDR:81 REJECT' */
0 0 fw-rej udp -- * * 104.0.0.0/8 104.15.15.15 udp dpt:81 /* FORWARD_LIST_4='IP_NET_2 IP_NET_2_IPADDR:81 REJECT' */
0 0 fw-rej tcp -- * * 104.0.0.0/8 104.15.15.15 tcp dpt:5000 /* FORWARD_LIST_5='IP_NET_2 IP_NET_2_IPADDR:5000 REJECT' */
0 0 fw-rej udp -- * * 104.0.0.0/8 104.15.15.15 udp dpt:5000 /* FORWARD_LIST_5='IP_NET_2 IP_NET_2_IPADDR:5000 REJECT' */
0 0 fw-rej tcp -- * * 104.0.0.0/8 104.15.15.15 tcp dpt:5001 /* FORWARD_LIST_6='IP_NET_2 IP_NET_2_IPADDR:5001 REJECT' */
0 0 fw-rej udp -- * * 104.0.0.0/8 104.15.15.15 udp dpt:5001 /* FORWARD_LIST_6='IP_NET_2 IP_NET_2_IPADDR:5001 REJECT' */
0 0 fw-rej tcp -- * * 104.0.0.0/8 104.15.15.15 tcp dpt:22 /* FORWARD_LIST_7='IP_NET_2 IP_NET_2_IPADDR:22 REJECT' */
0 0 fw-rej udp -- * * 104.0.0.0/8 104.15.15.15 udp dpt:22 /* FORWARD_LIST_7='IP_NET_2 IP_NET_2_IPADDR:22 REJECT' */
0 0 ACCEPT all -- * * 104.0.0.0/8 104.0.0.0/8 /* FORWARD_LIST_8='IP_NET_2 IP_NET_2 ACCEPT' */ |
Da ist auch alles schön dicht. Aber in dem Standardpaket eben an allen Interfaces.
Das FLI4L- Paket setzt die Regeln auch nicht zusammen. Das Zusammensetzen macht sicher Sinn.
Uli |
|
Nach oben |
|
|
glockman
Anmeldedatum: 21.09.2004 Beiträge: 2097 Wohnort: suermondtstr/degnerstr ... ohne AP
|
Verfasst am: 07.06.2006, 00:44 Titel: |
|
|
wenn man die benutzung der eizelnen netzwerke accounten will, macht das natürlich sinn ... wenn du in der richtung keine probleme hast, dann lass es so ...
aber das filtern von udp macht keinen wirklichen sinn ... denn alle resourcenraubenden verbindung laufen auf tcp ab ... lasst den P2P-geilen olsr-knoten doch den gleuben, er hätte sich erfolgreich verbunden ... wenn keine tcp-connection zustandekommt, wird er keinen byte runterladen können ... irgendwann ist er frustiert und gibts auf ... vlt ist er sogar so frustriert, dass er das filesharen sogar freiwillig als unbrauchbar abtut ... wodurch die P2P-netz in zukunft einen schmarotzer weniger haben ...
wegen der unterschiedlichen infos zur option "--ipp2p" ... die seite ist teilweise URALT ... die doku habe ich fast unverändert schon im sommer letzten jahren lesen können ... in der zwischenzeit arbeitet schon nen neuer entwickler dran ... |
|
Nach oben |
|
|
tm-107
Anmeldedatum: 24.03.2005 Beiträge: 1130 Wohnort: Panketal - OT Schwanebeck
|
Verfasst am: 07.06.2006, 19:34 Titel: |
|
|
Hi,
also DirectConnect habe ich doch glatt vergessen ... *gleich ändern*
Ich möchte aber nicht dass sich jemand zu einem Server verbinden kann, denn dabei werden ja auch seine Freigaben an den Server übermittelt. Und genau ab diesem Punkt befindet man sich juristisch nicht mehr ganz auf legalem Gebiet. Solchen Problemen möchte ich halt einfach von Anfang an aus dem Weg gehen.
gruss
tm-107 |
|
Nach oben |
|
|
wusel
Anmeldedatum: 28.05.2006 Beiträge: 43
|
Verfasst am: 07.06.2006, 21:31 Titel: |
|
|
Wäre da auch noch der Punkt mit den vielen hundert Verbindungen, die die P2P clients beim Connecten erzeugen. Manche Syteme steigen ja auch bei so vielen IP- Verbindungen aus.
Bei FLI4L hab ich das noch nicht gesehen, aber wer weiss...
Uli |
|
Nach oben |
|
|
tm-107
Anmeldedatum: 24.03.2005 Beiträge: 1130 Wohnort: Panketal - OT Schwanebeck
|
Verfasst am: 08.06.2006, 20:09 Titel: |
|
|
Und schon hat der Filter zugeschlagen
Die jeweiligen Verursacher sind mir mittlerweile jedoch bekannt (war keine böse Absicht) und versicherten mir beide dass kein Verbindungsaufbau möglich war.
Damit sind jetzt drei P2P-Netze definitiv geblockt
Trotzdem sollte ich vielleicht doch mal die Zuverlässigkeit der anderen Filter überprüfen. Hatte bisher nur keine Lust mir lauter P2P-Software auf mein Notebook zu packen bzw. kein Bock auf ein Backup
gruss
tm-107
PS: |
|
Nach oben |
|
|
tm-107
Anmeldedatum: 24.03.2005 Beiträge: 1130 Wohnort: Panketal - OT Schwanebeck
|
Verfasst am: 16.08.2006, 01:19 Titel: |
|
|
Interessante Beobachtung:
Mein Fli4l meldet wiedermal Soulseek-Traffic und fischerbln ist derzeit der einzige User in unserem 2-Personen-Netz auf Kanal 6.
Laut seiner Aussage lief auf dem Rechner zur betreffenden Zeit nur ein Radio-Stream in Winamp. Also scheint IPP2P hier ein paar Pakete falsch zuzuordnen ...
Jetzt ist Winamp abgeschaltet und die Sache wird bis morgen beobachtet. Mal schauen ob sich die Vermutung bestätigt.
gruss
tm-107 |
|
Nach oben |
|
|
glockman
Anmeldedatum: 21.09.2004 Beiträge: 2097 Wohnort: suermondtstr/degnerstr ... ohne AP
|
Verfasst am: 16.08.2006, 10:20 Titel: |
|
|
jaja ... das meinte ich mit overmatching ... bei tcp nicht weiter wild ... wirds halt nochmal gesendet ... aber bei udp ist das fälschlicherweise gedroppte paket einfach wech! |
|
Nach oben |
|
|
|