您可以通過手動編輯文件或呼叫命令來設置Postgres 的各種配置參數。postgresql.confALTER SYSTEM

這些配置設置之一是listen_addresses. 引用文件：

指定伺服器用於偵聽來自客戶端應用程序的連接的 TCP/IP 地址。該值採用逗號分隔的主機名和/或數字 IP 地址列表的形式。特殊條目 * 對應於所有可用的 IP 介面。條目 0.0.0.0 允許監聽所有 IPv4 地址， :: 允許監聽所有 IPv6 地址。如果列表為空，則伺服器根本不會偵聽任何 IP 介面，在這種情況下，只能使用 Unix 域套接字連接到它。預設值為 localhost，它只允許建立本地 TCP/IP “環回”連接。雖然客戶端身份驗證（第 20 章）允許對誰可以訪問伺服器進行細粒度控制，但 listen_addresses 控制哪些介面接受連接嘗試，這可以幫助防止在不安全的網路介面上重複的惡意連接請求。此參數只能在伺服器啟動時設置。

➥ 這是否意味著listen_addresses理論上停止了預認證攻擊？

Postgres 伺服器和傳入連接之間是否存在任何可能導致漏洞利用的連接？還是會在沒有任何參與的情況下阻止被禁止的傳入連接？

當然，理想情況下，主機作業系統上的防火牆也將到位，以阻止不需要的傳入連接。但是，出於本問題的目的，讓我們忽略防火牆。

listen_addresses在 postgres 看到它們之前過濾連接

➥ 這是否意味著listen_addresses理論上停止了預認證攻擊？

是的。如果 PostgreSQL 的 postmaster 沒有監聽給定的介面（由其本地地址標識），則沒有遠端主機可以通過該介面連接到它。作業系統會報告 TCP 埠已關閉，並向連接主機發送 TCP RST；PostgreSQL 程式碼永遠無法到達，因此無法利用 PostgreSQL 錯誤，即使是預授權錯誤。1 .

listen_addresses阻止預授權漏洞

Postgres 伺服器和傳入連接之間是否存在任何可能導致漏洞利用的連接？還是會在沒有任何參與的情況下阻止被禁止的傳入連接？

No.listen_addresses在作業系統級別配置偵聽 TCP 套接字，僅將其綁定到指定的網路介面2。它過濾遠端主機指定的連接目標地址。作業系統根本不會告訴 PostgreSQL 與其他介面的連接。

請注意，同樣的情況並非如此pg_hba.conf。pg_hba.conf控制遠端主機源地址過濾和身份驗證配置。PostgreSQL postmaster確實會處理任何進入監聽地址的連接，然後被pg_hba.conf配置拒絕。

您可以通過配置作業系統防火牆規則在 PostgreSQL 看到連接之前進行基於發件人地址的過濾。這些將通過阻止連接到達 PostgreSQL 來防止 PostgreSQL 預授權攻擊。

因此，如果您知道只有網路 111.1.0.0/16 中的主機有任何業務連接到您的 PostgreSQL，那麼相應地配置防火牆規則是個好主意。您應該設置pg_hba.conf為備份，但防火牆規則應該阻止任何人甚至試圖連接到 postgres 本身。

了解身份驗證流程

要連接到 postgres，您必須通過一系列“門”。忽略此解釋的 UNIX 套接字，我們有：

• 作業系統網路和 TCP 級別，在您使用 PostgreSQL 程式碼之前：

  • 您和 postgres 之間的任何邊界路由器或防火牆都必須允許 TCP 連接
  • 在 postgres 主機上配置的任何作業系統防火牆都必須允許 TCP 連接
  • listen_addresses- postgres 必須在介面上偵聽，否則作業系統將 TCP 埠視為關閉
  • 任何網路安全擴展，如 TCP Wrappers (/etc/hosts.allow和/etc/hosts.deny) 都必須允許連接。（假設它們在您的作業系統上受支持並且 postgres 被編譯以使用它們）

• 在 PostgreSQL 程式碼中：

  • 通過源地址、ssl 模式、目標 dbname 和請求的使用者名匹配時找到A pg_hba.conf host, hostsslor規則hostnossl
  • 匹配的pg_hba.conf規則不能指定reject
  • 如果啟用 SSL 客戶端證書檢查，則 SSL 客戶端證書滿足配置的 CA 證書。
  • 請求的使用者名和數據庫名稱必須都存在於 PostgreSQL 目錄中
  • 請求的使用者名或它繼承的角色必須LOGIN在 PostgreSQL 目錄中有選項
  • 請求的使用者必須CONNECT對請求的數據庫具有權限。（預設情況下，public所有使用者所屬的角色都具有CONNECT權限，但您可以REVOKE這樣做，並且GRANT僅對特定使用者或角色/組具有權限）。

• 是的，您已連接

如果一個連接在早期階段被阻塞，它永遠不會與後面的階段互動。我還沒有檢查 dbname 與使用者名權限檢查的確切順序，但其餘的都是正確的。

我在這裡忽略pg_ident.conf了使用者名映射、客戶端證書 DN 映射、SSPI/GSSAPI 和低級身份驗證方法等細節。

現在，如果您使用 UNIX 套接字（unix_socket_directories，以及libpq host作為路徑或完全省略的地址），PostgreSQL 階段是相同的，除了pg_hba.conf匹配不檢查源地址並查找local行而不是host,hostssl或hostnossl行。peer支持 auth 模式以要求 unix 使用者名與 postgres 使用者名匹配。手冊中的詳細資訊。

將 PostgreSQL 暴露在 Internet 上

讓我注意到 PostgreSQL 的 pre-auth 攻擊並非完全聞所未聞，而是很少見。直接在 Internet 上公開 PostgreSQL 是相當正常的。

您應該使用hostsslinpg_hba.conf來強制 SSL 連接以保護身份驗證交換並使隨意掃描更加困難。您應該採取與任何其他 Internet 公開服務相同的保護措施：使用 fail2ban 或類似的，使用 IDS，監控日誌，並使用防火牆規則排除任何您知道沒有業務連接的東西。

但是，如果您不需要將 PostgreSQL 公開到 Internet，請不要這樣做。特別是，如果您只需要環回連接，請將 PostgreSQL 綁定到環回地址127.0.0.1和::1. 或者更好的是，使用unix sockets。

也可以看看

• 手冊的“客戶端身份驗證”一章

• listen_addresses

• pg_hba.conf

• 對於 Ubuntu 和（主要是）Debian：

  • Ubuntu PostgreSQL 軟體包的 Ubuntu 文件
  • PostgreSQL 的 Ubuntu 社區幫助 wiki

---

1攻擊者仍然可以利用網路堆棧中的作業系統漏洞。或者（非常不可能）他們可能能夠使用諸如源地址欺騙之類的技巧來欺騙有缺陷的作業系統，讓其將初始數據包發送到 PostgreSQL，即使它綁定到不同的介面也是如此。任何現代的、合理配置的作業系統都會阻止這種情況發生。

2在內部，每個listen_addresses條目都用於創建一個單獨的偵聽 TCP 套接字。對於類 UNIX 作業系統，它被傳遞給bind(...)每個套接字上的呼叫。請參見postmaster.c第 1012 行if (ListenAddresses)，以及第 532 行附近的StreamServerPort適配器。src/backend/libpq/pqcomm.c

引用自：https://dba.stackexchange.com/questions/220931