easyvdr: Auffallend unsicher

[mpcww]

In den letzten Tagen habe ich die verschiedenen Instanzen in meinem Heimnetz einem Sicherheitsscan unterzogen.
Dazu habe ich 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.


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.

[Bleifuss2]

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

[mpcww]

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:

Code:

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.

[Bleifuss2]

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

[mpcww]

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.

[mpcww]

An drei Schrauben habe ich zunächst gedreht:


A) Für mich überflüssige Dienste deaktivieren:

Ich habe versucht mit

Code:

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:

1. lighttpd und shellinabox sind damit kein Thema mehr, d.h. über http ist der Rechner nicht mehr erreichbar
   
   
2. 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:

 

Code:

 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:

Code:

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           

[Bleifuss2]

Das sind vermutlich Upstart Dienste, vielleicht kann man es auch einfach deinstallieren ...
Ansonsten Wiki ubuntu Upstart, da sollte beschrieben sein wie man das deaktiviert.

[mpcww]

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):

Code:

# 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 [email protected],ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected],aes256-ctr
Macs [email protected],[email protected],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 ([email protected])

# key exchange algorithms
(kex) [email protected]          -- [info] available since OpenSSH 6.5, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp521                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp256                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) diffie-hellman-group-exchange-sha256  -- [warn] using custom size modulus (possibly weak)
                                            `- [info] available since OpenSSH 4.4

# host-key algorithms
(key) ssh-rsa                               -- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28
(key) ecdsa-sha2-nistp256                   -- [fail] using weak elliptic curves
                                            `- [warn] using weak random number generator could reveal the key
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(key) ssh-ed25519                           -- [info] available since OpenSSH 6.5

# encryption algorithms (ciphers)
(enc) [email protected]         -- [info] available since OpenSSH 6.5
                                            `- [info] default cipher since OpenSSH 6.9.
(enc) [email protected]                -- [info] available since OpenSSH 6.2
(enc) aes256-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52

# message authentication code algorithms
(mac) [email protected]         -- [info] available since OpenSSH 6.2
(mac) [email protected]         -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512                         -- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha2-256                         -- [warn] using encrypt-and-MAC mode
                                            `- [info] 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) [email protected]               -- 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) [email protected]             -- 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).

[mango]

Hi!

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

Gruss
Wolfgang

[mpcww]

Hi!

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

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 ?

[geraldkainz]

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

[Bleifuss2]

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

[mpcww]

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

[mpcww]

Gerade bin ich noch auf ein schönes Beispiel gestoßen, warum jeder Rechner im Heimnetz nicht mit unnötigen Risiken betrieben werden sollte.

Totale Kontrolle: Multifunktions-Drucker über Fax angreifbar


Vielleicht hilft es meine Sichtweise zu verstehen: "Brückenköpfe" ins Heimnetz zu minimieren.

[Wirbel]

..na ja, vielleicht sollte ein Anwender aber auch eine Video-rekorder Firmware nicht kit einer Festung für den Betrieb als Desktop verwechseln.

[Martin]

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

[maxprox]

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 ;-)

[SurfaceCleanerZ]

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

[rost21A]

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