[Discuss] p2p-Filter (war: [wien] DNS sperre wegen skype - heute abend im Metalab)

Mi Okt 9 16:32:27 CEST 2013

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Aaron,

klingt alles nach meinem alten Zapp-Script. Ungeändert wird es im Zappfall 4 Stunden lang  UDP sperren und Port 53 auf localhost biegen. Wenn da kein Resolver drauf läuft, dann sieht das wie eine DNS-Sperre aus.

Gruß aus Berlin // Sven-Ola

"L. Aaron Kaplan" <(spam-protected)> schrieb:
>
>
>Prinzipiell vorab: DNS Sperren (so wie ich sie kenne) sind *keine* gute
>Idee.
>
>Siehe auch: https://www.isc.org/blogs/blocking-dns/
>(Wer Paul Vixie nicht kennt: das ist der Autor vom BIND nameserver,
>unter anderem)
>
>
>On Oct 8, 2013, at 10:40 PM, "Erich N. Pekarek" <(spam-protected)>
>wrote:
>
>> Hallo!
>>
>> Am 2013-10-08 21:32, schrieb Martin Asmus:
>>> Hallo,
>>>
>>> da wir uns vom praktischen in den theoretischen Bereich bewegen, mal
>auf discuss verschoben.
>> Vorweg: ich gebe Dir in den maßgeblichen Punkten Recht, und ich bin
>nicht konkret auf das vorliegende Problem eingegangen, sondern auf das
>Problem einer Maßnahmensetzung im Allgemeinen. Daher würde ich die
>Diskussion auch gerne auf die Testtage verlagern, ... über Mails lösen
>wir das nicht.
>Umgekehrt kommen vielleicht 5% aller hier subscrib-ten zu den
>Testtagen.
>Also ich finde das schon OK auf der Liste.
>
>>>
>>> Am 08.10.2013 12:28, schrieb Erich N. Pekarek:
>> ...
>> Lass mich trotzdem hier ein paar Punkte klarstellen:
>>>> ...
>>> In meinem Fall werde ich gesperrt, sobald ich mein lokales Netz an
>0xff anbinde, da ich 2 Geräte betreibe, auf denen Symform läuft. (Ist
>zumindest meine einzige Erklärung)
>>> Er orientiert sich (soweit ich das beurteilen kann) weder an der
>Auslastung des Knotens, noch an der "Bösartigkeit" der Verbindungen.
>>> Außerdem handelt es sich auch nicht um ein "last resort", das nur
>benutzt wird, wenn der Knotenbetreiber nicht erreichbar ist.
>> Schon richtig. Hierzu sollten wir einen Ablauf - best practices -
>definieren. Manche Vorgehensweisen passieren einfach aus der Not heraus
>und ich gehe davon aus, dass einige Knoten keine ideale Konfiguration
>haben (siehe unten). Da liegt noch Arbeit vor uns - und auch das ist
>wohl "experimentell" am Netz.
>>>> Das Zuschalten von Filtern oder QOS mag im Prinzip des PPA als
>unzulässig gelten, aber man muss das, so denke ich, in Relation zum
>Zweck der Bestimmung sehen: und der ist nicht, die Verbreitung von
>Schadsoftware oder die Begünstigung von DDoS mit oder ohne Wissen der
>Nutzer, sondern im Schutz der Privatsphäre und im prinzipiell freien
>Datenverkehr zum Wohl der beteiligten Nutzer begründet.
>>> Und genau diesen freien Datenverkehr sehe ich hier beeinträchtigt.
>> Bleiben wir beim Problem: Es gibt guten Traffic und weniger guten
>Traffic, ob das nun ins Idealbild passt oder nicht: Eine Wasserleitung
>soll schließlich auch dicht und stabil sein, damit sie ihren Zweck
>erfüllt; Ist sie das nicht gibt es Schäden.
>> Netzneutralität sehe ich in diesem Vergleich durch Stabilität und
>Dichtheit und der Wassermenge begrenzt. Nur dort wo der Druck zu stark
>erhöht wird, dass Wasser eingefärbt, umgeleitet, etc wird, wird sie
>tatsächlich verletzt. Sie dient der ungestörten Versorgung, nicht
>einem, diesem Zweck zuwiderlaufenden bloßen Selbstzweck.
>>
>>> Inwiefern ergibt sich ein Schutz der Privatsphäre? (Außer, dass ich
>geschützt bin, wenn ich keine Daten ins Internet schicken kann...;-))
>> Scherzkeks ;-) Aber Du siehst das oben beschriebene Problem ;)
>> Gemeint war Datenschutz versus Deep Packet Inspection, die im PPA
>definitiv nicht zulässig wäre.
>>
>> Ich leite das aus
>> 	• Der Eigentümer bestätigt, freien Transit über seine freie
>Netzwerkinfrastruktur anzubieten
>> 	• Der Eigentümer bestätigt, die Daten, die seine freie
>Netzwerkinfrastruktur passieren, weder störend zu beeinträchtigen noch
>zu verändern.
>> her, auch, wenn so nicht dort steht.
>>>
>>>> (Es gibt aber kein Prinzip, das ohne sachliche begründete Ausnahme
>gerecht wäre und daher auf Biegen und Brechen umgesetzt werden muss -
>wäre dem so, könnten wir gleich wie die Provider eine Policy ausgeben,
>in Hard- und Software "enforcen", wie dies bei gewissen
>Provider(zwangs)modems der Fall ist. Die Deutschen diskutieren gerade
>heftig über diese Unsitte.)
>>>> Ich will das in unserem Netz nicht, ...
>>> ack, das will hier, glaub ich, niemand.
>>> Wir haben allerdings ein agreement, das besagt, dass der eigene
>Knoten als relay für den 0xff-traffic dienen muss. Die Funktionalität
>dafür sollte auf jedem Knoten gegeben sein.
>> Was auch aufgrund von Fehlkonfigurationen nicht immer passiert. Z.B.:
>Interface in der falschen Zone, Weiterleitung in der Zone auf Drop, NAT
>auf externen Interfaces... diese Fehler treten häufiger auf, als wir
>wahrhaben wollen und haben denselben störenden Effekt.
>>>
>>>> In diesem Zusammenhang muss ich allerdings auch (Selbst-)Kritik
>üben, denn ein unverschlüsseltes Datennetzwerk über Funk ist
>auch nicht gerade im Sinn einer Auslegung des PPA unter den Aspekten
>des Datenschutzes und der Selbstbestimmtheit der Nutzer. Ich würde
>daher zumindest soweit gehen, eine einfache Grundverschlüsselung
>(WPA2-PSK) des Netzes oder Teilen davon zu fordern, auch, wenn das
>nicht alle Lauscher abhalten kann.
>>> Soweit ich weiß, gab es da den Konsens Verschlüsselung auf höheren
>Layern zu propagieren.
>> Das ist illusorisch, solange man mit einfacheren Problem zu kämpfen
>hat und das Know-How nicht beim User (nicht unbedingt Betreiber)
>ankommt.
>
>Wieso ist das illusorisch. end-to-end crypto ist der einzige Weg. Und
>damit musst du halt auch den layer 7 einbeziehen.
>Martin hat da IMHO schon vollkommen recht.
>
>> Anytun als Ausweg?
>
>
>>> Da AES gerade unter Beschuss gerät und andere tiefgreifende
>Diskussionen und Probleme im Crypto-Bereich existieren, würde ich hier
>vielleicht noch abwarten, da man sonst evtl. ein falsches
>Sicherheitsgefühl erzeugt.
>> Das ist zu befürchten.
>
>Welcome to the Cryptocalypse...
>Das ganze ist wirklich mittlerweile eine ziemliche Tragoedie.
>
>>> Gibt es schon Überlegungen/Versuche, wie sich das auf die
>Netzlast/-kapazität auswirken würde?
>> Im AP-Mode sehe ich keine prinzipiellen Probleme: Sonst würden die
>auf eduroam basierenden Netze der Unis allesamt stehen - und soviele
>Nutzer wie dort haben wir üblicherweise nicht pro AP.
>> Zum Adhoc-Mode habe ich keine Erfahrungen - dass ich kein Fan des
>"Nicht-Standards" Adhoc bin.
>> Mich würde 802.11s weit mehr interessieren.
>
>Letzteres skaliert nicht. Das wissen wir seit vielen Jahren schon.
>Es ist vielleicht fuer ein lokales in der Wohnung-mesh gut.
>
>
>lg,
>a.
>
>(mit CC an die richtige security@ liste :)
>
>
>------------------------------------------------------------------------
>
>--
>Discuss mailing list
>(spam-protected)
>https://lists.funkfeuer.at/mailman/listinfo/discuss

- --
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8-fdroid

iHQEAREIADQFAlJVaPstHFN2ZW4tT2xhIFT8Y2tlIDxTdmVuLU9sYS5UdWVja2VA
Y29tbWFuZG8uZGU+AAoJEK8XFNEZA9CyhHcAoP9M6DB4zGbX0Kl93nxFdEFrnD9a
AKCYt/cyH7us7IWW8/jbLMxv/t7b9w==
=sVrb
-----END PGP SIGNATURE-----