LX-6200 - kein Update für LCOS LX seit Januar 2024

[lanwahn]

Hallo zusammen,

ich habe seit ca. 3 Jahren alles LANCOM-Only, also Router, Switche, APs, sogar die IP DECT Pro 510 wird eingesetzt. Auch einige S2S-Verbindungen laufen darüber, bisher war das immer stabil und ich war zufrieden.
Ich war daher seit einigen Monaten wirklich ein Stück entsetzt, dass für einen wirklich teuren WLAN-AP (ich habe mehrere LX-6500 sowie LX-6400 im Einsatz) über nun gut 6 Monate kein einziges Update mehr gab. Und das bei einer Linux-Firmware, welche hoher Wahrscheinlichkeit in dieser Zeit unabhängig der Linux-Kernel-Version schon X Sicherheitslücken im Kernel sowie den einzelnen Paketen in sich hat.

Klar, ist das Access-Layer und existiert in der Regel ein getrenntes Management-VLAN, aber den Security-Best-Practices entspricht dies nicht wirklich ein Gerät während des aktiven Supportzyklus so lange nicht zu pflegen.
Mir ist und war "digitale Souveränität" immer wichtig, weshalb ich wo möglich explizit keine China/USA-Hardware (zumindest als Primärhersteller) wollte und mich aktiv für LANCOM Systems entschieden habe.
Aber wenn Produkte nur noch halbherzig gepflegt werden muss ich mir in Zukunft hier auch eine Alternative suchen...

Wirklich schwierig wird das aber wenn die schlechte Pflege auch beim LCOS-Routern ankommt, weil meines Erachtens gibt es auf dem Markt keinen anderen Hersteller mehr, welcher "Fritzboxen fürs Business" bietet...eigentlich ist der 1926VAG genau das .

Grüße,
lanwahn

[fildercom]

Hallo zusammen,

ich habe seit ca. 3 Jahren alles LANCOM-Only, also Router, Switche, APs, (...)

So hatte ich es längere Zeit auch im Einsatz, weil ich dachte, dass es sowohl aus Gründen der IT-Sicherheit als auch aus Gründen der einfacheren Verwaltung sinnvoll ist, weitestegehend auf einen Hersteller aus Deutschland zu setzen.

Ich muss aber sagen, dass sich das als Sackgassse erwiesen hat. Einerseits ist das Produktportfolio in manchen Bereichen (vor allem Switches) einfach (noch) nicht so umfassend, als dass ich immer ein passendes Gerät gefunden hätte. Und andererseits ist es diese restriktive Updatepolitik ("Software Lifecycle Management"), die mir nicht wirklich zusagt.

Dieses Jahr stand ein Upgrade meiner Switch-Infrastruktur an und ich habe nun alle LANCOM-Switches "ausrangiert" (2 x GS-2326 und 1 x GS-2310P). Ersetzt habe ich diese Switches durch aruba 6100 12G. Gleichzeitig habe ich auch meine beiden bintec Switches ESW4000-12PH durch Extreme X440-G2-12P-GE4 ersetzt.

Technisch gesehen sind diese Switches die deutlich bessere Wahl, da sie mehr Funktionen und gut dokumentiertes Management über das CLI bieten. Was Updates angeht ist man bei aruba relativ gut versorgt, für Extreme braucht man eine Kontaktperson, aber das geht dann auch

Viele Grüße
fildercom (weiblich)

[GrandDixence]

Und das bei einer Linux-Firmware, welche hoher Wahrscheinlichkeit in dieser Zeit unabhängig der Linux-Kernel-Version schon X Sicherheitslücken im Kernel sowie den einzelnen Paketen in sich hat.

Der Linux Kernel ist heute ein "27 Millionen Zeilen Sourcecode-Monster".
https://www.visualcapitalist.com/millio ... s-of-code/

In der Regel befindet sich im Schnitt auf 1000 Zeilen Sourcecode eine Sicherheitslücke.

Mit Hilfsmitteln wie "menuconfig" lässt sich der Funktionsumfang des in der Firmware implementierten Linux Kernel beim Kompiliervorgang massiv reduzieren. Menuconfig ermöglicht das "Abspecken" vom Linux Kernel.
https://en.wikipedia.org/wiki/Menuconfig

LANCOM wird mit sehr hoher Wahrscheinlichkeit den im LCOS LX enthaltene Linux Kernels massiv abgespeckt haben. Weniger Speck, weniger Sicherheitslücken! Die Marketingabteilung von LANCOM wird dieses abgespeckte Linux als "gehärteten Linux-Kernel" verkaufen...

Der in der LCOS LX-Firmware enthaltene Linux Kernel hat sicher einen deutlich kleineren Funktionsumfang als ein Standard-Kernel von einer Linuxdistribution für Server- oder Desktoprechnern. Hier als Beispiel die Kernel-Tarballs von SLED15 SP6:

Code: Alles auswählen

tree -h /boot/ |grep -i vmlinuz
├── [  34]  vmlinuz -> vmlinuz-6.4.0-150600.23.14-default
├── [ 11M]  vmlinuz-5.14.21-150500.55.68-default
└── [ 14M]  vmlinuz-6.4.0-150600.23.14-default

Man beachte die Dateigrössenangaben der Kernel-Tarballs.
https://de.wikipedia.org/wiki/Tar_(Packprogramm)

LANCOM schwenkte für das Betriebssystem der Netzwerkkomponenten von RTOS auf Linux um, weil das Schreiben der Hardwareansteuerung (MS Windows-Jargon: Hardwaretreiber, Linux-Jargon: Kernelmodul) für das eigene RTOS und die eingekaufte Hardware immer mehr zum Problem wurde. Die Hardwarelieferanten rücken keine Spezifikationen zur Hardwareansteuerung mehr heraus, liefern aber ein fixfertiges Linux-Kernelmodul.
lancom-wireless-aktuelle-accesspoints-f ... ml#p109971

Dieses Problem haben aber auch alle anderen Netzwerkkomponentenhersteller, die ein RTOS einsetzen.
https://de.wikipedia.org/wiki/Echtzeitbetriebssystem

Vermutlich wird von LANCOM ein Linux Kernel mit dem "Real-time Patch" eingesetzt. Siehe dazu die Beiträge ab dem 17. November 2022 unter:
https://www.bsdforen.de/threads/embedde ... ost-331177

Das Betriebssystem einer Netzwerkkomponente muss Echtzeit-Anforderungen erfüllen, weil die Verarbeitung der meisten Datenpakete eine zeitkritische Angelegenheit ist. Zu "langsame" Netzwerkkomponenten haben negativen Einfluss auf die Performance und Qualität von (zeitkritischen) Serverdiensten. Zum Beispiel:
fragen-zu-lancom-systems-voip-router-f4 ... 20565.html

[sixty]

Der in der LCOS LX-Firmware enthaltene Linux Kernel hat sicher einen deutlich kleineren Funktionsumfang als ein Standard-Kernel von einer Linuxdistribution für Server- oder Desktoprechnern.

CVE listet im Moment alleine im 1. Halbjahr 2024 137 Einträge für Linux mit Score > 7, 125 davon im Kernel.

Ganz aktuell übrigens CVE-2024-3596 (Blast-Radius).
Die meisten anderen Hersteller haben inzwischen dazu ein Statement herausgegeben, und wenn es nur ist "wir haben geprüft, uns betrifft es nicht weil wir seit x Jahren keine unsignierten Pakete und kein MD5 mehr einsetzen".
Damit kann man arbeiten - auch im Sinne von NIS.
Gibt es ein solches Statement eigentlich schon von LANCOM?

[GrandDixence]

Gibt es ein solches Statement eigentlich schon von LANCOM?

Wenn ja, dann unter:
https://www.lancom-systems.de/service-s ... tshinweise

Diese LANCOM-Webseite sollten LANCOM-Netzwerkadministratoren und -administratorinnen regelmässig, mindestens 1x pro Woche konsultieren!

Zum Thema "Firmware-Updates" sollten auch die Hinweise unter:
fragen-zur-lancom-systems-routern-und-g ... ml#p112858
beachtet werden.

[5624]

Ja, der Kernel im LX ist mit dem PREEMPT-Patch versehen.

Code: Alles auswählen

"Linux version 3.14.26-g43b1178-00038-g96ef344 (lnxbuild@abait242-sd-lnx) (gcc version 4.9.x-google 20140827 (prerelease) (GCC) ) #1 SMP PREEMPT Fri Jun 5 15:15:57 PDT 2015"

LX basiert auf OpenWRT r49254, also umbei 2015/2016, passend zum Versionsstring des Kernels.

Code: Alles auswählen

arm-openwrt-linux-gcc (OpenWrt GCC 5.2.0 5da56622b3+r49254) 5.2.0

In wie weit da Updates in anderer Form hineingelaufen sind oder ob die Meldungen zu Lücken im Kernel überhaupt auf diese Kompilat anwendbar sind, kann ich nicht bewerten. Hab nur eben einmal das aktuelle Image durchgeschaut, während die Laugenstangen im Backofen waren.

[GrandDixence]

Wer Interesse daran hat, für ein im Produktiveinsatz stehendes Linux-System über mehrere Jahre alle bekannten Sicherheitslücken im Linux Kernel zu schliessen, hat heute nur die Wahl zwischen drei in der Praxis realistisch umsetzbare Lösungswege:

a) Einen offiziellen, "Longterm" Kernel von https://www.kernel.org einsetzen:
https://www.kernel.org/category/releases.html

https://www.thomas-krenn.com/de/wiki/Li ... _Versionen

b) Einen "Frankenstein"-Kernel von einer LTS-Linuxdistribution einsetzen (RedHat, SUSE, oder Ubuntu).
https://www.heise.de/hintergrund/Linux- ... ?seite=all

c) einen Linux Kernel von Android einsetzen (AOSP-Kernel)
https://source.android.com/docs/core/ar ... mmon?hl=de

(Vanilla-)OpenWrt, Debian und ChromeOS verfolgen den Lösungsweg a).
https://openwrt.org/docs/guide-develope ... ort_status

https://openwrt.org/docs/techref/targets/kernelversions

ChromeOS wird in Zukunft Lösungsweg c) verfolgen:
https://www.osnews.com/story/139941/chr ... ubsystems/

Weiter sollte bewusst und bekannt sein, dass das Open Source-Projekt "Linux Kernel" gravierende Probleme hat mit der Ausweisung aller bekannten Sicherheitslücken per CVE-Nummer. Siehe dazu die kostenpflichtigen Heise-Artikeln:
https://www.heise.de/hintergrund/Linux- ... ?seite=all

https://www.heise.de/news/Linux-Kernel- ... 28112.html

Wenn LANCOM in ihren Netzwerkkomponenten einen Linux Kernel mit einer Versionsangabe < 4.4 einsetzt, hat LANCOM offenbar kein Interesse daran, alle Sicherheitslücken im Linux Kernel zügig und zuverlässig zu schliessen. Aus den oben stehenden Angaben von 5624 entnehme ich, dass für LCOS LX ein 9-jähriger Linux Kernel 3.14.26 eingesetzt wird.

Die Versionsangabe 5.2.0 und 4.9.x bezieht sich auf den eingesetzten C/C++-Kompiler (gcc). Die aktuellste GCC-Version trägt die Nummer 14.1.
https://de.wikipedia.org/wiki/GNU_Compiler_Collection

https://gcc.gnu.org/

Beim Einsatz eines derart veralteten C/C++-Kompilers können praktisch keine der unter:
https://best.openssf.org/Compiler-Harde ... -C-and-C++
beschriebenen Massnahmen zur Verbesserung des kompilierten Programmcodes realisiert werden.

Hier als Beispiel ein 9 Jahre jüngerer Linux Kernel von SLED15 SP6 (Lösungsweg b ohne "Real-time Patch"):

Code: Alles auswählen

# uname -vr
6.4.0-150600.23.14-default #1 SMP PREEMPT_DYNAMIC Wed Jul  3 00:26:09 UTC 2024 (95fb0f8)

Ubuntu 16.04.0 LTS hat mit dem Linux Kernel 4.4 den ältesten mir bekannten Linux Kernel für Produktivsysteme im Einsatz, welcher heute noch zuverlässig und zügig mit Sicherheitsupdates versorgt wird (Lösungsweg b).
https://ubuntu.com/about/release-cycle# ... ease-cycle

Offensichtlich hat sich LANCOM in der "Qualcomm-Linux-Sackgasse" hoffnungslos "verrannt". Man beachte den Beitrag von jfuchs zum proprietären Qualcomm-OpenWrt unter:
lancom-allgemeine-fragen-f23/inzwischen ... ml#p117501

[lanwahn]

LX basiert auf OpenWRT r49254, also umbei 2015/2016, passend zum Versionsstring des Kernels.

Wow...also das außerhalb des Server/Desktop-Linux-Bereiches oft ältere Linux-Versionen anzutreffen sind, kenne ich.
Gerade im Embedded-Umfeld bei Multifunktionsgeräten, die haben da das Problem mit Binary-Blobs auch (Bluetooth, WLAN, Faxkarten).
Aber ein Produkt, welches aktuell im Supportzyklus ist mit einem Linux-Kernel auszuliefern, welcher bereits ungefähr 8 Jahre alt ist ist schon frech.
Ich bezweifle stark, das hier für ein solches Produkt temporär 20 Kernel-Entwickler angestellt wurden und alle Patches back-portet haben .

Hat jemand Erfahrungen wie das z.B. bei Ubiquiti oder Aruba aussieht? Im Prinzip kochen ja alle nur mit Wasser. Die Frage ist für mich, wie frisch ist das Wasser .


Grüße,
lanwahn

[5624]

aktuelle Firmware für den Unifi U7 Pro

Code: Alles auswählen

arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 5.2.0 c4c4fbf+r49254) 5.2.0

Code: Alles auswählen

"Linux version 3.14.26-g43b1178-00038-g96ef344 (lnxbuild@abait242-sd-lnx) (gcc version 4.9.x-google 20140827 (prerelease) (GCC) ) #1 SMP PREEMPT Fri Jun 5 15:15:57 PDT 2015"

Ist genau die gleiche veraltete Scheis+se drin.

Zu Aruba kann ich nichts sagen, bekomm ich gerade keine Firmwaredatei ran.

[lanwahn]

Oh, danke.
Das ist ein spannender Einblick, danke 5624 .

Also ist LANCOM Systems genauso so "scheis+se" wie die anderen. Also zumindest nicht "scheis+ser" .
Somit spielen die ja in der selben Liga (welche das jetzt auch immer ist).
Die Liga "Wir sind von den Binary-Blobs der Chiphersteller angewiesen, Hauptsache es funktioniert (halbwegs), Security braucht eh keiner".
Spannend wäre jetzt, auf welcher Kernel-Basis die Chiphersteller die der neusten Binary-Blobs von so einem QCN90x4 oder IPQ807x sind...hat da jemand Insider-Zugang?
Oder sind die auch immer X Jahre im Verzug?
Bekommt der Käufer bei der Abnahme von Anzahl X Chips nur eine veraltete Version und müsste nochmal extra für neuere Versionen bzw. Long-Term-Support bezahlen? Spannendes Thema .

Grüße,
lanwahn

[5624]

Es gibt ein SDK vom Hersteller des SoC und nur damit funktioniert es so mehr oder weniger. Das ist dann die Basis und der Käufer muss sich dann darum kümmern, dass es irgendwie funktioniert und gepflegt wird. Da es nicht so viele Hersteller entsprechender Chips gibt, wird man überall das gleiche finden.

Schau dir TP-Link an. Da gibt es für die einfachen Geräte die Auslieferungsfirmware und nur im Katastrophenfall noch ein Update. Die setzen darauf, dass sich die Anwender anderweitig versorgen lassen.

[fildercom]

Wir haben jetzt (fast) Mitte August und es gibt nach wie vor kein LCOS LX 6.20.

Morgen ist dann in Teilen Deutschlands Feiertag, da wird sich bestimmt auch nichts tun...

[Dr.Einstein]

Die DSC Datei ist zumindest schonmal da für LanConfig und LMC...

Aber auch die Bugbearbeitung bei LX ist die reinste Katastrophe. Trotz entsprechendem Partnerstatus 6 Monate und länger auf eine Lösung warten.

[fildercom]

Ich bin mir wirklich immer unsicherer, ob ich tatsächlich zukünftig auf APs mit LX vertrauen will. Das größte Problem ist aber, dass mit der Abkündigung der LN-17xx-Reihe keine Alternativen mehr zur Verfügung stehen. Ob ich auf einen anderen Hersteller wechseln will, weiß ich nicht...

[lanwahn]

Ja, aktuell ist da wirklich keine Motivation zu erkennen...
Es gibt wirklich aktuell keinen Grund, die LX-APs zu kaufen...selbst wenn man die LMC einsetzt, mit einer solchen veralteten Firmware würde mich wirklich mal interessieren, wie der Hersteller hier irgendeine Sicherheit sicherstellen möchte.
Leider ist hier LANCOM Systems kein Deut besser als große Netzwerkausrüster...ich warte mal noch bis Ende August ab...kann man das nicht irgendwo beim BSI melden?

Ich will ja niemandem etwas böses, ganz im Gegenteil: Macht aus dem Ding was ordentliches, die Hardware hat ja zumindest bei den LX-6400 und den LX-6500 schon Potenzial...mit gutem Beispiel voran gehen wäre der richtige Weg...und das wäre richtige Sicherheit "Made in Germany"