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
Docker ist und war nie eine Blackbox. Dockerfiles sind Nachvollziehbar. Zumindest bis zu einem Gewissen grad. Wichtig ist, damit man eben eine IDENTISCHE Buildumgebung schafft. Denn was bringen einem Images, die man auf verschiedenen Maschienen mit unterschiedlichen gcc versionen baut? Nichts, denn ggf. wird dort im Detail etwas anders optimiert und schon kannst du nichts mehr vergleichen. Docker ist hier der einfachste Weg konsistent eine Entwicklungsumgebung für alle bereit zu stellen, ohne jemanden einzuschränken.
Du kannst natürlich auch alles in Vargrant packen und hoffen, aber das hilft dir halt auch nur bedingt.
Tipp: Bevor du dich über Docker in Rage schreibst, bedenke, dass der Fehler nicht in Docker, sondern primär in dessen Benutzungsweise liegt. Hier stellt es übrigens keinen großen Unterschied mehr zu den sonstigen Repos da. Denn auch hier müsste man ja die Sourcen lesen um die Anwendung zu verstehen, was ähnlich wenige tun 
Wie auch immer… Wir wollen ja nicht vom Thema abschweifen Aber wenn du eine Dockerdebatte führen willst, steht dir meine Inbox offen
ein feiner unterschied liegt darin, das code, den ich mir erst holen muss, auch von anderen benutzt wird und insofern auch von anderen mit gemaintaint wird - und da schaut dann letztendlich irgendwann eher jemand drauf. Einfach weil der potentiell in vielen Projekten steckt, da kann ich auch extern nicht so einfach Dinge hinzufügen oder tun.
In einem vorbereitetem Docker File ist das schlicht nicht der Fall - und wenn man hier unter dem Thema „Code Review auf Sicherheit“ schreibt ist Docker zwar Nachvollziehbar - aber absolut kein Gewinn.
Wo liegt das Problem? Das ist doch sehr einfach möglich. In dem dockerimage wird das git repository zum bauen geclont. Das sorgt natürlich dafür, dass alle commits NACHVOLLZIEHBAR vorliegen. Mit einem git status kann ich nun schauen ob Dateien manipuliert wurden und ob die Commit-ID stimmt. ist das der Fall… Juhu alles super. Wenn nicht, mhm dann sollte da nochmal wer dran. Den Code selbst kann ich dann eben über GitHub, GitLab, eine Repository verwaltung meiner Wahl machen, bzw. einfach klassisch über die Git-CLI und vi oder emacs.
Docker bildet hier nur die Möglichkeit auch die fertigen Builds gegeneinander vergleichbar zu halten.
Edit: Ich kann beim commit sogar noch weiter gehen… Ich kann sogar schauen die Signatur noch hinhaut, wenn der commit denn signiert ist.