Hallo,
kürzlich ist ja die Mirai Malware wieder aufgetaucht -> Telekom Router.
Anfällig sollen ja Router mit Betriebssystem, welches auf Linux basiert,
sein. Wie sieht das denn bei der Freifunk Firmware aus, da diese ja auch
auf Linux basiert?
Grüße
Klaus Dint
NTP
Am 04.12.2016 23:50 schrieb "Jan-Tarek Butt via Dev" <dev(a)lists.ffnw.de>:
On 12/03/16 11:30, Bjoern Franke via Dev wrote:
> Moin,
>
>>
>> z.b. könnte der Umstieg auf gluon v2016.2.x ffnw-ginaliesa-....bin
>> heißen.
>>
>> Was haltet ihr davon ?
>>
>
> Du möchtest doch nur ein Release nach dir benennen, oder? ;)
Nein, Ernsthaft das wäre doch witzig.
vg
Tarek
_______________________________________________
Dev mailing list
Dev(a)lists.ffnw.de
https://lists.ffnw.de/mailman/listinfo/dev
Naja bei den Telekom Routern war es einfach nur ein einziges DDOS gewesen. Kein Angriff auf irgendwas. Der exploid war nicht Firma die Router geschrieben, aber abgehackt sind sie trotzdem.
Mit freundlichen Grüßen
Jens Ellerbrock
--------------------
Freifunk Nordwest e.V. Website
Unterstütze uns doch mit einer kleinen Spende, oder ganz einfach beim Onlineshoppen (ohne extra Kosten)
Von meinem Samsung Galaxy Smartphone gesendet.
-------- Ursprüngliche Nachricht --------Von: Jan-Tarek Butt via Dev <dev(a)lists.ffnw.de> Datum: 05.12.16 00:39 (GMT+01:00) An: dev(a)lists.ffnw.de Cc: Jan-Tarek Butt <tarek(a)ring0.de> Betreff: Re: [Dev] Mirai Malware - Freifunk Router anfällig?
On 12/04/16 21:27, Klaus Dint via Dev wrote:
> Hallo,
>
> kürzlich ist ja die Mirai Malware wieder aufgetaucht -> Telekom Router.
> Anfällig sollen ja Router mit Betriebssystem, welches auf Linux basiert,
> sein. Wie sieht das denn bei der Freifunk Firmware aus, da diese ja auch
> auf Linux basiert?
Im falle der Telekom Router wurde der Angriff auf ein Fernwartungsprotokoll gefahren.
Problematisch war das TR-64 Protokoll welches eigentlich nur in lokalen Netzen zum
Einsatz kommen sollte. Dieses war aber öffentlich aus dem Netz zugänglich.
Diese Protokoll kommt bei uns gar nicht zum Einsatz. Das war die Schwachstelle leider war das nicht alles.
Über das Protokoll kann jeden beliebe alle Router um konfigurieren. Natürlich reicht das noch nicht zum
code ausführen. Dazu hab es dann ein zweiten gravierendes Problem was erlaubt hatte das code der dem TR-64
mitgegeben wurde perseh durch sh lief. Das das somit eine sehr angenehme Möglichkeit für remote code execution.
mitgegeben wurde perseh durch sh lief. Das das somit eine sehr angenehme Möglichkeit für remote code execution
Die Freifunk Router hängen perse hinter einem DSL Router und somit in den meisten fällen hinter einen NAT.
Generell gibt es kaum Möglichkeiten an den Router ran zu kommen. Da die Router daruf gebaut werden möglichst
verschlossen nach außen zu sein und autark zu arbeiten.
vg
Tarek
_______________________________________________
Dev mailing list
Dev(a)lists.ffnw.de
https://lists.ffnw.de/mailman/listinfo/dev
Hallo zusammen,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
* Firmware-Version: 1.2
* Gluon-Version: v2016.1.x
* Commit ID: ee597c66769a455d38467192598813e7f8411cfd
* Download: https://firmware.ffnw.de/1.2
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/ee597c...ee597c
Folgende Comunnity spezifischen Änderungen gab es:
package repo:
* logic Fehler im configmode wurden behoben
Das Dropdown menu hat, bei wiederholten ausführen des
configModes seinen zustand nicht wiederhergestellt.
Das setzen zweier uci Parameter ist durch einen Typen Fehler
nie zu Stande gekommen.
* Client seitige Javascript map im configeMode
Es wird nun vom Router aus via Javascript auf den Client eine
OSM Karte geladen, sofern der Client über eine Internet
Verbindung verfügt. Um das selektieren von statischen Geo
Koordinaten zu vereinfachen.
* hoodselector: hoodinfo Sektion in respondd wurde erstellt #63 #48
Über respondd werden nun Informationen über die aktuell
selektierte hood eines Routers verteilt.
* hoodselector: das MOLWM Protokoll wurde implementiert Mesh On Lan
/ Wan Managemend
Das MOLWM Protokoll detektiert hood Kollisionen im mesh on lan
oder mesh on wan. U.a. anhand von Vergleichungen von md5 hashes
der einzelnen hoods.
* hoodselector: Der hoodselector gibt nun returncodes bei der
Terminierung zurück.
* hoodselector: pid datei write Permission wird abgefangen
* hoodselector: Unbenutzte variablen wurden entfernt und das überlappen
von Globalen variablen wurde behoben (zum Einsatz kam luacheck)
* hoodselector: Es können nun mehrere fastd peers mit äquivalenten DNS
aber unterschiedlichen Port bestehen. #40
Das ermöglicht uns anstelle von folgenden zu schreiben:
starwars0.sn.ffnw.de 1001
starwars1.sn.ffnw.de 1010
starwars1.sn.ffnw.de 1011
Lediglich:
starwars.sn.ffnw.de 1001
starwars.sn.ffnw.de 1010
starwars.sn.ffnw.de 1011
Das reduziert somit die ganzen DNS Einträge.
* hoodselector: Im scanmode arbeitet der hoodselector nun nicht mehr mit
einen statisch festgelegten WLAN Interface, sondern scannt über alle WLAN
Interfaces die ein Gerät hat. #69
* hoodselector: Im scanmode wird nicht mehr statisch 30 sec abgewartet
um anschließend zu prüfen ob eine mesh Verbindung besteht. Es wird nun
kontinuierlich geschaut und spätesten nach einem Zeitablauf von 30 sec
fortgesetzt. #70
* hoodselector: Fehlermeldungen werden nun in ein logfile geschrieben und
können und über logread eingesehen werden. #36
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/v1.1.1...v…
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/v1.1.1...v…
Schöne Grüße
Tarek