☰

Warum wäre ein Benutzer ohne Passwort (in diesem Szenario) eine schlechte Idee?

tag-icon • tag-icon security users password non-root-user privileges
Warum wäre ein Benutzer ohne Passwort (in diesem Szenario) eine schlechte Idee?

Ich habe überlegt, ob ich das hier oder in Security SE posten soll... habe mich dann aber für Unix SE entschieden, da es sich hier nicht wirklich um eine Frage zu Kryptographie, sondern mehr um Linux-Benutzer/-Privilegien handelt. Vielleicht ist mein Google-Fu heute schwach, aber die einzigen Dinge, die ich bisher gefunden habe, sind entweder

  1. sehr allgemeine, vage Antworten darüber, dass es eine „schlechte Praxis“ oder „verpönt“ sei, ohne konkrete Beispiele, oder
  2. erhalten Antworten, die davon ausgehen, dass der Benutzer ohne Kennwort Root-Zugriff hat oder auf andere Weise alle möglichen Schutzmaßnahmen außer Kraft setzt.

Um es klar zu sagen: Ich befürworte das nicht und suche tatsächlich nach triftigen Gründennichtdas zu tun, aber ich würde lieber konkrete Gründe dafür finden und nicht nur sagen „es ist schlecht“. :-)

Nachdem das geklärt ist, möchte ich nun das Beispiel anführen, das mich überhaupt erst zum Nachdenken über dieses Thema gebracht hat:

Nehmen wir an, ich überlege, ein Heimsystem einzurichten, bei dem ich ein sicheres Passwort für das rootKonto habe. Darüber hinaus werde ich einNicht-Root-Konto mit dem Namen Freddas istNICHTin der Admin-Gruppe wheel(oder sudoersbei Debian / Ubuntu). Auf diesem System werde ich auch /homeeine separate, LUKS-verschlüsselte Partition haben, die während des Bootvorgangs entsperrt wird. Mit anderen Worten, ein Passworttutnoch zwischen GRUB und dem Login-Manager eingegeben werden - aber der Login-Manager ist auf automatische Anmeldung eingestellt. Darüber hinaus nehmen wir an, ich richte (von root aus) Folgendes ein password -f -u fred:Entsperren erzwingendas Kennwort für fred(wodurch freddas Kennwort effektiv leer bleibt).

Mit welchen Sicherheitsproblemen muss ich in dieser Situation rechnen? Es scheint, als gäbe es einen guten Grund, warum Sie das nicht tun möchten.Aber dienurdas, was mir bisher in den Sinn kommt, ist:

  • LUKS-Partitionen werden nicht geschlossen, wenn die Bildschirmschonersperre ausgelöst wird (zumindest nicht bei Cinnamon und vorausgesetzt, eineIstauf Auslösen eingestellt). Wenn also jemand in mein Haus einbricht und fredbereits angemeldet ist, kann er sich einfach hinsetzen, den Monitor einschalten und dann alles durchsuchen, fredworauf er Zugriff hat – solange er den PC nicht vorher aussteckt/neu startet/wegnimmt (und damit LUKS wieder sperrt). Und ich vermute, wenn ich mir genug Mühe gebe, könnte ich vielleicht einen Weg finden, ein Skript aufzurufen, wenn der Bildschirmschoner ausgelöst wird, und dann LUKS von diesem Skript aus zu sperren und so diese Lücke zu schließen (oder vielleicht haben KDE/XFCE/Gnome/usw. bereits eine Möglichkeit, sich darum zu kümmern?).

Selbst wenn freder ein schönes, sicheres Passwort hätte, könnte er keine Software installieren oder Systemeinstellungen ändern, ohne Administratorrechte zu haben. Und ich weiß es nicht genau, aber ich denke, der Browser-/Wine-Zugriff auf Dateien würde sich in beiden Fällen nicht ändern. Ist hier etwas mehr gefährdet als wennfred tathaben Sie ein Passwort?

Bearbeiten: Ich denke nicht, dass es wichtig ist, aber die Distribution ist Fedora (mit aktiviertem SELinux). Wenn Sie jedoch lieber in Bezug auf eine andere Distribution (oder ohne SELinux) antworten, ist das in Ordnung.

Bearbeitung #2: Bezüglich ssh/ samba. Ich richte im Allgemeinen so etwas wie einen /media/sdb1/sharedOrdner für ein, anstatt Sambas $HOMEFreigaben oder wie auch immer sie heißen zu verwenden. Ich finde, dass dies in einer kleinen Benutzerumgebung wie zu Hause ziemlich einfach einzurichten ist (ich würde dies natürlich nicht in einer Arbeitsumgebung oder einer Umgebung tun, in der sich nicht alle Benutzer gegenseitig vertrauen). Aber ich verwende immer separate, passwortgeschützte Samba-Benutzerkonten (nicht dieselben Benutzer, mit denen ich mich anmelde) und ich folge mehreren Anleitungen zum Härten meines smb.confSetups. Wenn Sie Fehler in diesem Setup sehen, betrachte ich diese als gültig für den Angriff auf das hypothetische Szenario/Setup mit einem leeren Passwort für das Anmeldekonto fred(denken Sie daran, dass das Passwort des Samba-Kontos lautetnichtallerdings leer).

Für sshmöchte ich bestätigen, dass standardmäßig leere Passwörter abgelehnt werden aufalleKonten (nicht nur auf root). Wenn nicht, dann betrachte ich die Antwort von FelixJN als gültig. Andernfalls würde ich – ähnlich wie samba– wahrscheinlich dasselbe Setup verwenden, das ich normalerweise verwende, nämlich eine gehärtete Version der Standardkonfiguration. Ich kann mich nicht erinnern, viele Einstellungen dafür geändert zu haben, also werde ich versuchen, herauszufinden, welche Einstellungen ich normalerweise genau ändere, und sie hier einfügen. Aus dem Kopf weiß ich, dass ich die Portnummer ändere, aber das ist nicht so wichtig.

Als ich die Ablehnung bestätigte ssh, war ich überrascht, dass LM19 passwddas Flag (Force) anscheinend nicht unterstützt. -fSo konnte ich seltsamerweise nur einen Nicht-Root-Benutzer mit leerem Passwort auf Fedora erstellen. Als ich versuchte, von der LM19-Box auf Fedora zuzugreifen ssh, wurde dies abgelehnt:

    $ ssh -p 2468 fred@fedora-testbox
    fred@fedora-testbox's password: 
    Permission denied, please try again.
    fred@fedora-testbox's password: 
    Permission denied, please try again.

Abgesehen vom Port habe ich anscheinend auch die Mindestanzahl an zulässigen Chiffren/MACs/Kex-Algorithmen erhöht, reduziert LoginGraceTime/ MaxAuthTries/ MaxSessions, gesetzt PermitRootLogin no/ UsePAM yes/ ChallengeResponseAuthentication no. Für PermitEmptyPasswords:nein schien die Standardeinstellung zu seinaber ich hatte mich deutlich gemacht.

Antwort1

Der wichtigste praktische Grund, der mir einfällt, ist, dass manche Netzwerksoftware es jemandem ermöglichen könnte, sich ohne Passwort aus der Ferne bei Ihrem Computer anzumelden. Das Risiko liegt nicht so sehr in der Software, die Sie kennen, sondern in der Software, an die Sie nicht gedacht haben. Vielleicht in der Software, die mit Ihrer Distribution geliefert wurde.

Bei passwortlosen Benutzern ist es Ihre Aufgabe, jeden mit dem Netzwerk verbundenen Dienst auf Ihrem Computer zu überprüfen, um festzustellen, ob eine Remote-Anmeldung ohne Passwort möglich ist.

Ein allgemeines Sicherheitsprinzip besteht darin, dass Dinge „fehlschlagen“ sollen, indem alle ausgesperrt werden, anstatt jemanden hereinzulassen. Wenn Sie passwortlose Benutzer haben, besteht eine größere Gefahr, dass durch Fehler und einfache Versehen irgendwo eine Hintertür geöffnet wird.

Ein solches Beispiel könnten E-Mail-Server sein. Wenn Sie eine Maschine mit einer öffentlichen IPv4-Adresse haben, dann gibt es garantiertWillewöchentliche oder sogar tägliche Versuche, sich bei SMTP anzumelden. Hacker durchsuchen einfach jede einzelne IPv4-Adresse auf der Suche nach einem anfälligen Rechner (es gibt nur 4 Milliarden Adressen).

Das Gleiche gilt für SSH. OpenSSH ist so konfiguriert, dass Anmeldeversuche ohne Passwort (ohne Authentifizierung) abgelehnt werden, also ist das höchstwahrscheinlich sicher. Aber ich sehe jeden Tag ein paar Versuche von Hackern, die versuchen, einen Benutzernamen mit einem leeren Passwort zu finden. Sie gehen einfach Tausende gängiger Benutzernamen durch, in der Hoffnung, Glück zu haben.

Antwort2

Diese Aspekte würde ich grundsätzlich berücksichtigen:

  1. Fernzugriff:

Wenn Sie über Fernzugriffsoptionen wie „ sshAktiv“ verfügen, steht Ihnen dies aus offensichtlichen Gründen offen. In diesem Fall gelten insbesondere die Punkte 2 und 3.

  1. Datenschutz und Sicherheit:

Ihr Benutzer legt Informationen offen, die möglicherweise nicht für unberechtigte Benutzer zugänglich sein sollten, und natürlich können Ihre Daten von jedem gelöscht werden. Manche Leute sind einfach destruktiv.

  1. Systemsicherheit:

Natürlich hat der Benutzer offiziell keine Administratorrechte, aber kein System ist unhackbar. Sobald jemand als Benutzer Zugriff hat, kann ihn niemand daran hindern, Malware hochzuladen, Sicherheitslücken auszunutzen, Programme lokal zu kompilieren und dann in das System einzudringen ...

Es kommt darauf an, wie viele Steine ​​Sie jemandem in den Weg legen möchten.

Die Frage ist also, warum man einen Benutzer ohne Passwort einrichten sollte, wenn man auch eine automatische Anmeldung einrichten und so zumindest einige dieser Risiken vermeiden könnte, wodurch der Bedarf an physischem Zugriff so hoch wie möglich wäre?

verwandte Informationen