Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
easyvdr: Auffallend unsicher
#1
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.


Angehängte Dateien
.pdf   report-d7578455-3a6a-4959-9446-51683fa8c347.pdf (Größe: 149,33 KB / Downloads: 4)
.txt   report-d7578455-3a6a-4959-9446-51683fa8c347.txt (Größe: 32,96 KB / Downloads: 3)
Zitieren
#2
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® Core™ i5-3470, Cine S2 DVB, WD 3TB Green, WDC WD20EARS-00J  2TB, Geforce 750Ti oder Intel HD
Easyvdr 3.0
Zitieren
#3
(24.11.2018, 21:09)Bleifuss2 schrieb: 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.
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
Zitieren
#4
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® Core™ i5-3470, Cine S2 DVB, WD 3TB Green, WDC WD20EARS-00J  2TB, Geforce 750Ti oder Intel HD
Easyvdr 3.0
Zitieren
#5
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
Zitieren
#6
Wink 
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 Smile

  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           
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
Zitieren
#7
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® Core™ i5-3470, Cine S2 DVB, WD 3TB Green, WDC WD20EARS-00J  2TB, Geforce 750Ti oder Intel HD
Easyvdr 3.0
Zitieren
#8
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 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          -- [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) chacha20-poly1305@openssh.com         -- [info] available since OpenSSH 6.5
                                            `- [info] default cipher since OpenSSH 6.9.
(enc) aes256-gcm@openssh.com                -- [info] available since OpenSSH 6.2
(enc) aes256-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52

# message authentication code algorithms
(mac) hmac-sha2-512-etm@openssh.com         -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256-etm@openssh.com         -- [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) +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).


Angehängte Dateien
.pdf   report-7008b056-223b-442e-a283-d23e14e820c8.pdf (Größe: 50,75 KB / Downloads: 2)
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
Zitieren
#9
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?? Confused  Confused

Gruss
Wolfgang

Zitieren
#10
(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?? Confused  Confused

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
Zitieren
#11
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
Zitieren
#12
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® Core™ i5-3470, Cine S2 DVB, WD 3TB Green, WDC WD20EARS-00J  2TB, Geforce 750Ti oder Intel HD
Easyvdr 3.0
Zitieren
#13
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
Zitieren
#14
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.
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
Zitieren
#15
..na ja, vielleicht sollte ein Anwender aber auch eine Video-rekorder Firmware nicht kit einer Festung für den Betrieb als Desktop verwechseln.
Du brauchst Hilfe? Wir brauchen Daten!
while (! asleep()) sheep++;
Zitieren
#16
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
-----------------------------------------------------------------------------------------------------------
Du brauchst Hilfe? Wir brauchen Daten! English-Version: Don't eat yellow snow!
Meine VDRs (Spoiler klicken) 

Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste