| Kopie des easyVDR-Forums zum Nachschlagen | |
easyVDR - >VARforumsname - >easyvdr: Auffallend unsicher
| mpcww 24.Nov.2018 14:11:14 |
| In den letzten Tagen habe ich die verschiedenen Instanzen in meinem Heimnetz einem Sicherheitsscan unterzogen. Dazu habe ich [url=https://www.bsi.bund.de/DE/Themen/Cyber-Sicherheit/Tools/OpenVAS/OpenVAS.html]openVAS benutzt. Erstaunt war ich, dass bereits bei der 3.0 im Vergleich mit anderen Debian-basisierten Installation größere Sicherheismängel festgestellt wurden, die letztendlich mit Gesamt-"Severity"=High bewertet wurden. Ursächlich scheint hier insbesondere die alte lhttpd-Version zu sein. Auch im "medium"-Bereich finden sich bei den verwendeten SSL-Eigenschaften einige Probleme. [url=https://imagenes.maquena.org/fts/#15430668507386]Screenshot Ergebnisübersicht Ein Rescan gegen die Version 3.5 hat hier keine Verbesserung gebracht. Auch ein Heimnetz ist nur so start, wie das schwächste Glied in der Kette ! Einen aktuellen Report des Vulnerabilty-Scanners gebe ich hier als Attachment mit, so dass diese "Schwächen" in 4.0 vermieden werden können. report-d7578455-3a6a-4959-9446-51683fa8c347.pdf report-d7578455-3a6a-4959-9446-51683fa8c347.txt Software: easyVDR (3.5.02-stable, VDR-Version: 2.2.0-12easyVDR1~trusty, Kernel-Version:4.4.0-96-generic Hardware: MSI MS-7636, Intel i3, Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 |
| Bleifuss2 24.Nov.2018 20:09:07 |
| Hi Nun ja der VDR ist ja im Normalfall nicht von außen erreichbar (DSL/Kabel Router). Wer da natürlich ohne VPN Ports freigibt hat ein Risiko. Solange du nicht alle Passwörter änderst sind die Lücken immer noch das kleinste Problem ... Was könnte Passieren? Hackerangriff, wäre wenn die Ports im Router offen sind sicher erfolgreich (schon deshalb weil die Passwörter bekannt sind). Virus? Der müsste dann von einem anderen PC im Netzwerk kommen, nur denke ich du nutzt Windows, da müsstest du einen Java Virus haben und der müsste noch zufällig zu den Sicherheitslücken passen. Viel wahrscheinlicher, zu ziehst dir in Windows / Android/ MACOS einen Virus, der verschlüsselt über das Netzwerk deine VDR Filme (aber auch nur wenn du im VDR die Daten freigegeben hast) Wenn du mal mit Wireshark an die Sache gehst wirst du noch feststellen keine verschlüsselte Verbindungen. Wenn du mal richtig schlimme Sachen sehen willst, dann Kali Linux auf SmarTv oder Verstärker, Reciver loslassen. Auch Smarhome Steuerungen,Kameras und Heizungen sind da erstaunlich. Gruß Bleifuss Produktiv-VDR: Board GA H77-DS3H, Intel Intel(R) Core(TM) i5-3470, Cine S2 DVB, WD 3TB Green, WDC WD20EARS-00J 2TB, Geforce 750Ti oder Intel HD Easyvdr 3.0 |
| mpcww 25.Nov.2018 15:11:29 |
| [quote='Bleifuss2' pid='182423' dateline='1543086547'] Wenn du mal mit Wireshark an die Sache gehst wirst du noch feststellen keine verschlüsselte Verbindungen. Wenn du mal richtig schlimme Sachen sehen willst, dann Kali Linux auf SmarTv oder Verstärker, Reciver loslassen. Auch Smarhome Steuerungen,Kameras und Heizungen sind da erstaunlich. ok, ich würde konkret die gefundenen Schwachstellen angehen: lighttpd-Version ... Aber grundsätzlich nehme ich mit VDR erstmal auf ein isoliertes Fernsehen zu reduzieren und möglichst alle weiteren (schwach bzw. unverschlüsselten) Dienste zu stoppen: Aktuell sind folgende Dienste aktiv: Aktive Internetverbindungen (Nur Server) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name tcp 0 0 0.0.0.0:4200 0.0.0.0:* LISTEN 0 15157 1558/shellinaboxd tcp 0 0 0.0.0.0:60810 0.0.0.0:* LISTEN 121 13144 709/rpc.statd tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 13781 700/rpcbind tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 0 10053 1630/lighttpd tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN 0 18590 2063/dnsmasq tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 15151 1230/sshd tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 0 20676 3198/cupsd tcp6 0 0 :::111 :::* LISTEN 0 13784 700/rpcbind tcp6 0 0 :::45364 :::* LISTEN 121 13148 709/rpc.statd tcp6 0 0 :::22 :::* LISTEN 0 15153 1230/sshd tcp6 0 0 ::1:631 :::* LISTEN 0 20675 3198/cupsd udp 0 0 0.0.0.0:631 0.0.0.0:* 0 19875 1332/cups-browsed udp 0 0 0.0.0.0:47783 0.0.0.0:* 121 13142 709/rpc.statd udp 0 0 0.0.0.0:826 0.0.0.0:* 0 13780 700/rpcbind udp 0 0 127.0.0.1:885 0.0.0.0:* 0 13138 709/rpc.statd udp 0 0 0.0.0.0:5353 0.0.0.0:* 111 14969 1098/avahi-daemon: udp 0 0 0.0.0.0:8091 0.0.0.0:* 0 14281 1809/dhclient udp 0 0 127.0.1.1:53 0.0.0.0:* 0 18589 2063/dnsmasq udp 0 0 0.0.0.0:68 0.0.0.0:* 0 16582 1809/dhclient udp 0 0 0.0.0.0:51287 0.0.0.0:* 111 14971 1098/avahi-daemon: udp 0 0 0.0.0.0:111 0.0.0.0:* 0 13777 700/rpcbind udp6 0 0 :::826 :::* 0 13783 700/rpcbind udp6 0 0 :::39766 :::* 121 13146 709/rpc.statd udp6 0 0 :::37996 :::* 0 14282 1809/dhclient udp6 0 0 :::5353 :::* 111 14970 1098/avahi-daemon: udp6 0 0 :::42287 :::* 111 14972 1098/avahi-daemon: udp6 0 0 :::111 :::* 0 13782 700/rpcbind Falls ich "nur" den vdr mit lokaler Aufnahmefunktion nutzen will: Sprichte tewas dagegen die rpc-Dienste, cups und lighttpd zu deaktivieren ? Alternative könnte ich auch eine FW aufsetzen, die nur noch ssh-Verbindungen zulässt. So wäre der Rechner als "Schwachstelle" gut abgeschottet. Software: easyVDR (3.5.02-stable, VDR-Version: 2.2.0-12easyVDR1~trusty, Kernel-Version:4.4.0-96-generic Hardware: MSI MS-7636, Intel i3, Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 |
| Bleifuss2 25.Nov.2018 15:33:15 |
| Hi Verstehe ich dich richtig,du willst da was updaten? Wenn ja kannst du das gerne in der Distrie machen, dann haben alle was davon. Gruß Bleifuss Produktiv-VDR: Board GA H77-DS3H, Intel Intel(R) Core(TM) i5-3470, Cine S2 DVB, WD 3TB Green, WDC WD20EARS-00J 2TB, Geforce 750Ti oder Intel HD Easyvdr 3.0 |
| mpcww 25.Nov.2018 15:47:39 |
| Hi, nein, kein update einfach alle nicht benötigten Dienste auschalten oder und den Rechner per iptables bis auf port 22 abschotten. Den Zugang aber beschränken auf wenige Rechner, idealerweise ohne Passwort, nur publickey, kein root-login .... Passwörter habe ich tlw. geändert, aber es ist nicht einfach, alle Stellen zu finden. Z.B. reicht es nicht aus eayvdr-pw in der shell zu ändern, es ist weiterhin gültig im http-VDR-Portal. Software: easyVDR (3.5.02-stable, VDR-Version: 2.2.0-12easyVDR1~trusty, Kernel-Version:4.4.0-96-generic Hardware: MSI MS-7636, Intel i3, Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 |
| mpcww 25.Nov.2018 16:37:22 |
| An drei Schrauben habe ich zunächst gedreht: A) Für mich überflüssige Dienste deaktivieren: Ich habe versucht mit sudo update-rc.d -f lighttpd remove sudo update-rc.d -f cupsd remove sudo update-rc.d -f shellinabox remove sudo update-rc.d -f rpcbind remove sudo update-rc.d -f nmbd remove für mich überflüssige Dienste zu deanktivieren: [*]lighttpd und shellinabox sind damit kein Thema mehr, d.h. über http ist der Rechner nicht mehr erreichbar :) [*]samba, cups und rpc sind aber nach einem Neustart wieder aktiv. Wie deaktivierie ich samba ? Z.B. habe ich über "setup->Netzwerk->Samba" geprüft. Dort ist "Starte Samba" nicht aktiviert. Woher kommen die nmbd und smbd - Dienste ? Es bleibt eine komische Fehlermeldung beim Systemstart "load_image_gtk" kann Verzeichnis oder Datei nicht finden . Sie stört aber nicht den Betrieb. Woher kommt diese Meldung ? B. ssh-Zugang "härten": Nachdem ich einen gültigen Schlüssel für den Nutzer easyvdr auf dem Rechner installiert habe, habe ich die Konfiguration in /etc/ssh/sshd_config angepasst: ChallengeResponseAuthentication no PasswordAuthentication no UsePAM no C. Per FW: Nur noch port 22 zulassen und nur für internes Netz öffnen: Per iptables erlaube ich nur noch den ssh-Zugriff aus den internen Netzen: aptitude install iptables-persistent mit folgenden Regeln: Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 0 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT tcp -- 192.168.3.0/24 0.0.0.0/0 tcp dpt:22 ACCEPT tcp -- 192.168.1.0/24 0.0.0.0/0 tcp dpt:22 REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 Software: easyVDR (3.5.02-stable, VDR-Version: 2.2.0-12easyVDR1~trusty, Kernel-Version:4.4.0-96-generic Hardware: MSI MS-7636, Intel i3, Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 |
| Bleifuss2 25.Nov.2018 17:18:53 |
| Das sind vermutlich Upstart Dienste, vielleicht kann man es auch einfach deinstallieren ... Ansonsten Wiki ubuntu Upstart, da sollte beschrieben sein wie man das deaktiviert. Produktiv-VDR: Board GA H77-DS3H, Intel Intel(R) Core(TM) i5-3470, Cine S2 DVB, WD 3TB Green, WDC WD20EARS-00J 2TB, Geforce 750Ti oder Intel HD Easyvdr 3.0 |
| mpcww 25.Nov.2018 19:15:47 |
| Ein Test ergab schon ein deutlich besseres Abschneiden beim openVAS - Security -Scan. Nun habe ich für ssh die schwachen 'encryption methods' herausgenommen (in /etc/ssh/sshd.conf): # Remove dsa hostkeys HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ecdsa_key KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr Macs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256 PermitRootLogin No Ein Vorabtest der ssh-Verbindung ergibt nun folgenden Stand: # general (gen) banner: SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.11 (gen) software: OpenSSH 6.6.1p1 (gen) compatibility: OpenSSH 6.5+, Dropbear SSH 2013.62+ (gen) compression: enabled (zlib@openssh.com) # key exchange algorithms (kex) curve25519-sha256@libssh.org -- available since OpenSSH 6.5, Dropbear SSH 2013.62 (kex) ecdh-sha2-nistp521 -- using weak elliptic curves `- available since OpenSSH 5.7, Dropbear SSH 2013.62 (kex) ecdh-sha2-nistp384 -- using weak elliptic curves `- available since OpenSSH 5.7, Dropbear SSH 2013.62 (kex) ecdh-sha2-nistp256 -- using weak elliptic curves `- available since OpenSSH 5.7, Dropbear SSH 2013.62 (kex) diffie-hellman-group-exchange-sha256 -- using custom size modulus (possibly weak) `- available since OpenSSH 4.4 # host-key algorithms (key) ssh-rsa -- available since OpenSSH 2.5.0, Dropbear SSH 0.28 (key) ecdsa-sha2-nistp256 -- using weak elliptic curves `- using weak random number generator could reveal the key `- available since OpenSSH 5.7, Dropbear SSH 2013.62 (key) ssh-ed25519 -- available since OpenSSH 6.5 # encryption algorithms (ciphers) (enc) chacha20-poly1305@openssh.com -- available since OpenSSH 6.5 `- default cipher since OpenSSH 6.9. (enc) aes256-gcm@openssh.com -- available since OpenSSH 6.2 (enc) aes256-ctr -- available since OpenSSH 3.7, Dropbear SSH 0.52 # message authentication code algorithms (mac) hmac-sha2-512-etm@openssh.com -- available since OpenSSH 6.2 (mac) hmac-sha2-256-etm@openssh.com -- available since OpenSSH 6.2 (mac) hmac-sha2-512 -- using encrypt-and-MAC mode `- available since OpenSSH 5.9, Dropbear SSH 2013.56 (mac) hmac-sha2-256 -- using encrypt-and-MAC mode `- available since OpenSSH 5.9, Dropbear SSH 2013.56 # algorithm recommendations (for OpenSSH 6.6.1) (rec) -ecdh-sha2-nistp521 -- kex algorithm to remove (rec) -ecdh-sha2-nistp384 -- kex algorithm to remove (rec) -ecdh-sha2-nistp256 -- kex algorithm to remove (rec) -ecdsa-sha2-nistp256 -- key algorithm to remove (rec) +aes128-ctr -- enc algorithm to append (rec) +aes128-gcm@openssh.com -- enc algorithm to append (rec) +aes192-ctr -- enc algorithm to append (rec) -hmac-sha2-512 -- mac algorithm to remove (rec) -hmac-sha2-256 -- mac algorithm to remove (rec) +umac-128-etm@openssh.com -- mac algorithm to append Und noch einen kleineren Mangel bereinigt: To disable TCP timestamps on linux add the line 'net.ipv4.tcp_timestamps = 0' to /etc/sysctl.conf. Execute 'sysctl -p' to apply the settings at runtime. Für die easyvdr 4.0 lässt sich das bestimmt noch feinfühliger Einstellen, aber der Aufwand erscheint mir doch nicht unlösbar. Mit meiner Holzhammermethode habe ich nun jedenfalls keine "findings" mehr (s. Report in der Anlage). report-7008b056-223b-442e-a283-d23e14e820c8.pdf Software: easyVDR (3.5.02-stable, VDR-Version: 2.2.0-12easyVDR1~trusty, Kernel-Version:4.4.0-96-generic Hardware: MSI MS-7636, Intel i3, Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 |
| mango 25.Nov.2018 20:48:30 |
| Hi! [quote='mpcww' pid='182447' dateline='1543169747'] Für die easyvdr 4.0 lässt sich das bestimmt noch feinfühliger Einstellen, aber der Aufwand erscheint mir doch nicht unlösbar. Ja, kein Samba kein Web-If(lighttpd und shellinabox) usw. ..wäre es nicht sinnvoller, gleich das Netzwerkkabel nach install vom VDR zu trennen?? :s :s Gruss Wolfgang [spoiler="My VDR Stuff"]DVB-S/S2: Silverstone LC17 mit 8,4" TFT Display, ASUS P5KPL SE, E6300, 2GB, NT-Fanlees, System SSD 40GB, Media 2TB, GT630, DVD-LG, SkyStar S2, Nova-T, FB X10 Medion-Scroll, "Arch-Linux - VDR 2.3.8" Test-VDR: ASRock ALiveNF6G, AMD X2 3800+ (35W),4GB, GT 630 - nvidia-384, SSD 64GB, SkyStar S2, Cinergy T RC USB, easyVDR 3.5(Kernel-4.4.0) - VDR-2.3.8 - KODI-18.0 - FB X10 Medion-Scroll Client: Evo N600c, Puppy-Slacko 6.3 - VDR-2.2.0 - FB X10 Medion_OR25V Spielwiese: RPI2 als Client mit LibreELEC-9.80-Milhouse(Kodi-19.0) - MLD-5.4 VDR2VDR |
| mpcww 25.Nov.2018 21:06:24 |
| [quote='mango' pid='182449' dateline='1543175310'] Hi! [quote='mpcww' pid='182447' dateline='1543169747'] Für die easyvdr 4.0 lässt sich das bestimmt noch feinfühliger Einstellen, aber der Aufwand erscheint mir doch nicht unlösbar. Ja, kein Samba kein Web-If(lighttpd und shellinabox) usw. ..wäre es nicht sinnvoller, gleich das Netzwerkkabel nach install vom VDR zu trennen?? :s :s Gruss Wolfgang Samba ist für nicht Windows-Nutzer tatsächlich nicht notwendig. Ich ziehe den gehärteten ssh-Zugang dem fancy shellinsthebox, was ja keinen Mehrwert bringt, vor. lighttpd ist wirklich eine alte, unsichere Version. Falls Ubuntu dieses Softwarepakete nicht aktuell hält und auf Sicherheit achtet, ist vielleicht ein anderer Werbserver (nginx ?) besser geeignet. Vielleicht sogar eine andere Distri ? SSL sollte grundsätzlich eingerichtet sein. Jedes NAS bringt das im Heimnetz mit. Wie gesagt. Ich bin zufrieden, so wie es jetzt ist und hoffe auf Verbesserungen in 4.0. Die obigen Konfigurationsschrtte und Test sind für 4.0 doch kein Unmöglichkeit, oder ? Software: easyVDR (3.5.02-stable, VDR-Version: 2.2.0-12easyVDR1~trusty, Kernel-Version:4.4.0-96-generic Hardware: MSI MS-7636, Intel i3, Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 |
| geraldkainz 26.Nov.2018 00:03:45 |
| Hi, Ich denke ich muß da auch meine Erfahrungen teilen.. Einerseits sind Linux basierte Rechner die im internen Netz werkeln sicherheitsmäßig hintanzustellen, das wäre die Grundidee dieser "ganz miserablen" security-policy von EasyVDR, weil Maßnahmen zur Sicherheit nur dann Sinn machen wenn sie auch notwendig sind. Es sei denn man macht, wie bereits Peter bemerkte, vom Gateway aus Portforwards direkt zu diesen internen "Schwachstellen", dann trägt man aber selbst die Verantwortung und sollte wissen wie man den EasyVDR genügend absichert. Sobald ein Rechner als Gateway fungiert ist die Sache natürlich eine komplett andere. Ich betreibe seit Jahren sorgenfrei einen Easyvdr 2.5 als Gateway, Webserver, Mailserver, sshServer, Hausautomationsserver und Streamingserver und andere Dienste mit fixer externer IP Adresse. Ein nmap scan sagt mehr als tausend Worte. Die Angiffe aus aller Welt laufen rund um die Uhr, hauptsächlich brute force attacs. Natürlich habe ich eine kleine Firewall laufen, aber die einzig wichtige Sicherung des Systems waren gute Passwörter. Um den Rest kümmert sich der Kernel, und der war bei Easyvdr 2.5 --kurz nachschauen.. 3.12.0-7-generic, also aus heutiger Sicht völlig veraltet :-) Ich empfehle jetzt zwar nicht jedem Neuankömmling EasyVDR als Gateway einzusetzen, aber das soll nur zeigen daß sogesehen die Möglichkeit für Netzwerk-internen Angriff auf Ubuntu-basierte Systeme zu vernachlässigen ist. gute N8 ! gerrry 1) Wohnzimmer: Easyvdr 4, AsRock J4105, DD Cine S2 (rev 6.5), Serielle IR FB an com1/ttyS0 2) Schlafzimmer: Easyvdr 3.5, IntelAtom 330, 2x1,6Ghz, 2GbRam, GeForce 9400, Cine S2 (rev5.5), Serielle IR FB an com1/ttyS0 3) Headless streaming Server: Easyvdr 3.0, Compaq DC 7800SFF,2x 2,66GHz,4GbRam,2x DD CineS2 Rev5.5 4) Kellersauna-TV mit Raspberrypi4 und NOOBS (OSMC mit PVR-VNSI Streaming Client und Raspbian Stretch als Dualbootsystem ) |
| Bleifuss2 26.Nov.2018 08:01:15 |
| Guten Morgen Nur zur Info, wer eine aktuelle Fritzbox hat kann ohne Probleme ein VPN erstellen, ist aber etwas langsam, ich denke bei meiner ist so bei 20MBit Schluss. Jetzt noch eine ernsthafte Frage, warum willst du Easyvdr so absichern, betreibst du ihn ein einem öffentlichen Netz? Oder ist es mehr cool das ich das kann (auch wichtig so lernt man was)? Normal hat man ja heute eh schon 2 Netze zuhause, einmal das normale, dann ein Wlan für Gäste, das kann jeder Router. Damit ist man komplett getrennt. Und solltest du den VDR tatsächlich über Internet nutzen wollen, dann würde ich eine Firewall dazwischen schalten, schon deshalb weil du da prüfen kannst was läuft. Pfsense ist da recht gut. Und mehr als SSH würde ich da auch nicht freigeben (da kann man so ziemlich alles tunneln), lieber VPN. Gruß Bleifuss Produktiv-VDR: Board GA H77-DS3H, Intel Intel(R) Core(TM) i5-3470, Cine S2 DVB, WD 3TB Green, WDC WD20EARS-00J 2TB, Geforce 750Ti oder Intel HD Easyvdr 3.0 |
| mpcww 26.Nov.2018 12:27:53 |
| Ausgangspunkt war ein Scan aller Geräte im Heimnetz : Arbeitsplatz-Rechner, NAS, MPD-Server, 2. Firewall, WEB-Server, DNS-Filter und VPN-Proxy ....) . Für alle rein internen Server gelten die gleichen "Risikoabwägungen" oder Unwahrscheinlichkeiten. Was "interne genutzte" Geräte belangt: Es gibt auch genügend kritische Artikel zu smarten Fertig-TVs bezüglich Sicherheit oder ein anderes Thema: Datenschutz . Unabhängig von solchen Betrachtungen war der VDR beim openVAS-Scan im Vergleich deutlich aus der Reihe gefallen. Distribution easyvdr Die Situation bei easyvdr 3.0/3.5 würde sich m.E. leicht entspannen durch 2 einfache Maßnahmen: - lighttp aktualisierte Version: Geht aber wohl mit den Ubuntu-Quellen für trusty nicht (nur das meine ich mit veraltet). - in sshd.conf : HostKey /etc/ssh/ssh_host_dsa_key entfernen Bei einem so geringen, überschaubaren Aufwand mache ich persönlich keine weiteren "Wahrscheinlichkeitsabwägungen" . Als "Distributor", wenn auch basierend auf Ubuntu, würde ich leicht vermeidbare Schwächen auch abstellen. Deswegen erwarte ich keine Verbesserung in 3.5 aber in 4.0: lighttpd wird aktuell sein, und dsa-keys bei ssh zu vermeiden ist kein Hexenwerk. Vergleicht klappt es ja sogar mit grundsätzlichem https. Anwendung/individuelle Konfiguration Jeder Anwender kann natürlich sein Netz so absichern oder öffnen wie es seinen Bedürfnissen/Erfahrungen/Risikofreude entspricht. Von einer "eierlegenden Wollmilchsau" (Web, Mail, Multimedia ... -Server) halte ich ehrlich gesagt nicht so viel, unabhängig, wo sie im Netz integriert ist. Ich sichere grundsätzlich bei jeder unabhängigen Hardware (auch im internen Netz) Webzugriff mit SSL und erlaube SSH-Zugänge nur per public-key-Zugriff. Das ist auch kein großer Aufwand, aber individuelle Konfiguration und nicht unbeding Job der Distribution. Nicht jeder Angriff muss immer durch die Fritzbox erfolgen. Er kann auch von einem anderen internen Gerät ausgehen. Dienste, die ich nicht brauche, versuche ich abzuschalten oder nicht freizugeben (hier Samba). Wegen der Paketabhängigkeiten z.B. zu Kodi läßt sich Samba wohl nicht deinstallieren. Hier finde ich es trügerisch, dass WebUI und setup samba nicht aktiviert anzeigen, es aber wegen der Kodi-Abhängigkeit aktiv ist (nmbd,smbd). Software: easyVDR (3.5.02-stable, VDR-Version: 2.2.0-12easyVDR1~trusty, Kernel-Version:4.4.0-96-generic Hardware: MSI MS-7636, Intel i3, Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 |
| mpcww 05.Dec.2018 10:46:17 |
| Gerade bin ich noch auf ein schönes Beispiel gestoßen, warum jeder Rechner im Heimnetz nicht mit unnötigen Risiken betrieben werden sollte. [url=https://m.heise.de/security/meldung/Totale-Kontrolle-Multifunktions-Drucker-ueber-Fax-angreifbar-4135522.html]Totale Kontrolle: Multifunktions-Drucker über Fax angreifbar Vielleicht hilft es meine Sichtweise zu verstehen: "Brückenköpfe" ins Heimnetz zu minimieren. Software: easyVDR (3.5.02-stable, VDR-Version: 2.2.0-12easyVDR1~trusty, Kernel-Version:4.4.0-96-generic Hardware: MSI MS-7636, Intel i3, Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 |
| zzzözzz 05.Dec.2018 18:16:54 |
| ..na ja, vielleicht sollte ein Anwender aber auch eine Video-rekorder Firmware nicht kit einer Festung für den Betrieb als Desktop verwechseln. |
| Martin 05.Dec.2018 20:42:14 |
| Also ich finde den Beitrag gut. Hinweise sind immer gut. Wenn wir etwas davon vernünftig umsetzen können ist doch gut. Ob/wer den Aufwand zum Webserver treibt wird sich zeigen. Ich gehe erst mal davon aus was Canonical uns liefert ist gut genug. Aber es spricht ja nichts dagegen das noch besser zu machen. An dem Beispiel: Wenn jemand ein konkretes PPA mit besserem Stand nennt ist kann (aus technischer Sicht, nicht aus Sicht einer getesteten Distrie) sowas sehr kurzfristig bereitgestellt werden (falls jemand Zeit + Lust hat das aufzugreifen). Grüße Martin ----------------------------------------------------------------------------------------------------------- [url=http://wiki.easy-vdr.de/index.php/Hilfe]Du brauchst Hilfe? Wir brauchen Daten! English-Version: Don't eat yellow snow! Meine VDRs (Spoiler klicken) VDR1: ASROCK Q1900M, 4GB, SSDs als Bootplatte, Bild+Ton aus Geforce 720, easyVDR3.x als Streamdev- und SatIP Client VDR2: Esprimo, 2GB, NVIDIA Ausgabe per HDMI, kein GraphTFT am VGA Anschluss, easyVDR3.x als Streamdev-Client VDR3: Activy350; SW: Gen2VDR Activy-Edition SERVER: Asrock Q170M vPro, Core i5-6600K, Cine S2 V4 mit 4 S2-Tunern, 16GB Corsair, 4*4TB WD-RED, 240 GB SSD, 19" Gehäuse Clients: Motorola VIP 19xx, Handys und Tablets |
| maxprox 22.Dec.2018 23:01:59 |
| Das Thema Sicherheit ist immer wieder so eine Sache... erst mal Danke an dich, mpcww, für den Tipp mit openVAS, das sieht sehr interessant aus, werde die nächsten Tage mal eine Testinstallation durchführen (eher nicht um den VDR zu scannen). Sicher sollte man gerade als Linux user das Thema Sicherheit immer sehr ernst nehmen und Sicherheitslücken sollte es kein geben. ABER: zB habe ich ein Multifunktionsgerät von HP (M477fdw) trotzdem interessiert mich die FAX Lücke nicht, weil die Faxfunktion nicht genutzt wird, und nicht mal ein Telefonkabel angeschlossen ist, so banal wie einfach. Ein 16stelliges PW hilft mir nur an der einen Stelle, wo das PW benötigt wird, hab ich im Netz einen User, der einen Trojaner einspielt, und habe ich dann im LAN, wegen solcher dreckst HP Teile, die im Jahr (fast) 2019 nur das unverschlüsselte SMB 1.0 (unglaublich aber wahr und - wie ich finde - 1000fach schlimmer als die FAXLücke) können, eben nur SMB1 am Laufen, wäre denkbar, dass das 16stellige PW schnell ausgelesen ist.... usw. usw. Also noch mal: Sicherheit wird ein immer wichtigeres Thema, dabei ist ABER immer der Weg des Schädlings zu betrachten: "wie kommt die Schadsoftware in mein System oder mein Netz?" Ein direkt am Initernet hängender XP Rechner ist wohl im Schnitt nach wenigen Minuten übernommen (Stichwort Honeypot) ich möchte nicht wissen, wie viele XP Rechner heute immer noch problemlos in einer Art Sanbox laufen In diesem Sinne: Holzauge sei Wachsam ;-) easyVDR 5 auf: Digital Device Cine S2 V7; alter Terra-PC, FUJITSU D3041-A1, Pentium Dual-Core E5800 3.20GHz; 6GB RAM, NVIDIA GT-710 von PNY; IR-USB Selbstbau + Logitech Harmony + Funkverlängerung, 7,5m HDMI Kabel zum TV, Headless im Keller 24/7 weil gleichzeitig BackupPC |
| SurfaceCleanerZ 23.Dec.2018 13:30:12 |
| Hi, Geldautomaten nutzen oft XP... (ok sind wohl nicht richtig online sondern in eigenem Netz und die Betreiber bezahlen fleißig für den extended Support, da sie den Wechsel auf gepflegte OS verpennt haben). Aber Recht hast du: Mein Smart-TV hat auch keinen Zugriff... Aber wievel Promille der Nutzer juckt das? SMB1 ist ein Thema für sich, AVM nutzt das wohl auch immer noch nur. MfG, Stefan Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, Mygica t230 Stick als Tuner, nvidia Slim-GT218 512MB PCIe x1 - v3.5-64 VDR2 in Rente VDR3 in Rente VDR4: MSI G31M2 v2, Intel E5200, 6" t6963c gLCD, 2GB, WD Red 4TB, 2x TT3200, ASUS GT730-SL-2GD3-BRK, mod. Digitainergeh. - v3.5-64 VDR5: GIGABYTE GA-G31M-S2L, Intel E5200, GT630 passiv, 2GB, 3TB, 6" t6963c gLCD, mod. Digitainergeh. - v3.5-64 VDR6: MSI MS-7236, Intel E2140, GT630 passiv, 2GB, WD Green 2TB, 6" t6963c gLCD, 2x TT3200 - v2.5-64 [url=http://tinyurl.com/ycx4qsv]Hilfe gefällig? Dann brauchen wir ein easyInfo aus easyPortal! |
| rost21A 25.Dec.2018 19:36:26 |
| Hallo Zusammen Ich möchte niemandem einen Vorwurf machen, EasyVDR ist ein fantastisches System! Herzlichen Dank für die vielen geleisteten Arbeitsstunden!!! Ich kann dem Ersteller dieses Beitrags nur zustimmen. Warum soll EasayVDR niemals von Aussen zugänglich sein? EasyVDR sollte unabhängig von Betriebssystemen im Netzwerk einsetzbar sein (ich nutze zwar nur Linux, aber ob das überall zutrifft?) Warum nicht sicher machen, wenn es relativ einfach machbar ist und keine wesentlichen Nachteile einbringt? Ansonsten sollte man die Nutzer deutlich darauf hinweisen - "Vorsicht, aus Sicherheitsgründen wird der Betrieb eines EasyVDR-Systems mit Internetzugang NICHT empfohlen... Oder so ähnlich... Ich glaube wir sind alle der selben Meinung, das System sollte möglichst sicher sein. Grüsse rost21A VDR: EasyVDR 3.0 Mainboard: Gigabyte H67MA-USB3-B3, 4 GB Ram, Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz TV-Karte: 2x TBS6928 (PCIe & CI) Grafikkarte: Gainward GF 210 (GT218) 1024 MB (128 Bit, passiv) Festplatte: Seagate ST1000NM0011 Fernbedienung: ?...(Drahtlose Tastatur :D ) |