Code Review auf Sicherheit

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 :slight_smile: *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.

2 „Gefällt mir“

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

  • codereview bei gluon (Openwrt, module, packages)
  • best practises für den sicheren Firmwarebau in Communities (buildserver, signing process)

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

  • 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). :wink: