linux中不存在“黑名单同步项”标准机制，真实需求是多机共享封禁ip列表，需按场景选择：同步hosts.deny需rsync+服务重启；firewalld rich rule应导出再批量导入并reload；iptables同步须确保持久化文件一致且服务启用；fail2ban推荐集中日志+统一管控。
Linux 中没有叫“黑名单同步项”的标准机制，这个说法通常是对几种不同场景的混淆：可能是想同步 /etc/hosts.deny、firewalld rich rule、iptables 规则，或是 fail2ban 封禁列表；也可能是误把 cron 白名单/黑名单（/etc/cron.allow、/etc/cron.deny）理解成“同步项”。真实需求往往是“让多台机器共享同一套封禁 IP 列表”，下面分场景说明。
同步 /etc/hosts.deny 里的 TCP Wrappers 黑名单
TCP Wrappers 的黑名单靠 /etc/hosts.deny 文件生效，但它本身不支持自动同步。手动同步时要注意两点：一是该文件只对使用 libwrap（如 sshd、vsftpd）的服务有效；二是规则顺序敏感，ALL: ALL 必须放在最后，否则会覆盖前面的白名单。
- 用 rsync 推送（推荐）：
rsync -avz /etc/hosts.deny user@192.168.1.10:/etc/hosts.deny - 不要直接覆盖，先比对差异：
diff /etc/hosts.deny user@192.168.1.10:/etc/hosts.deny - 修改后需重启对应服务（如
systemctl restart sshd），TCP Wrappers 不会自动重载
同步 firewalld 的 rich rule 黑名单
firewalld 的富规则存在 XML 配置中（/etc/firewalld/zones/public.xml 等），但直接复制 XML 文件风险高——firewalld 会校验 checksum，且 zone 名称、接口绑定可能不一致。
- 正确做法是导出规则再批量导入：
firewall-cmd --permanent --list-rich-rules > rules.txt，然后在目标机上逐条执行firewall-cmd --permanent --add-rich-rule=... - 避免用
--runtime-to-permanent同步，它只保存当前运行态，不含富规则 - 导入后必须
firewall-cmd --reload，否则不生效
同步 iptables 黑名单规则（含持久化）
iptables 规则本身是内存态，同步关键在于持久化文件是否一致。不同发行版路径不同：/etc/iptables/rules.v4（Debian/Ubuntu）、/etc/sysconfig/iptables（RHEL/CentOS 7）。
- 同步前确认目标机 iptables-service 已启用：
systemctl is-enabled iptables - Debian 系统别用
iptables-restore 直接加载，应先停服务：<code>systemctl stop iptables，再覆盖文件，再start - CentOS 7 上若用了 firewalld，就别碰 iptables —— 两者冲突，
iptables命令可能被 firewalld 覆盖
fail2ban 封禁 IP 的跨机同步
fail2ban 默认只封本机，它的封禁记录存在内存或 /var/log/fail2ban.log，不自动共享。真要同步，得靠外部协调。
- 最稳妥方式是集中日志 + 统一 fail2ban 服务器：所有机器日志发到 rsyslog server，由一台 fail2ban 解析并下发封禁指令（如通过 ansible 调用
firewall-cmd） - 避免用数据库同步封禁表——fail2ban 没内置 DB 支持，强行加会破坏原子性
- 如果只是小规模，可写定时脚本从 A 机抓
fail2ban-client status sshd | grep "Banned IP"，再推送到 B 机的hosts.deny
真正容易被忽略的是：同步 ≠ 生效。哪怕文件一模一样，服务没 reload、zone 没匹配、libwrap 没启用，黑名单照样不拦流量。每次同步后，务必验证实际连接行为，而不是只看配置是否存在。
