Der Freifunknode gehört in ein eigenes VLAN und darf nur ins Internet kommunizieren.
Wenn bei Privatpersonen nur ein Netz vorhanden ist gibt es viel lohnendere Ziele. PC/Laptop, Smartphone, SmartTV, Spielekonsolen und die neu rauskommenden SmartHome Geräte.
Nintendo empfiehlt z. B. bei der Wii U alle Ports in der Firewall für eingehende Verbindungen zu öffnen und per Portweiterleitung zur Verfügung zu stellen um mit der Konsole online spielen zu können.
Also von einem eigenen VLAN ist in vielen Beschreibungen keine Rede und ich glaube auch nicht das wir eine kritische Masse bekommen wenn wir nur Personen gewinnen wollen die das Wort VLAN aussprechen können.
Und ob das private Netz ein lohnendes Ziel darstellt oder nicht interessiert den Menschen nicht den wir als Freifunker gewinnen wollen. Wenn er sich nicht sicher fühlt dann macht er nicht mit.
Das halte ich im Heimnetz für vollkommen überflüssig. Die iptables / ebtables die von gluon verwendet werden bieten hinreichende Sicherheit, die Firmware erhält regelmäßig Updates.
Ich habe deutlich mehr vertrauen in meine Freifunk Knoten als meine Fritzbox.
Vielleicht können ja @anon75826926 oder @tcatm was dazu sagen so im Code die ebtables Regeln stecken.
Gluon verwendet primär verschiedene Routingtabellen um die Netze voneinander zu trennen. Es ist angedacht diese durch getrennte Netzwerksnamensräume zu ersetzen. Die Firewall greift hier noch garnicht, da Pakete aufgrund der Routingtabellen nicht ins LAN gelangen können.
Explizit dokumentiert ist dies jedoch nirgends.
Naja, hier sollte man vielleicht anmerken, dass der Begriff Firewall von Windows Usern als Schutz verstanden wird. Bei Windows ist es häufig notwendig unsichere Dienste die erreichbar wären mittels einer Firewall wieder zu sperren.
Bei Linux wird dafür gesorgt dass Dienste gar nicht erst erreichbar sind, es ist also nicht notwendig eine Firewall zu betreiben.
Ähnlich verhält es sich mit Freifunk Firmware Gluon. Es wird aus dem Freifunk Netz schlicht nicht in das Private Netz geroutet. Somit ist keine Verbindung vom Freifunk in das Private Netz möglich, daher ist es schlicht nicht notwendig eine wie auch immer geartete Firewall zu zu betreiben.
Da man selber vollen Zugriff auf seien Knoten hat kann man relevante Informationen von den Knoten beziehen:
Am Beispiel der Aachener Firmware:
Routing Tabellen:
IPv4
default via 192.168.178.1 dev br-wan
10.5.0.0/16 dev br-client
192.168.178.0/24 dev br-wan src 192.168.178.42
IPv6
unreachable default dev lo metric 65535 error -128
unreachable default dev lo metric -1 error -128
default from :: via fe80::dcae:2ff:fe02:4e9c dev br-client metric 1024
default from 2a03:2260:114:2::/64 via fe80::dcae:2ff:fe02:4e9c dev br-client metric 1024
default from fdac::/64 via fe80::dcae:2ff:fe02:4e9c dev br-client metric 1024
2a03:2260:114:2::/64 dev br-client metric 256
unreachable fd9f:4d1b:ba7b::/48 dev lo metric 2147483647 error -128
fdac::ac dev local-node metric 256
fdac::/64 dev br-client metric 256
fdac::/64 dev br-client metric 1024
fe80::/64 dev br-wan metric 256
fe80::/64 dev client0 metric 256
fe80::/64 dev br-client metric 256
fe80::/64 dev local-node metric 256
fe80::/64 dev mesh-vpn metric 256
fe80::/64 dev bat0 metric 256
unreachable default dev lo metric -1 error -128
ff00::/8 dev br-wan metric 256
ff00::/8 dev local-node metric 256
ff00::/8 dev client0 metric 256
ff00::/8 dev br-client metric 256
ff00::/8 dev mesh-vpn metric 256
ff00::/8 dev bat0 metric 256
unreachable default dev lo metric -1 error -128
Die iptables
# Generated by iptables-save v1.4.21 on Wed Jan 20 11:06:32 2016
*nat
:PREROUTING ACCEPT [395:80792]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [1225:62306]
:POSTROUTING ACCEPT [1191:59738]
:delegate_postrouting - [0:0]
:delegate_prerouting - [0:0]
:postrouting_client_rule - [0:0]
:postrouting_lan_rule - [0:0]
:postrouting_local_node_rule - [0:0]
:postrouting_rule - [0:0]
:postrouting_wan_rule - [0:0]
:prerouting_client_rule - [0:0]
:prerouting_lan_rule - [0:0]
:prerouting_local_node_rule - [0:0]
:prerouting_rule - [0:0]
:prerouting_wan_rule - [0:0]
:zone_client_postrouting - [0:0]
:zone_client_prerouting - [0:0]
:zone_lan_postrouting - [0:0]
:zone_lan_prerouting - [0:0]
:zone_local_node_postrouting - [0:0]
:zone_local_node_prerouting - [0:0]
:zone_wan_postrouting - [0:0]
:zone_wan_prerouting - [0:0]
-A PREROUTING -j delegate_prerouting
-A OUTPUT -d 127.0.0.1/32 -o lo -p udp -m owner --gid-owner 800 -m udp --dport 53 -j DNAT --to-destination :54
-A POSTROUTING -j delegate_postrouting
-A delegate_postrouting -m comment --comment "user chain for postrouting" -j postrouting_rule
-A delegate_postrouting -o br-wan -j zone_wan_postrouting
-A delegate_postrouting -o br-client -j zone_client_postrouting
-A delegate_postrouting -o local-node -j zone_local_node_postrouting
-A delegate_prerouting -m comment --comment "user chain for prerouting" -j prerouting_rule
-A delegate_prerouting -i br-wan -j zone_wan_prerouting
-A delegate_prerouting -i br-client -j zone_client_prerouting
-A delegate_prerouting -i local-node -j zone_local_node_prerouting
-A zone_client_postrouting -m comment --comment "user chain for postrouting" -j postrouting_client_rule
-A zone_client_prerouting -m comment --comment "user chain for prerouting" -j prerouting_client_rule
-A zone_lan_postrouting -m comment --comment "user chain for postrouting" -j postrouting_lan_rule
-A zone_lan_prerouting -m comment --comment "user chain for prerouting" -j prerouting_lan_rule
-A zone_local_node_postrouting -m comment --comment "user chain for postrouting" -j postrouting_local_node_rule
-A zone_local_node_prerouting -m comment --comment "user chain for prerouting" -j prerouting_local_node_rule
-A zone_wan_postrouting -m comment --comment "user chain for postrouting" -j postrouting_wan_rule
-A zone_wan_postrouting -j MASQUERADE
-A zone_wan_prerouting -m comment --comment "user chain for prerouting" -j prerouting_wan_rule
COMMIT
# Completed on Wed Jan 20 11:06:32 2016
# Generated by iptables-save v1.4.21 on Wed Jan 20 11:06:32 2016
*raw
:PREROUTING ACCEPT [33398:8234026]
:OUTPUT ACCEPT [36514:7891306]
:delegate_notrack - [0:0]
:zone_client_notrack - [0:0]
:zone_local_node_notrack - [0:0]
-A PREROUTING -j delegate_notrack
-A delegate_notrack -i br-client -j zone_client_notrack
-A delegate_notrack -i local-node -j zone_local_node_notrack
-A zone_client_notrack -j CT --notrack
-A zone_local_node_notrack -j CT --notrack
COMMIT
# Completed on Wed Jan 20 11:06:32 2016
# Generated by iptables-save v1.4.21 on Wed Jan 20 11:06:32 2016
*mangle
:PREROUTING ACCEPT [33398:8234026]
:INPUT ACCEPT [33043:8158206]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [36514:7891306]
:POSTROUTING ACCEPT [36514:7891306]
:fwmark - [0:0]
:mssfix - [0:0]
-A PREROUTING -j fwmark
-A FORWARD -j mssfix
-A mssfix -o br-wan -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "wan (mtu_fix)" -j TCPMSS --clamp-mss-to-pmtu
COMMIT
# Completed on Wed Jan 20 11:06:32 2016
# Generated by iptables-save v1.4.21 on Wed Jan 20 11:06:32 2016
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:delegate_forward - [0:0]
:delegate_input - [0:0]
:delegate_output - [0:0]
:forwarding_client_rule - [0:0]
:forwarding_lan_rule - [0:0]
:forwarding_local_node_rule - [0:0]
:forwarding_rule - [0:0]
:forwarding_wan_rule - [0:0]
:input_client_rule - [0:0]
:input_lan_rule - [0:0]
:input_local_node_rule - [0:0]
:input_rule - [0:0]
:input_wan_rule - [0:0]
:output_client_rule - [0:0]
:output_lan_rule - [0:0]
:output_local_node_rule - [0:0]
:output_rule - [0:0]
:output_wan_rule - [0:0]
:reject - [0:0]
:syn_flood - [0:0]
:zone_client_dest_ACCEPT - [0:0]
:zone_client_dest_REJECT - [0:0]
:zone_client_forward - [0:0]
:zone_client_input - [0:0]
:zone_client_output - [0:0]
:zone_client_src_ACCEPT - [0:0]
:zone_lan_dest_ACCEPT - [0:0]
:zone_lan_forward - [0:0]
:zone_lan_input - [0:0]
:zone_lan_output - [0:0]
:zone_lan_src_ACCEPT - [0:0]
:zone_local_node_dest_ACCEPT - [0:0]
:zone_local_node_dest_REJECT - [0:0]
:zone_local_node_forward - [0:0]
:zone_local_node_input - [0:0]
:zone_local_node_output - [0:0]
:zone_local_node_src_ACCEPT - [0:0]
:zone_wan_dest_ACCEPT - [0:0]
:zone_wan_dest_REJECT - [0:0]
:zone_wan_forward - [0:0]
:zone_wan_input - [0:0]
:zone_wan_output - [0:0]
:zone_wan_src_REJECT - [0:0]
-A INPUT -j delegate_input
-A FORWARD -j delegate_forward
-A OUTPUT -j delegate_output
-A delegate_forward -m comment --comment "user chain for forwarding" -j forwarding_rule
-A delegate_forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A delegate_forward -i br-wan -j zone_wan_forward
-A delegate_forward -i br-client -j zone_client_forward
-A delegate_forward -i local-node -j zone_local_node_forward
-A delegate_forward -j reject
-A delegate_input -i lo -j ACCEPT
-A delegate_input -m comment --comment "user chain for input" -j input_rule
-A delegate_input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A delegate_input -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j syn_flood
-A delegate_input -i br-wan -j zone_wan_input
-A delegate_input -i br-client -j zone_client_input
-A delegate_input -i local-node -j zone_local_node_input
-A delegate_output -o lo -j ACCEPT
-A delegate_output -m comment --comment "user chain for output" -j output_rule
-A delegate_output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A delegate_output -o br-wan -j zone_wan_output
-A delegate_output -o br-client -j zone_client_output
-A delegate_output -o local-node -j zone_local_node_output
-A reject -p tcp -j REJECT --reject-with tcp-reset
-A reject -j REJECT --reject-with icmp-port-unreachable
-A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 25/sec --limit-burst 50 -j RETURN
-A syn_flood -j DROP
-A zone_client_dest_ACCEPT -o br-client -j ACCEPT
-A zone_client_dest_REJECT -o br-client -j reject
-A zone_client_forward -m comment --comment "user chain for forwarding" -j forwarding_client_rule
-A zone_client_forward -m conntrack --ctstate DNAT -m comment --comment "Accept port forwards" -j ACCEPT
-A zone_client_forward -j zone_client_dest_REJECT
-A zone_client_input -m comment --comment "user chain for input" -j input_client_rule
-A zone_client_input -p tcp -m tcp --dport 53 -m comment --comment client_dns -j reject
-A zone_client_input -p udp -m udp --dport 53 -m comment --comment client_dns -j reject
-A zone_client_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT
-A zone_client_input -j zone_client_src_ACCEPT
-A zone_client_output -m comment --comment "user chain for output" -j output_client_rule
-A zone_client_output -j zone_client_dest_ACCEPT
-A zone_client_src_ACCEPT -i br-client -j ACCEPT
-A zone_lan_forward -m comment --comment "user chain for forwarding" -j forwarding_lan_rule
-A zone_lan_forward -m comment --comment "forwarding lan -> wan" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -m conntrack --ctstate DNAT -m comment --comment "Accept port forwards" -j ACCEPT
-A zone_lan_forward -j zone_lan_dest_ACCEPT
-A zone_lan_input -m comment --comment "user chain for input" -j input_lan_rule
-A zone_lan_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT
-A zone_lan_input -j zone_lan_src_ACCEPT
-A zone_lan_output -m comment --comment "user chain for output" -j output_lan_rule
-A zone_lan_output -j zone_lan_dest_ACCEPT
-A zone_local_node_dest_ACCEPT -o local-node -j ACCEPT
-A zone_local_node_dest_REJECT -o local-node -j reject
-A zone_local_node_forward -m comment --comment "user chain for forwarding" -j forwarding_local_node_rule
-A zone_local_node_forward -m conntrack --ctstate DNAT -m comment --comment "Accept port forwards" -j ACCEPT
-A zone_local_node_forward -j zone_local_node_dest_REJECT
-A zone_local_node_input -m comment --comment "user chain for input" -j input_local_node_rule
-A zone_local_node_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT
-A zone_local_node_input -j zone_local_node_src_ACCEPT
-A zone_local_node_output -m comment --comment "user chain for output" -j output_local_node_rule
-A zone_local_node_output -j zone_local_node_dest_ACCEPT
-A zone_local_node_src_ACCEPT -i local-node -j ACCEPT
-A zone_wan_dest_ACCEPT -o br-wan -j ACCEPT
-A zone_wan_dest_REJECT -o br-wan -j reject
-A zone_wan_forward -m comment --comment "user chain for forwarding" -j forwarding_wan_rule
-A zone_wan_forward -m conntrack --ctstate DNAT -m comment --comment "Accept port forwards" -j ACCEPT
-A zone_wan_forward -j zone_wan_dest_REJECT
-A zone_wan_input -m comment --comment "user chain for input" -j input_wan_rule
-A zone_wan_input -p udp -m udp --dport 68 -m comment --comment Allow-DHCP-Renew -j ACCEPT
-A zone_wan_input -p icmp -m icmp --icmp-type 8 -m comment --comment Allow-Ping -j ACCEPT
-A zone_wan_input -p tcp -m tcp --dport 22 -m comment --comment wan_ssh -j ACCEPT
-A zone_wan_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT
-A zone_wan_input -j zone_wan_src_REJECT
-A zone_wan_output -m comment --comment "user chain for output" -j output_wan_rule
-A zone_wan_output -j zone_wan_dest_ACCEPT
-A zone_wan_src_REJECT -i br-wan -j reject
COMMIT
# Completed on Wed Jan 20 11:06:32 2016das klingt erstmal so als ob da ein missverständnis vorliegt - wir erkläre den Leuten das der Traffic er WifiNutzer_Freifunk das eine Netz sind und das der Upling in einem eigenen If hängt was direkt über einen Tunnel an einen Supernode geroutet wird.
der Begriff „Firewall“ is da eher ungünstig gewählt.
wie man prüft ob eine lokale FW auf dem Knoten sauber ist? Ad-hoc - garnicht , mit root auf der Kiste vielleicht ein bisschen weil man kucken kann welcher IF was wohin routet.
Ein oft gemachter „Fehler“ - man stöpselt einen der 4 gelben Ports an den DSL Router … damit hat man sein internes Netz dann in den Freifunk gebracht (so wie einige Comunitys das betreiben)
Ich habe den Begriff gewählt weil er in vielen Architekturfolien auftaucht. Ich denke das ist für die meisten Normalos auch der Begriff den sie am ehesten verstehen wenn er vielleicht auch der technisch falsche ist. Aber ich glaube es ist wichtig das wir dieses Thema besser dokumentieren damit auch „Halbleien“ (wie ich) genug Informationen haben um sich etwas einzuarbeiten.
Alleine diese Aussage „ein FF Router muss in ein VLAN“ ist schon gut geeignet viele Nutzer abzuschrecken die dann sagen. Das ist mir zu kompliiziert um das sicher zu betreiben.
Any other hints?
deswegen wird Freifunk von vielen Comunitys so gebaut wie es gebaut wird,
man macht ein offenes Netz auf, auf einem anderen Interface dann den Uplink - durch den uplink geht ein Tunnel ausschliesslich zu einer Supernode/Gateway. Damit sind Betreiber von Uplinks(also DSL Anschlüssen oder ähnliches) rechtlich wie technisch im Hintergrund der ganzen Freifunk Geschichte. Genau deswegen macht man das … um dann noch die Supernode Betreiber aus dem „schussfeld“ zu bekommen baut man von dort ausgehend nochmal VPN ins Ausland, oder zu befreundeten InternetServiceProvidern (ISP) auf.
Die verwendeten Tools sind im einzelnen gut Dokumentiert (wenn auch die Kombinationen in dem lokalen Freifunk und deren Zusammenspiel selber nicht immer gut dokumentiert sind)
Ein Review setzt dann entweder bei einem Check der Config und Kombi an … da will man dann freifunk-gluon in die mangel nehmen, oder bei gängigen linuxtools , iw bridgetools fastd alfred batman 80211s
In @rubo77 Flyer ist alles einsteigerfreundlich beschrieben.
In den Branches gibt es schon verschiedene, an die Communitys angepasste Versionen.
Einsteigerfreundlich ja, aber ich bin schon auf der Suche nach etwas mehr Tiefe. Ich habe aber erstmal genug Hinweise bekommen das ich mich mal Einarbeiten werde
Das ist so und hat mit der Firewall nur am Rande zu tun. Du stellst Dir da einen Rechner (Router) in Dein Lan und lässt ein Programm (Firmware) drauf laufen das von einem Nerd kommt.
Wenn man dort nicht vertraut muss man sein Netz mit einer eigenen Firewall schützen.
Dass man vertraut ist aber eigentlich normal. Sowohl die Firewall in Windows als auch die meiste Software kommt von Nerds - denen vertraut man auch. Wieso nicht denen die die Firmware zusammen bauen?
Weiterer Aspekt: Die Firmware ist offen. Vertrauen ist nicht nötig. Man kann jederzeit einen Fachmann seines Vertrauens bitten sich das anzuschauen.
Die ganze Diskussion um die gefühlten Sicherheitsprobleme von Freifunk-Routern ist eine Chimäre.
Solange anderswo solche Dinge seitens Firmen mit Millionen Kunden passieren.
Natürlich sind Audits nicht falsch, wenn sich dafür jemand berufen fühlt. Aber hier mehr als ein Aluhut-Sicherheitsproblem herbeireden zu wollen grenzt für mich an Trolling.
naja, fair bleiben … es ging im Ursprung (mal den 1. Post lesen) um Argumentationsstrukturen und den sich aus dem halbwissen resultierenden Fragen nach wer prüft das eigtl. - genau das haben wir hier glaube ich ganz gut beantwortet.
Menschen muss man dort abholen wo sie sind, und von dort gehts weiter - sollen wir dich und deinen fast-troll-plüschtier auch abholen 
*ironietag
Genau: Und mein Ziel wäre es eine Beschreibung zu bauen die es einem IT nahen Menschen (der kein Freifunk Experte ist) erlaubt zu verstehen was wie gemacht wurde.
na jetzt mal easy. Ich habe gar nicht von Sicherheitsprobleme gesprochen. Da hat wohl der Pawlosche Hund gesabbert weil irgendwo eine Klingel geläutet hat.
Ich wollte nur wissen ob es schon mal so etwas gab und danach Dokumentation finden.
Für beides ist die Antwort Nein und es wurde mir Quellen genannt wo ich starten könnte. Alles gut.
Um es konstruktiv zu formulieren:
a) Ich fände es wirklich super, wenn sich ein Team explizit kümmern würde um
b) in als hinreichend kritisch einzustufenden Infrastrukturen würde ich einen Freifunkrouter „mit VPN-Uplink“ in eine Routerkaskade einsperren. Also entweder ein abgehangenes OpenWRT-Release, einen ehemaligen Bundelrouter, dem man vertraut (wo gibt’s die?) oder schlicht eine $$$-Firewall-Appliance.
c) mangels realer (bekannter) Misbrauchsfälle sind die Überlegungen spekulativer Natur. Unterschiedliche Strategien der TerroristInnenbekämpfung in Hessen sind schlicht nicht so einfach zu benchmarken wie in Tel Aviv.
Ich habe das mal hier zusamengefasst:
https://wiki.freifunk.net/Sicherheit#Häufige_Frage_zur_Sicherheit_der_Firmware
Vielleicht könnt ihr dort ja noch einige Formulierungen ergänzen, z.B. mit welchen Befehlen man die routingtabellen einsehen kann
Ich fände einen Hinweis nicht schlecht, dass Freifunkende darauf bestehen sollten, dass es „von der Download-Webseite“ einen einfachen (auffindbaren, nachvollziehbaren) Weg gibt, um den Software-Build nachzuvollziehen zu können.
Also mindestens
(Dass das auch lizenrechtlich durch die GNU-GPL geboten ist unterstreicht das noch. Aus der könnte man sogar ableiten, dass es ein Archiv mit dem exakten Tarball „für diesen Build“ geben müsste. Was ich aber für ggf. overdone halte.)
Vorsicht:
Wenn man selber vollen Zugriff auf den Knoten hat, weil man entweder ein Root-Paßwort gesetzt hat oder seinen Public-Key auf den Router kopiert hat, heißt das, daß man über diesen Weg auch vollen Zugriff auf das Gastnetz hat, wie man anhand Deiner Routing-Tabellen ja auch sehr schön sehen kann. Da nützt auch keine „Firewall“, das sollte man immer bedenken.