Warum benötigt der Benutzer 'bin' eine Anmeldeshell?

Während eines Audits /var/log/auth.logauf einem meiner öffentlichen Webserver fand ich Folgendes:

Jan 10 03:38:11 Bucksnort sshd[3571]: pam_unix(sshd:auth): authentication failure; 
    logname= uid=0 euid=0 tty=ssh ruser= rhost=61.19.255.53  user=bin
Jan 10 03:38:13 Bucksnort sshd[3571]: Failed password for bin from 61.19.255.53 
    port 50647 ssh2

Auf den ersten Blick sieht dies wie typischer sshLogin-Spam von zufälligen Hackern aus. Als ich genauer hinsah, bemerkte ich jedoch etwas anderes. In den meisten fehlgeschlagenen /var/log/auth.logEinträgen heißt invalid useres wie folgt:

Jan  9 10:45:23 Bucksnort sshd[3006]: Failed password for invalid user sales 
    from 123.212.43.5 port 10552 ssh2

Die beunruhigende Sache über diese Login - Nachricht fehlgeschlagen für binist , dass es sich um eine gültige Benutzer in /etc/passwddiesem selbst hat eine Login - Shell:

[mpenning@Bucksnort ~]$ grep ^bin /etc/passwd
bin:x:2:2:bin:/bin:/bin/sh

Ich dachte , ich bedeckt hatte , die alle Standardbenutzernamen , die remote könnte anmelden , wenn ich deaktiviert PermitRootLoginin /etc/ssh/sshd_config; das entdecken dieses eintrags eröffnete neue möglichkeiten in meinem paranoiden verstand. Wenn irgendwie Dienste binunterliefen, ist es aus der Ferne möglich, dass jemand einen SSH-Schlüssel binaus einem auf der Box ausgeführten Dienst in das Benutzerverzeichnis einfügt, sodass ich die Anmeldung für den binBenutzer nach Möglichkeit vollständig deaktivieren möchte .

Fragen

• Dieser Server ist remote und teuer zu reparieren (dh ich bezahle für Remote-Hände, um eine KVM plus KVM-Miete anzuschließen). Ich versuche herauszufinden, was ich brechen könnte, wenn ich den /etc/passwdEintrag so ändere bin:

  bin:x:2:2:bin:/bin:/bin/false

• Ich habe die folgenden Befehle ausgeführt, um herauszufinden, wofür sie binbenötigt werden ... Diese Befehle enthielten jedoch keine Dateien und ich konnte keine Prozesse finden, deren Eigentümer ich war bin. Was macht der binBenutzer überhaupt?

  $ sudo find / -group bin

  $ sudo find / -user bin

• Gibt es andere Benutzer, deren Login-Shells auf festgelegt werden sollen /bin/false? Zu Ihrer Information, ich habe bereits /bin/falseauf www-data.

• Bin ich zu paranoid?

Ich verwende Debian, wenn es darauf ankommt.

Ein Benutzer, der über eine gültige Shell und kein Kennwort verfügt, kann sich weiterhin mit nicht kennwortbasierten Methoden anmelden, wobei der häufigste ein SSH-Schlüssel ist. Eine gültige Shell ist erforderlich, um Cron-Jobs auszuführen. Eine gültige Shell ist auch erforderlich, um su bin -c 'wibble'zu arbeiten (zumindest unter Linux su bin -s /bin/sh -c 'wibble'wird es auch funktionieren).

Im Fall von führen die binmeisten Systeme niemals einen Befehl wie binim normalen Betrieb aus, daher /bin/falsewäre es in Ordnung , die Shell auf "OK" zu setzen.

Es besteht kein Risiko, dass ein direkter Angriff das binAnmelden über SSH ermöglicht, da dies das Erstellen /bin/.ssh/authorized_keysals Benutzer binoder als Root erforderlich macht . Mit anderen Worten, der einzige Weg, um einzusteigen, besteht darin, einzusteigen. Eine gültige Shell erhöht jedoch das Risiko einer Fehlkonfiguration. Es kann auch einige Remote-Angriffe mit anderen Diensten als SSH zulassen. Ein Benutzer meldet beispielsweise , dass ein Angreifer ein Kennwort für die daemonRemote-Anmeldung über Samba festlegen und dieses Kennwort dann für die Anmeldung über SSH verwenden könnte.

Sie können die SSH-Lücke schließen, indem Sie die Namen der Systembenutzer in einer DenyUsersDirektive /etc/ssh/sshd_configangeben (Sie können leider keinen numerischen Bereich verwenden). Umgekehrt können Sie eine AllowGroupsDirektive setzen und nur die Gruppen zulassen, die physische Benutzer enthalten (z. B. userswenn Sie all Ihren physischen Benutzern diese Gruppenmitgliedschaft gewähren).

In Debian ( Nr. 274229 , Nr. 330882 , Nr. 581899 ) sind Fehler bezüglich dieses Problems aufgetreten , die derzeit offen sind und als "Wunschliste" klassifiziert sind. Ich stimme eher zu, dass dies Fehler sind, die Systembenutzer /bin/falseals Shell haben sollten, es sei denn, es erscheint notwendig, etwas anderes zu tun.

Sie müssen sich nicht um diese als Benutzer kümmern. Sie sind "Benutzer" im Sinne von Sicherheitsgruppen, keine Benutzer im Sinne von "Anmelden und Verwenden". Wenn Sie in "/ etc / shadow" nachsehen, werden Sie feststellen, dass all diese "Benutzer" keine Passwörter haben (entweder "x" oder "!" Anstelle eines langen gesalzenen Hashes). Dies bedeutet, dass sich diese Benutzer nicht anmelden können, egal was passiert.

Trotzdem weiß ich nicht, ob es eine gute Idee ist, "/ bin / sh" für alle diese Benutzer in "/ bin / false" zu ändern. Da Programme unter diesen Gruppen ausgeführt werden, können sie möglicherweise nicht die erforderlichen Befehle ausführen. Ich würde sie als "/ bin / sh" belassen.

Sie müssen sich keine Sorgen um diese Benutzer machen. Sorgen Sie sich nur um die Benutzer, die Sie erstellen (und diejenigen mit Hashes in "/ etc / shadow")

Ich glaube, dies ist kein Problem, da der Angreifer zum Einrichten eines öffentlichen SSH-Schlüssels im binHome-Verzeichnis /bindes Benutzers ( ) root-Zugriff auf das Dateisystem haben muss, was bedeutet, dass Sie sowieso geschraubt sind.

Wenn Sie binmöchten , können Sie alle Authentifizierungsmethoden für den Benutzer in der Konfiguration von sshd mithilfe des MatchUserBlocks deaktivieren .

Das heißt, es sieht so aus, als ob der bin-Benutzer auf modernen, von Debian abgeleiteten Systemen nicht verwendet wird und lediglich eine Anspielung auf die Tradition ist oder zur Einhaltung einiger Standards da ist.