为 Discourse 配置防火墙

文档 自我托管
,
1

如果您使用的是标准的基于 Docker 的 Discourse 安装，以下 Uncomplicated Firewall 规则将保护您服务器上的任何非 Docker 服务：

ufw allow http
ufw allow https
ufw allow ssh
ufw enable

也就是说，只允许 HTTP (端口 80)、HTTPS (端口 443) 和 SSH (端口 22)，别无其他。

:warning: 注意： Docker 直接 操作 iptables 并绕过 ufw 规则。这意味着 ufw 无法阻止或限制对 Docker 容器公开的端口（标准 Discourse 安装中的端口 80 和 443）的访问。上述 ufw 规则仅保护在主机上运行的非 Docker 服务。

使用以下命令检查防火墙的当前状态：

ufw status verbose

示例输出：

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
80                         ALLOW IN    Anywhere
443                        ALLOW IN    Anywhere
22                         ALLOW IN    Anywhere
80 (v6)                    ALLOW IN    Anywhere (v6)
443 (v6)                   ALLOW IN    Anywhere (v6)
22 (v6)                    ALLOW IN    Anywhere (v6)

如果您想随时关闭它：

ufw disable

Discourse 的默认 Docker 安装仅暴露端口 80 和 443，因此主机防火墙并非绝对必要。但是，如果您在主机上运行了在其他端口上监听的其他服务，添加防火墙可以为这些服务提供额外的“双重保险”安全层。

33 个赞
:cn: Discourse Official Install Guide | Discourse 云平台安装
How might we better structure #howto?
Mail-receiver relay access denied
I can't start a Discourse
4

据我所知，Docker 容器只向主机系统开放了很少的端口，因此 Discourse 实际上被防火墙隔离在它运行的服务器之外。

当然，如果主机系统上还有其他东西在运行，那么“明显队长”会说你需要采取合理的预防措施。

我曾有一台服务器，我们认为它已经相当安全了，结果却被入侵了，那场面可不好看。

1 个赞
5

主题不完全准确。如果 UFW 在 Docker 之外使用，就像在 VPS 上“正常”使用一样，它本身并不适用于 Discourse。我可以禁用端口 80，但 Discourse/docker 仍然可以完全访问。

当然，它可以保护其他所有东西，但如果没有其他服务在监听，它就是不必要的。

我不知道 UFW 或 iptables 在 enter app 之后是如何工作的，或者防火墙是否可以那样使用。

我指的是这个主题：

3 个赞
6

我很想听听这个故事，也许可以在一个单独的帖子里 :slight_smile:

顺便说一句，关于 Docker 和 ufw / 防火墙之间关系的讨论几乎和 Docker 本身一样古老，这里有一个非常受关注的讨论，其中包含许多有趣的见解：

Docker 自己近年来在记录相关细节方面做得更好；Packet filtering and firewalls | Docker Docs

不想在这个帖子里灌太多链接，但如果你对防火墙话题感兴趣，这些似乎是很有见地的文章，可以一起参考，还可以通过常规的 Google 搜索了解更多细节。

基于其中一些观点，以及 @Jagster 链接的非常有用的帖子，似乎默认开箱即用的 Discourse 安装配置本身就足够了？毕竟，我的看起来是这样的；

$ docker ps
CONTAINER ID   IMAGE                 COMMAND        CREATED      STATUS        PORTS                                                                      NAMES
5dd4a572cd8e   local_discourse/app   \"/sbin/boot\"   6 days ago   Up 16 hours   0.0.0.0:80-\u003e80/tcp, :::80-\u003e80/tcp, 0.0.0.0:443-\u003e443/tcp, :::443-\u003e443/tcp   app

所以，除非我弄错了，除非服务器上的其他软件还在使用其他端口，否则我认为唯一应该连接进来的入站流量将是这些列出的端口 80 和 443。

如果你想做一个健全性检查，我认为你可以使用 netstat 来检查服务器上的监听端口（How to Install netstat on Ubuntu ; https://linuxize.com/post/check-listening-ports-linux/）。

netstat -tunlp

为了进行更强的健全性检查，你可以考虑启动第二个小型 Linux 服务器，并尝试扫描你的 Discourse 服务器的开放端口；How To Use Nmap to Scan for Open Ports | DigitalOcean

# 扫描所有端口；在此处插入你的 IP 地址
sudo nmap -n -PN -sT -sU -p- 1.2.3.4
  • 查看 DigitalOcean 文档中包含的链接，了解更多关于扫描等的命令。

我认为，如果有人担心他们的 Discourse 服务器的防火墙问题，这些资源和见解应该非常有帮助 :slight_smile:

3 个赞
7

小问题，但这个链接似乎失效了。

1 个赞
8

最新的 Ubuntu LTS ufw 提供的是 ALLOW 而不是 ALLOW IN。

这让 mail-reciever 管理员很烦恼，即使 ufw 上的 25 端口已打开，在 ./launcher logs mail-receiver 中也会出现 API 准备失败。

允许所有入站和出站流量，然后拒绝所需端口，一直是一个解决方案。

我还不足以了解 iptables 以进行进一步的微调。