dns-filter 挖矿病毒，cpu占用高，处理方法

结论:centos 7.9系统，先使用hosts.deny拒绝所有连接，然后在hosts.allow中添加允许的白名单

由于没使用firwall，直接使用iptables添加白名单，然后拒绝所有的22端口连接

参与如下：

dns-filter 进程反复自动重启，且你提到的定时任务 /etc/.dd/systemdev/cron-fetch 具有典型的恶意软件特征（隐藏目录、伪装名称、高频执行），这表明你的系统已经感染了‌持久化恶意软件（极可能是挖矿病毒或僵尸网络代理）‌。

仅仅删除定时任务和杀死进程是无效的，因为恶意软件通常拥有‌多重持久化机制‌（如 systemd 服务、init.d 脚本、动态链接库劫持等）。dns-filter 很可能是该恶意套件的一部分，用于拦截或篡改 DNS 请求以维持连接或进行流量劫持。

请按照以下步骤彻底清理：

1. 定位 dns-filter 的真实路径和所属用户

首先确定该进程的具体位置和启动者，这有助于找到其他残留文件。

bash
# 查看进程详细信息，包括完整路径
ps -ef | grep dns-filter

# 假设 PID 为 12345，查看其打开的文件和网络连接
ls -l /proc/12345/exe
netstat -antp | grep 12345

注意‌：如果 /proc/PID/exe 指向 /tmp、/var/tmp、/dev/shm 或 /etc/.dd 等非常规目录，确认为恶意文件。
2. 排查所有可能的持久化入口

攻击者不会只依赖 crontab。你需要检查以下所有位置：

A. Systemd 服务（最常见）

恶意软件常注册为系统服务以实现开机自启和崩溃重启。

bash
# 查找包含 "dns"、"filter"、"systemdev"、"dd" 或可疑名称的服务
systemctl list-units --type=service --all | grep -E "dns|filter|systemdev|dd"

# 检查具体服务文件内容
cat /etc/systemd/system/<可疑服务名>.service
cat /usr/lib/systemd/system/<可疑服务名>.service

# 如果发现可疑服务，禁用并删除
systemctl stop <可疑服务名>
systemctl disable <可疑服务名>
rm /etc/systemd/system/<可疑服务名>.service
systemctl daemon-reload

B. Init.d 和 RC 本地脚本
bash
# 检查启动脚本
ls -l /etc/init.d/ | grep -E "dns|filter|systemdev"
cat /etc/rc.local
cat /etc/rc.d/rc.local

C. 其他定时任务目录

除了 crontab，还要检查：

bash
# 检查 /etc/cron.d/, /etc/cron.hourly/, /etc/cron.daily/ 等
ls -l /etc/cron.d/
grep -r "dns-filter\|cron-fetch\|\.dd" /etc/cron.*

D. SSH 公钥和 Bash 配置文件

攻击者可能通过修改 .bashrc 或 .profile 在用户登录时启动进程。

bash
# 检查 root 和当前用户的配置文件
cat ~/.bashrc
cat ~/.profile
cat /root/.bashrc
cat /root/.profile

# 检查 authorized_keys，移除未知的公钥
cat ~/.ssh/authorized_keys

E. 动态链接库劫持 (LD_PRELOAD)

检查环境变量是否被篡改，导致每次执行程序时加载恶意库。

bash
# 检查全局环境变量
cat /etc/environment
cat /etc/profile.d/*.sh

# 检查 ld.so.preload
cat /etc/ld.so.preload

如果 /etc/ld.so.preload 存在且包含可疑 .so 文件，这是高级持久化手段，需立即清空该文件并删除对应的 .so 文件。

3. 彻底清除恶意文件

停止进程‌：

bash
kill -9 <dns-filter的PID>
kill -9 <cron-fetch相关进程的PID>

删除恶意目录和文件‌：

bash
# 删除之前发现的恶意目录
rm -rf /etc/.dd

# 删除 dns-filter 可执行文件（根据步骤1找到的路径）
rm -f /path/to/dns-filter

# 清理临时目录中的可疑文件
rm -rf /tmp/*
rm -rf /var/tmp/*

清除 DNS 配置篡改‌：
恶意软件可能修改了 /etc/resolv.conf 或安装了本地 DNS 代理。

bash
# 检查 resolv.conf
cat /etc/resolv.conf
# 如果 nameserver 指向 127.0.0.1 或未知 IP，请恢复为正常的 DNS（如 8.8.8.8 或公司内网 DNS）

4. 深度排查与加固

由于该恶意软件表现出极强的 persistence（持久性），建议执行以下操作：

检查网络连接‌：
使用 ss -antp 或 netstat -antp 查看是否有异常的外联连接，特别是连接到国外 IP 或非标准端口的连接。结合你提供的威胁情报，注意排查与 msupdate.us、guikms.dns.army 等恶意域名的关联 IP 的连接。

全盘扫描‌：
使用 Linux 恶意软件扫描工具（如 ClamAV、LMD (Linux Malware Detect) 或 rkhunter）进行全盘扫描，查找其他潜在的后门或 Rootkit。

bash
# 示例：安装并使用 rkhunter
apt-get install rkhunter # 或 yum install rkhunter
rkhunter --check

修改所有密码‌：
感染期间，所有账户密码可能已泄露。请在清理完成后，立即修改 root 及所有用户密码，并检查 /etc/passwd 中是否有新增的异常特权账户（UID 为 0 的非 root 账户）。

审计日志‌：
检查 /var/log/secure (CentOS/RHEL) 或 /var/log/auth.log (Ubuntu/Debian)，查找入侵初期的暴力破解记录或异常登录 IP，以便在防火墙上封禁。

5. 最终建议

如果经过上述清理后，dns-filter 或 cron-fetch 仍然复发，或者系统出现无法解释的行为（如文件被锁定、命令失效），‌最安全且彻底的做法是备份重要数据后重装操作系统‌。因为高级 Rootkit 可能内核级隐藏，常规手段难以彻底清除。

紧急处置总结：‌

kill 掉所有相关进程。
删除 /etc/.dd 目录和 dns-filter 二进制文件。
检查并删除恶意的 systemd 服务文件。
检查 /etc/ld.so.preload 和 .bashrc。
重置 DNS 配置。
修改所有密码并更新系统补丁。

 

这是一个‌确凿的挖矿病毒（Monero/XMR 门罗币矿工）‌感染现场。

根据你提供的最新证据，恶意进程 dns-filter 实际上是一个伪装成 DNS 过滤工具的 ‌XMRig 或类似变种的门罗币挖矿程序‌。它正在利用你的服务器资源为攻击者的钱包地址挖矿，并通过加密连接（TLS）将算力贡献给矿池 xmr.kryptex.network。

以下是详细的证据链分析、彻底清理步骤和防止复发的方案。

1. 核心证据链分析
表格
证据项 分析结果 风险等级
进程路径‌ /usr_hxas/lib/dev/systemdev/dns-filter
路径 /usr_hxas/... 是典型的非标准隐藏目录，意在模仿系统库但实际是恶意存放点。 🔴 极高
进程命令‌ -o xmr.kryptex.network:8029 -u 883kAB7... -k --tls
-o: 矿池地址 (Kryptex 是知名门罗币矿池)
-u: 攻击者的钱包地址
-k --tls: 使用 TLS 加密通信以逃避流量检测 🔴 极高
网络连接‌ 51.195.127.124:8029 ESTABLISHED
IP 51.195.127.124 位于法国 OVH 机房，是常见的矿池节点 IP。端口 8029 是 Kryptex 的标准挖矿端口。 🔴 极高
CPU占用‌ 99% 进程 PID 40791 占用 99% CPU，这是典型的满载挖矿行为，会导致服务器响应极慢。 🔴 极高
持久化机制‌ */45 * * * * /etc/.dd/systemdev/cron-fetch
每45分钟运行一次下载脚本，从 NPM 拉取最新恶意负载并执行，用于复活进程或更新版本。 🔴 极高
2. 紧急清理步骤（按顺序执行）

请严格按照以下顺序操作，‌切勿先杀进程‌，否则守护脚本会立即重启它。

第一步：阻断网络与锁定文件（防止复活）

切断恶意进程的网络连接‌（可选，但推荐）：

bash
# 阻止访问矿池 IP
iptables -A OUTPUT -d 51.195.127.124 -j DROP
# 阻止访问矿池域名
iptables -A OUTPUT -p tcp --dport 8029 -j DROP

锁定恶意二进制文件‌（防止被删除后重新写入或正在运行时无法替换）：

bash
chattr +i /usr_hxas/lib/dev/systemdev/dns-filter
chattr +i /etc/.dd/systemdev/cron-fetch

第二步：清除持久化启动项（Cron & Systemd）

清除 Root 定时任务‌：

bash
crontab -e
# 在编辑器中删除包含 "/etc/.dd/systemdev/cron-fetch" 的那一行
# 保存退出

检查并清除其他用户的定时任务‌：

bash
for user in $(cut -f1 -d: /etc/passwd); do
if crontab -l -u $user 2>/dev/null | grep -q "cron-fetch\|dns-filter"; then
echo "Found in user: $user";
crontab -r -u $user; # 谨慎：这会删除该用户所有定时任务，建议手动编辑
fi
done

检查 Systemd 服务‌：
虽然之前 systemctl 没显示明显异常，但恶意软件可能使用了隐藏的服务名。

bash
# 查找最近修改过的 service 文件
find /etc/systemd/system /usr/lib/systemd/system -name "*.service" -mtime -2 -exec ls -l {} \;

# 如果有可疑文件（如名字随机或指向 /usr_hxas），禁用并删除
# systemctl disable <可疑服务名>
# rm /etc/systemd/system/<可疑服务名>.service
# systemctl daemon-reload

检查 Init.d 和 RC 本地启动‌：

bash
grep -r "dns-filter\|cron-fetch\|/usr_hxas" /etc/init.d/ /etc/rc.local /etc/rc.d/rc.local 2>/dev/null
# 如果发现，编辑对应文件删除相关行

第三步：清除恶意文件与目录

解锁并删除恶意文件‌：

bash
chattr -i /usr_hxas/lib/dev/systemdev/dns-filter
chattr -i /etc/.dd/systemdev/cron-fetch

rm -rf /usr_hxas/
rm -rf /etc/.dd/

清理临时目录中的残留‌：
恶意脚本通常在 /tmp 或 /var/tmp 留下解压后的临时文件。

bash
rm -rf /tmp/.cbc97b7a*
rm -rf /var/tmp/.cbc97b7a*
rm -rf /tmp/*miner*
rm -rf /var/tmp/*miner*

第四步：终止恶意进程

现在持久化机制已清除，可以安全地杀死进程了。

bash
kill -9 40791
# 确认进程是否消失
ps -ef | grep dns-filter

如果进程再次出现，说明还有未被发现的持久化入口（如 .bashrc、ld.so.preload 或隐藏的 systemd timer），请重复第二步的深度排查。

第五步：修复 DNS 与系统配置

恢复 DNS‌：
如前所述，修改 /etc/resolv.conf 为可信 DNS（如 223.5.5.5），并锁定文件 chattr +i /etc/resolv.conf。

检查 SSH 公钥‌：
攻击者可能留下了后门公钥。

bash
cat /root/.ssh/authorized_keys
# 删除任何你不认识的公钥

检查动态链接库劫持‌：

bash
cat /etc/ld.so.preload
# 如果文件存在且不为空，或者指向可疑 .so 文件，清空它：
echo > /etc/ld.so.preload

3. 验证清理结果
监控 CPU‌：执行 top，观察 CPU 空闲率是否恢复正常，dns-filter 或类似高占用进程是否消失。
监控网络‌：执行 netstat -antp，确认没有到 51.195.127.124 或其他陌生 IP 的异常连接。
监控定时任务‌：等待 1 小时，检查 crontab -l 是否再次出现恶意任务。
4. 根本原因分析与加固建议

入侵入口推测‌：

弱口令爆破‌：检查 /var/log/secure 是否有大量 SSH 登录失败记录。
应用漏洞‌：如果服务器运行了 Redis、Drupal、WebLogic 等应用，可能存在未修补的远程代码执行漏洞。
供应链攻击‌：之前的 npm 脚本表明攻击者利用了开发工具链或镜像源进行投毒。

加固措施‌：

修改密码‌：立即修改 root 及所有用户密码，使用强密码。
SSH 加固‌：
禁止 root 直接远程登录 (PermitRootLogin no in /etc/ssh/sshd_config)。
改用密钥认证，禁用密码登录 (PasswordAuthentication no)。
修改默认 SSH 端口（非 22）。
防火墙策略‌：
仅开放业务必需端口。
限制出站流量，特别是针对非常用端口（如 8029, 3333, 4444）的出站连接。
定期快照‌：在进行重大清理前，务必对云服务器打快照，以便在清理失败时回滚。

重要提示‌：由于该病毒具有极强的持久化和自我修复能力，且已经深入系统多个层面（Cron, 自定义目录, 可能的 LD_PRELOAD），‌如果经过上述清理后，病毒仍在 24 小时内复发，最安全、最彻底的建议是：备份重要数据（仅备份数据，不备份可执行程序），然后重装操作系统。‌

在 CentOS 7.9 系统中，默认的防火墙管理工具是 ‌firewalld‌，但底层依然依赖 ‌iptables‌（或 nftables）进行数据包过滤。由于你之前使用了 iptables 命令来阻断恶意连接，我们需要确认当前的防火墙状态以及是否有其他安全工具在运行。

以下是详细的检查步骤和替代方案：

1. 检查 firewalld 服务状态

CentOS 7 默认使用 firewalld 作为前端管理工具。请执行以下命令查看其状态：

bash
systemctl status firewalld

如果显示 active (running)‌：说明防火墙已开启。此时你直接使用 iptables 添加的规则可能会与 firewalld 的规则冲突，或者在 firewalld 重启后丢失。建议改用 firewall-cmd 或直接操作底层 iptables 并锁定。
如果显示 inactive (dead)‌：说明 firewalld 服务未运行。此时系统可能没有加载任何防火墙规则，或者仅保留了之前手动设置的 iptables 规则。
2. 检查底层 iptables 规则是否生效

即使 firewalld 服务停止，之前执行的 iptables -A OUTPUT ... 命令添加的规则通常仍然存在于内核中，除非系统重启或执行了 iptables -F（清空规则）。

查看当前所有 iptables 规则：

bash
iptables -L -n -v

重点观察 OUTPUT 链（Chain OUTPUT）：

如果你能看到类似 DROP all -- 0.0.0.0/0 51.195.127.124 的规则，说明‌拦截已经生效‌，无论 firewalld 服务是否开启。
如果列表为空或没有相关规则，说明拦截未生效，你需要重新执行之前的 iptables 命令。

注意‌：在 CentOS 7 中，如果 firewalld 正在运行，它通常会接管 iptables 表。如果你直接用 iptables 命令修改规则，firewalld 可能会在下次重载时覆盖这些更改。为了确保持久化且不被覆盖，建议在 firewalld 运行时也直接使用 iptables 命令（因为 iptables 命令直接操作内核 netfilter，优先级高于 firewalld 的用户态配置，但管理上会混乱），或者更好的方式是‌停止 firewalld 并启用传统的 iptables 服务‌（见下文第 4 点）。

3. 检查是否有其他安全/拦截工具

除了防火墙，CentOS 上可能运行以下安全工具，它们也可能具备网络拦截或进程控制能力：

A. SELinux (Security-Enhanced Linux)

SELinux 主要控制进程对文件、端口的访问权限，‌通常不用于拦截特定的外部 IP 连接‌，但它可能阻止恶意进程绑定端口或写入文件。

检查状态：
bash
getenforce

Enforcing：强制模式（正常安全状态）。
Permissive：宽容模式（只记录不拦截）。
Disabled：已禁用。
结论‌：SELinux 无法替代防火墙来阻断对外部矿池 IP 的访问。
B. TCP Wrappers (/etc/hosts.deny 和 /etc/hosts.allow)

这是一种老式的访问控制机制，仅对支持 libwrap 的服务（如 sshd, vsftpd 等）有效，‌对普通的出站连接（如挖矿程序发起的连接）无效‌。

检查方法：
bash
cat /etc/hosts.deny
cat /etc/hosts.allow

结论‌：无法用于阻断挖矿程序的出站流量。
C. 第三方安全软件 (如云盾、安骑士、CrowdStrike 等)

如果你的服务器是云服务器（如阿里云、腾讯云、AWS 等），厂商通常在宿主机层面提供‌安全组（Security Group）‌或‌网络 ACL‌。

检查方法‌：登录云平台控制台，查看“安全组”规则。
作用‌：云安全组可以拦截出站流量。你可以在云平台的安全组中添加一条‌出站方向（Outbound）‌的拒绝规则，目标 IP 为 51.195.127.124，端口 8029。这是最彻底、最难以被病毒篡改的拦截方式。
D. eBPF / Falco / OSSEC 等高级监控工具

一般默认安装的系统不会包含这些，除非你手动部署过。可以通过 ps -ef | grep -E "falco|ossec|auditd" 检查。auditd 是审计守护进程，只记录日志，不拦截网络。

4. 推荐的最佳实践：切换至传统 iptables 服务

鉴于你已经在使用 iptables 命令进行紧急封堵，且 firewalld 可能会干扰规则管理，建议在清理病毒期间‌暂时停用 firewalld，启用传统的 iptables 服务‌，以便更直观地管理规则。

操作步骤：‌

停止并禁用 firewalld‌：

bash
systemctl stop firewalld
systemctl disable firewalld

安装并启动 iptables-services‌（如果未安装）：

bash
yum install -y iptables-services
systemctl start iptables
systemctl enable iptables

重新添加阻断规则‌（因为切换服务可能清空了临时规则）：

bash
# 阻断特定 IP
iptables -A OUTPUT -d 51.195.127.124 -j DROP

# 阻断特定端口（可选，防止连接其他矿池）
iptables -A OUTPUT -p tcp --dport 8029 -j DROP

# 保存规则，确保重启后生效
service iptables save

验证规则‌：

bash
iptables -L OUTPUT -n -v

5. 总结与建议
当前状态判断‌：执行 iptables -L -n -v。如果有 DROP 规则，则拦截已生效，无需关心 firewalld 状态。如果没有规则，则拦截未生效。
其他工具‌：SELinux 和 TCP Wrappers 无法拦截此类出站连接。‌云平台安全组‌是唯一比本地防火墙更底层的拦截手段，建议同时在云控制台配置出站拒绝规则。
最终建议‌：
短期‌：使用 iptables 命令直接阻断，并执行 service iptables save 持久化。
长期‌：病毒清除后，建议重新启用 firewalld 并配置严格的出站策略，或保持 iptables-services 但定期审查规则。
根本解决‌：防火墙只是缓解措施，必须按照之前的步骤彻底清除恶意进程、定时任务和持久化文件，否则攻击者可能通过其他端口或协议绕过封锁。

iptables -L OUTPUT -n -v 是一个用于‌查看 Linux 防火墙中特定链的详细规则及流量统计信息‌的命令。

以下是该命令各参数的详细拆解与解释：

1. 参数逐项解析
表格
参数 全称/含义 作用详解
-L‌ --list ‌列出规则‌。告诉 iptables 显示指定链中的所有防火墙规则。如果不加此参数，iptables 默认会等待输入其他指令或报错。
OUTPUT‌ 链名称 ‌指定目标链‌。Linux 防火墙有五个主要链（INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING）。
OUTPUT 链专门负责过滤‌从本机发出‌、流向外部网络的数据包。
在你之前的场景中，恶意挖矿程序 dns-filter 发起的连接就是经过这条链。
-n‌ --numeric ‌数字格式显示‌。
- ‌IP地址‌：不尝试将 IP 反向解析为域名（例如显示 51.195.127.124 而不是 ovh.net），加快显示速度并避免 DNS 解析干扰。
- ‌端口号‌：不尝试将端口号解析为服务名称（例如显示 8029 而不是 unknown 或具体服务名）。
在排查恶意连接时，必须加 -n 以确保看到的是真实的 IP 和端口。
-v‌ --verbose ‌详细信息模式‌。
除了显示规则本身，还会显示每条规则匹配的‌数据包数量（pkts）‌和‌字节数（bytes）‌，以及对应的网卡接口（in/out）。
这能帮你判断规则是否生效：如果某条 DROP 规则的 pkts 计数在增加，说明它正在成功拦截流量。
2. 命令执行结果示例

当你执行该命令后，通常会看到类似以下的输出：

bash
Chain OUTPUT (policy ACCEPT)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 51.195.127.124
12 1024 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8029
1500 120K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

关键字段解读：‌

pkts / bytes‌：分别表示匹配该规则的数据包数量和总字节数。
如果你刚添加了阻断矿池 IP 的规则，观察 pkts 是否随时间增长。如果增长，说明拦截生效。
如果为 0，可能意味着没有流量尝试连接该 IP，或者流量被前面的其他规则优先匹配了。
target‌：动作，如 DROP（丢弃）、ACCEPT（放行）、REJECT（拒绝）。
prot‌：协议，如 tcp、udp、all。
source / destination‌：源 IP 和目标 IP。0.0.0.0/0 代表任意 IP。
dpt:8029‌：目标端口为 8029。
3. 为什么在清理病毒时需要用这个命令？

在你之前处理的 dns-filter 挖矿病毒场景中，执行 iptables -L OUTPUT -n -v 的核心目的是‌验证拦截策略是否生效‌：

确认规则存在‌：检查你之前执行的 iptables -A OUTPUT -d 51.195.127.124 -j DROP 是否真的添加到了 OUTPUT 链中。
监控拦截效果‌：
如果 destination 为 51.195.127.124 的那行规则，其 pkts（数据包计数）一直在增加，说明病毒进程仍在尝试连接矿池，但被防火墙成功拦下了。
如果 pkts 长时间不变，且病毒进程已被杀死，说明威胁已暂时解除。
发现隐藏连接‌：通过 -v 看到的字节数，可以发现是否有其他未知的大流量出站连接，辅助判断是否还有其他恶意进程在运行。
4. 补充建议

实时监测‌：如果你想实时看规则匹配计数的变化，可以结合 watch 命令使用：

bash
watch -n 1 'iptables -L OUTPUT -n -v'

这将每秒刷新一次显示，你可以直观地看到哪些规则的计数器在跳动。

保存规则‌：请注意，iptables 命令添加的规则在重启后会丢失（除非使用了 iptables-services 并执行了 service iptables save，或者使用了 netfilter-persistent 等工具）。在确认拦截有效后，务必做好规则的持久化保存，防止重启后病毒再次连上矿池。

既然你的 firewalld 未启动，且希望直接使用 iptables 来拦截 SSH 暴力破解并降低负载，这是非常高效的做法。iptables 工作在内核网络层（Netfilter），在数据包到达 sshd 进程之前就能将其丢弃，因此能显著减少系统负载和日志噪音。

针对你的需求，提供两种方案：‌方案一（严格白名单）‌最推荐，负载最低；‌方案二（动态频率限制）‌适合无法固定 IP 的场景。

⚠️ 重要安全警告
保持当前会话连接‌：在执行以下命令时，‌千万不要关闭当前的 SSH 窗口‌。请新开一个终端窗口测试连接，确认无误后再保存规则。
备份规则‌：执行前建议运行 iptables-save > /root/iptables_backup_$(date +%F).txt。
确保 iptables 服务已启用‌：
bash
systemctl stop firewalld
systemctl disable firewalld
yum install -y iptables-services
systemctl start iptables
systemctl enable iptables

方案一：严格白名单模式（强烈推荐）

原理‌：只允许特定 IP 访问 22 端口，其他所有 IP 的连接请求在内核层直接 DROP（丢弃）。
优点‌：sshd 完全感知不到非法连接，日志干净，CPU/内存负载极低。
缺点‌：需要你的管理 IP 是固定的。

1. 清理旧规则并设置基础保障
bash
# 1. 允许本地回环接口（必须）
iptables -I INPUT -i lo -j ACCEPT

# 2. 允许已建立的连接和RELATED状态（防止当前SSH断开，也保证出站流量正常）
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

2. 添加白名单 IP

将 YOUR_TRUSTED_IP 替换为你自己的公网 IP 或内网网段（如 192.168.1.0/24）。如果有多个 IP，重复执行此命令。

bash
# 插入到 INPUT 链的前面，优先级高于后面的拒绝规则
iptables -I INPUT -p tcp -s YOUR_TRUSTED_IP --dport 22 -j ACCEPT

3. 拒绝所有其他 IP 访问 SSH 端口

这条规则会丢弃所有非白名单 IP 发往 22 端口的 SYN 包。

bash
# 追加到 INPUT 链末尾，作为兜底规则
iptables -A INPUT -p tcp --dport 22 -j DROP

4. 验证与保存
bash
# 查看规则顺序，确保 ACCEPT 在 DROP 之前
iptables -L INPUT -n --line-numbers

# 如果新开的 SSH 窗口能连上，说明配置成功，执行保存
service iptables save

方案二：动态频率限制模式（Recent 模块）

原理‌：利用 iptables 的 recent 模块记录源 IP。如果某个 IP 在 60 秒内发起超过 5 次新的 SSH 连接请求，则将该 IP 加入临时黑名单并丢弃后续请求。
优点‌：无需固定 IP，自动封禁高频扫描者。
缺点‌：前几次连接仍会到达 sshd（产生少量日志），但高频攻击会被内核拦截。

1. 加载模块（通常已内置）
bash
modprobe xt_recent

2. 配置规则（注意顺序至关重要）

我们需要按顺序插入规则到 INPUT 链。建议使用 -I 插入到链首，或者先清空相关规则再重新添加。以下是‌按执行逻辑顺序‌的配置步骤：

bash
# --- 第一步：基础保障（同方案一） ---
iptables -I INPUT -i lo -j ACCEPT
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# --- 第二步：配置 Recent 模块规则 ---
# 注意：以下规则针对的是 --dport 22 的新连接 (--state NEW)

# 规则 A：检查该 IP 是否已在“攻击列表”中（被封禁期间）
# 如果 IP 在最近 300 秒(5分钟)内已经被标记过，直接 DROP
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH_BRUTE --rcheck --seconds 300 -j DROP

# 规则 B：检测阈值并封禁
# 如果 IP 在 60 秒内第 5 次发起新连接，则将其加入 SSH_BRUTE 列表，并 DROP 本次连接
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH_BRUTE --set -m recent --name SSH_BRUTE --rcheck --seconds 60 --hitcount 5 -j DROP

# 规则 C：记录正常的新连接
# 对于未达到阈值的连接，更新其在列表中的时间戳（用于后续计数）
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH_BRUTE --set -j ACCEPT

# 注意：由于我们使用 -I (Insert)，后执行的命令会排在前面。
# 为了确保逻辑正确，建议先清空 INPUT 链中关于 22 端口的旧规则，然后按以下顺序一次性执行脚本：

更稳妥的一键配置脚本（复制前请修改白名单IP或注释掉白名单部分）：‌

bash
#!/bin/bash
# 清除现有 INPUT 链规则（谨慎：确保你有控制台权限）
iptables -F INPUT

# 1. 基础放行
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# 2. (可选) 如果你有固定白名单，在这里添加，优先级最高
# iptables -A INPUT -p tcp -s YOUR_TRUSTED_IP --dport 22 -j ACCEPT

# 3. Recent 模块防御规则
# 3.1 如果 IP 在黑名单中(300秒内被触发过)，直接丢弃
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH_BRUTE --rcheck --seconds 300 -j DROP

# 3.2 如果 60 秒内第 5 次连接，加入黑名单并丢弃
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH_BRUTE --set -m recent --name SSH_BRUTE --rcheck --seconds 60 --hitcount 5 -j DROP

# 3.3 记录此次连接（用于计数），并接受连接
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH_BRUTE --set -j ACCEPT

# 4. 默认策略（可选，根据你其他端口需求决定）
# iptables -A INPUT -j DROP

# 保存规则
service iptables save
echo "Rules saved."

效果对比
表格
特性 hosts.deny (当前) iptables 白名单 (方案一) iptables Recent (方案二)
拦截层级‌ 应用层 (sshd进程) 网络层 (内核) 网络层 (内核)
系统负载‌ 高 (每个请求都创建进程) ‌极低‌ (直接丢包) ‌低‌ (仅高频时丢包)
日志噪音‌ 多 (refused connect) ‌无‌ (连接未建立) 少 (仅前几次有日志)
配置难度‌ 简单 中等 (需维护IP) 中等 (需理解规则顺序)
适用场景‌ 临时调试 ‌固定IP管理‌ ‌动态IP/公网开放‌
建议

鉴于你日志中 117.50.211.254 这种高频攻击，‌方案一‌是终极解决方案。如果你的管理 IP 不固定，可以使用 ‌方案二‌，它能在攻击开始后的第 5 次请求起就在内核层拦截，大幅减轻 sshd 负担。

配置完成后，你可以观察 /var/log/secure，你会发现来自被封禁 IP 的 refused connect 日志消失或大幅减少，同时使用 top 命令观察，sshd 的 CPU 占用率会明显下降。