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
- angabe der Gluon-Checkout-ID
- stable link auf
- site.conf
- site.mk
- modules
(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.
Ich verstehe nicht, was Du an der Aussagen von @MrMM auszusetzen hast.
Oder warum warnst Du ihn?
1 „Gefällt mir“
An seinen Aussagen habe ich nichts auszusetzen – soll ich das Vorsicht löschen? Ich wollte nur zu Bedenken geben, daß über SSH sehr wohl ein Weg in das interne Netz besteht.
Aber genau das schrieb MrMM doch!
Dass das auch alles mit einschliesst was der Knoten erreichen kann, das sollte doch wohl klar sein.
Was mir an der Diskussion fehlt ist der Bezug auf das Code-Review.
Die Tatsache, dass es viele Communities den Nutzenden schwer bis fast unmöglich machen, den aktuell genutzten Codestand und Config-Dateien einzusehen (zu laden) spricht meiner Meinung nach Bände.
Und das obwohl das nicht so schwer wäre.
1 „Gefällt mir“
Ich finde es wichtig, jedem die Möglichkeit zu geben, sich den Code selber anzugucken. Und zwar genau den Code, der auf seinem Router läuft. Und das stellt sich oft als nicht so leicht heraus… In der FW sollten irgendwo Links zu allen Modules und zum Gluon Repo in der Revision zu finden sein.
Hallo Rubo
sind die „richtigen“ Routingtabellen irgendwo beschrieben oder dokumentiert?
Gruß
Hagen
wie bereits erwähnt, wer Zugang zu dem Router hat, z.b. via Passwort, sshkey kann alles tun, auch und insbesondere ins lokale „Spender“ Netz gelangen.
Zugang kann hier auch physischer Zugang sein - da der Configmode in der Regel ungesichert ist. Dort kann man Verkehr umleiten, mitschneiden und manipulieren.
Physischer Zugang in Kneipen in der Sitzecke, oder außen unterm Dach an der Regenrinne … alles so gesehen. Da hilft so ein FritzBox Gastnetz schonmal ein kleines (!) bisschen.
Ich würde hier statt einer Aufzählung eher einen kurztext zu vertrauen schreiben. und das Sicherheit letztendlich am ehesten mit selbst gebauter Firmware kommt.
man könnte sich mit den vorgelegten site.mk site.conf und modules zur Kontrolle begnügen - wobei man schon nicht sicher sein kann , das dies die zur Firmware gehörigen Pakete sind. Unter anderem kann man im update Prozess, mit heimlichen Zwischenupdate „ungewollte features“ einbauen, die nirgendwo dokumentiert auftauchen.
Wenn man aber eine kurze Aufzählung nimmt, würde ich die offensichtlichsten Sachen machen : Rootpassword, FastD keys/server und mtu abgleichen, ssh-keys anzeigen, autoupdater (ja, an oder aus? wenn aus fehlen sec. updates, wenn an sind nachträgliche sshkeys trivial, wohin zeigt der … wieviele Leute müssen den sign’en, was sind das für Leute.) und ein blick in die Prozesslist UND cronjobs auf verdächtige programme / einstellungen, ein Blick in Liste der installierten Pakete.
… wie du siehst, das eskaliert so schnell das selber bauen einfacher ist - unter der Vorraussetzung das man den genutzten Programmen a sich vertraut (gluon Zeug, Batman, Alfred, batctl, fastd, openwrt, busybox …linuxkernel, libc)
… oder, statt den Aluhut zu weit ins Geischt zu ziehen - man schreibt über vertrauen und glaubt das die site.mk , site.conf und modules den gebauten FW entsprechen. (daher ein unbdingtes minimal must have !)
anderer Punkt zur „sicherheit“ im Layer 2 Netz und Metadaten : meine Lieblingskritik : Rein aus Proof-of-concept hab ich mal ein Skript geschrieben was die layer2 Struktur Ausnutzt und einzelne MAC im ganzen batman netz tracken kann. → https://cccfr.de/git/viisauksena/toolbox/blob/master/tracker_poc.sh
da es jq nutzt kann das nicht auf knoten laufen, wenn man aber auf die Auflösung von Nodename, geo etc. verzichtet, oder das umbaut, kann man damit MAC bequem Tracken durch das Freifunk Netz - und endgeräte melden sich nur zu gerne überall an bekannten Netzen an.
Mea culpa – wenn Du meinst, daß das nicht zum Thema gehört.
Aber der netzweit erreichbare SSH-Zugang ist in meinen Augen die Sicherheitslücke Nummer eins, da braucht es dann auch kein Code-Audit mehr, ob es vielleicht möglich wäre, aus dem FASTD-Tunnel auszubrechen. Man muß schon sehr viel Vertrauen in seinen netten Freifunker vor Ort haben, sich so etwas in den Laden zu stellen. Den wenigsten Ladenbesitzern dürfte das aber überhaupt bewußt sein.
Dann mache dafür einen eigenen Thread auf.
Hier geht es um das Code-Review.
Ich tippe drauf, dass du verstanden hast es gäbe einen generellen ssh Zugang zu allen Knoten - das ist nicht der Fall. Andernfalls kann ich mir deine Aussagen nicht erklären.
ssh Zugang per key stellt keine Sicherheitslücke dar.
Zum Thema Nachvollziehbarkeit, wir dokumentieren unsere Firmwareversionen im Wiki und stellen dort die Links zu alles Release Tags zur Verfügung:
https://wiki.freifunk.net/Freifunk_Aachen/Firmware
Die Wiki Seite verlinken wir auch auf unsere Homepage damit sie leichter gefunden wird.
Zum Thema etwas per Autoupdate Unterschieben:
Unser stable Autoupdate verlangt 4 Signaturen (build Server + 3 Personen), das ist mehr als bei manch kommerziellem Produkten erforderlich ist um ein Update auf Geräte in Kundennetzen aufzuspielen.
2 „Gefällt mir“
Es gibt durchaus eine Diskussion um die vom Dropbear (Bestandteil des Standard-Openwrt) genutzten Crypto-Algorithmen.
Und auch bezüglich „SSH deaktiviert wenn kein Passwort gesetzt“ gab in einem der Gluon-Master 2015 mal (kurzzeitig) eine riesige Lücke. War nämlich schlicht nicht der Fall.
Von daher: Ja, es ist sinnvoll, über den Code zu schauen. Und -wie Du erläutert hast- zu erfahren, auf welcher Basis die eigene Community da gebaut hat.
6 Beiträge wurden in ein neues Thema verschoben: Gluon-Dokumentation finden
(Ich habe es ausgelagert, weil es der nächte Versuch war, vom Thema „Codereview“ abzulenken)
dort sieht man zwar was ihr vorgebt gemacht zu haben, aber in der Firmware findet sich ja kein Beweis, dass diese Firmware wirklich mit dem tag des Releases gebaut wurde oder?
Wenn man direkt einen Commit, der einen „annotated tag“ hat baut, dann ist das überhauptnicht mehr beweisbar. dann steht da z.b. nur „Firmware2016.1.5.1 / gluon-v2016.1.5“, ohne commit id und den tag v2016.1.5 könnte ja jeder in seinem privaten repo setzen wenn man nicht auf einem tag baut, dann sieht man wenigstens die kurz-commit-ID am Ende, z.b. v2016.2.1~exp1611111417 / gluon-v2016.2-28-g5ef3d88 ist der commit 5ef3d88
wobei v2016.2 der letzte annotated tag, der vor dem commit in dem repo existierte war.
Schön wäre, wenn in der firmware auf dem Router in einer config datei das benutzte repo und die benutzte commit-id verankert wird. ausserdem noch, welcher commit aus dem site-repo benutzt wurde um zu beuen, dann hätte man alles beisammen um nachzuvollziehen wie die Firmware gebaut wurde.
(Einen „absoluten Beweis“ kann man natürlich eh nie hinbekommen, aber man könnte es ja zumindest so transparent und Nachvollziebar wie möglich machen.)
Stimmen muss dann aber noch lange nicht (wenn man Manipulationen bei der Dokumentation unterstellt). 
Ich denke, wie sollten hier nur über Automatiken reden, die dann funktionieren. Last uns nicht über absichtliche Manipulation reden.
Am besten wäre, wenn automatisch erkennbar ist, wie gebaut wurde.
die idee dahinter ist doch das jemand der nach dem tag xy baut die gleiche FW rausbekommen sollte, das kann aus verschiedenen Gründen scheitern weil gluon/openwrt/linuxtools kaskade, oder allein schon weil man andere Pfade und Nutzer zum bauen benutzt. (die mit in der firmware auftauchen, siehe dmesg |head -n1 )
# sieht man Benutzer@hostname wo gebaut wurde, gcc und timestamp
[ 0.000000] Linux version 3.18.44 (fffr@v32412.1blu.de) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r49389) ) #11 Fri Nov 11 20:58:26 CET 2016
aber dein „ultimativer“ beweis wäre eben die prüfsumme der (nach)gebauten FW.
Der rest ist schall und rauch und nachstellbar/manipulierbar
es wäre schön reproduzierbar fw bauen zu können, allein wegen dieser 1. line - dürfte das in der Regel scheitern (gibt bestimmt noch mehr Gründe)
Nachvollziehbare Buildumgebungen sind schon lange dank Docker möglich. Hier würde man also erst ein Dockerimage mit den aktuellen Sourcen bauen, mit denen man dann wiederum die Source baut die das fertige Gluon ergeben. Funktioniert einwandfrei (lange man nicht irgendwo noch einen Timestamp einbackt?) und ist auch ideal um es jedem Zu erlauben den Buildprozess nachzuvollziehen.
@Sheogorath - der witz ist doch das man jemanden NICHT gesammelte source in die hände gibt sondern die liste wo und was und wie , und dann muss da dass gleiche rauskommen! … die Sicherheit mit Docker is fürn Arsch - bequem ist das sicher, aber das auch alles.
Worin liegt der Sinn, hier ist die Black box, drückste aufs VM knöpfchen - kommt Freifunk-FW raus , „genau wie bei mir“ … drückste aufs knöpfchen …
… bei docker könnt ich mich in rage schreiben …
der einzige kleine Vorteil wäre das ein bug/backdoor/unintended behaviour foo, dann in den ausgelieferten docker sources liegt, die aber NIEMAND ankuckt