☰

为什么没有密码的用户是一个坏主意（在这种情况下）？

tag-icon • tag-icon security users password non-root-user privileges
为什么没有密码的用户是一个坏主意（在这种情况下）？

我考虑过是否将其发布在这里或在安全​​ SE 中...但决定使用 Unix SE，因为这实际上并不是一个关于密码学的问题，而是更多关于 Linux 用户/权限的问题。也许我的谷歌今天很弱，但到目前为止我遇到的唯一的事情

  1. 在没有任何具体例子的情况下，对这是一种“不好的做法”或“不受欢迎”做出非常笼统的回答，或者
  2. 有回复假设没有密码的用户具有 root 访问权限或以其他方式放弃所有可能的保护。

需要明确的是：我并不是提倡这样做，而是实际上在寻找正当理由不是这样做，但我想找到具体的原因，而不仅仅是“这很糟糕”。 :-)

因此，让我举一个实际上让我首先思考这个问题的例子：

假设我正在考虑设置一个家庭系统，我的帐户有一个强密码root。另外，我还会有一个名为 fred 的非 root 帐户那是不是在管理员组中wheel（或sudoers在 Debian / Ubuntu 上）。在此系统上，我还将拥有/home一个单独的 LUKS 加密分区，该分区在启动过程中会解锁。换句话说，密码做仍然在 GRUB 和登录管理器之间输入 - 但登录管理器设置为自动登录。除此之外，假设我还进行了设置（从根目录）：password -f -u fred：强制解锁的密码fred（有效地使fred密码为空）。

在这种情况下我可能会遇到哪些类型的安全问题？感觉你不想这样做应该有一些充分的理由。但是仅有的到目前为止我想到的是：

  • 当屏幕保护程序锁定触发时，LUKS 分区不会关闭（至少在 Cinnamon 上并假设一个是设置为触发）。因此，如果有人闯入我的房子并且fred已经登录，他们可以坐下来打开显示器，然后继续查看fred可以访问的任何内容 - 只要他们没有先拔掉/重新启动/带走电脑（从而重新锁定LUKS）。我怀疑，如果我足够努力，我也许可以找到一种方法，在触发屏幕保护程序时调用脚本，然后从所述脚本中锁定 LUKS，从而关闭这个漏洞（或者也许 kde/xfce/gnome/etc 已经有某种方法了）来处理这个？）。

即使fred有一个很好的强密码，如果不是管理员，他也无法安装软件/弄乱系统设置。而且，我不确定，但我认为浏览器/Wine 对文件的访问不会以任何方式改变。这里还有比如果更危险的事情吗？fred 做过有密码吗？

编辑：我认为这并不重要，但发行版是 Fedora（启用了 SELinux），但如果您觉得回答其他发行版（或不启用 SELinux）更舒服，那也没关系。

编辑#2：关于ssh/ samba。我通常会设置类似/media/sdb1/shared文件夹之类的东西，而不是使用 samba 的$HOME共享或任何名称。我发现这在像家里这样的小型用户环境中相当容易设置（我显然不会在工作环境或并非所有用户都相互信任的环境中执行此操作）。但我总是使用单独的、受密码保护的 samba 用户帐户（与登录的用户帐户不同），并且我遵循一些强化smb.conf设置的指南。如果您发现此设置中的缺陷，我将认为它们对于在登录帐户上使用空白密码攻击假设场景/设置是有效的fred（记住 samba 帐户密码是不是虽然是空​​白）。

对于ssh，我想确认默认情况下拒绝空白密码全部帐户（不仅仅是root）。如果没有，那么我会认为 FelixJN 的答案是有效的。否则，我会 - 类似于samba- 可能使用我通常使用的相同设置，这是默认配置的强化版本。我不记得为此更改了许多设置，因此我将尝试查看是否可以准确找到我通常修改的设置并将其包含在此处。我不知道，我知道我更改端口号并不重要。

在确认ssh拒绝时，我惊讶地发现 LM19passwd似乎不支持-f（强制）标志，所以奇怪的是我只能在 fedora 上创建一个空白密码非 root 用户。当我尝试ssh从 LM19 box 到 fedora 时，被拒绝了：

    $ 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.

除了端口之外，看起来我还增加了可接受的最小密码/MAC/KexAlgorithms，减少了// LoginGraceTime，设置了// 。为了：MaxAuthTriesMaxSessionsPermitRootLogin noUsePAM yesChallengeResponseAuthentication noPermitEmptyPasswordsno 似乎确实是默认值但我已经明确表示了。

答案1

我能想到的最大的实际原因是某些网络软件可能允许某人无需密码即可远程登录您的计算机。风险不在于您了解的软件，而在于您没有考虑到的软件。也许是您的发行版附带的软件。

对于无密码用户，您的工作是检查计算机上的每个网络连接服务，看看它是否允许无需密码的远程登录。

一般的安全原则是，您希望通过将所有人锁定在外面而不是让任何人进入来“失败”。如果您有无密码的用户，那么错误和简单的疏忽更容易在某个地方解锁某些后门。

一个例子可能是电子邮件服务器。如果你有一台有公共 IPv4 地址的机器，那么可以保证，将要每周甚至每天尝试登录 SMTP。黑客只需遍历每个 IPv4 地址来寻找易受攻击的机器（地址只有 40 亿个）。

同样的 SSH。 OpenSSH 配置为拒绝没有密码（无需身份验证）的登录尝试，因此这很可能是安全的。但我每天都会看到一些黑客试图找到密码为空的用户名。他们只是循环使用数千个常见的用户名，希望能获得幸运。

答案2

我一般会考虑这几个方面：

  1. 远程访问：

如果您有任何远程访问选项，例如ssh主动访问，那么出于显而易见的原因，这是一扇敞开的大门。在这种情况下，第 2 点和第 3 点尤其适用。

  1. 数据隐私和安全：

您的用户暴露了非特权用户可能不应该获得的信息，当然您的日期可能会被任何人删除。有些人只是破坏性的。

  1. 系统安全：

当然，正式用户没有管理员权限，但没有系统是不可破解的。一旦有人以用户身份访问，没有人会阻止他们上传恶意软件、利用安全漏洞、在本地编译程序，然后破坏系统......

这取决于你愿意在别人的道路上扔多少块石头。

所以问题是，当您还可以进行自动登录并至少避免其中一些风险，从而使物理访问的需求尽可能高时，为什么还要使用非密码用户呢？

相关内容