/ usr / sbin / nologin作为登录shell是否出于安全目的？

在我的/etc/passwd文件中，我可以看到www-dataApache所使用的用户以及各种系统用户都具有/usr/sbin/nologin或/bin/false作为其登录外壳。例如，以下是几行：

daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
games:x:5:60:games:/usr/games:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
syslog:x:101:104::/home/syslog:/bin/false
whoopsie:x:109:116::/nonexistent:/bin/false
mark:x:1000:1000:mark,,,:/home/mark:/bin/bash

因此，如果我尝试交换这些用户中的任何一个（有时我想检查我对他们的权限的了解，并且可能还有其他至少至少一半的理智的原因），则我将失败：

mark@lunchbox:~$ sudo su www-data
This account is currently not available.
mark@lunchbox:~$ sudo su syslog
mark@lunchbox:~$ 

当然，这不算什么麻烦，因为我仍然可以通过这样的方法为他们启动外壳程序：

mark@lunchbox:~$ sudo -u www-data /bin/bash
www-data@lunchbox:~$ 

但这让我想知道拒绝这些用户的登录外壳将达到什么目的。环顾互联网进行解释，许多人声称这与安全性有关，并且每个人似乎都同意更改这些用户的登录外壳在某种程度上是个坏主意。这是引号的集合：

将Apache用户的shell设置为非交互式通常是一种很好的安全做法（实际上，所有不必交互式登录的服务用户都应将其shell设置为非交互式）。

- https://serverfault.com/a/559315/147556

用户www-data的shell设置为/ usr / sbin / nologin，这是有充分理由的。

- https://askubuntu.com/a/486661/119754

[系统帐户] 可能是安全漏洞，尤其是在启用了外壳程序的情况下：

• 坏

  bin:x:1:1:bin:/bin:/bin/sh

• 好

  bin:x:1:1:bin:/bin:/sbin/nologin

- https://unix.stackexchange.com/a/78996/29001

出于安全原因，我创建了一个没有登录外壳程序的用户帐户来运行Tomcat服务器：

# groupadd tomcat
# useradd -g tomcat -s /usr/sbin/nologin -m -d /home/tomcat tomcat

- http://www.puschitz.com/InstallingTomcat.html

尽管这些帖子一致同意不给系统用户真实的登录外壳对安全性有好处，但没有一个可以证明这一主张是正当的，我无法在任何地方找到对此的解释。

我们试图通过不给这些用户真实的登录Shell来保护自己免受什么攻击？

如果查看nologin手册页，将看到以下描述。

摘抄

nologin显示一条消息，提示帐户不可用，并且退出非零值。它旨在作为替换外壳程序字段来拒绝对帐户的登录访问。

如果文件/etc/nologin.txt存在，则nologin向用户显示其内容，而不是默认消息。

返回的退出代码nologin始终为1。

因此，的实际意图nologin是，当用户尝试使用在中使用该帐户的帐户登录时，会向其/etc/passwd显示一条用户友好的消息，并且会尝试使用任何脚本/命令来使用此登录名的退出代码为1。

安全

关于安全性，您通常/sbin/nologin会/bin/false在该字段中看到或者有时看到。它们都有相同的目的，但/sbin/nologin可能是首选方法。无论如何，他们都以该特定用户帐户的形式限制对Shell的直接访问。

为什么在安全性方面认为这很有价值？

“为什么”很难完全描述，但是以这种方式限制用户帐户的价值在于，login当您尝试使用该用户帐户获取访问权限时，它会阻止通过应用程序进行的直接访问。

使用nologin或/bin/false完成此操作。限制系统的攻击面是安全领域中的一种常用技术，无论是禁用特定端口上的服务还是限制系统上登录的性质。

仍然有其他合理使用的理由nologin。例如，scp将不再使用未指定实际外壳的用户帐户，如此ServerFault常见问题解答标题为：/ sbin / nologin和/ bin / false之间有什么区别？。

绝对可以达到安全目的。例如，查看以下针对具有外壳程序的系统用户所提交的错误。

由于守护程序帐户具有有效的登录Shell并已打开samba进行互联网访问，因此我的debian服务器受到了威胁。通过使用samba远程设置守护程序帐户的密码并通过ssh登录来进行入侵。然后使用一些本地根漏洞利用自己的服务器。

我建议您阅读Gilles的精彩解答，他还提供了一些错误的链接。

在Debian（274229，330882，581899）中已针对此问题提交了一些错误报告，目前已打开并归类为“收藏夹”。我倾向于同意这些是错误，并且系统用户应将/ bin / false作为其外壳，除非另有必要。

要添加到@slm和@ramesh的出色答案：

是的，正如您所指出的，您仍然可以通过运行sudo已定义的外壳程序来切换到将nologin用作默认外壳程序的用户，但是在这种情况下，您必须：

1. 以具有有效外壳程序的其他用户身份登录
2. 为该用户配置sudo权限以运行su命令，并且
3. 如果您的su尝试已记录到sudoers日志中（当然假设已启用sudo日志记录）。

将nologin定义为其默认外壳的用户通常具有比普通用户更高的特权/能够对系统造成更大的破坏，因此让他们无法直接登录尝试限制因破坏系统而遭受的破坏。 。

除了给出的出色答案之外，它还具有其他目的。

如果在服务器上运行FTP守护程序，它将检查尝试登录的用户的登录Shell。如果外壳未在中列出/etc/shells，则不允许他们登录。因此，给守护程序帐户一个特殊的shell可以防止某人通过FTP修改帐户。

除了已经给出的好答案之外，我还可以考虑以下情形。

以受限用户身份运行的服务中的安全漏洞允许以该用户身份写入文件。该文件可以是〜/ .ssh / authorized_keys。

这使攻击者可以直接在shell中登录，这将使执行特权升级变得更加容易。

禁止登录外壳会使此选项更加困难。

通常，我会说/ bin / false和/ sbin / nologin是相同的-但我想这取决于您所使用的SSH服务器。

请谨慎地指出，最近对OpenSSH的这种利用似乎会影响/ bin / false登录，但不会影响/ sbin / nologin。但是，它指出Dropbear在这种方式上有所不同（此漏洞也专门适用于OpenSSH）。

漏洞利用会影响大多数版本：

7.2p1及更低版本（所有版本；可追溯至20年）启用X11转发

https://www.exploit-db.com/exploits/39569/

因此，基于此-我个人将执行/ sbin / nologin，但是我不确定这是否会影响在/ etc / passwd中创建/ bin / false条目的服务。您可以进行实验并查看结果，但后果自负！我想在最坏的情况下，您可以将其改回并重新启动任何受影响的服务。我个人使用/ bin / false有很多条目-不知道是否要打扰一下，因为我没有启用X11转发；）

如果您使用OpenSSH（我认为很多人...）并且启用了X11转发-您不妨考虑使用/ sbin / nologin（或切换到Dropbear）。

通常，将服务和应用程序帐户设置为非交互式登录是一种很好的安全措施。授权用户仍然可以使用SU或SUDO访问这些帐户，但是在Sudoers日志文件中会跟踪他们的所有操作，并且可以追溯到以服务帐户特权执行命令的用户。这就是为什么将日志文件存储在集中式日志管理系统中以使系统管理员无权访问更改日志文件的原因。在SU或SUDO下执行命令的用户已被授权访问系统。

另一方面，系统的外部或未经授权的用户将完全无法使用这些帐户登录，这是一种安全措施。

是的，它具有安全性。这是一种纵深防御措施。

其用途的核心原因是，有各种各样的软件可以验证指定用户的某种形式的登录凭据，然后使用该用户的登录外壳来运行命令。也许最著名的例子是SSH。如果您通过SSH成功​​验证了用户身份，则SSH然后启动用户的登录外壳程序（或使用它来运行您提供的命令（如果使用ssh someuser@example.com 'command to run'语法））。

当然，理想情况下，攻击者根本无法认证为用户。但是，假设发生以下情况：

• 您控制的服务器以具有主目录和登录外壳程序的用户身份运行Web服务
• 攻击者在该服务中发现一个漏洞，该漏洞使攻击者可以将文件写入用户的主目录

现在，您的攻击者可以将SSH公共密钥写入~/.ssh/authorized_keys，然后进行SSH输入，然后-繁荣！-他们可以通过外壳访问您的服务器。

如果用户改为/usr/sbin/nologin将其作为登录外壳，那么即使攻击者成功将公钥写入authorized_keys，它对他们也没有用。它允许他们做的所有事情都是远程运行的nologin，这不是很有用。他们无法获得炮弹，他们的攻击已得到缓解。

万一这种情况看起来非常假想，我想指出的是，正是在我问了这个问题大约一年后的2015年某个时候，我正是这次攻击的目标。就像该死的白痴一样，我离开了Redis实例，没有向世界公开任何密码。它受到Redis Crackit攻击的攻击，攻击者在该攻击中将 SSH公钥插入您的Redis数据库，然后发送命令告诉Redis将数据库内容写入.ssh/authorized_keys，然后尝试SSH。我自己的无能仅是因为redis-serverApt软件包的维护者（我曾用于安装Redis）才具有使它作为Redis运行的智慧。redis没有主目录或登录外壳的用户；如果不是他们，我的服务器可能已经被勒索软件了，或者最终成为了某些黑客僵尸网络的一部分。

这段经历使我感到有些谦卑，并使我意识到纵深防御的重要性，尤其是不要为运行Web服务器，数据库和其他后台服务的帐户授予登录Shell。