-----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" <[email 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" <[email 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 >[email 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----- -- Discuss mailing list [email protected] https://lists.funkfeuer.at/mailman/listinfo/discuss
