出于安全原因,重命名/ etc / passwd和/ etc / shadow [关闭]


8

我有一台服务器。我的服务器是安全的,但让我们想象一下有一个很好的黑客可以入侵。他现在可以调查/etc/passwd/etc/shadow。我想将该文件重命名/etc/passwd/etc/xxanoda

我以为我可以建立链接,但是对于黑客来说,这很容易做到ls -l

可以重命名这些文件,并且仍然具有运行中的操作系统,而不会出现兼容性问题,或者这完全没用吗?只是为了寻求知识。


1
我认为可以使用单独的身份验证服务器来保存所有用户密码。当用户尝试登录时,主服务器将与身份验证服务器联系。身份验证服务器与用户保持距离(不能直接访问Internet)。
ctrl-alt-delor

9
默默无闻的安全性根本不是安全性。
门把手2014年

这是一个可怕的,可怕的,可怕的想法。
沙杜尔

Answers:


29

文件系统层次标准的类Unix系统包括/etc/passwd在固定位置,和工具通常因而硬编码到那里寻找它。从理论上讲,您可以重新编译所有相关实用程序以查找新位置,但是任何攻击者始终可以仅在那些二进制文件中查找字符串来查找新文件,或者使用正则表达式查找具有passwd类似内容的文件。

shadow文件应仅可读取root(可能也可以读取到称为的组shadow)。如果攻击者设法获得了对系统的超级用户访问权限,则他们可以完全控制,并且此时是否可以读取您的passwd / shadow文件几乎无关紧要。

可以想到的是,在某些情况下,将文件放在不希望的地方可能会有所帮助,例如,如果您的Web服务器配置不当而使某人请求http://myserver/../../etc/passwd,但是通常这种间接访问将需要大量工作,以最大程度地降低安全性。


8
在最后一种情况下,最好是修复Web服务器……
Braiam 2014年

不过没关系,因为所有与本身没有密码,只有SSH密钥,并在服务器上帐户的用户密码信息不被存储在/etc/passwd,对吧?
Blacklight Shining

12

正如您所说,最好的事情是“完全没用”。(它不会为入侵者提供额外的障碍)

/etc/passwd 确实包含帐户名,但是任何具有外壳程序访问系统权限的人都可以找到它们。

/etc/shadow包含敏感信息(密码哈希),但仅root用户可以读取。如果入侵者获得了root特权-那么您如何拼写灾难


1
您还应该假设攻击者拥有对系统上每个文件的完全访问权限(并且可能会下载他们自己的副本),直到您另行知道为止。
伯特2014年

4
“你怎么拼写灾难?” 在您不必拼写灾难来询问的情况下,它可能会更好地工作:D

9

在现代的Unices(以及类似Unix的系统,包括Ubuntu)中,/etc/passwd不包含任何秘密。鉴于必须重新构建多少实用程序才能在新位置查找它,重命名它的麻烦多于其价值。

/etc/shadow这是另一回事,因为该文件中包含秘密,但是重命名它无济于事。它只能由root读取,因此即使黑客以其他用户身份进入系统,也不足以获取文件。这就是为什么首先删除密码的原因/etc/passwd:每个人都必须能够读取/etc/passwd,但是只有root用户才能获得实际的密码,因此密码被移到了只有root用户才能读取的文件中。

如果黑客确实拥有 root身份,则重命名不会保存您。一个简单的递归grep可以为黑客提供类似/etc/shadow格式的文件列表,然后黑客只需浏览它们即可找到他想要的数据。您最多将他延迟了几个小时,甚至可能更少:再次,这不值得花时间修改和重新编译所有依赖/etc/shadow位置的实用程序。


此外,如果他具有root用户访问权限,则不需要/不需要/任何其他人的密码。他可以使用su自己想要的任何帐户,也可以更改系统上任何用户的密码。如果他真的想拥有密码(以防用户在其他地方重用密码),他可以上传修改后的login二进制文件或添加一个pam模块来拦截身份验证尝试并将用户名/密码组合中继给他。
Shadur 2014年

2

您不能仅重命名这些文件。许多进程和程序都会搜索它们,因为这是Linux系统中的标准。您可以做的就是以正确的方式保护服务器的安全。


我只是想增加安全性,我的服务器上有多个网站。
Marco Caggiano 2014年

2

虽然重命名/etc/passwd/etc/shadow文件可能没有用,但是如果您想提高安全性,则可能需要查看PAM(可插拔身份验证模块)和NSS(名称服务开关)。像这儿。

PAM可用于添加身份验证模块,而不是从标准文件读取身份验证规范,而是从其他来源(例如ldap或数据库)读取身份验证模块。使用它意味着/etc/shadow几乎可以完全淘汰。

NSS通过使一些名称解析的补充PAM(如这组该用户是否属于)独立于标准文件(/etc/passwd/etc/groups)。使用它意味着您的passwd文件可能仅包含root用户的后备选项,仅此而已。使用SSH密钥来验证root登录也可以消除在影子文件中使用root密码的需要(尽管如果SSH连接中断,可能需要这样做)。

另外,如果您不想通过单独的数据库或ldap主机对用户进行身份验证,也可以创建自己的PAM和NSS模块,它们从非标准文件中读取其数据,尽管我不建议使用此选项。

当您想使用它们时,请不要忘记对已知的,有效的身份验证层进行某种回退,否则,即使使用root用户,也可以将自己锁定在系统之外。

请注意,并非所有应用程序都支持PAM(但是很多应用程序都支持PAM)。但是,NSS可用于为不支持PAM的应用程序实施身份验证,而我所读过的有关NSS的某些网站实际上建议采用这种方法。但是,这意味着NSS模块将向可能访问NSS身份验证层的任何人提供(潜在地)哈希密码,这几乎总是您要避免的事情(它与为影子文件提供非root用户读取权限基本相同) )!因此,如果要采用这种方法,请务必确保NSS仅用于向用户提供基本数据(如的内容/etc/passwd),而PAM用作身份验证层。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.