Angriff auf unsere Infrastruktur

Am 3. Mai wurden Teile unserer Infrastruktur von Freifunk Stuttgart, die Dienste wie das Wiki, die Karte u.a. mehr anbieten, Opfer eines Hacker-Angriffes. Dieser Angriff kam, zum Glück für uns, bei der Umkonfiguration der Firewall durch den Angreifer zum stehen, da die Umkonfiguration fehl schlug und der Angreifer sich selbst aus dem System ausschloss.

Hier finden sich alle Infos zu dem Exploit, welcher auch in Version 1 bei uns genutzt wurde: Salt-Exploit.

Um dem Ideal der Transparenz zu entsprechen können wir aktuell folgende Infos geben. Weitere Updates dazu werden am Ende eingefügt:

Vorwort

Wir verwenden für Teile unserer Infrastruktur ‚salt‚ um eine einheitliche Konfiguration zu ermöglichen. Das ist auf recht niedrigem Niveau einheitlich, aber es sind mindestens alle User-Accounts überall eingerichtet und überall werden die Systemupdates regelmäßig automatisch eingespielt (unattended-upgrades), ausserdem gibt es ein paar Dienste die besser mit Salt integriert sind, z.B. der Reverse Proxy, der mit minimalem Aufwand eine neue Domain mit einer neuen Servicemaschine lernt oder unsere Proxmox-Server, die mit sehr wenig Konfiguration mal eben einen kompletten an unser Namensschema angepassten neuen Gastserver aufsetzen.

Was ist passiert?

Es gibt derzeit zwei Fehler im Salt:

  1. Authentifizierte User können auf Dinge zugreifen auf die sie eigentlich nicht zugreifen können sollten und haben deshalb root-Rechte auf dem salt-master
  2. Nicht authentifizierte User werden als authentifizierte User akzeptiert, das macht den 1. Fehler so gefährlich.

In der Folge kann ein Angreifer den salt-master und alle salt-minions steuern. In anderen Worten: die meisten unsere Dienste. Von dem Angriff gibt es mittlerweile mehrere Versionen, wir hatten Glück und wurden gleich von der ersten Version getroffen. Deren Code habe ich mittlerweile auch. Das Ziel war wohl einen Cryptominer laufen zu lassen mit maximal möglicher CPU-Leistung Cryptowährungen zu bekommen. In Version 1 des Angriffs war das alles noch nicht wirklich persistent, nur selinux und apparmor wurden deaktiviert, sowie der nmi-watchdog. Anschliessend wurden bestimmte Prozesse und Dockercontainer gestoppt, die auch CPU brauchen damit der Miner mehr CPU hat. Diese Prozesse liefen bei uns aber gar nicht. Ausserdem hat der Angreifer mittels ‚ufw‘ welche wir nicht verwenden, die Firewall deaktiviert und dann die verbleibenden Regeln mit iptables gelöscht. Unsere Maschinen verwenden Firewall-Code der eine Standardeinstellung von ‚DROP‘ hat, das sollte eigentlich Common Sense sein. Jedenfalls waren danach keine Verbindungen von oder zu den ffs-Hosts mehr erlaubt und so ging der Download des Schadcodes auch schief und der Angriff war zu Ende.

Was haben wir gemacht?

Nach einem längeren Telefonat zwischen zwei Admins von uns haben wir uns entschlossen Zweigleisig zu fahren. Einer bereitet uns einen neuen Salt-Master vor der nicht mehr anfällig ist. Ein anderer hat versucht herauszufinden was genau passiert ist, unter anderem durch den Vergleich der Backups vor und nach dem Angriff. Die Änderungen am System wurden rückgängig gemacht und die salt-minions überall gelöscht. Anschliessend wurden die Systeme wieder hoch gefahren. Salt bleibt noch ein paar Tage aus. Wenn mal ein Fehler in einer Software gefunden wurde ist es nicht so unüblich dass noch weitere hinterher kommen.

Hätten wir den Angriff verhindern können?

Leider nein, nicht mit der realen Installation die wir haben. Wir haben unattended-upgrade am Laufen, welches Systemupdates automatisch macht. Leider in der Konfiguration von uns nur die von Debian kommenden Sicherheitsupdates. Damit werden die von uns für salt verwendeten salt-Repositories nicht berücksichtigt, sondern nur die Debian-Repositories. Debian hat aber das Salt-Paket mit der Priorität ‚mittel‘ zum Zeitpunkt des Angriffs nur auf debian-unstable aktualisiert, wir verwenden debian-stable. Aber selbst wenn die Salt-Repositories von unattended-upgrades berücksichtigt worden wären, wäre das schief gegangen, weil die Repositories hart auf nicht aktualisierte Versionen gezeigt haben. Und da wo das nicht so war, war der Repository-Key ausgetauscht und deshalb kein Update möglich.

Sind Nutzerdaten betroffen?

Nach derzeitigem Stand: nein. Die größte Gefahr besteht für wiki-Zugangsdaten, das läuft aber auf einem LXC und es scheint als wären unsere LXCs vom Angriff übergangen worden. Dass kein lesender Zugriff auf die Nutzerdatenbank satt gefunden hat kann aber nicht vollständig garantiert werden.

Flash in den Mai 2020

In den letzten Jahren wurde in der Stuttgarter Freifunk-Community der „Flash in den Mai (FidM)“ etabliert. Mal kleiner mit Knoten flashen, grillen und dem geselligem Austausch. Oder auch mal größer mit Mitgliederversammlung des e.V. und anschließendem Workshop-/Vortragsprogramm teils mit bis zu drei parallelen Slots.

Dieses Jahr wollen wir den FidM nicht ausfallen lassen, sondern dezentral und virtuell doch gemeinsam durchführen. Vorbereitend und nebenher kann man die Zeit nutzen und eventuelle Schrankware entstauben und mit aktueller Firmware bespielen. Dies bitte am 30.04.2020 machen, so dass auf der Karte ein sichtbarer Anstieg der Freifunk-Knoten in der Region Stuttgart erkennbar wird.
Abends kann man sich ab 20 Uhr zum gemeinsamen Mate trinken virtuell via Jitsi Meet unter https://meet.lihas.de/ffs treffen.

Wem das zu wenig ist und gegebenenfalls auch eine Session anbieten möchte, kann das gerne via Mailingliste ankündigen. Wir würden Thema und Uhrzeit hier dann ergänzen und veröffentlichen.

Noch ein Punkt zur aktualisierter Schrankware. Vielleicht findet ihr ja einen Standort zu Hause oder könnt Knoten in der Nachbarschaft verteilen. Auf diese Weise könnte für Menschen mit keiner oder schlechter Internetanbindung das Homeschooling bzw. das Homeoffice erleichtert werden.

Bis dahin bleibt gesund, bleibt zu Hause und macht das Beste aus dieser außergewöhnlichen Zeit. Vor allem aber lasst euch nicht die Freude nehmen und funkt weiterhin frei.

PS Die diesjährige Mitgliederversammlung ist bis auf weiteres Verschoben. Je nach weiterer Entwicklung, gibt es mit etwas Glück das erste mal ein „Ernte-Flash-Fest“ 😉

Freifunk-Treffen am 13. April 2020 – virtuell

Heute Montag , den 11. Mai 2020, findet um 19 Uhr unser monatliches Freifunktreffen statt. Diesmal wieder virtuell unter folgender Adresse: https://meet.lihas.de/ffs

Diesmal aber virtuell. Wir können einen Jitsi-Server eines Freifunkers aus Stuttgart nutzen. Hier dazu die Adresse: https://meet.lihas.de/ und der Konferenzname: ffs-april2020

Bitte sorgt für guten Sound mit Headsets. Benutzt keine Laptop-Mikrophone. Diese sorgen nur für Störungen, die alle anderen Teilnehmer nerven. Hier dazu ein Leitfaden. Natürlich ist Video keine Pflicht, Audio in einem virtuellen Treffen kann völlig ausreichend sein.

TOPs können diesmal direkt ins Etherpad eingetragen werden.

Freifunk-Treffen am 9. März 2020

Heute Montag , den 11. Mai 2020, findet um 19 Uhr unser monatliches Freifunktreffen statt. Diesmal wieder virtuell unter folgender Adresse: https://meet.lihas.de/ffs

Beginn ist wie immer um 19 Uhr im shackspace, Ulmer Str. 255, S-Wangen. U-Bahnhaltestelle ‚Im Degen‘.

Themen, die besprochen werden sollen, können im Etherpad eingetragen werden.

Wir freuen uns auf zahlreiches virtuelles Beisammensein.

Freifunk-Treffen am 10. Februar 2020

Heute Montag , den 11. Mai 2020, findet um 19 Uhr unser monatliches Freifunktreffen statt. Diesmal wieder virtuell unter folgender Adresse: https://meet.lihas.de/ffs

Beginn ist wie immer um 19 Uhr im shackspace, Ulmer Str. 255, S-Wangen. U-Bahnhaltestelle ‚Im Degen‘.

Themen sind die neue Firmware 1.8, sowie die Möglichkeit mehrere neue Projekte mit Freifunk zu realisieren.

Themen, die besprochen werden sollen, können im Etherpad eingetragen werden.

Wir freuen uns auf zahlreiches virtuelles Beisammensein.

Freifunk-Treffen am 13.01.2020

Heute Montag , den 11. Mai 2020, findet um 19 Uhr unser monatliches Freifunktreffen statt. Diesmal wieder virtuell unter folgender Adresse: https://meet.lihas.de/ffs

Beginn ist wie immer um 19 Uhr im shackspace, Ulmer Str. 255, S-Wangen. U-Bahnhaltestelle ‚Im Degen‘.

Themen sind die neue Firmware 1.8, sowie die Möglichkeit mehrere neue Projekte mit Freifunk zu realisieren.

Themen, die besprochen werden sollen, können im Etherpad eingetragen werden.

Wir freuen uns auf zahlreiches virtuelles Beisammensein.

Firmware v. 1.7 – Update-Probleme

Evtl. hat der ein odere andere FreifunkerIn schon bemerkt, dass es eine neue Firmware mit der Version 1.7 gibt. Und auch hat er oder sie am eigenen Router festegestellt das dieser mit angeschaltetem Autoupdate die neue Firmware noch nicht bekommen hat. Wascheinlich ist dann dieser Router ein TP-Link CPE / TP-Link WBS, eine Unifi AC Lite / AC Pro oder ein x86-Computer.

Diese Geräte werden absichtlich nicht vom Autoupdater beliefert, da sie beim Update von Version 1.3 auf 1.7 Probleme machen können. Welche Probleme das sind und wie diese lösbar sind wurde von einem Freifunker in unserem Wiki beschrieben. Teilweise sind leider technisch tiefe Eingriffe nötig. Sollte jemand hierbei Probleme haben oder sich dies nicht zutrauen, kann er gerne mit seinen Routern bei unseren Treffen vorbei kommen oder sich auf der allgemeinen Mailingliste melden. Die Treffen werden in der Regel auch hier im Blog kurzfristig angekündigt. Wir treffen uns jeden 2. Montag im Monat im shackspace in Stuttgart.

Wir empfehlen ein zeitnahes Update, da wir auf mittelfristige Sicht Router mit alten Firmware-Versionen aus technischen Gründen nicht weiter unterstützen können. Diese werden dann ihre Verbindung zum Freifunk-Netz verlieren.

Neue Knoten-Karte

Im Zuge der Infrastrukturkonsolidierung haben wir eine neue Knotenkarte erstellt. Die alte Karte hat auf HopGlass basiert. Die neue basiert auf dem Meshviewer, welche aktuell von den Regensburger Freifunkern gepflegt wird und wofür wir herzlich danken. Aktuell habe sich ein paar Freifunker bereit erklärt den Meshviewer für Stuttgart auch in Zukunft zu pflegen.

Neue Funktionen im Meshviewer

Es werden nun für einzeln ausgewählte Knoten nicht nur die Anzahl der Endgeräte angezeigt, sondern auch auf welcher Frequenz sie über WLAN mit dem Knoten verbunden sind. Rot steht für 2,4 Ghz, Gelb für 5 Ghz, blau für andere Verbindungsarten oder unbekannt.


Desweiteren wird nun auch das jeweilige Segment und die PLZ, sofern angegeben, bei jedem einzelnen Knoten angezeigt.


Bei den Verbindungen gibt es nun auch mehr visualisierte Daten. So wird bei Verbindungen eines Knoten zu anderen Knoten ganz links angezeigt, ob es sich um eine Verbindung über WLAN oder Kabel bzw. Richtfunk-Brücke handelt. Das nächste Symbol rechts davon zeigt an, ob Koordinaten für den Knoten vorliegen. Danach kommt der Knotenname. Es folgt die Anzahl der Endgeräte auf dem verbundenen Knoten, sowie die Verbindungsqualität und die Distanz zwischen den Knoten.


Wird die Verbindung zwischen zwei Knoten auf der Karte ausgewählt, so gibt es nun ein weitere Funktion zu früher. Die Verbindungslinie zeigt nun in farbiger Abstufung ein Maximum und ein Minimum der Verbindungsqualität an. Bei der alten Karte war dies nur 1 Wert. Dort wurden auch Verbindungen über Kabel bzw. Richtfunk-Brücke als blaue Linie angezeigt. Diese fällt nun weg und steht nur noch als Text unter Verbindungsart (wifi oder andere)


Was nicht neu ist, aber sich trotzdem ein wenig geändert hat ist die Farbanzeige der Knoten. Neue Knoten werden nun 14 Tage als neu angesehen. Ansonsten bleibt alles beim alten. Knoten die offline sind, werden nach 7 Tagen aus der Karte entfernt. Kommen sie danach wieder online, werden sie als neue Knoten angesehen.


Was auch nicht neu, aber trotzdem noch erwähnenswert ist, sind die Möglichkeiten unter dem Tab „Statistiken“. Hier können die Knoten nach mehreren Werten sortiert werden, je nachdem was man ermitteln will. Oben sieht man ein kleines Beispiel mit zwei ausgewählten Werten. Die Werte werden ausgewählt indem man auf die blau angezeigten Textfragmente klickt. Auch werden auf der Karte selber nur noch die ausgewählten Knoten angezeigt.


Für jeden Knoten werden nun auch vier Graphen ausgegeben, welche die Anzahl der Endgeräte, die Bandbreite, die durchschnittliche Last des Routers und Ausnutzung des Arbeitsspeichers anzeigen.

Alte Karten

Für Freifunk Stuttgart existierten zwei Karten die jeweils unter karte.freifunk-stuttgart.de und map.freifunk-stuttgart auffindbar waren. Erstere wird in naher Zukunft komplett gelöscht werden . Die Domain wird dann auf den neuen Meshviewer verweisen, zweitere ebenso. Die früher unter map.freifunk-stuttgart.de auffindbare Karte wird noch weiterhin unter oldmap.freifunk-stuttgart.de zu finden sein, da es auch noch Knoten mit Freifunk-Firmware gibt, die aus technischen Gründen auf der neuen Karte nicht erscheinen.

Technisches

Kurz noch ein paar Erwähnungen des technischen Hintergrundes für diejenigen, die es interessiert:

Respondd: Sammelt die Daten von allen Knoten im Freifunk-Netz.

Yanic: Sammelt die Daten von Respondd und macht eine .json daraus.

Meshviewer: nutz dies Daten der .json für die Darstellung auf der Karte.

InfluxDB: Wird für Grafana benötigt. Bekommt seine Daten von Yanic geliefert.

Grafana: Wird für die Darstellung der Graphen im Meshviewer benötigt. Holt sich die Daten von InfluxDB.

Mesh-Netzwerke und Switche

Häufig kommt es vor, dass man Mesh-Verbindungen mit externer Richtfunk-Hardware betreibt. Man tut dies, weil für die Richtfunk -Hardware kein Gluon verfügbar ist oder weil es aus regulatorischen Gründen nicht erlaubt wäre (DFS). Für Gluon erscheint der Mesh-Link dann wie eine Kabelverbindung. Manchmal hat man mehrere solche Richtfunk-Verbindungen hintereinander. Dann ist es verlockend, auf einem Knoten Mesh-on-LAN zu aktivieren und die Richtfunk-Verbindungen mit den LAN-Ports zu verbinden. Dieser Wiki-Artikel soll erklären, warum das oft eine schlechte Idee ist und wie man das Problem entschärfen kann. Hier klicken.

Danke an den Stuttgarter Freifunker für diese Erläuterungen.