Hallo!
Am 2016-05-16 um 13:18 schrieb David Hopfmueller:
On 05/16/2016 10:48 AM, Stefan Schultheis (home) wrote:
Hi,
[...]
Wow, ein Drittel des Netzes ist offline?! Ich wusste nicht, dass das
derartige Ausmaße angenommen hat.
Laut Ubnt-Forum hat es auch einige (kommerzielle) WLAN-Provider
(weltweit) kalt erwischt.
[...]
Mich wundert, dass es zu dem Thema nicht mehr Traffic auf dieser Liste
gibt. Da müssen doch einige zig Leute betroffen sein. Ist das
großteils unbemerkt geblieben, kommuniziert ihr offline, leidet in
Stille, …?
Mich wundert es weniger: Funkfeuer ist für manche ein Add-On. Wieder
andere Nodebesitzer haben einen Maintainer, der sich darum kümmert.
Das ist ja auch Teil meiner wiederkehrenden, langjährigen Kritik: dass
die Weitergabe von Wissen bezüglich des Betriebs von Netzen stagniert,
wenn man auf Maintainer anstelle von "Angels" (Mentoren) setzt.
Wir sollten jedenfalls für die Zukunft eine Lösung finden.
Strategien?
Etwa: Mentorship ausbauen, Tools für die Anomalieerkennung im Netz,
Hard- und Software-Diversität; Auflösung des Widerspruchs zwischen einem
informativen Community-OS (Fokus: verteilte
Status/OLSR-Status-Interfaces) und der Vermeidung von allzu vielen
(potentiell angreifbaren) Diensten pro Gerät.
Der Vorfall ist ein weiteres Argument gegen Black-Box-Devices wie die
Ubnt-Bridges.
AirOS ist nicht in der Gesamtheit eine Black-Box, nur Teile, wie
proprietäre WLAN-Treiber, für die man als Programmierer ein NDA
unterzeichnen müsste.
Soviel darf ich von einem solchen, mir bekannten NDA-Unterzeichner
weitergeben: die OpenSource-Treiber beherrschen nur einen kleinen
Bruchteil der Funktionalität dessen, was von den Chips unterstützt wird.
Was aktuell betroffen ist, ist lighttpd, respektive das modifizierte "PHP2".
Siehe
https://community.ubnt.com/t5/airMAX-General-Discussion/Virus-attack-URGENT-UBNT/td-p/1562940/page/5
Und gerade wegen der besseren WLAN-Treiber und aktuellen Regulatorien
führt momentan kaum ein Weg an Hersteller-Software vorbei.
Was man jedoch tun kann: Lobbying betreiben und an den
Open-Source-Teilen, die auch dort zum Einsatz kommen mitwirken. (Audits
etc).
Und ein deutlicher Reminder, uns als Community um eine
Update-Strategie und ein Sicherheitskonzept zu kümmern.
Die Update-Strategie nützt wenig, wenn es sich um einen Zero-Day-Exploit
handelt - und somit begriffsgemäß Herstellerpatches fehlen.
Und das in diesem Fall anzuwendende Sicherheitskonzept stünde, wie oben
erwähnt, im Widerspruch zu den bisherigen Anforderungen der "Community".
Was aber die "Community" ist, was ihr kollektiver Wille ist und, wie man
im Sinne dessen arbeiten kann, das sind die wiederkehrenden Grundfragen...
(Rollen: Node Maintainer vs. Node Owner vs Node User vs ...).
Aber auch das hat sein Gutes:
In diesem Funknetz gibt einen zentralen Uplink - auch das steht im
Widerspruch zu Paradigmen eines echten Community-Netzes, aber gerade
das erweist sich als Vorteil, wenn aufgrund erkennbarer Muster Ports
geblockt werden sollen. (Es sei denn, unser Netz hat aus
wissenschaftlichen Gründen den Zweck, ein Honeypot sein, was ich einmal
nicht annehme.;-)
Und wieder einmal zeigt sich, dass rein technische Lösungen für eine
soziale oder gemischt technisch-soziale Problematik nicht funktionieren
können. Und wieder einmal darf ich sagen: Funknetze, wie wir sie kennen,
sind EOL. Leider zeigen die Ereignisse, dass diese meine von Einigen
hier herabgewürdigte Aussage zutreffend ist - Nur vom Leugnen der
Probleme und mit Blocken von Nachrichten wird es auch nicht besser.
Besinnnen wir uns auf diese Fragen, bevor wir uns auf konkrete
strategisch-technische Maßnahmen festlegen, die über ein Stopfen von
Löchern hinausgehen:
Community, wer bist Du?
Community, was willst Du?
Community, wohin gehst Du?
Für den Moment können wir die "Black Boxes" nur aus der Schusslinie
nehmen, indem wir die Anzahl der laufenden, angreifbaren Dienste reduzieren.
U.z. nicht gerade durch Security by Obscurity (Ports verlegen oder "nur"
Blocken), sondern durch Abschalten des Webservers (http/https), dem
Deaktivieren von SSH-Passwörtern (anstelle dessen SSH-Keys nützen).
Auf Verdacht würde ich auch auf SNMP verzichten.
Alternativ kann man den Bridge-Modus nützen und ggfls. die Boxen
dedizierten VLANs zuordnen - wobei rein quelloffene und aktuelle
Software Schnittstellen nach Außen bieten sollte.
Aaron kann einstweilen via Cert.at das Pentesting von AirOS vorantreiben.
CU,
David
LG
Erich
--
Discuss mailing list
[email protected]
https://lists.funkfeuer.at/mailman/listinfo/discuss
