如何保护开放的 PostgreSQL 端口

Question

所以，情况就是这样。看来我们需要一个开放的 TCP 端口 5432 到全世界，客户可以访问他的 PostgreSQL 数据库。

出于显而易见的原因，我们不能只说“不”，只能作为最后的手段。

最大的困难是什么？如何保护我们的基础设施？

无论如何：为什么不应该向世界开放？我想，也许它比一些已有 20 年历史、无人维护的 FTP 服务器更安全。

PS VPN 不行。一些加密可能（如果我可以给他其中JDBC连接URL的作品）。

Answer 1

需要 SSL，保持 SELinux 开启，监控日志，并使用当前的 PostgreSQL 版本。

服务器端

需要 SSL

在postgresql.conf集ssl=on，并确保你有你的密钥文件和certFile中适当地安装（请参阅该文档，并在注释postgresql.conf）。

如果您想让客户端信任它而无需在客户端上进行特殊设置，您可能需要从 CA 购买证书。

在pg_hba.conf使用类似：

hostssl theuser thedatabase 1.2.3.4/32 md5

... 可能对用户和/或数据库使用“全部”，并且可能使用更广泛的源 IP 地址过滤器。

限制可以登录的用户，拒绝远程超级用户登录

如果可能，不要允许用户使用“全部”；如果可以避免超级用户登录的需要，您不想允许它远程登录。

限制用户权限

限制可以登录的用户的权限。不要给他们CREATEDB或CREATEUSER权限。

REVOKE所有数据库上的CONNECT权限PUBLIC，然后仅将其返还给应该能够访问该数据库的用户/角色。（将用户分组为角色并向角色授予权限，而不是直接授予单个用户）。

确保具有远程访问权限的用户只能连接到他们需要的数据库，并且只能访问他们实际需要的模式、表和列。这对本地用户来说也是很好的做法，这只是明智的安全措施。

客户端设置

在 PgJDBC 中，传递参数ssl=true：

要指示 JDBC 驱动程序尝试建立 SSL 连接，您必须添加连接 URL 参数 ssl=true。

...并在客户端的信任库中安装服务器证书，或者如果您不希望用户必须安装证书，则使用 Java 内置信任库中的某个 CA 信任的服务器证书。

正在进行的行动

现在确保您使 PostgreSQL 保持最新。PostgreSQL 只有几个预身份验证安全漏洞，但多于零，所以请保持最新状态。无论如何你应该，错误修正是很好的东西。

如果您知道不需要访问的大型网络块/区域，请在前面添加防火墙。

记录连接和断开连接（请参阅postgresql.conf）。如果可行，请记录查询。如果可行，在前面运行入侵检测系统或fail2ban 或类似系统。对于在Postgres的fail2ban，有一个方便的操作方法在这里

监视日志文件。

奖金偏执

需要考虑的额外步骤...

需要客户端证书

如果需要，您还可以使用pg_hba.conf要求客户端提供服务器信任的 X.509 客户端证书。它不需要使用与服务器证书相同的 CA，您可以使用自制的 openssl CA 来做到这一点。JDBC 用户需要将客户端证书导入到他们的 Java 密钥库中，keytool并可能配置一些 JSSE 系统属性以将 Java 指向他们的密钥库，因此它不是完全透明的。

隔离实例

如果您真的想成为一个偏执狂，请在单独的容器/VM 中运行客户端实例，或者至少在不同的用户帐户下运行客户端实例，仅使用它们需要的数据库。

这样，如果他们破坏了 PostgreSQL 实例，他们就不会再有任何进展。

使用 SELinux

我不应该说这个，但是......

运行支持 SELinux 的机器，如 RHEL 6 或 7，不要关闭 SELinux 或将其设置为 permissive mode。保持在强制模式。

使用非默认端口

只有默默无闻的安全是愚蠢的。一旦你做了明智的事情，使用一点默默无闻的安全性可能不会受到伤害。

在非默认端口上运行 Pg 使自动攻击者的生活变得更加艰难。

在前面放一个代理

您还可以在 PostgreSQL 前面运行 PgBouncer 或 PgPool-II，充当连接池和代理。这样您就可以让代理处理 SSL，而不是真正的数据库主机。代理可以位于单独的 VM 或机器上。

无论如何，在 PostgreSQL 中使用连接池代理通常是一个好主意，除非客户端应用程序已经有一个内置池。大多数 Java 应用程序服务器、Rails 等都有内置的池。即便如此，服务器端池代理在最坏的情况下也是无害的。