+- easyVDR (http://www.easy-vdr.de)
+-- Forum: easyVDR (http://www.easy-vdr.de/forum-5.html)
+--- Forum: easyVDR 3.x (http://www.easy-vdr.de/forum-148.html)
+--- Thema: easyvdr: Auffallend unsicher (/thread-18511.html)
easyvdr: Auffallend unsicher - mpcww - 24.11.2018
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.
RE: easyvdr: Auffallend unsicher - Bleifuss2 - 24.11.2018
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
RE: easyvdr: Auffallend unsicher - mpcww - 25.11.2018
(24.11.2018, 21:09)Bleifuss2 schrieb: Wenn du mal mit Wireshark an die Sache gehst wirst du noch feststellen keine verschlüsselte Verbindungen.ok, ich würde konkret die gefundenen Schwachstellen angehen: lighttpd-Version ...
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.
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.
RE: easyvdr: Auffallend unsicher - Bleifuss2 - 25.11.2018
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
RE: easyvdr: Auffallend unsicher - mpcww - 25.11.2018
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.
RE: easyvdr: Auffallend unsicher - mpcww - 25.11.2018
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 removefü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 ?
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 noC. 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 RE: easyvdr: Auffallend unsicher - Bleifuss2 - 25.11.2018
Das sind vermutlich Upstart Dienste, vielleicht kann man es auch einfach deinstallieren ...
Ansonsten Wiki ubuntu Upstart, da sollte beschrieben sein wie man das deaktiviert.
RE: easyvdr: Auffallend unsicher - mpcww - 25.11.2018
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 NoEin 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).
RE: easyvdr: Auffallend unsicher - mango - 25.11.2018
Hi!
(25.11.2018, 20:15)mpcww schrieb: 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
RE: easyvdr: Auffallend unsicher - mpcww - 25.11.2018
(25.11.2018, 21:48)mango schrieb: Hi!
(25.11.2018, 20:15)mpcww schrieb: 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 ?
RE: easyvdr: Auffallend unsicher - geraldkainz - 26.11.2018
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
RE: easyvdr: Auffallend unsicher - Bleifuss2 - 26.11.2018
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
RE: easyvdr: Auffallend unsicher - mpcww - 26.11.2018
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).
RE: easyvdr: Auffallend unsicher - mpcww - 05.12.2018
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.
RE: easyvdr: Auffallend unsicher - Wirbel - 05.12.2018
..na ja, vielleicht sollte ein Anwender aber auch eine Video-rekorder Firmware nicht kit einer Festung für den Betrieb als Desktop verwechseln.
RE: easyvdr: Auffallend unsicher - Martin - 05.12.2018
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).
RE: easyvdr: Auffallend unsicher - maxprox - 23.12.2018
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 ;-)
RE: easyvdr: Auffallend unsicher - SurfaceCleanerZ - 23.12.2018
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
RE: easyvdr: Auffallend unsicher - rost21A - 25.12.2018
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