Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?
28.02.2020, 00:31:05

.
Einloggen mit Benutzername, Passwort und Sitzungslänge

Mitglieder
  • Mitglieder insgesamt: 23513
  • Letzte: stefan555
Statistiken
  • Beiträge insgesamt: 642953
  • Themen insgesamt: 52096
  • Heute online: 462
  • Am meisten online: 2287
  • (22.01.2020, 19:20:24)
Benutzer Online
Mitglieder: 8
Gäste: 457
Gesamt: 465

Autor Thema:  Welches Risiko entsteht durch kurze Passwörter?  (Gelesen 665 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Welches Risiko entsteht durch kurze Passwörter?
« am: 14.01.2020, 20:37:57 »
Hallo,

man findet reichlich diffuse Hinweise, dass kurze Passwörter ein Sicherheitsrisiko darstellen. Gilt das auch für Computer mit Linux Mint in Standardkonfiguration, die im Heimbereich verwendet werden, wenn man davon ausgeht, dass von den Personen, die physisch Zugriff haben, keine Gefahr ausgeht?
Ein Risiko bestünde meiner Meinung nach nur dann, wenn jemand Manipulationen über das Internet vornehmen könnte, was nur möglich wäre, wenn Linux-Mint irgendwelche Dienste anbietet. Daher meine Frage:
Welche Dienste bietet Linux Mint in der Standardkonfiguration an?

Gibt es vielleicht eine (einfache) Möglichkeit, um jeglichen Verbindungsaufbau aus dem Internet heraus zu unterbinden, aber im LAN zu ermöglichen? In dem Fall könnte man mit einfachen oder gar ohne Passwörter ssh und vnc im LAN benutzen.

Ich benutze im Moment Mint xfce und Cinamon 18.3 64 bit.

Re: Welches Risiko entsteht durch kurze Passwörter?
« Antwort #1 am: 14.01.2020, 20:46:10 »
Das Problem ist in der Praxis eher Malware, die du dir per "Drive-by-Infection" im Netz einfängst. Wenn die auf dem Rechner erhöhte Rechte versucht zu bekommen, machst du es ihr mit kurzen Passwörtern und womöglich Wörtern aus dem Wörterbuch, einfacher. Zum Glück für uns sind die allermeisten Schadroutinen auf Windows oder Server aus.
« Letzte Änderung: 14.01.2020, 20:49:13 von toffifee »

Re: Welches Risiko entsteht durch kurze Passwörter?
« Antwort #2 am: 14.01.2020, 21:03:47 »
Welche Dienste bietet Linux Mint in der Standardkonfiguration an?
Das kannst Du im Terminal mit
sudo netstat -tulpnnachsehen.

Gibt es vielleicht eine (einfache) Möglichkeit, um jeglichen Verbindungsaufbau aus dem Internet heraus zu unterbinden,
Das sollte eigentlich der Default-Zustand Deines DSL-Routers sein. Wenn Du an dessen Einstellungen nichts verändert hast, sollte aus dieser Richtung auch nichts passieren können.

wenn man davon ausgeht, dass von den Personen, die physisch Zugriff haben, keine Gefahr ausgeht?

Das ist der Trugschluss... im Regelfall ist der berechtigte Benutzer immer der, von dem die größte Gefahr ausgeht. Damit meine ich nicht Vorsatz und absichtliche Boshaftigkeit. Aber das, worauf mein Vorredner schon hingewiesen hat... solche Angriffe funktionieren nur mit der Unterstützung des Anwenders... dem das nicht mal bewusst sein muss.

thebookkeeper

  • aka AnanasDampf
  • *****
Re: Welches Risiko entsteht durch kurze Passwörter?
« Antwort #3 am: 14.01.2020, 22:10:11 »
... Gibt es vielleicht eine (einfache) Möglichkeit, um jeglichen Verbindungsaufbau aus dem Internet heraus zu unterbinden ...
Ja, Firewall aktivieren per Terminalbefehl:
thebookkeeper@Dell-DV051:~$ sudo ufw enable
Die Firewall ist beim System-Start aktiv und aktiviert
thebookkeeper@Dell-DV051:~$ sudo ufw logging on
Protokollierung wurde aktiviert
thebookkeeper@Dell-DV051:~$ sudo ufw status verbose
Status: Aktiv
Protokollierung: on (low)
Voreinstellung: deny (eingehend), allow (abgehend), disabled (gesendet)
...

Nicht wundern, wenn nach Firewall-Aktivierung trotzdem
vom Online-Portscanner https://www.heise.de/security/dienste/portscan/test/go.shtml?scanart=1
offene Ports angezeigt werden. Das liegt daran, weil per Default UFW erlaubt Ping-Requests.

Off-Topic:
In order to disable ping (icmp) requests, you need to edit /etc/ufw/before.rules and remove the following lines:

# ok icmp codes
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-input -p icmp --icmp-type source-quench -j ACCEPT
-A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT

or change the "ACCEPT" to "DROP"

# ok icmp codes
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j DROP
-A ufw-before-input -p icmp --icmp-type source-quench -j DROP
-A ufw-before-input -p icmp --icmp-type time-exceeded -j DROP
-A ufw-before-input -p icmp --icmp-type parameter-problem -j DROP
-A ufw-before-input -p icmp --icmp-type echo-request -j DROP



Langes Rechnerpasswort brauch ich nicht,
bei mir überwacht fail2ban die Datei
/var/log/auth.log und verhindert Brute-Force, aber dafür muss die Firewall aktiv sein.

Off-Topic:
sudo apt-get install fail2ban
« Letzte Änderung: 14.01.2020, 23:34:25 von thebookkeeper »

Re: Welches Risiko entsteht durch kurze Passwörter?
« Antwort #4 am: 14.01.2020, 22:12:31 »
Unnötig, wenn du hinter einem üblichen Router sitzt, wie schon erwähnt wurde.

Re: Welches Risiko entsteht durch kurze Passwörter?
« Antwort #5 am: 14.01.2020, 22:26:14 »
Sinnvoll wäre es dann, wenn man z.B. mit seinem Rechner ohne DSL-Router direkt  mit einem Modem im Internet verbunden ist. Oder wenn man mit dem Laptop an unbekannten öffentlichen WLAN-Access-Points verbunden ist.



Re: Welches Risiko entsteht durch kurze Passwörter?
« Antwort #7 am: 15.01.2020, 08:47:03 »
Heiliges Blech! netstat -tulpn zeigt wesentlich mehr offene Ports, als ich es vermutet hätte:

sudo netstat -tulpn
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:50963           0.0.0.0:*               LISTEN      973/rpc.mountd 
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      1076/dnsmasq   
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      763/cupsd       
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      1481/smbd       
tcp        0      0 0.0.0.0:59135           0.0.0.0:*               LISTEN      973/rpc.mountd 
tcp        0      0 0.0.0.0:33537           0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:2049            0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:40067           0.0.0.0:*               LISTEN      973/rpc.mountd 
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      1481/smbd       
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      961/rpcbind     
tcp6       0      0 ::1:631                 :::*                    LISTEN      763/cupsd       
tcp6       0      0 :::45435                :::*                    LISTEN      -               
tcp6       0      0 :::445                  :::*                    LISTEN      1481/smbd       
tcp6       0      0 :::2049                 :::*                    LISTEN      -               
tcp6       0      0 :::44293                :::*                    LISTEN      973/rpc.mountd 
tcp6       0      0 :::139                  :::*                    LISTEN      1481/smbd       
tcp6       0      0 :::52621                :::*                    LISTEN      973/rpc.mountd 
tcp6       0      0 :::36815                :::*                    LISTEN      973/rpc.mountd 
tcp6       0      0 :::111                  :::*                    LISTEN      961/rpcbind     
udp        0      0 0.0.0.0:60692           0.0.0.0:*                           704/avahi-daemon: r
udp        0      0 0.0.0.0:57113           0.0.0.0:*                           973/rpc.mountd 
udp        0      0 0.0.0.0:2049            0.0.0.0:*                           -               
udp        0      0 0.0.0.0:40457           0.0.0.0:*                           973/rpc.mountd 
udp        0      0 0.0.0.0:60428           0.0.0.0:*                           -               
udp        0      0 127.0.1.1:53            0.0.0.0:*                           1076/dnsmasq   
udp        0      0 0.0.0.0:68              0.0.0.0:*                           979/dhclient   
udp        0      0 0.0.0.0:49244           0.0.0.0:*                           1076/dnsmasq   
udp        0      0 0.0.0.0:111             0.0.0.0:*                           961/rpcbind     
udp        0      0 0.0.0.0:631             0.0.0.0:*                           764/cups-browsed
udp        0      0 10.0.2.15:123           0.0.0.0:*                           1413/ntpd       
udp        0      0 127.0.0.1:123           0.0.0.0:*                           1413/ntpd       
udp        0      0 0.0.0.0:123             0.0.0.0:*                           1413/ntpd       
udp        0      0 0.0.0.0:46720           0.0.0.0:*                           973/rpc.mountd 
udp        0      0 10.0.2.255:137          0.0.0.0:*                           1456/nmbd       
udp        0      0 10.0.2.15:137           0.0.0.0:*                           1456/nmbd       
udp        0      0 0.0.0.0:137             0.0.0.0:*                           1456/nmbd       
udp        0      0 10.0.2.255:138          0.0.0.0:*                           1456/nmbd       
udp        0      0 10.0.2.15:138           0.0.0.0:*                           1456/nmbd       
udp        0      0 0.0.0.0:138             0.0.0.0:*                           1456/nmbd       
udp        0      0 0.0.0.0:713             0.0.0.0:*                           961/rpcbind     
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           704/avahi-daemon: r
udp6       0      0 :::40729                :::*                                -               
udp6       0      0 :::2049                 :::*                                -               
udp6       0      0 :::46621                :::*                                973/rpc.mountd 
udp6       0      0 :::52287                :::*                                973/rpc.mountd 
udp6       0      0 :::111                  :::*                                961/rpcbind     
udp6       0      0 fe80::8d18:5852:e29:123 :::*                                1413/ntpd       
udp6       0      0 ::1:123                 :::*                                1413/ntpd       
udp6       0      0 :::123                  :::*                                1413/ntpd       
udp6       0      0 :::56457                :::*                                973/rpc.mountd 
udp6       0      0 :::713                  :::*                                961/rpcbind     
udp6       0      0 :::52949                :::*                                704/avahi-daemon: r
udp6       0      0 :::5353                 :::*                                704/avahi-daemon: r

Ich versuche mich so kurz wie möglich zu fassen, aber das wird wahrscheinlich dennoch unübersichtlich.

Das Problem ist in der Praxis eher Malware, die du dir per "Drive-by-Infection" im Netz einfängst. Wenn die auf dem Rechner erhöhte Rechte versucht zu bekommen, machst du es ihr mit kurzen Passwörtern und womöglich Wörtern aus dem Wörterbuch, einfacher. Zum Glück für uns sind die allermeisten Schadroutinen auf Windows oder Server aus.

Zitat von: Gurkengräber am Gestern um 20:37:57

    wenn man davon ausgeht, dass von den Personen, die physisch Zugriff haben, keine Gefahr ausgeht?


Das ist der Trugschluss... im Regelfall ist der berechtigte Benutzer immer der, von dem die größte Gefahr ausgeht. Damit meine ich nicht Vorsatz und absichtliche Boshaftigkeit. Aber das, worauf mein Vorredner schon hingewiesen hat... solche Angriffe funktionieren nur mit der Unterstützung des Anwenders... dem das nicht mal bewusst sein muss.

Meine Einschränkung war nicht präzise genug. Ich war nur auf den Vorsatz aus.
Drive-By-Infection ist ja praktisch unabhängig davon, denn das kann jeden Benutzer treffen. Wenn man davon ausgeht, dass das ein reales Risiko ist und beliebiger Code eines Angreifers auf dem Rechner ausgeführt werden kann, dann nutzt mMn. auch ein gutes PW nichts, denn das würde mit einem Keylogger mitgelesen werden können.


Sinnvoll wäre es dann, wenn man z.B. mit seinem Rechner ohne DSL-Router direkt  mit einem Modem im Internet verbunden ist. Oder wenn man mit dem Laptop an unbekannten öffentlichen WLAN-Access-Points verbunden ist.

Ja, das ist ein Szenario, was mir am Herzen liegt. Ab und an benutze ich mein Laptop in fremden Netzen und dann habe ich immer ein ungutes Gefühl und beschränke mich meist nur auf das Nötigste.
Als hier neulich der Glasfaseranschluss installiert worden ist, hatte ich noch keinen passenden Router und habe das Laptop zum Testen direkt an den ONT (Optischer Netzwerkabschluss) angeschlossen.
Der Router, den ich mir dann zugelegt habe, macht bei IPv4 NAT und der Provider CGNAT, sodass von außen nichts kommen kann, aber IPv6 wird komplett durchgereicht und ich habe auch keine Möglichkeit gefunden, das irgendwie zu unterbinden. Soweit ich herausgefunden habe, ist NAT bei IPv6 unüblich und wenn der Router keine Firewall hat, dann ist es normal, dass die Verbindungen komplett durchgeroutet werden. (Erinnert mich an ein Borg-Hive).

Eine Firewall erscheint mir sinnvoll zu sein, aber ohne GUI mit Regelassistenten (Doofen-Modus) kann ich mir das nicht vorstellen. Angenommen ich sperre alle eingehenden Verbindungen und möchte z.B. später Dateien oder einen lokalen Drucker freigeben, dann würde das wahrscheinlich in der Grundkonfiguration nicht funktionieren, und ich hätte die FW nicht auf dem Schirm, weil sie mich nicht auf den Verbindungsversuch aufmerksam macht.

Ich versuche es zusammenzufassen:

1. sind die oben von netstat angezeigten offenen Ports alle notwendig oder kann man die (ohne Firewall) auf Zugriff aus dem LAN beschränken?
2. besteht meinerseits ein Denkfehler mit den kurzen Passwörtern?
3. gibt es ein brauchbares GUI mit Regelassistenten für die integrierte Firewall?


Re: Welches Risiko entsteht durch kurze Passwörter?
« Antwort #8 am: 15.01.2020, 10:33:57 »
3. gibt es ein brauchbares GUI mit Regelassistenten für die integrierte Firewall?
Es gibt gufw apt install gufw. Mit Assistenz bzgl. Regeln ist da nicht viel, man kann aber welche erstellen.

Re: Welches Risiko entsteht durch kurze Passwörter?
« Antwort #9 am: 15.01.2020, 12:50:54 »
Heiliges Blech! netstat -tulpn zeigt wesentlich mehr offene Ports, als ich es vermutet hätte:

Hinsichtlich offener Ports ist das der Normalzustand.... das heißt, auf einem Linux-Desktop-System sind per Default keine Ports ausdrücklich gesperrt. Es gibt da lediglich die Unterscheidung von privilegierten (<1024) und unprivilegierten (1024>) Ports.... aber gesperrt ist da erst Mal nichts. Damit ist zunächst auch  kein Risiko verbunden, das entsteht erst in weiterer Folge durch einen schlecht konfigurierten Dienst, der auf einem bestimmten Port lauscht. Bei Dir lauschen alle Dienste auf allen verfügbaren Interfaces und lassen Verbindungen von allen Domains resp. Remote-Machines zu. Im weiteren ist festzustellen, dass hier vermutlich per Default alles mögliche an Diensten eingerichtet ist, unabhängig von der Frage, ob für diese Dienste eine ausdrückliche Verwendung besteht oder nicht. Als Fazit kann man feststellen, dass das eine eher als unsicher einzustufende Konfiguration ist.

Aber, und jetzt das große aber.... wenn man sich diese Frage zur Sicherheit stellt, sollte man sich vorher die Frage beantworten, warum man überhaupt eine Distribution verwendet, deren erklärtes Ziel ist, eine maximale Anfängertauglichkeit und schnelle Funktionalität OOTB versucht zu garantieren und deren Zielgruppe eine Klientel ist, die ausdrücklich hohe Ansprüche an einfache Bedienbarkeit haben und auf der Gegenseite sehr geringe Ansprüche an Sicherheit stellen. Dann wird sich eine anschließende Frage stellen, ob Du mit dem Herauskonfigurieren diese Default-Funktionen überhaupt noch eine stabile Installation hast oder ob man sich auf einmal einer Problem-Kaskade gegenübergestellt sieht, weils mal hier, mal dort, mal da Probleme gibt oder weil für irgendwas irgendeine Abhängigkeit nicht mehr verfügbar ist.

Zum Netstat-Output.... da ist -glaube ich- ausser cups nichts dabei, was auf unseren Linux-Systemen läuft....

Zitat
Meine Einschränkung war nicht präzise genug. Ich war nur auf den Vorsatz aus.
Das hatte ich auch so verstanden. Deswegen sagte ich, dass es dem Anwender oft gar nicht bewusst ist, wenn er instrumentalisiert wird. Er kann sich dagegen mangels Sachkenntnis nur schwer wehren, weil ihm solche Aktionen gar nicht bewusst werden. Man kann dem begegnen, wenn man verhindert, dass der Anwender gleichzeitig auch über Admin-Rechte verfügen kann.

Zitat
dass das ein reales Risiko ist und beliebiger Code eines Angreifers auf dem Rechner ausgeführt werden kann, dann nutzt mMn. auch ein gutes PW nichts, denn das würde mit einem Keylogger mitgelesen werden können.
Genau das meinte ich... es werden die Berechtigungen des Anwenders unbemerkt missbraucht... und hier ist die Erkenntnis, hat er keine Privilegien, können die auch nicht missbraucht werden. Darf er außerdem auch keine Anwendungen ausführen, die nicht zuvor von einem Admin installiert wurden, kann auch kein fremder Code ausgeführt werden.

Zitat
Ja, das ist ein Szenario, was mir am Herzen liegt. Ab und an benutze ich mein Laptop in fremden Netzen und dann habe ich immer ein ungutes Gefühl und beschränke mich meist nur auf das Nötigste.
Bei der Anzahl an laufenden Services solltest Du mehr als nur ein ungutes Gefühl haben. Dir muss klar sein, dass Dein Laptop in einem fremden Netzwerk die gleiche Sichtbarkeit hat, wie im lokalen Netzwerk zuhause. Wenn ich ehrlich bin, würde ich einen solchen Laptop, der sich bereits wiederholt an fremden Accesspoints angemeldet hat, konkret das Vertrauen entziehen.

Zitat
Der Router, den ich mir dann zugelegt habe, macht bei IPv4 NAT und der Provider CGNAT, sodass von außen nichts kommen kann, aber IPv6 wird komplett durchgereicht und ich habe auch keine Möglichkeit gefunden, das irgendwie zu unterbinden. Soweit ich herausgefunden habe, ist NAT bei IPv6 unüblich und wenn der Router keine Firewall hat, dann ist es normal, dass die Verbindungen komplett durchgeroutet werden. (Erinnert mich an ein Borg-Hive).
IPv6-NAT ist nicht notwendig. Und ich halte es für eine sehr dumme Entscheidung, wie man das häufig liest, IPv6 zu deaktivieren... IPv6 ist zweifelsfrei das bessere Protokoll. Und nein, auch wenn Deine Clients eine öffentliche IPv6 haben, so leitet der DSL-Router dennoch keine aus dem Internet kommenen Pakete an den Laptop weiter. Ich würde nur zusehen, dass die PCs im Netzwerk keine pseudostatische IPv6-Adresse haben, sondern sich bei jedem Einschalten eine neue bilden.

Zitat
Eine Firewall erscheint mir sinnvoll zu sein, aber ohne GUI mit Regelassistenten (Doofen-Modus) kann ich mir das nicht vorstellen.
Wenn man das System des Paketfilters nicht verstanden hat, kann man das von der Firewall erzeugte Regelwerk auch nicht gegenprüfen... also bleibt die Sicherheit in gewisser Weise Wunschdenken und blindes Vertrauen. Und wenn man das System des Paketfilters versanden hat, ist die UFW eher hinderlich, kontraproduktiv, man braucht sie dann gar nicht. Die GUFW hat allerdings zwei sehr einfache Einstellungen, öffentliches Netzwerk und privates Netzwerk. Aktivierst Du draußen das öffentliche Netzwerk ist per default alles geschlossen... das macht die FW richtig gut. Damit kannst Du meiner Meinung nach nichts falsch machen und durchaus zufrieden sein.

Zitat
Angenommen ich sperre alle eingehenden Verbindungen und möchte z.B. später Dateien oder einen lokalen Drucker freigeben, dann würde das wahrscheinlich in der Grundkonfiguration nicht funktionieren, und ich hätte die FW nicht auf dem Schirm, weil sie mich nicht auf den Verbindungsversuch aufmerksam macht.
Sperren ist totaler quatsch. Wenn man einem Service den Hahn zudrehen kann, weil man ihn nicht verwendet, dann ist die bessere Lösung, diesen Service einfach ganz zu deinstallieren oder alternativ den Start zu maskieren. Und die Dienste, die man braucht, die überprüft man, ob für diese Verbindungen zu anderen Hosts notwendig sind oder nicht... und wenn nicht, konfiguriert man sie auf localhost und gut ist's.....

Aber dennoch bleibt am Ende die Feststellung, dass ein PC mit auf bestimmten Ports lauschenden Diensten hinter einem DSL-Router keine allzugroße Gefahr droht, weil ein solcher Router üblicherweise eine Firmware-Firewall akiviert hat, die ankommenden Traffic vollständig blockiert. Das ändert sich erst, wenn Du außerhalb Deines Netzwerkes ins Internet gehst.
« Letzte Änderung: 15.01.2020, 15:03:51 von Patchpanel »

Re: Welches Risiko entsteht durch kurze Passwörter?
« Antwort #10 am: 15.01.2020, 14:32:57 »
Was macht der Computer mit kurzen Passwörtern? Füllt er die intern mit Nullen auf auf, oder ist das Passwort "000000000000000000000000000001" tatsächlich so viel sicherer als "1"?

Re: Welches Risiko entsteht durch kurze Passwörter?
« Antwort #11 am: 15.01.2020, 14:57:08 »
Was macht der Computer mit kurzen Passwörtern? Füllt er die intern mit Nullen auf auf,
Nein, denn die Passwörte werden nicht gespeichert, sondern nur ein Hashcode

Zitat
oder ist das Passwort "000000000000000000000000000001" tatsächlich so viel sicherer als "1"?

Die Hash-Codes für z.B. diese 3  Passwörter sehen so aus:
1                           $1$7a0lMKam$xScpp9AlEmYhgY9TS03Er.
0000000000000001            $1$Ge33Kwpv$4hsDtxluTs/9Jx6DaK7lp0
000000000000001             $1$i0lnbyAq$dF2pjlSCGdiE3VU3qHrdb/

Re: Welches Risiko entsteht durch kurze Passwörter?
« Antwort #12 am: 15.01.2020, 16:39:23 »

Allgemein:
Eine Hashfunktion ist eine Abbildung, die effizient eine Zeichenfolge beliebiger Länge (Eingabewert) auf eine Zeichenfolge mit fester Länge (Hashwert) abbildet.

Speziell:
Eine kryptologische Hashfunktion oder kryptografische Hashfunktion ist eine spezielle Form einer Hashfunktion (Streuwertfunktion), welche kollisionsresistent ist. Es ist also praktisch nicht möglich, zwei unterschiedliche Eingabewerte zu finden, die einen identischen Hashwert ergeben.

https://de.wikipedia.org/wiki/Kryptographische_Hashfunktion

Re: Welches Risiko entsteht durch kurze Passwörter?
« Antwort #13 am: 15.01.2020, 16:43:52 »
Was macht der Computer mit kurzen Passwörtern? Füllt er die intern mit Nullen auf auf,

Liest man sich Hinweise zu den verschiedenen Hashalgorithmen durch, dann gibt tatsächlich welche, die vor dem Hashen den Klartext des Inputs auf eine bestimmte Länge auffüllen.

EDIT:  Das wird als 'Padding' bezeichnet.

Re: Welches Risiko entsteht durch kurze Passwörter?
« Antwort #14 am: 17.01.2020, 11:56:40 »
Danke für die ausführliche Kommentierung. Ich hatte erst mal versucht ein paar meiner Fragen dazu per Internetrecherche zu beantworten, aber da sehe ich im Moment kein Land.


Damit ist zunächst auch  kein Risiko verbunden, das entsteht erst in weiterer Folge durch einen schlecht konfigurierten Dienst, der auf einem bestimmten Port lauscht. Bei Dir lauschen alle Dienste auf allen verfügbaren Interfaces und lassen Verbindungen von allen Domains resp. Remote-Machines zu. Im weiteren ist festzustellen, dass hier vermutlich per Default alles mögliche an Diensten eingerichtet ist, unabhängig von der Frage, ob für diese Dienste eine ausdrückliche Verwendung besteht oder nicht. Als Fazit kann man feststellen, dass das eine eher als unsicher einzustufende Konfiguration ist.


Ohne vorgeschalteten, vertrauenswürdigen Router oder Firewall sehe ich das auch so.
Ich habe mir noch die Ausgabe von netstat -tulpn eines anderen Rechners von mir und die eines Live-Sticks (beide Mint XFCE 18.3) angesehen. Auf dem anderen Rechner sieht es praktisch genauso aus, wie die gepostete Ausgabe, während es beim Live-Stick deutlich übersichtlicher ist:

Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      1543/dnsmasq   
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      1165/cupsd     
tcp6       0      0 ::1:631                 :::*                    LISTEN      1165/cupsd     
udp        0      0 0.0.0.0:41479           0.0.0.0:*                           1164/avahi-daemon:
udp        0      0 127.0.1.1:53            0.0.0.0:*                           1543/dnsmasq   
udp        0      0 0.0.0.0:68              0.0.0.0:*                           1523/dhclient   
udp        0      0 0.0.0.0:631             0.0.0.0:*                           1276/cups-browsed
udp        0      0 10.0.2.15:123           0.0.0.0:*                           1953/ntpd       
udp        0      0 127.0.0.1:123           0.0.0.0:*                           1953/ntpd       
udp        0      0 0.0.0.0:123             0.0.0.0:*                           1953/ntpd       
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           1164/avahi-daemon:
udp        0      0 0.0.0.0:51488           0.0.0.0:*                           1543/dnsmasq   
udp6       0      0 :::42418                :::*                                1164/avahi-daemon:
udp6       0      0 fe80::a832:f01f:bb5:123 :::*                                1953/ntpd       
udp6       0      0 ::1:123                 :::*                                1953/ntpd       
udp6       0      0 :::123                  :::*                                1953/ntpd       
udp6       0      0 :::5353                 :::*                                1164/avahi-daemon:


Zitat

Aber, und jetzt das große aber.... wenn man sich diese Frage zur Sicherheit stellt, sollte man sich vorher die Frage beantworten, warum man überhaupt eine Distribution verwendet, deren erklärtes Ziel ist, eine maximale Anfängertauglichkeit und schnelle Funktionalität OOTB versucht zu garantieren und deren Zielgruppe eine Klientel ist, die ausdrücklich hohe Ansprüche an einfache Bedienbarkeit haben und auf der Gegenseite sehr geringe Ansprüche an Sicherheit stellen. Dann wird sich eine anschließende Frage stellen, ob Du mit dem Herauskonfigurieren diese Default-Funktionen überhaupt noch eine stabile Installation hast oder ob man sich auf einmal einer Problem-Kaskade gegenübergestellt sieht, weils mal hier, mal dort, mal da Probleme gibt oder weil für irgendwas irgendeine Abhängigkeit nicht mehr verfügbar ist.


Für Linux Mint gab es eine ganze Reihe von Gründen. Ich habe in den 90ern mal Suse Linux probiert und war schwer enttäuscht. Da hat nichts funktioniert, es gab keine Software dafür, mit der ich etwas hätte anfangen können. Hilfeseiten und Foren dazu, in denen man auch als Computerneuling oder Windowsbenutzer nicht gleich angeflamed worden ist, gab es auch nicht.
Ich suche eine Alternative zu Windows. Am Liebsten wäre mir, wenn ich genau den Desktop von W2k/XP Classic bekäme, aber das gibt es nicht. Mit Mint xfce habe ich mich inzwischen arrangiert. Die geringe Verbreitung von Linux-Desktops ansich bringt schon viele Probleme mit sich, weshalb ich möglichst eine Mainstream-Distri verwenden wollte.
Mit dem Netzwerkteil von Linux habe ich mich bisher wenig beschäftigt und hätte auch nicht gedacht, dass Mint praktisch wie eine offene Tür ist. Wenn ich Infos zu Mint suche, dann lese ich sehr gerne bei wiki.ubuntuusers.de, denn dort sind die Sachen für mich meistens im richtigen Grad komprimiert und aufgearbeitet und fast immer 1:1 für Mint zu gebrauchen. Dort (https://wiki.ubuntuusers.de/Personal_Firewalls/) hatte ich gelesen, dass eine Firewall für ubuntu nicht notwendig sei und dass es keine offenen Ports gibt. Das hatte ich auch für Mint angenommen, aber so weit gehen die Gemeinsamkeiten von Ubuntu und Mint wohl nicht. Vielleicht sollte ich mir xubuntu mal ansehen.
Zitat

Zum Netstat-Output.... da ist -glaube ich- ausser cups nichts dabei, was auf unseren Linux-Systemen läuft....


Was meinst du mit "*unseren* Linux-Systemen"?

Ich habe versucht herauszufinden, wofür die offenen Ports, bzw. die Programme dahinter gut sind, aber das wird schnell viel zu komplex.
Bei avahi ist mir zumindest grundsätzlich klar, wofür das gut ist. Das würde ich wahrscheinlich eher ausschalten. UPNP habe ich auch unter Windows nie benutzt. Bei ntpd leuchtet mir nicht ein, wozu das gut sein soll. IdR. möchte man die Uhrzeit holen und nicht anderen diesen Dienst anbieten. rpc.mountd soll nach meiner Recherche etwas mit NFS zu tun haben, welches man nicht im öffentlichen Netz verwenden soll. Wieso lauscht so etwas auf allen Adressen? Bei jedem einzelnen Dienst müsste ich viel Zeit investieren, um meine Fragen und die Auswirkungen von Änderungen zu beantworten. Unpraktikabel.

Das Problem ist meiner Meinung nach ein benutzerfreundliches System zu erhalten, das trotzdem nicht mehr als unbedingt notwendig auf eingehende Verbindungsversuche reagiert, besonders nicht von denen aus aus dem WAN.

Zitat
Man kann dem begegnen, wenn man verhindert, dass der Anwender gleichzeitig auch über Admin-Rechte verfügen kann.


Das scheint mir auch die einzige Möglichkeit zu sein, das betr. Risiko zu minimieren. Allerdings vergeht keine Linux-Session, in der ich nicht die Rootrechte verwende, was auch der Grund für meine ursprüngliche Frage nach kurzen Passwörtern war.
Als ich mit Linux Mint und Raspbian angefangen habe, war ich sehr überrascht, wie leicht man als Benutzer Rootrechte erhält. Das erscheint mir insgesamt nicht sicherer als das Konzept von Windows mit UAC zu sein.

Wie richtet man sein Linux sicherer ein? Der Benutzer darf nicht mit dem Benutzer-Passwort rootrechte erhalten. Zwei PW pro Benutzer geht vermutlich nicht. Also muss man zwei Konten pro Benutzer einrichten: Ein Benutzerkonto ohne und eins mit Zugang zu Rootrechten.
Damit muss sich der Benutzer aber zwei PWs merken und er muss sich für ein simples Systemupdate immer mit dem zweiten Benutzerkonto anmelden. Das verleitet dann wieder dazu, dass man einfachere PWs verwendet oder sich lieber nur mit dem Konto mit Zugang zu Rootrechten anmeldet.

Es müsste doch möglich sein, zumindest oft benötigte Vorgänge wie z.B. "apt update" in einem Skript unterzubringen, welches von einem Benutzer ohne Rootrechte zwar gestartet, aber nicht verändert werden darf, und das "irgendwie" nur für apt Rootrechte gespeichert hat. Dann könnte ein Benutzer die Systemaktualisierung anstoßen.

Zitat

Zitat
Ja, das ist ein Szenario, was mir am Herzen liegt. Ab und an benutze ich mein Laptop in fremden Netzen und dann habe ich immer ein ungutes Gefühl und beschränke mich meist nur auf das Nötigste.

Bei der Anzahl an laufenden Services solltest Du mehr als nur ein ungutes Gefühl haben. Dir muss klar sein, dass Dein Laptop in einem fremden Netzwerk die gleiche Sichtbarkeit hat, wie im lokalen Netzwerk zuhause. Wenn ich ehrlich bin, würde ich einen solchen Laptop, der sich bereits wiederholt an fremden Accesspoints angemeldet hat, konkret das Vertrauen entziehen.


Meine Erkenntnisse mit Linux sind noch nicht weit fortgeschritten, sodass ich mein Laptop bisher "nur" mit Windows mit aktivierter Firewall an fremden APs benutzt habe. Mein Ziel ist es aber, standardmäßig Linux zu benutzen und Windows nur dann, wenn es nicht anders geht. Ich werde mir zumindest für den Anfang (g)ufw ansehen.

Zitat

Zitat
Der Router, den ich mir dann zugelegt habe, macht bei IPv4 NAT und der Provider CGNAT, sodass von außen nichts kommen kann, aber IPv6 wird komplett durchgereicht und ich habe auch keine Möglichkeit gefunden, das irgendwie zu unterbinden. Soweit ich herausgefunden habe, ist NAT bei IPv6 unüblich und wenn der Router keine Firewall hat, dann ist es normal, dass die Verbindungen komplett durchgeroutet werden. (Erinnert mich an ein Borg-Hive).

IPv6-NAT ist nicht notwendig. Und ich halte es für eine sehr dumme Entscheidung, wie man das häufig liest, IPv6 zu deaktivieren... IPv6 ist zweifelsfrei das bessere Protokoll. Und nein, auch wenn Deine Clients eine öffentliche IPv6 haben, so leitet der DSL-Router dennoch keine aus dem Internet kommenen Pakete an den Laptop weiter. Ich würde nur zusehen, dass die PCs im Netzwerk keine pseudostatische IPv6-Adresse haben, sondern sich bei jedem Einschalten eine neue bilden.


Ich habe den Router hier zwischen zwei PCs geklemmt. Ein PC an den WAN- und einen an den LAN-Anschluss. Dann habe ich iperf3 laufen lassen und ich konnte den PC auf WAN- und LAN-Seite per IPv6 erreichen.
Bei IPv4 ging das nicht.

Wie schon erwähnt, habe ich mit Netzwerken nicht viel am Hut, aber wenn keine Firewall, NAT, oder etwas ähnliches im Router aktiviert ist, dann muss er doch alles durchreichen. Hast du evtl. ein Stichwort, wonach ich suchen könnte, um herauszufinden, ob sich der Router auch so konfigurieren lässt, dass er auch bei IPv6 keine eingehenden Verbindungen zulässt?

Zitat


Zitat
Angenommen ich sperre alle eingehenden Verbindungen und möchte z.B. später Dateien oder einen lokalen Drucker freigeben, dann würde das wahrscheinlich in der Grundkonfiguration nicht funktionieren, und ich hätte die FW nicht auf dem Schirm, weil sie mich nicht auf den Verbindungsversuch aufmerksam macht.

Sperren ist totaler quatsch. Wenn man einem Service den Hahn zudrehen kann, weil man ihn nicht verwendet, dann ist die bessere Lösung, diesen Service einfach ganz zu deinstallieren oder alternativ den Start zu maskieren. Und die Dienste, die man braucht, die überprüft man, ob für diese Verbindungen zu anderen Hosts notwendig sind oder nicht... und wenn nicht, konfiguriert man sie auf localhost und gut ist's.....


Der Vorteil der Konfiguration über eine Firewall wäre, dass man den Netzwerkzugriff zentral verwalten kann und nicht die Eigenheiten jedes Dienstes berücksichtigen muss. Bei der Firewall wüsste ich zumindest grundsätzlich, wie ich die Ports einschränken könnte. Für rpc.mountd wüsste ich nicht mal, wo ich anfangen sollte.