[Freifunk Franken] 60 GB Overhead im Monat f�¼r ?sinnloses? Routing

Tim Niemeyer tim.niemeyer at mastersword.de
Di Mär 3 19:47:59 CET 2015


Hallo Michael

Am Dienstag, den 03.03.2015, 13:47 +0100 schrieb Michael Fritscher:
> Hi,
> 
> bislang habe zumindest ich nur von Routing bedingten Broadcasts geredet.
> Schon alleine, weil ich ehrlich gesagt davon ausgegangen bin, dass
> Nutzer-Broadcasts gefiltert werden.
> 
> Von Nutzer-Broadcasts halte ich garnichts, schon weil die Netze extrem
> zumüllen. Das nervt schon in lokalen (Unternehmens-)netzen, in einem
> ausgedehnten Netz will man das aber in den allerwenigsten Fällen. Das hat
> nichts mit willkürlichen Einschränkungen zu tun, sondern dient dem
> Selbstschutz des Netzes und auch der User.
Du kannst das Netz damit nicht vor Missbrauch schützen, da jeder dieser
Filter von den Router Betreibern (was jeder sein kann) entfernt werden
kann. Ein Angreifer kann aber auch einfach gleich seine Maschine direkt
ins Batman-Netz hängt.

Bis heute ist mir kein Fall bekannt, wo ein Freifunk Netz absichtlich
gestört wurde. Aber ich bin mir auch ganz sicher, dass diese Zeiten
kommen werden.

> 
> Beispiele für problematische Broadcasts
> 
>   * DHCPv4 und v6 (letzteres wird v.a. für die DNS-Server Zuweisung
> verwendet) - sollte lokal bearbeitet werden (z.B. durch abfangen &
> direktes zusenden an den DNS-Server).
Entweder ich verstehe nicht, was du mit lokal bearbeitet meinst, oder du
hast die Freifunk Franken Netz Struktur nicht verstanden. 

Es ist außerdem beabsichtigt, dass zumindest jeder theoretisch selber
dhcp senden kann und damit das Netz erweitert. Das das so einfach
natürlich nicht geht ist klar, aber es ist gewollt.

>   * SMB-Geraffel (WINS ist für solch große und dynamische Netze nicht
> ausgelegt, und sicherheits- und datenschutztechnisch ist das auch
> zumindest fragwürdig)
>   * CUPS (die wenigsten wissen überhaupt darum)
>   * avahi, uPNP und Konsorten (ähnliche Probleme wie SMB und CUPS)
>   * Spanning Tree Protokolle (werden gerne von einige Switche rausgehaun,
> das sollte aber Aufgabe von batman sein. Außerdem sind die STP oftmals
> nicht auf so lange Delays ausgelegt -> kann lustige Effekte geben)
> 
> Ein weiteres großes Problem ist die Angreifbarkeit des Netzes durch
> Broadcasts. Es brauchen nur paar Leute Webcams zu broadcasten, was schon
> durch eine Unaufmerksamkeit passieren kann, und schon wird das Netz
> überflutet. Auch sind Scans+Pings auf Broadcastadressen oft eine ziemlich
> interessante Sache ;)
Du kannst das Netz nicht vor sowas schützen. Es ist einfach ein offenes
Netz, da kannst du auch nichts weg filtern. Auf der L3 Ebene haben wir
einen gewissen Schutz, weil eben nicht jeder Zugriff in das Netz hat und
ein Anschluss daran nur über jemanden geht, der bereits einen Anschluss
hat. Hier ziehen wir das Konzept des gegenseitigen Vernetzens durch.

> Es gibt einige wenige Fälle, wo Broadcasts sinnvoll sein könnten (z.B.
> globale Statusmeldungen) - aber solche Anwendungen sollten meines
> Erachtens von einem größeren Nutzerkreis abgesegnet und nicht einfach so
> von einem einzelnen Teilnehmer aus ins Netz gehauen werden können.
> 
> In den allermeisten Fällen wäre aber Multicast wesentlich sinnvoller, wo
> sich Teilnehmer in logische Broadcast-Gruppen reinhängen können. Es wäre
> ein Traum, wenn das funktioniert :-)
Bitte informiere dich mal, wie das Routing von Multicast im Batman-Adv
Netz läuft.

Tim

> 
> Viele Grüße,
> Michael
> 
> _______________________________________________
> franken mailing list
> franken at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net





Mehr Informationen über die Mailingliste franken