有人一直试图登录我的 dovecot 服务器。由于他一直从同一个小型网络中选取不同的地址，我为网络添加了 ufw 拒绝规则，但这些拒绝规则似乎没有任何效果。只有当我指定 IP 地址时，规则才似乎有效。
我改变了dovecot服务器的监听端口，但是他找到了新的端口并继续尝试登录。
我想要过滤的网络是185.211.245.128 - 185.211.245.255。
我已打开 postfix 和 ssh 端口，但他专注于 dovecot。
这些是我在 ufw 中设置的规则
任何地方 拒绝 185.211.245.128/25 任何地方 拒绝 185.211.245.0/24 任何地方 拒绝 185.211.245.170 996 拒绝 185.211.245.170 996/tcp 允许任何地方
只有最后一次拒绝有效。我现在有来自此网络的另一个地址的连接尝试。
我使用以下命令添加了网络拒绝规则：
# ufw 拒绝来自 185.211.245.128/25
为什么 ufw 没有考虑这些拒绝规则？
更新 1：我重新启动并花了一个小时的时间，但我再次尝试连接。iptables 看起来正确：
Chain ufw-user-input (1 个引用)
pkts 字节数 目标 协议 选择加入 退出 源 目标
3 180 接受 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:xxx
32 1672 接受 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
19 1092 接受 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
22 1268 接受 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
0 0 接受 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:587
7 424 接受 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:465
0 0 全部删除 -- * * 141.98.80.16 0.0.0.0/0
0 0 全部删除 -- * * 5.79.252.176 0.0.0.0/0
0 0 全部删除 -- * * 5.53.119.178 0.0.0.0/0
5 200 删除全部 -- * * 185.211.245.128/25 0.0.0.0/0
0 0 全部删除 -- * * 185.211.245.0/24 0.0.0.0/0
0 0 全部删除 -- * * 185.211.245.170 0.0.0.0/0
0 0 删除 tcp -- * * 185.211.245.170 0.0.0.0/0 tcp dpt:996
0 0 删除 udp -- * * 185.211.245.170 0.0.0.0/0 udp dpt:996
0 0 全部删除 -- * * 168.228.151.234 0.0.0.0/0
0 0 全部删除 -- * * 185.211.245.198 0.0.0.0/0
34 2160 接受 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:996
显然，规则拒绝了 185.211.245.128/25，拒绝了 5 个数据包。但是我现在又有来自 185.211.245.170 的连接。
这是我在 auth.log 中看到的内容。我在 12:00 之前重启了。
2 月 18 日 12:37:28 srv01 auth：pam_unix(dovecot:auth)：身份验证失败；logname=uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170 2 月 18 日 12:37:31 srv01 auth：pam_unix（dovecot：auth）：身份验证失败；logname=uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170 2 月 18 日 12:37:58 srv01 auth：pam_unix（dovecot：auth）：身份验证失败；logname=uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170 2 月 18 日 12:38:00 srv01 auth：pam_unix(dovecot:auth)：身份验证失败；logname=uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170 2 月 18 日 13:11:12 srv01 auth：pam_unix(dovecot:auth)：身份验证失败；logname=uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170 2 月 18 日 13:11:14 srv01 auth：pam_unix（dovecot：auth）：身份验证失败；logname=uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170 2 月 18 日 13:11:33 srv01 auth：pam_unix（dovecot：auth）：身份验证失败；logname=uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170 2 月 18 日 13:11:36 srv01 auth：pam_unix(dovecot:auth)：身份验证失败；logname=uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170
看起来 iptables 不能正常工作或者可以被规避。
dovecot 进程正在监听 0.0.0.0:996 和 :::996。
更新 2：更奇怪了。查看 ufw.log，我发现今晚从我家到端口 996 的服务器的连接尝试被拒绝。但是昨天晚上我确实设法在同一端口访问了我的 imap 服务器。这确实有点可疑。
更新 3：我曾运行过 fail2ban。由于我停止了 fail2ban，导致删除了 iptables 中的规则，auth.log 中不再报告失败的连接尝试。可能是 fail2ban 生成了这些尝试，而我以为是 dovecot。在 iptables 中，我看到规则 185.211.245.128/25 的数据包丢失数量缓慢增加。这正是我所期望的。似乎 fail2ban 干扰了 iptables，或者只是日志记录不正确。但 4 小时后，就在发布此更新后，我收到了四次新的连接尝试。
更新4：我取得了一些进展。当删除规则放在所有允许规则之前时，登录尝试会被阻止。看起来攻击者利用其他允许规则来规避拒绝规则。这是如何实现的仍不清楚。如果这种解释是正确的，那么 ufw 就有一个漏洞，这是一个安全问题！
拒绝规则显然必须放在首位。我可以自己确保这一点，但粗心地使用 ufw 可能会暴露主机。我建议 ufw 始终将拒绝规则插入任何允许规则之前，以作为预防措施。
答案1
首先，UFW 非常基础，我觉得它很糟糕。它似乎被设计得非常简单，但出于某种原因，设计这种东西的人认为简单意味着让你感到困惑，让你很难学习任何东西，而不是按照你的要求做，即使这意味着有时会把自己锁在外面或阻止错误的网络。你可能应该使用更好的东西，比如 shorewall。
其次，我建议，无论何时使用模糊且功能有限的 UFW 用户界面，也请检查iptables -nvL以获取有关正在运行的 iptables 配置的清晰完整描述。看到该输出后，我相信您的问题会很清楚（即使对您来说不是，对我来说也是），但不确定您是否可以找到 UFW 命令来生成正确的 iptables 设置（我从未对 UFW 进行过如此深入的故障排除... 如果有任何问题，我只是用 shorewall 替换它）。
答案2
重新加载服务
sudo ufw reload并执行 sudo service iptables restart，如果您在服务器上，请记住允许 ssh。
答案3
运行sudo ufw enable或sudo ufw reload如果已在创建规则后启用