Probleme

  1. Wenn  alle Rechner im selben Netz hängen ist arpspoofing möglich. Somit könnte jeder beliebige Rechner das ganze Netz lahm legen!
  2.  Jeder kann dem anderen seine IP-Adresse wegnehmen? Wie kann ich sicher  einen Server dienst anbieten? Kann ein Node identifiziert werden,         sodass jeder überprüfen kann ob er diese IP rechtmäßig benutzt
  3. Was ist wen der GATE ausfällt, wer verteilt dhcp?
  4. Wie kann man DNS realisieren? wer betreibt den Master? sind alle nodes slaves?
  5. Sichere Kommunikation

Immer bedenken sollte man denke ich: Freie/Offene WLANs wie es Freifunk Prinzipbedingt ja nunmal ist, erreichen nie eine "ausreichende" Sicherheit - erfordern also IMMER eine end-to-end verschlüsselung ausgehend vom User (Auch wenn das DAUs nicht verstehen/das problem nicht sehen)

(Oder?)
-ja

:-))hihi


Gedanken von anderen Freifunkern ber dieses Thema:

 - http://kbu.freifunk.net/index.php?title=Anforderungen
 - http://kbu.freifunk.net/index.php/Netzwerk-Konfiguration
 - http://kbu.freifunk.net/index.php?title=Server:Felix ( Vergleichbar mit unserem aktuellen Gate1 )
 - http://www.google.de/url?sa=t&rct=j&q=ipsec%20mesh%20network&source=web&cd=2&ved=0CDsQFjAB&url=http%3A%2F%2Fvpmn.googlecode.com%2Ffiles%2Fscg08_vpmn_r1.pdf&ei=Gc7IUKD2Mo_UsgaC0YHgCA&usg=AFQjCNGg_Sei4Zalm-ik-gen-eQFlyWGIQ&bvm=bv.1354675689,bs.1,d.Yms 

Lösungen / Ideen:
  1.Nodes haben aktuell "AP Isolation" aktiviert, genauer Test steht noch aus, auf den ersten blick versteckt dies aber schon sehr viel (Vom Traffic) von den End-Clients
      Interessanter Link hierzu mit einigen Denkansätzen: http://kbu.freifunk.net/index.php/Netzwerk-Konfiguration
      
  2. Es muss eine Unabhängige Instanz sicherstellen dass die gerade verwendete IP von der dazugehörigen physischen Maschine benutzt wird, bzw. diese Instanz muss anzeigen ob die IP gerade der "rechtmäßigen" maschine gehört oder nicht
  - Mir aktuell bekannt ist zB IPSec - dort werden aber von den Teilnehmern die Schlüssel vorab ausgetauscht, sobald jemand einen Node ins Netz bringen will kriegt er also unweigerlich auch diese Schlüssel mit, damit macht es also wieder keinen sinn :-)
  - http://de.wikipedia.org/wiki/Message_Authentication_Code
  - sehr primitive idee: Unabhängige Instanz sendet an die Server/zu (natürlich verschlüsselt ;-))schützenden IPs eine geheime Frage und nur wenn die geheime Antwort richtig ist wird er als vertrauenswürdig eingestuft - Unabhängige Instanz teilt Blacklist/Whitelist der Welt mit
  
  3. Zuerst hatten wir den DHCP auf den nodes um genau dem entgegen zu wirken, wenn tinc down ist kriegt ein client keine adresse, ist aber dann doch scheiße administrierbar - eine primary/Secondary DHCP lösung wär da von vorteil!
  
  3. Wenn jeder sein Subnetz hat vergibt jeder node für sein netz eine IP / Client-Traffic muss geNATed werden oder man überlegt das MESH-Netz auf BGP o.ä. umzubauen
  
 3. Vermutlich schwer organisierbar, also von der verwaltungsmäßigen Seite, aber ein guter ansatz - außerdem: Subnetze sind nur begrenzt verfügbar)
 
  4. Um Namenspaces im Internen Netz zu realisieren braucht es einen DNS im internen Netz (der kann natürlich wieder angegriffen/ausgelesen/etc werden) - das sicherste wäre denke ich allen Clients+Nodes einen externen (z.B. CCC) DNS zu pushen, der wird genutzt und nichts kann im Netz gespeichert/geloggt werden ... evtl. Primary:CCC Secondary:Intern (Der nur lokale namensauflösungen für Interne Dienste übernimmt und nicht cached)
  
  4. Es gibt doch sicher dezentrale DNS lösungen? Solange man eine signierte "namens tabelle" hat ist doch alles in orgnung? jeder node kann einen dns slave haben und das ist es egal ob da einer angegriffen wir oder nicht ? Es gibt ein DNS system auf bitcoin basis ! http://en.wikipedia.org/wiki/Namecoin, http://distributeddns.sourceforge.net/, http://www.google.de/url?sa=t&rct=j&q=ipsec%20mesh%20network&source=web&cd=2&ved=0CDsQFjAB&url=http%3A%2F%2Fvpmn.googlecode.com%2Ffiles%2Fscg08_vpmn_r1.pdf&ei=Gc7IUKD2Mo_UsgaC0YHgCA&usg=AFQjCNGg_Sei4Zalm-ik-gen-eQFlyWGIQ&bvm=bv.1354675689,bs.1,d.Yms 
  Sicher eine möglichkeit, ist aber viel komplexer, denke mal damit dass Flashen/Konfigurieren etc so einfach und ohne statische einrichtungen wie möglich vonstatten gehen sollte, aber guter ansatz! mit Primary Extern + Secondary Intern spart man sich eben nur die Arbeit (die vielleicht nicht zu unterschätzen ist, weiß nicht genau)

  5. Ich finde wir sollten uns auch um Kommunikationsplattfomem kümmern: toll ist z.B. http://bitmessage.org/ ;)


Link to the Pad