☰

在 Unix 系統上，綁定到連接埠 < 1024 只授權給 root 是否還有原因？

tag-icon • tag-icon security unix ip socket
在 Unix 系統上，綁定到連接埠 < 1024 只授權給 root 是否還有原因？

在 Unix 系統上，拒絕從沒有 root 權限的程序綁定到 < 1024 的 TCP 連接埠。

最初的原因是什麼？

例如，http 伺服器不需要 root 權限來提供 html 頁面。

Unix 用戶需要什麼進程/協定來確保它以 root 特權運行？

謝謝

答案1

此連接埠範圍不應由程式設計師定義。
這是由 IANA 保留,

眾所周知的連接埠是從 0 到 1023 的連接埠。

DCCP 知名埠未經 IANA 註冊不得使用。註冊程序在 [RFC4340] 第 19.9 節中定義。

如有不同意見請核對，

  1. 來自一個Linux問題線程（閱讀連結以獲取更多上下文）

    埠 1024 限制實際上是自取其辱。它強制執行可能會開啟安全漏洞的守護程序實踐，從而使限製作為安全措施無效。

    • 這SANS Top 20 漏洞筆記

      一些核心系統服務透過遠端過程呼叫 (RPC) 為客戶端元件提供遠端介面。它們主要透過可透過通用 Internet 檔案系統 (CIFS) 協定、眾所周知的 TCP/UDP 連接埠以及某些情況下的臨時 TCP/UDP 連接埠存取的命名管道端點公開。從歷史上看，服務中存在許多可被匿名用戶利用的漏洞。一旦被利用，這些漏洞就會為攻擊者提供與該服務在主機上擁有的相同權限。

如今，像這樣的協議BT和Skype已透過臨時連接埠移至未保留的空間，並且無需進行 root 存取。目標是不僅僅是繞過這個舊的保留端口安全;今天的協議想要甚至繞過網路邊界（Skype 就是一個很好的例子）。隨著網路頻寬和可用性的增加，事情會進一步發展，每個電腦使用者都可能會自行運行網路伺服器- 和或許,不知不覺地， 是的一部分 殭屍網路。

我們需要這些舊方法所需的安全性
，但現在需要用更新的方法來實現。

答案2

嗯，據我回憶，BSD Unix 時代的最初想法是，< 1024 的端口預計將保留給“眾所周知的服務”，並且假設仍然是服務器相對較少，並且具有 root 權限的人會被認為在某種程度上是「可信的」。因此，您必須具有特權才能綁定套接字以偵聽代表其他使用者將存取的網路服務的連接埠。

連接埠 1024-4999 旨在用作代表 TCP 連線客戶端的「臨時」連接埠。連接埠 5000+ 用於非根伺服器。

顯然，所有這些假設很快就消失了。檢查 IANA TCP 連接埠號碼保留列表，以了解情況到底有多高。

這個問題的一個解決方案是 RPC 連接埠映射器的想法。該服務不會為每個服務保留 TCP 端口，而是會在隨機端口上啟動並告訴端口映射器守護進程它正在偵聽的位置。客戶端會詢問連接埠對映器「服務 X 在哪裡」正在偵聽並從那裡繼續。我不記得採用了哪些安全機制來保護眾所周知的 RPC 服務免遭假冒。

我不確定現在這一切是否有充分的理由，但就像大多數 *nix 世界一樣，事情往往會積累，而不是完全重新發明。

有人讀過弗諾·文奇嗎？我記得他在一本小說中寫到，關於遙遠未來的電腦系統，包含了來自遠古時代的層層代碼，時間仍然用自某個遠古日期（1970 年1 月1 日）以來的秒數來表示。他可能已經不遠了。

答案3

過去，一般使用者習慣登入 Unix 機器。所以你不會希望普通用戶設定假的 ftp 服務或其他東西。

如今，典型的用法是只有管理員和其他一些受信任的人可以登入伺服器，因此如果今天重做模型，< 1024 限制可能不存在。

答案4

對於接受系統密碼的服務來說，在特權連接埠上運行是有意義的；這意味著擁有 shell 帳戶的用戶無法在同一連接埠上設定「虛假」服務來捕獲人們的登入詳細信息，也無法透過在同一連接埠上設定非功能性服務來拒絕存取。

如果您有一個多用戶機器，並且非特權用戶能夠設定惡意 ssh 守護進程，他們可能能夠捕獲其他用戶的密碼並獲得對其帳戶的存取權限（當然，他們必須在合法的ssh 守護進程已關閉，可能是為了維護或在系統啟動或關閉期間）

不接受系統密碼的東西並不那麼重要，儘管在多用戶盒子上的用戶之間共享諸如網絡伺服器之類的東西存在重大安全問題（正如共享託管提供商所發現的那樣）

相關內容