☰

为什么在 Unix 系统上只有 root 才被授权绑定到端口

tag-icon • tag-icon security unix ip socket
为什么在 Unix 系统上只有 root 才被授权绑定到端口

在 Unix 系统上，没有 root 权限的进程绑定到 tcp 端口 <1024 会被拒绝。

最初的原因是什么？它仍然有效吗？

例如 http 服务器不需要 root 权限来提供 html 页面。

Unix 用户需要确保哪个进程/协议以 root 权限运行？

谢谢

答案1

该端口范围不应由程序员定义。
它是由 IANA 保留，

知名端口是从 0 到 1023 的端口。

未经 IANA 注册，不得使用 DCCP 知名端口。注册程序定义在 [RFC4340] 第 19.9 节中。

如有不同意见，请检查

  1. 从linuxquestions 主题（阅读链接了解更多背景信息）

    1024 端口限制实际上会给自己带来麻烦。它强制执行守护进程操作，这可能会打开安全漏洞，从而使限制作为安全措施无效。

    • 这SANS 前 20 个漏洞笔记

      一些核心系统服务通过远程过程调用 (RPC) 为客户端组件提供远程接口。它们主要通过可通过通用 Internet 文件系统 (CIFS) 协议、众所周知的 TCP/UDP 端口以及某些情况下的临时 TCP/UDP 端口访问的命名管道端点来公开。从历史上看，服务中存在许多可被匿名用户利用的漏洞。一旦被利用，这些漏洞将使攻击者获得与主机上的服务相同的权限。

如今，诸如比特流和Skype已经通过临时端口移至未保留空间，并且不需要 root 访问权限。目标是不仅仅是绕过这个旧的保留端口安全；今天的协议想要甚至绕过网络边界（Skype 就是一个很好的例子）。随着网络带宽和可用性的提高，情况将进一步恶化，届时每个计算机用户都可能自行运行 Web 服务器- 和或许，不知不觉地， 是的一部分 僵尸网络。

我们需要这些旧方法所需的安全性
，但现在需要采用新方法来实现。

答案2

嗯，我记得 BSD Unix 时代的最初想法是，小于 1024 的端口应该保留给“众所周知的服务”，并且仍然假设服务器相对较少，并且具有 root 权限的人在某种程度上被认为是“值得信赖的”。因此，您必须拥有权限才能绑定套接字以侦听代表其他用户将访问的网络服务的端口。

端口 1024-4999 旨在用作“临时”端口，代表 TCP 连接的客户端。端口 5000 以上用于非根服务器。

显然，所有这些假设都很快被推翻了。查看 IANA TCP 端口号预留列表，看看情况到底有多糟。

解决这个问题的一个方法是 RPC 端口映射器。服务不会为每个服务保留一个 TCP 端口，而是在随机端口上启动并告诉端口映射器守护程序它正在监听的位置。客户端会询问端口映射器“服务 X 在哪里监听”，然后从那里继续。我不记得当时有什么安全机制可以保护众所周知的 RPC 服务免遭冒充。

我不确定现在发生这一切是否有一个好的理由，但就像大多数 *nix 世界中的事物一样，事物往往会不断积累，而不是彻底重塑。

有人读过 Vernor Vinge 的作品吗？我记得他在一本小说中写到，未来计算机系统采用了来自古代的层层代码，时间仍然以某个古老日期（确切地说是 1970 年 1 月 1 日）以来的秒数来表示。他可能说得并不离谱。

答案3

过去，普通用户习惯登录 Unix 计算机。因此，您不会希望普通用户设置虚假的 ftp 服务或类似的东西。

目前，典型的用法是只有管理员和少数其他受信任的人才能登录服务器，因此如果今天重新做模型，则可能不存在 < 1024 的限制。

答案4

接受系统密码的服务在特权端口上运行是有意义的；这意味着具有 shell 帐户的用户不能在同一端口上设置“虚假”服务来捕获人们的登录详细信息，或者通过在相同端口上设置非功能性服务来拒绝访问。

如果您有一个多用户机箱，并且一个非特权用户能够设置恶意 ssh 守护程序，他们可能能够捕获其他用户的密码并访问他们的帐户（当然，他们必须在合法的 ssh 守护程序关闭时执行此操作，可能是为了维护或在系统启动或关闭期间）

不接受系统密码的东西并不那么重要，尽管在多用户机箱上的用户之间共享诸如 Web 服务器之类的东西存在重大的安全问题（正如共享主机提供商所发现的那样）

相关内容