公网服务器上线后，很快会遇到 SSH（安全外壳远程登录协议）爆破、端口扫描、异常登录和 Web 探测。本文是一份协同封禁指南，重点解决“单台服务器各自防守、黑名单更新慢、误封难排查”的问题，帮助你把本机日志、社区威胁情报和防火墙规则串起来，让可疑 IP 在进入业务层之前就被拦截。
协同封禁的价值不在于替代所有安全工具，而是把已有防护做得更及时。对中小企业网站、外贸独立站、API 服务和运维跳板机来说，它可以把重复攻击挡在更靠前的位置，减少无效连接、日志噪音和账号暴力破解压力。下面我们按“场景判断→部署逻辑→验证方法→运维边界”的顺序说明，避免只堆命令而不知道为什么这样配置。
为什么单机黑名单不够用
传统做法通常是在每台服务器上安装日志分析工具，检测到连续登录失败后，把来源 IP 写入本机防火墙。这个思路适合处理已经打到本机的攻击，但它有两个明显短板：第一，攻击者可能已经在别的服务器上出现过，却要等它再次访问你的机器才会触发封禁；第二，多台服务器之间没有共享判断，每台都要重复经历一次试探。
协同封禁的思路，是把“本机观察到的行为”和“其他节点已经确认的恶意行为”结合起来。服务器本地仍然读取 /var/log/auth.log、/var/log/secure 或 Web 访问日志，但决策不再只依赖单机阈值。当某个来源被多个节点识别为扫描、爆破或漏洞探测时，本机可以提前获取封禁列表，并把对应规则下发到 nftables、iptables 或 firewalld。
这类机制适合暴露在公网的 Linux 服务器，尤其是 SSH（安全外壳远程登录协议）端口、面板登录入口、管理后台和低频但高价值的业务 API。你可以把它理解为“分布式观察、本地执行”：风险信息来自多个来源，真正拦截仍由本机防火墙完成，控制权不会完全交给外部服务。
先确认你的服务器是否适合接入
不是所有业务都应该一上来启用强封禁。接入前建议先看 7 天日志，确认攻击类型、登录方式和现有防火墙策略。如果服务器每天只有少量管理登录，且公网端口明确，协同封禁的收益会比较明显；如果业务有大量动态用户 IP、开放代理访问或特殊爬虫流量，则要更谨慎地设置白名单和观察期。
可以先用下面的命令快速观察 SSH（安全外壳远程登录协议）失败登录来源，Ubuntu/Debian 常见日志路径为 /var/log/auth.log，Rocky Linux/AlmaLinux 常见路径为 /var/log/secure：
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -20
sudo grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -20
如果 20 个来源里有多个 IP 在短时间内各尝试 10 次以上，说明暴力破解已经形成噪音。再检查当前开放端口，避免把不该公开的服务暴露出去：
sudo ss -lntup sudo nft list ruleset | head -80
这一步也能帮你决定基础架构是否需要调整。例如，业务放在 服务器 环境中时，安全策略应和系统更新、端口管理、备份恢复一起规划；如果运行的是外贸站或后台系统，还可以结合 网站性能优化 的思路，避免安全组件造成不必要的访问延迟。
部署思路：让日志、情报和防火墙各司其职
协同封禁通常由 3 个层次组成：日志采集负责发现本机异常，情报同步负责接收社区或组织内共享结论，防火墙负责在内核网络层执行拦截。部署时不要把三者混在一起，否则排障时很难判断是规则误判、同步失败，还是防火墙未生效。
在 Linux 服务器上，建议先从观察模式开始。安装代理后，只读取日志并生成告警，不立即封禁真实流量。观察 24 到 72 小时后，确认被标记的来源确实属于扫描或爆破，再启用防火墙联动。生产环境中，我们建议保留固定管理 IP 白名单，并把紧急回滚命令写进运维文档。
sudo nft add table inet filter
sudo nft add chain inet filter input '{ type filter hook input priority 0; policy accept; }'
sudo nft add set inet filter blocked_ipv4 '{ type ipv4_addr; flags interval; }'
sudo nft add rule inet filter input ip saddr @blocked_ipv4 drop
上面示例展示了 nftables 的基本结构：blocked_ipv4 是封禁集合，真正的封禁动作由 input 链上的 drop 规则完成。实际部署时，协同封禁代理会负责维护集合内容，而不是让管理员手动逐条添加。为了验证链路，可以先加入一个测试 IP，再从外部机器发起连接确认是否被拦截。
如果你的业务部署在 VPS（虚拟专用服务器）上，建议选择支持快照、控制台和系统重装的方案，便于在防火墙配置失误时恢复访问。Hostease 的 VPS（虚拟专用服务器）主机 适合需要独立系统环境、可自主管理安全策略的站点；流量更稳定、资源更独占的场景，则可以参考 独服（独立服务器） 方案。
关键配置：白名单、封禁时长和回滚路径
协同封禁最怕两类问题：误封管理入口，以及封禁规则累积过多导致排查困难。所以配置时要先保护“人能进去”，再考虑“攻击能挡住”。建议把办公出口 IP、监控节点、备份节点和第三方回调来源加入白名单；如果办公网络经常变化，至少保留云控制台、救援模式或带外管理方式。
封禁时长不宜一开始就设置过长。对 SSH（安全外壳远程登录协议）爆破和端口扫描，可以从 4 小时、24 小时两个级别开始：短期封禁处理试探流量，长期封禁处理重复出现的高风险来源。Web 登录页探测则要结合业务访问特征，避免把共享出口、企业网关或搜索引擎抓取错误识别为攻击。
sudo nft add element inet filter blocked_ipv4 { 203.0.113.10 timeout 4h }
sudo nft list set inet filter blocked_ipv4
sudo nft delete element inet filter blocked_ipv4 { 203.0.113.10 }
这些命令分别对应临时加入封禁、查看封禁集合、删除测试封禁。正式上线前，可以用保留地址段做演练，不要直接拿真实客户 IP 测试。若系统使用 iptables，思路相同，但要注意发行版是否已经默认切到 nftables 后端，避免两套规则并存导致判断混乱。
为了降低误封风险，建议至少记录以下 4 项信息：触发规则名称、来源 IP、封禁开始时间、解封时间。小团队可以用系统日志保存，大团队可以接入集中日志平台。只要排障时能在 5 分钟内回答“为什么封、谁封的、何时解封”，这套机制就更容易被业务团队接受。
验证方法：不要只看规则是否存在
很多安全配置失败，不是因为工具没安装，而是因为验证只停留在“服务正在运行”。协同封禁上线后，至少要验证 3 条链路：日志能否被解析、封禁决策能否生成、防火墙是否真的拦截。任一环节断开，表面上看都有告警，实际流量却可能照常进入。
你可以按下面的顺序做一次小范围演练：先在测试机器上模拟多次失败登录；再查看协同封禁代理是否产生告警；最后检查防火墙集合是否出现对应来源。不要在业务高峰期直接用真实用户来源测试，也不要把公司固定出口 IP 加入黑名单。
sudo journalctl -u ssh --since "30 min ago" | tail -50 sudo nft list set inet filter blocked_ipv4 sudo conntrack -L 2>/dev/null | grep 203.0.113.10 | head
第一条命令验证日志，第二条验证规则集合，第三条辅助观察连接跟踪记录。若日志中已经出现失败登录，但集合里没有新增元素，应检查解析规则和情报同步；若集合里有元素但连接仍能进入，应检查防火墙链优先级、云侧安全组和本机防火墙是否有冲突。
对线上站点而言，安全加固还应和 SSL（安全传输协议）、DNS（域名解析系统）和 CDN（内容分发网络）策略一起考虑。SSL（安全传输协议）保证传输加密，DNS（域名解析系统）决定访问入口，CDN（内容分发网络）可能隐藏源站 IP；如果源站 IP 已经暴露，就算前端接入 CDN（内容分发网络），服务器本机仍然需要防火墙层面的访问控制。
上线后的维护边界
协同封禁不是一次安装后就可以长期不管的组件。攻击模式、业务入口和团队办公网络都会变化，所以维护重点应放在规则审计、误封处理和版本更新上。建议每周抽查一次封禁 Top 20 来源，每月复盘一次误封记录，并在系统大版本升级前备份防火墙规则。
可以把维护动作拆成三个固定节奏：每天查看异常峰值，每周清理过期白名单，每月演练一次回滚。这样做比临时排障更可靠，因为很多误封不是单条规则造成的，而是白名单过旧、代理同步失败、云侧安全组和本机规则同时变更叠加出来的。
sudo nft list ruleset > /root/nftables-backup-$(date +%F).conf sudo systemctl status nftables --no-pager sudo journalctl -u nftables --since "24 hours ago" | tail -80
如果你管理的是多台公网服务器，建议把安全基线做成模板：统一 SSH（安全外壳远程登录协议）登录策略、统一防火墙默认规则、统一日志路径和告警方式。这样后续新增服务器时，不需要从零复制命令，也能减少“某一台忘记配置”的风险。
总结：先小范围观察，再逐步封禁
总结来看，协同封禁适合已经暴露在公网、经常遇到扫描和爆破的服务器，但它应该作为分层防护的一环，而不是唯一安全措施。推荐的落地顺序是：先检查 7 天日志和开放端口，再用观察模式运行 24 到 72 小时，确认误报可控后联动防火墙，最后把白名单、封禁时长和回滚命令写进运维手册。
如果你需要为企业网站、外贸站或业务后台选择承载环境，可以考虑把服务器安全基线纳入选型标准：是否有控制台、快照、独立系统权限、稳定的网络和技术支持。Hostease 可以提供 VPS（虚拟专用服务器）和独服（独立服务器）等基础设施选项，但具体安全策略仍建议结合你的业务访问来源、管理方式和合规要求逐项验证。