CT 2017-2 Artikel SATIP Megasat SAT to IP Server 3 - Erfahrungen?

Quote from umaier

[...] Die c't war mal "alternativlos" und in voellig anderen Sphaeren als die anderen Blaettchen. Heute macht sie Mainstream und biedert sich mit reisserischen, billigen und sensationsheischenden Aufmachern bei Hein Bloed an. ...

Dem kann ich nur Zustimmen!!
Allerdings ist "Mainstream" wohl doch sehr übertrieben, denn die c't liegt mittlerweile, was das Niveau angeht, sogar noch weit unter der Computer Bild.

Quote from umaier

[...] Schade drum. Ich fand's einfach nur noch Zeit- und Geldverschwendung und habe nach 27 Jahren ohne verpasste Ausgabe meine Konsequenzen gezogen. ...

Ich hatte die c't von Ausgabe 1 an gelesen, habe dann aber vor ca. 10 Jahren das Abo gekündigt, weil man ja offensichtlich bei Heise keinen Wert mehr auf kompetente Redakteure legt.

Hi,
Das ist ein hartes Urteil...
CoBi erklärt was eine Maus ist im Kasten...

Dass es besser geht und war bestreite ich nicht...
MfG Stefan

Quote from wirbel

..na ja, jetzt übertreibst du ein wenig.

Es kann sein, dass ich bei solchen Sicherheitsthemen sehr "empfindlich" reagiere, das kommt wohl von den leidvollen Erfahrungen in der Vergangenheit. Ist schon ein saublödes Gefühl, wenn man plötzlich nicht mehr Herr seiner Systeme ist...

Deswegen fahre ich bei sowas eine Null-Toleranz-Strategie. Systeme mit offenem root-Zugang, ohne die Möglichkeit, das Passwort zu ändern, will ich einfach nicht mehr haben. Mein gesamtes System ist auf Sicherheit und OpenSource ausgerichtet: eigene Firewall, extern erreichbare Systeme in der DMZ, Smart-TV über Kodi, ... Da ärgert es mich schon, dass ich mir mit dem Megasat quasi ein Scheunentor in mein System geholt habe.

Quote from wirbel

Für diese CPU Architektur kann man nicht einfach etwas aus dem Netz
laden, man müsste das schon speziell für diese CPU compilieren.
Normaler Code für x86 oder ARM läuft darauf nicht, die CPU ist selten. Maximal shell scripte laufen und das Linux drauf hat
nur das allernötigste.

>> dank eingebautem wget hätten wir auch bequem zusätzliche Programme aus dem Internet nachladen ... können. ..." (!!!)

Hätten sie dann mal versuchen sollen, statt es nur zu schreiben.
Das Dateisystem ist readonly, es gibt nur einen einzigen Ordner der schreibbar ist. Und der fasst max 5MByte.

wget hatte ich mit einem einfachen Shell-Script getestet und das konnte ich auch ausführen. Mehr wollte ich nicht versuchen, ich will das Teil ja noch zurückgeben können und so DER Linux-Hacker bin ich auch nicht. Aber ein Shell-Script mit root-Rechten ist auf jedem System schon sehr mächtig, für einen einfachen DDoS-Bot reicht das auf jeden Fall. Da reichen auch die 5 MB Speicher mehr als aus. Allerdings halte ich das in der c't angesprochene Szenario "Tauschbörse für illegale Inhalte" doch für recht weit hergeholt. Da müsste dann ja noch Zugriff auf einen externen Speicher bestehen.

Quote from wirbel

Und normalerweise sollte das Ding im abgeschotteten Heimnetz sein. Port 22 zu blockieren sollte ssh unmöglich machen.

Natürlich habe ich Port 22 nicht ins Internet freigeschaltet, der ist nur aus dem internen Netz erreichbar. Trotzdem sehe ich bei so einer offenen Kiste die Gefahr, dass über einen internen Angriff (z.B. über einen gehackten Laptop von Freunden) das Teil kompromittiert wird.

Was mich ärgert ist, dass die Hersteller es immer noch nicht gelernt haben, bei ihren Produkten auf IT-Sicherheit zu achten. Im Gegenteil wurde ja hier wohl aktiv der Passwortschutz deaktiviert. Aber das wird im IoT-Bereich ja scheinbar immer schlimmer, wenn jetzt schon Kühlschränke für DDoS-Attacken genutzt werden...

Das Netz zu segmentieren, nur weil ein Hersteller Mist baut, da habe ich keine Lust drauf. Und dadurch würde ich mir ja auch tatsächlich einiges verbauen. Außerdem: was machen denn die "Normaluser" (oder: Hein Bloed)? Die wissen ja nicht mal, dass es solche Probleme gibt und wundern sich dann, wenn plötzlich ein Ermittler vor der Tür steht (das passiert wirklich, ich kenne einen Fall persönlich).

Ich würde mir wünschen, dass es bei dem Megasat einen sichern SSH-Zugang mit einem änderbaren Standard-Passwort gibt, der auch so in der Anleitung dokumentiert wird (mit der Empfehlung, das Passwort zu ändern). Aber dafür ist wohl kein Geld da. Wie schrieb schon vdr_rossi:

Quote from vdr_rossi

Wer billig kauft, kauft zweimal.

Zum Thema c't: Ja, ich sehe das auch so, dass die Qualität nachgelassen hat. Aus meiner Sicht hat das angefangen, als Heise von monatlich auf alle 2 Wochen als Erscheinungstermin gewechselt hat. Da haben die Redakteure halt nur noch halb soviel Zeit, um zu recherchieren... Auch solche Aktionen wie die Aufkleber in der letzten Ausgabe oder diese komische Nerd-Karte finde ich einfach nur daneben. Allerdings ist die c't für mich noch meilenweit vom Niveau einer ComputerBild entfernt und ich kenne bisher keine bessere Alternative.

Quote

Was mich ärgert ist, dass die Hersteller es immer noch nicht gelernt haben, bei ihren Produkten auf IT-Sicherheit zu achten. Im Gegenteil wurde ja hier wohl aktiv der Passwortschutz deaktiviert. Aber das wird im IoT-Bereich ja scheinbar immer schlimmer, wenn jetzt schon Kühlschränke für DDoS-Attacken genutzt werden...

Leider kann man das bei manchen Firmen wohl nur mit finanziellen Argumenten klären... (Rückgabe des Gerätes)
Akzeptieren darf man offene+ungeschützte LAN Ports schon, aber nicht bei Geräten die ins LAN müssen... (Bei nem BlueRay Player wäre mir das egal)

Quote

Das Netz zu segmentieren, nur weil ein Hersteller Mist baut, da habe ich keine Lust drauf.

Das wird uns wohl nicht auf Dauer erspart bleiben wenn die LANs immer fetter werden.

Man denke mal an die POE-LAN Kamera außen am Haus. Oder wenn irgendwann mal alle Freunde der Verwandten nur noch kommen bei (W)LAN-Zugang, ...
(Und die ganzen seriellen Geräte die man einfach ins LAN trickst (per ESP8266, usw.) oder die Heizung erfordern eh ein eigenes LAN wenn man ehrlich zu sich selbst ist.

PS: Bin mir nicht ganz sicher ob das alle noch OT ist

>> Mein gesamtes System ist auf Sicherheit und OpenSource ausgerichtet: eigene Firewall, extern erreichbare Systeme in der DMZ, Smart-TV über Kodi
(..)
>> über einen internen Angriff (z.B. über einen gehackten Laptop von Freunden) das Teil kompromittiert wird.

Wenn Freunde bei dir ohne weiteres in dein internes Netz kommen, ohne dass du halbwegs sicher bist, dass deren Rechner ok sind, ist das doch keinerlei Sicherheit?

>> Was mich ärgert ist, dass die Hersteller es immer noch nicht gelernt haben, bei ihren Produkten auf IT-Sicherheit zu achten.

Jup, z.Z. geht man am besten bei jedem netzwerkfähigen Gerät von einem Problemfall aus, den man sicher einsperren oder detailliert checken muss.
Die Hersteller haben scheinbar davon keine Ahnung. Am besten wäre für dieses Gerät nur Port 554 TCP, Port 80 TCP sowie jeden UDP Port zu erlauben.

Aber vllt. hilft deine email ja, und der Hersteller rührt sich, dann hätten alle gewonnen.

Quote from wirbel

Aber vllt. hilft deine email ja, und der Hersteller rührt sich, dann hätten alle gewonnen.

Wollte mich hierzu auch mal äußern!

• c't ist IMHO immer noch besser als Computer-Blöd. Allerdings finde ich auch, dass die Artikel nicht mehr so sorgfältig recherchiert sind wie früher einmal.
• Die angesprochene Artikelreihe empfand ich als Alptraum, das habe ich dem verfassenden Redakteur auch gemailt. Und zwar aus verschiedenen Gründen:
• IoT Geräte, die nicht als solche wahrgenommen werden, die von Haus aus aber mit gruseligen Sicherheitslücken aufwarten.
• Eine in einer langen Artikelserie ausgewälzte "Abhilfe" die aus Routerkaskaden, Enterprise-Switches die so laut sind dass man sie in den Keller verbannen muss, Kilometern von zu verlegenden Ethernetkablen und dem weiteren Zuballern des eh schon überlaufenen 2,4GHz Bandes mit zusätzlichen Netzen besteht. Den Installationsaufwand, den Stromverbrauch, den Wartungsaufwand für den Geräteberg dann noch dazugerechnet und das ganze soll dann von Otto Normal-DAU in Betrieb genommen und gehalten werden - geht's noch???
• Als Resultat nur die bessere Absicherung der Sahnestücke des eigenen Netzes, jedoch nicht ein einziger IoT Botnetzmember im Netz weniger.

Was soll das? Dafür treib ich nicht solch einen Aufwand, das ist eine Farce!

Was den MEG-8000 angeht hätte ich folgende Punkte:

• Er scheint - steinigt mich im VDR-Forum - mit tvheadend recht zuverlässig und problemlos zu laufen, mit vdr aber leider nicht. Ich konnte mit vdr nicht ein einziges Bild(!!) aus der Kiste ziehen (mit dem testweise genutzten DBVviewer unter Windoof hingegen schon). Ich hatte mit unzähligen Problemen zu kämpfen bis hin zum Verhalten, dass der bloße Versuch ein Livevideo via VLC/Windoze abzuspielen reproduzierbar den kompletten Linux-Rechner auf dem vdr lief zum Einfrieren brachte.
• Ich habe nach tagelangem(!) Gebastel entnervt aufgegeben, vdr vom Server (Ubuntu) und Client (Raspi mit Kodi) geschmissen und die Sache mit tvheadend neu hochgezogen. Was sol ich sagen, seitdem flutscht die Sache, ich kann live schauen, ich kann mehrere Sender gleichzeitig aufnehmen, ich hatte noch kein schwarzes Bild was sich nur durch Neustart des MEG-8000 lösen lies.
• Die Auswahl an Sat-IP-Servern ist bekanntlich immer noch nicht sehr groß und viele der verfügbaren Server setzen offenbar auf dem Referenzdesign von Astra auf, so auch der MEG-8000. Und alle Refrenzdesign-Implementationen scheinen dieselben Probleme mit Bildausfällen unter vdr zu haben. Egal ob und wie buggy der MEG-8000 bzw. das Astra-Referenzdesign nun auch sein mag, so sollte man sich fragen, ob man nicht vdr bzw. das sat-ip Plugin so überarbeiten könnte/sollte, dass es mit den Unzulägnlichkeiten der Hardware zurechtkommt - Nein, "kauf dir halt vernünftige Hardware anstatt so'n Schrott" zählt nicht als Argument! Nicht jeder kann/will hunderte von Euro für einen Sat-IP-Server ausgeben.
• Nur mit dem Sperren des SSH-Ports im Router ist es natürlich nicht getan (bzw. standardmäßig ist der Port ja eh gar nicht offen). Das Szenario aus der c't ist ein anderes: Sohnemann hängt sein trojanerverseuchtes Smartphone ins Heimnetz, der Trojaner nistet sich daraufhin im MEG-8000 häuslich ein und wird zukünftig Teil des IoT-Botnetzes. Es geht also nicht darum, dass der MEG-8000 ins Internet kommt, sondern darum, dass keiner auf den SSH-Port des MEG-8000 draufkönnen soll, also muss ich das Ding auch zu meinem lokalen Netz abschotten.
• Mein Lösungsvorschlag für die Abschottung des Rootzugangs des MEG-8000 sähe so aus, dass ich dem vdr/tvheadend eine weitere Netzwerkkarte spendiere. An dieser Karte hängt der MEG-8000 direkt ohne Switch und weitere Geräte. Damit ist der Videoserver das einzige Gerät das darauf zugreifen kann und der SSH-Zugang ist ansonsten weggesperrt. Wie das bei VDR ist weiss ich nicht, tvheadend kann selber sat-ip-Server spielen, so dass die restlichen Geräte im Netz nun einfach ihren Server wechseln müssen, ansonsten aber anstandslos weiterarbeiten. Als solches stellt dann die neue Alleinherrschaft des Videoservers über den MEG-8000 auch kein Problem dar. Die Lösung ist simpel, billig und fehlerunanfällig, sie braucht (fast) keinen zusätzlichen Strom, und auch Otto Normal-DAU bekommt das aufgesetzt.
• Anhand des Aufbaus der Verzeichnisstruktur des MEG-8000 frage ich mich ob es sich auch hierbei und ein GPL-System handelt. Ich habe daraufhin versucht bei Megasat einen Link zu finden, über den der Download des Quellcodes möglich ist, bin aber nicht fündig geworden. Liegt hier also ein weiterer Fall von GPL-Verletzung vor, oder worauf basiert die Software des MEG-8000? Würde man die in die Hände bekommen, dann ließen sich Bugs sicherlich lokalisieren und beheben, selbst wenn der Hersteller da keine Arbeit reinstecken will. Und man könnte dem Ding gleich mal eine vernüftige Weboberfläche spendieren und neue/nützliche Funktionen einbauen. Wäre doch mal was, oder?

Cheerz
Don

>>der Trojaner nistet sich daraufhin im MEG-8000 häuslich ein und wird zukünftig Teil des IoT-Botnetzes

das wird wirklich schwierig. Keine x86 oder ARM Architektur, also laufen normale binaries nicht.
Es gibt eine shell und 5MByte schreibbaren Speicher - wenn man weiß wo. Für einen Teil eines botnetztes
fehlt noch eine Sende Möglichkeit per Netzwerk.

>>ob es sich auch hierbei und ein GPL-System handelt.
Die meisten Teile des Systems mit Sicherheit. Beim satip server binary selbst weiß man es nicht.

Quote from wirbel

das wird wirklich schwierig. Keine x86 oder ARM Architektur, also laufen normale binaries nicht.
Es gibt eine shell und 5MByte schreibbaren Speicher - wenn man weiß wo. Für einen Teil eines botnetztes
fehlt noch eine Sende Möglichkeit per Netzwerk.

Hm, security by obscurity hat bekanntlich noch nie funktioniert! Wenn hier die GPL am Werke ist, dann wird zum Bauem von Software mit an Sicherheit grenzender Wahrschienlichkeit der gcc vewendet. Megasat scheint hier BTW mehr oder minder 1:1 einen Entwurf von Abilis und Maxlinear umgesetzt zu haben:
http://www.maxlinear.com/abilis-systems…nected-devices/
Und mit einer Shell und 5 MB Flash kann man schon etwas anfangen. Z. B. kann man schon eine steinalte Fritzbox 7050 mit vergleichsweise winzigen Ressourcen an passender Stelle so beschreiben, dass sie zukünftig bei jedem Neustart automatisch eine Datei aus dem Netz lädt und ausführt. So bekommt man auf dem Kistchen - obwohl gar nicht genug freier Flash vorhanden ist - problemlos eine Busybox ans Laufen, die nur im RAM gehalten wird. Darauf aufbauend kann man dann weitere Schritte veranstalten. Auch hier ist weder ARM noch x86 am Start, sondern MIPS. Das ist aber ziemlich togal, man braucht einfach nur einen GCC der Maschinencode für den jeweiligen Prozessor erzeugen kann und baut sich die benötigten Binaries neu. Ein ähnliches Konzept ist auch für den MEG-8000 denkbar, wenn man sich von den 1GB RAM ein paar MB für einen Bot abknappst fällt das vmtl. niemandem groß auf. Natürlich kann das nicht jeder, aber den entsprechenden Programmierbackground und genügend kriminelle Energie vorausgesetzt sind eine seltene Prozessorarchitektur, wenig Flash und andere "Kleinigkeiten" kein unüberwindbares Hindernis. Schaut man sich an was auf der Kiste läuft, dann sieht man schon einiges:

Mem: 28416K used, 97520K free, 0K shrd, 0K buff, 18184K cached
CPU: 0% usr 4% sys 0% nic 95% idle 0% io 0% irq 0% sirq
Load average: 0.09 0.07 0.06 1/57 20875
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
20567 20559 root R 1520 1% 3% top
587 542 root S 3384 3% 0% /opt/bin/sat2ip_server/sat2ip_tb100.elf
20550 512 root S 1592 1% 0% dropbear
579 542 root S 3384 3% 0% /opt/bin/sat2ip_server/sat2ip_tb100.elf
575 542 root S 3384 3% 0% /opt/bin/sat2ip_server/sat2ip_tb100.elf
543 542 root S 3384 3% 0% /opt/bin/sat2ip_server/sat2ip_tb100.elf
540 1 root S 3384 3% 0% /opt/bin/sat2ip_server/sat2ip_tb100.elf
576 542 root S 3384 3% 0% /opt/bin/sat2ip_server/sat2ip_tb100.elf
577 542 root S 3384 3% 0% /opt/bin/sat2ip_server/sat2ip_tb100.elf
542 540 root S 3384 3% 0% /opt/bin/sat2ip_server/sat2ip_tb100.elf
586 542 root S 3384 3% 0% /opt/bin/sat2ip_server/sat2ip_tb100.elf
584 542 root S 3384 3% 0% /opt/bin/sat2ip_server/sat2ip_tb100.elf
19228 542 root S 3384 3% 0% /opt/bin/sat2ip_server/sat2ip_tb100.elf
20415 542 root S 3384 3% 0% /opt/bin/sat2ip_server/sat2ip_tb100.elf
20404 542 root S 3384 3% 0% /opt/bin/sat2ip_server/sat2ip_tb100.elf
588 542 root S 3384 3% 0% /opt/bin/sat2ip_server/sat2ip_tb100.elf
479 478 root S 2280 2% 0% /opt/bin/mongoose 8000
476 1 root S 2280 2% 0% /opt/bin/mongoose 8000
478 476 root S 2280 2% 0% /opt/bin/mongoose 8000
484 478 root S 2280 2% 0% /opt/bin/mongoose 8000
482 478 root S 2280 2% 0% /opt/bin/mongoose 8000
480 478 root S 2280 2% 0% /opt/bin/mongoose 8000
486 478 root S 2280 2% 0% /opt/bin/mongoose 8000
481 478 root S 2280 2% 0% /opt/bin/mongoose 8000
485 478 root S 2280 2% 0% /opt/bin/mongoose 8000
488 478 root S 2280 2% 0% /opt/bin/mongoose 8000
487 478 root S 2280 2% 0% /opt/bin/mongoose 8000
489 478 root S 2280 2% 0% /opt/bin/mongoose 8000
483 478 root S 2280 2% 0% /opt/bin/mongoose 8000
506 1 root S 1528 1% 0% udhcpc -b -i eth0 -s /etc/udhcpc.conf -p /var/run/udhcpc.eth0.pid -t 3 -T 6 -A 100
512 1 root S 1528 1% 0% dropbear
20559 20550 root S 1520 1% 0% -sh
470 1 root S 1520 1% 0% acpid
259 1 root S 1512 1% 0% syslogd -m 0 -s 1024 -b 3 -L -S
1 0 root S 1512 1% 0% init
515 1 root S 1512 1% 0% ntpd -p pool.ntp.org
597 595 root S 1512 1% 0% sh -c logger
596 1 root S 1512 1% 0% init
598 597 root S 1512 1% 0% logger
261 1 root S 1504 1% 0% klogd
595 1 root S 1152 1% 0% /opt/bin/system-monitor
3 2 root SW 0 0% 0% [ksoftirqd/0]
4 2 root SW 0 0% 0% [kworker/0:0]
2 0 root SW 0 0% 0% [kthreadd]
17 2 root SW 0 0% 0% [kswapd0]
278 2 root SW 0 0% 0% [ubifs_bgt0_0]
270 2 root SW 0 0% 0% [ubi_bgt0d]
16 2 root SW 0 0% 0% [khungtaskd]
6 2 root SW 0 0% 0% [kworker/u2:0]
7 2 root SW< 0 0% 0% [khelper]
10 2 root SW 0 0% 0% [kworker/u2:1]

Hier sind also stinknormale elf-Binaries am Werk. Und dann schaut man noch hier:

[AS-B3S100-Server]$ cat /proc/cpuinfo

ARC IDENTITY : Family [0x34] Cpu-id [0x0] Chip-id [0x270f]
processor : ARC 700 R4.10
CPU speed : 500.00 Mhz
Timers : TIMER1 TIMER0
Vect Tbl Base : 0x80000000
UNCACHED Base : 0xc0000000
Bogo MIPS : 332.54
ARC700 MMU [v3] : 8k PAGE, J-TLB 512 (128x4), uDTLB 8, uITLB 4,
I-Cache : (32K) VIPT, 2way set-asc, 32b Line
D-Cache : (32K) VIPT, 4way set-asc, 32b Line
Extn [700-Base] : norm, barrel-shift, minmax, ext-arith
Extn [700-MPY] : 32x32 (ANY Result Reg) MAC MPY: Dual 16x16 and 32x16
Extn [700-4.10] : LLOCK/SCOND (in-use), SWAPE (in-use), RTSC (not used)
Extn [CCM] : N/A
Extn [FPU] : N/A
OS ABI [v3] : no-legacy-syscalls

Und sieht direkt, dass hier ein ARC 700 am Werke ist. Und als nächstes findet man, dass man für kleines Geld eine komplette Developer Toolchain für die CPU erwerben kann:
https://en.wikipedia.org/wiki/ARC_(proc…are_development
Als solches: Happy hacking, happy coding, dafür muss man keinerlei Eigenaufwand treiben.

Quote from wirbel

>>ob es sich auch hierbei und ein GPL-System handelt.
Die meisten Teile des Systems mit Sicherheit. Beim satip server binary selbst weiß man es nicht.

Korrekt, vmtl. sind hier mal wieder freie Anteile mit einem proprietären Modul vermixt worden. Trotzdem müsste Megasat für den freien Teil eine Downloadmöglichkeit bereitstellen. Tun sie das nicht ist die GPL verletzt und man könnte sie erfolgreich verklagen.

Cheerz

Don

>>security by obscurity

Von Sicherheit hat niemand etwas geschrieben. Also - außer dir - .

>>an passender Stelle so beschreiben, dass sie zukünftig bei jedem Neustart automatisch eine Datei aus dem Netz lädt und ausführt.
Wie? /etc/ ist nicht schreibbar. Alles andere - klar, theoretisch möglich.

Quote from wirbel

Von Sicherheit hat niemand etwas geschrieben. Also - außer dir - .

Naja, ich verstehe deine Argumentation "das wird wirklich schwierig. Keine x86 oder ARM Architektur, also laufen normale binaries nicht." so, dass es schon keiner tun wird, weil's zu schwierig ist und keiner weiß wie's geht. Das ist doch eine Form von Obscurity und eine Form von (vermeintlicher) Security. "Wird wohl nix passieren, es weiß ja keiner wie's geht." interpretier ich jedenfalls so.

Quote from wirbel

Wie? /etc/ ist nicht schreibbar. Alles andere - klar, theoretisch möglich.

Z. B. indem man sich via "less /data/webui/users.txt" die Logindaten zur Web-GUI der Kiste holt (Name/Pwd stehen dort im Klartext drin) und damit dann über die GUI eine manipulierte Firmware flasht. Ja, jetzt kann man auch wieder argumentieren, dass keiner weiß wie die Firmwarefiles aufgebaut ist und dass der MEG-8000 hoffentlich nur Dateien flasht die mit einer Prüfsumme versehen sind. Wie dem auch sei, eine gute alte Admin-Regel besagt, dass man nicht mehr Ports öffnen und mehr Dienste anbieten soll als nötig. Ein sperrangelweit offener SHH-Zugang ohne die Möglichtkeit das abzustellen ist daher aus meiner Sicht - hm - ich sag mal "außerordentlich unerwünscht"...

Hallo zusammen,

hier mal ein Update zum Thema Sicherheit: Nachdem sich Megasat zuerst sehr geziert hat, haben die mir jetzt eine neue Firmware bereitgestellt. Das verdanke ich hauptsächlich dem hartnäckigen Support meines Lieferanten, der hat denen scheinbar mächtig Dampf gemacht. Das ist mal ein extrem positives Beispiel, wie Kundenservice funktionieren kann.

In der neuen Firmware ist der SSH-Zugang zwar noch aktiv, aber der root-Zugang ist jetzt durch ein Passwort geschützt. Ich habe verschiedene Standard-Passwörter ausprobiert und davon hat keines funktioniert. Geht doch!

Hier mal der Link zum Download, auf der Homepage steht die Firmware noch nicht bereit:

https://wetransfer.com/downloads/03f1…15110852/91334f

Ob man die jetzt installiert muss jeder selbst wissen. Damit hat man natürlich keinen root-Zugang mehr. Für mich war dich Sicherheit aber deutlich wichtiger und im System rumbasteln will ich eh nicht.

P.S.: Es wäre natürlich besser gewesen, wenn Megasat einen root-Zugang inkl. Passwort bereitgestellt hätte und das Passwort änderbar wäre. So weiß ich nicht, ob das verwendete Passwort nicht doch zu einfach gewählt wurde. Aber besser so als komplett ohne Passwort.

Quote from HuskyMS

Hallo zusammen,

hier mal ein Update zum Thema Sicherheit: Nachdem sich Megasat zuerst sehr geziert hat, haben die mir jetzt eine neue Firmware bereitgestellt. Das verdanke ich hauptsächlich dem hartnäckigen Support meines Lieferanten, der hat denen scheinbar mächtig Dampf gemacht. Das ist mal ein extrem positives Beispiel, wie Kundenservice funktionieren kann.

In der neuen Firmware ist der SSH-Zugang zwar noch aktiv, aber der root-Zugang ist jetzt durch ein Passwort geschützt. Ich habe verschiedene Standard-Passwörter ausprobiert und davon hat keines funktioniert. Geht doch!

Hier mal der Link zum Download, auf der Homepage steht die Firmware noch nicht bereit:

https://wetransfer.com/downloads/03f1…15110852/91334f

Ob man die jetzt installiert muss jeder selbst wissen. Damit hat man natürlich keinen root-Zugang mehr. Für mich war dich Sicherheit aber deutlich wichtiger und im System rumbasteln will ich eh nicht.

Display More

Hi.

Danke für die Info.

Kannst du bitte mal prüfen ob jetzt die Unicable unterstützen einbaut haben?

Danke und Gruß.

Leider nein, immer noch nur Quattro, Quad und "One user per RF"

Quote from HuskyMS

Leider nein, immer noch nur Quattro, Quad und "One user per RF"

Schade. Danke für deine Info.

Danke und Gruß.

Quote from HuskyMS

P.S.: Es wäre natürlich besser gewesen, wenn Megasat einen root-Zugang inkl. Passwort bereitgestellt hätte und das Passwort änderbar wäre. So weiß ich nicht, ob das verwendete Passwort nicht doch zu einfach gewählt wurde. Aber besser so als komplett ohne Passwort.

Auch das geht, also zumindest temporär. Zumindest solange man selbst noch als root auf die Kiste drauf kommt.
Auf /data eine neu kompilierte Version von busybox hochladen, mit chmod +x ausführbar machen und einen
symbolischen Link /data/passwd -> /data/busybox anlegen. Danach /data/passwd ausführen und ein passwort vergeben.

Beim nächsten reboot allerdings ist die Kiste dann wieder offen, da /etc nicht schreibbar ist und nur als ramdisk lebt.

Hallo zusammen,

auf der Megsat-Webseite ist mittlerweile eine neue Firmware vorhanden. Es ist die Version: 3.1.13

Gruß Fadi

Quote from fadi2013

Hallo zusammen,

auf der Megsat-Webseite ist mittlerweile eine neue Firmware vorhanden. Es ist die Version: 3.1.13

Gruß Fadi

Nach dem Flash erfreut festgestellt, dassder Login über SSH nicht mehr mit einem beliebigen Passwort funktioniert, aber das eingestellte war nicht wirklich schwer zu erraten. Schon beim 2. Versuch hatte ich Erfolg: "MEG-8000". Passwortänderung ging zwar über SSH, der Server war auch danach nur noch über das neue Passwort erreichbar, aber nach einem Reboot war es wieder das Standardpasswort. Die anfängliche Freude war wieder dahin... Ein nicht (dauerhaft) änderbares (für alle Server gleiches) Passwort ist genauso gut wie kein Passwort

cu
Markus

Quote from fadi2013

auf der Megsat-Webseite ist mittlerweile eine neue Firmware vorhanden. Es ist die Version: 3.1.13

Äh, hab ich was verpasst? Die Version 3.1.13 ist doch schon am 16. Januar 2017 erschienen, oder nicht?!

Quote from AnK

Äh, hab ich was verpasst? Die Version 3.1.13 ist doch schon am 16. Januar 2017 erschienen, oder nicht?!

Nö. Erst seit Juni.