Schlagwort-Archive: Freifunk

Freifunk-Treffen am 12. Oktober – virtuell

Am Montag , den 12. Oktober 2020, findet um 19 Uhr unser monatliches Freifunktreffen statt. Da der shackspace weiterhin geschlossen ist treffen wir uns wieder virtuell unter folgender Adresse: https://meet.lihas.de/ffs

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

Wir freuen uns auf zahlreiches virtuelles Beisammensein.

Freifunk-Treffen am 14. September– virtuell

Am Montag , den 12. Oktober 2020, findet um 19 Uhr unser monatliches Freifunktreffen statt. Da der shackspace weiterhin geschlossen ist treffen wir uns wieder virtuell unter folgender Adresse: https://meet.lihas.de/ffs

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

Wir freuen uns auf zahlreiches virtuelles Beisammensein.

Neues Etherpad

Etherpad ist ein Werkzeug zur kollaborativen Arbeit und kommt bei Freifunk Stuttgart seit vielen Jahre zum Einsatz. Inbesondere als Protokoll-Werkzeug bei den monatlichen Treffen, den Vorstandssitzungen oder verschiedenen Projekten, als ToDo-Liste oder für Brainstorming.

Freifunk Stuttgart hat nun einen eigenen Etherpad-Server mit entsprechender Domain, welcher von jedem genutzt werden kann. Auch das Metapad ist dorthin umgezogen. Alle alten Pads im Metapad werden weiterhin auf dem alten Server verbleiben. Eine Sicherungskopie davon ist angelegt.

Neues Design – Textbereich ist hell, da so mehr Kontrast für die Schrift vorhanden ist – mehr barrierefreiheit.

Wir bedanken uns auch bei Dentaku dafür, dass Freifunk Stuttgart eine jahrelange Heimat auf seiner Etherpad-Instanz haben konnte.

Die neue Domain für neue Pads lautet: pad.freifunk-stuttgart.de

Das neue Metapad findet sich unter: https://pad.freifunk-stuttgart.de/p/ffs-metapad

Beim Aufruf der Pads werden drei Cookies gespeichert:

  1. um die Sprache auf Client-Seite im User-Interface zu speichern.
  2. um auf Client-Seite verschieden Einstellungen zu speichern, wie Schriftart, Chat immer sichtbar oder nicht, Farben des Autors, etc.
  3. ein zufälliger Token, damit der entsprechende Autor wieder erkannt wird.

Der Server ist bei uberspace gehostet und wird von Wilhelm (primär) und Nico administriert und gewartet.

Regelmäßige Treffen

Freifunk Backnang, schon seit einiger Zeit im Aufbau befindlich, kann nun mit Freude verkünden, dass ab dem nächsten Monat regelmäßige Freifunk-Treffen in Backnang stattfinden. So sind nun jeden 1. Mittwoch im Monat ab 19:00 Uhr die Backnanger Freifunker meistens im Gemeindehaus St. Johannes zu finden. Das wäre für den September 2020 der 02.09. Alle weiteren Informationen finden sich auf der Website von Freifunk Backnang.

Freifunk-Treffen am 10. August– virtuell

Am Montag , den 12. Oktober 2020, findet um 19 Uhr unser monatliches Freifunktreffen statt. Da der shackspace weiterhin geschlossen ist treffen wir uns wieder virtuell unter folgender Adresse: https://meet.lihas.de/ffs

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

Wir freuen uns auf zahlreiches virtuelles Beisammensein.

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.

Freifunk-Treffen am 13. April 2020 – virtuell

Am Montag , den 12. Oktober 2020, findet um 19 Uhr unser monatliches Freifunktreffen statt. Da der shackspace weiterhin geschlossen ist treffen wir uns 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.