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

  • [...] 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.


    [...] 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

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • ..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.



    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.


    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:

    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.

    Server HW: Intel DH67BL | Celeron G530 | 4GB RAM | 60 GB SSD | 1 TB HDD | DVBSky S592; SW: EasyVDR 3.0
    Client HW: Intel NUC DN2820FYK; SW: EasyVDR 3.0

  • 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.

  • 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.

  • 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/abili…-to-ip-connected-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/…sor)#Software_development
    Als solches: Happy hacking, happy coding, dafür muss man keinerlei Eigenaufwand treiben.

    >>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.

  • 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.

    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. :tup


    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! 8)


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


    https://wetransfer.com/downloa…316920170515110852/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.

    Server HW: Intel DH67BL | Celeron G530 | 4GB RAM | 60 GB SSD | 1 TB HDD | DVBSky S592; SW: EasyVDR 3.0
    Client HW: Intel NUC DN2820FYK; SW: EasyVDR 3.0

  • 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.

    Server HW: Intel DH67BL | Celeron G530 | 4GB RAM | 60 GB SSD | 1 TB HDD | DVBSky S592; SW: EasyVDR 3.0
    Client HW: Intel NUC DN2820FYK; SW: EasyVDR 3.0

  • Hi.


    Danke für die Info.


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


    Danke und Gruß.

  • 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.


  • 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

  • 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?! :schiel

    HW I: Thermaltake DH 202, Intel DH67BL, Intel Pentium G630, TT Premium S2-6400, Crucial m4 SSD,
    Fortron Source Aurum Gold 400W, Scythe Big Shuriken, LG DVD-RW GH22NS50, Kingston ValueRAM 4GB

    HW II: A+case Cupid 2, Intel D945GSEJT, 512 MB RAM, 2x PCI Riser, Atric IR-Einschalter Rev. 5,
    Hauppauge Nexus Rev 2.2, 60W 12V/DC, Slimline Samsung DVD-RW, CF/SATA-Adapter, 4 GB CF Card