Linux SSH安全加固：用/etc/hosts.deny实现系统级早期拦截

1. 为什么现在还要用/etc/hosts.deny？——一个被低估但依然锋利的系统级守门人

很多人一提 Linux SSH 安全，第一反应就是改端口、禁密码、配密钥、上 fail2ban、套 Cloudflare 或 WAF。这些都没错，也确实该做。但当我去年在一台部署在公网边缘的 CentOS 7 路由管理节点上，连续三天凌晨 3:17 分收到同一 IP 的第 47 次暴力 SSH 登录尝试时，我顺手翻了下/var/log/secure，发现它早在sshd进程启动前，就已经被系统内核层面的 TCP Wrappers 拦在了门外——而拦它的，就是那行写在/etc/hosts.deny里、看起来像古董一样朴素的sshd: 192.168.123.45。

这不是怀旧，是精准拦截。/etc/hosts.deny不是防火墙替代品，也不是 fail2ban 的低配版；它是 Linux 系统最底层的访问控制网关之一，工作在 socket 层，比 SSH 服务进程本身更早介入连接请求。它不消耗 CPU 去解析日志、不依赖 Python 解释器、不启动额外守护进程，只要内核加载了tcp_wrappers模块（绝大多数主流发行版默认启用），它就静默运行，毫秒级响应。对高频扫描类攻击，它能直接让恶意连接连sshd的欢迎 banner 都看不到，从源头减少日志污染、降低系统负载、规避部分基于 banner 指纹的自动化探测。关键词：Linux、SSH 安全、hosts.deny、TCP Wrappers、系统级访问控制、暴力破解防护。这篇文章适合所有需要快速加固裸机或轻量 VPS 的运维人员、DevOps 工程师、以及正在备考 RHCE/LPIC-2 的考生——你不需要会写 Python 脚本，也不必配置复杂的 iptables 规则链，只要理解三行配置文件的逻辑，就能为你的服务器加一道“物理门禁”。

它解决的不是“如何构建企业级安全体系”这种宏大命题，而是“当凌晨三点你被告警短信吵醒，发现又是那个熟悉的 IP 在扫弱口令，你能不能在 30 秒内让它永远连不上来”的具体问题。它不炫技，但极可靠；不智能，但极确定。接下来，我会带你从原理到实操，把这把老式铜钥匙擦亮，让它在现代服务器上继续咬合严丝合缝。

2. TCP Wrappers 是什么？——不是防火墙，却是第一道无声的哨兵

2.1 它的工作位置：比 SSH 进程更早的“门房”

要真正用好/etc/hosts.deny，必须先扔掉一个常见误解：它不是sshd自己读取并执行的配置。sshd本身并不解析这个文件。真正起作用的是TCP Wrappers—— 一个独立的、历史悠久的 Linux 访问控制库（libwrap.so）。它的设计哲学非常朴素：在应用程序（如sshd,vsftpd,xinetd托管的服务）调用accept()接收一个新连接之前，由系统动态链接库libwrap.so主动介入，检查该连接的源 IP 和目标服务名，再对照/etc/hosts.allow和/etc/hosts.deny两份白名单与黑名单，做出放行或拒绝的决定。

这个时机极其关键。我们画个简化的连接流程图（纯文字描述，无 mermaid）：

客户端发起 TCP SYN → 服务器内核完成三次握手 → 内核将已建立的 socket 传递给 sshd 进程 ↓ libwrap.so 拦截此 socket 请求 ↓ 查询 /etc/hosts.allow（优先匹配，找到即停） ↓ 未匹配 → 查询 /etc/hosts.deny（找到即拒绝，不再往下） ↓ 均未匹配 → 默认放行（即“默认允许”策略）

注意这个“默认允许”原则。很多初学者以为写了hosts.deny就万事大吉，结果发现规则没生效，根源就在这里：TCP Wrappers 的决策逻辑是“先查 allow，匹配则放行；不匹配再查 deny，匹配则拒绝；都不匹配则放行”。它不像 iptables 那样有“默认 DROP”的概念。所以，如果你只想拒绝特定 IP，而其他所有 IP 都应正常访问，那么/etc/hosts.allow里通常需要明确写上sshd: ALL，否则hosts.deny的规则可能根本不会被触发。

2.2 它能控制哪些服务？——不是所有程序都买账

TCP Wrappers 并非万能。它只对显式链接了libwrap.so库的程序有效。你可以用ldd命令快速验证一个服务是否支持：

ldd $(which sshd) | grep wrap # 正常输出类似：libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f...) # 如果没有输出，说明该 sshd 编译时未启用 TCP Wrappers 支持

主流发行版中：

• OpenSSH：RHEL/CentOS 7/8、Debian 10/11、Ubuntu 18.04/20.04 默认编译时启用了--with-libwrap，sshd支持。
• 但 Ubuntu 22.04+ 和较新版本的 OpenSSH（如 9.0+）：上游 OpenSSH 社区已正式移除对libwrap的支持，其sshd不再链接libwrap.so。这是重大变化，意味着在这些系统上，/etc/hosts.deny对sshd完全无效。你必须改用iptables/nftables或fail2ban。

提示：在动手配置前，请务必确认你的系统和sshd版本是否支持。执行sshd -V 2>&1 | grep -i wrap，如果输出为空，则不支持。别在不支持的系统上浪费时间调试hosts.deny。

2.3 为什么它比 fail2ban 更“轻”？——一次判断，零开销

fail2ban 的工作流是：sshd记录失败登录 →fail2ban-server读取/var/log/auth.log→ 正则匹配失败模式 → 触发iptables命令添加临时封禁规则。这个过程涉及磁盘 I/O、日志解析、进程间通信、内核 netfilter 规则更新，每次封禁都有毫秒级延迟，且持续消耗资源。

而 TCP Wrappers 的拦截发生在内存中，libwrap.so加载规则后，对每个新连接的判断就是一次哈希表查找（IP 地址转为整数，查预编译的规则树），耗时在纳秒级别。它不产生任何日志（除非你手动开启log_on_success/log_on_failure），不修改内核网络栈，不增加任何守护进程。对于一台只跑sshd和nginx的小 VPS，启用hosts.deny几乎感知不到性能影响；而 fail2ban 却可能在高并发扫描时，因日志轮转和正则匹配拖慢整个系统。

这就是它的核心价值：用最低的系统成本，换取最高确定性的早期拦截。它不是取代 fail2ban，而是和它形成纵深防御：hosts.deny拦住已知恶意 IP 的首次连接；fail2ban 则负责动态学习和封禁新出现的扫描者。

3./etc/hosts.deny的语法精解——从单 IP 到 CIDR 网段的实战写法

3.1 最基础的拒绝：一行一个，直击要害

假设你通过lastb或/var/log/secure发现恶意 IP 是203.0.113.42，你想立刻禁止它。最简单的写法就是：

echo "sshd: 203.0.113.42" >> /etc/hosts.deny

这条语句的结构是：<服务名>: <客户端地址>。其中：

• sshd是服务名，必须与sshd进程注册给 TCP Wrappers 的名字一致（通常是sshd，不是ssh或openssh）。
• 203.0.113.42是 IPv4 地址，精确匹配。

执行后，无需重启sshd，规则立即生效。你可以用另一台机器ssh -o ConnectTimeout=5 user@your-server-ip测试，会立刻得到Connection refused，而不是Permission denied。因为连接在到达sshd之前就被libwrap拒绝了，TCP 层直接返回 RST 包。

注意：hosts.deny文件本身没有“重载”命令。修改后，新连接会自动应用新规则。但已有连接（如你当前的 SSH 会话）不受影响，这是设计使然。

3.2 拒绝整个网段：CIDR 表示法与通配符的正确用法

单个 IP 拒绝太被动。攻击者往往使用僵尸网络，IP 地址成片出现。这时就要用 CIDR（无类别域间路由）网段表示法。例如，拒绝192.0.2.0/24整个 C 类网段：

echo "sshd: 192.0.2.0/24" >> /etc/hosts.deny

/24表示子网掩码255.255.255.0，覆盖192.0.2.0到192.0.2.255共 256 个地址。这是最推荐、最清晰的网段写法。

你可能在网上看到过sshd: 192.0.2.这种写法（末尾带点）。它利用了 TCP Wrappers 的“前缀匹配”特性，意思是“所有以192.0.2.开头的 IP”，效果等同于/24。但强烈不推荐。原因有二：

1. 歧义性：192.0.2.会被解释为192.0.2.0/24，但192.0.2.123也会被匹配，而192.0.2.1234（非法 IP）在某些旧版本解析器中可能出错。
2. 可读性差：/24是标准网络术语，任何网络工程师一眼看懂；192.0.2.则像一个模糊的字符串匹配，容易引发误判。

同样，避免使用sshd: ALL这种全局拒绝（除非你明确想锁死所有 SSH）。它会覆盖hosts.allow中的所有规则，导致你把自己也关在外面。

3.3 复杂场景：多 IP、多服务、带注释的生产级配置

一个真实的hosts.deny文件，绝不会只有一行。它应该是一个有组织、可维护、带上下文的配置清单。以下是我在线上环境使用的模板（已脱敏）：

# === [2023-10-15] 源自 AbuseIPDB 的高危扫描网段 === sshd: 203.0.113.0/24 sshd: 198.51.100.128/25 # === [2023-11-02] 本地测试环境误操作 IP === sshd: 10.10.20.155 # === [2024-01-10] 某云厂商已知恶意 AS（自治系统）出口网段 === sshd: 192.0.2.192/28 sshd: 192.0.2.208/28 # === [通用规则] 拒绝所有来自私有地址空间的 SSH 连接（除非你明确需要）=== # （注：此规则需确保 hosts.allow 中有明确的允许项，否则会锁死所有连接） # sshd: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

关键实践技巧：

• 按时间戳和来源分类注释：方便日后审计，知道哪条规则是何时、因何加入的。
• 用空行分隔逻辑区块：提升可读性，避免规则堆砌。
• 把“可能误伤”的规则注释掉：比如最后一条私有网段规则，我把它注释掉了，因为我的服务器需要接受来自内网管理网段的 SSH。只有当你 100% 确认不需要任何私有地址访问时，才取消注释。
• 拒绝多 IP 时，不要写在同一行用逗号分隔：sshd: 1.1.1.1, 2.2.2.2是错误的。TCP Wrappers 不支持这种语法。必须每行一个。

3.4 高级技巧：结合hosts.allow实现“白名单优先”策略

前面提到，默认策略是“允许”。但生产环境中，更安全的做法是“默认拒绝，仅允许白名单”。这就需要hosts.allow配合使用。一个典型的最小化hosts.allow配置如下：

# /etc/hosts.allow # 只允许来自公司办公网和运维跳板机的 SSH 访问 sshd: 203.0.113.100/32 sshd: 203.0.113.101/32 sshd: 198.51.100.0/24 # 允许 localhost（用于本地脚本调用） sshd: 127.0.0.1 # 允许 IPv6 本地环回 sshd: [::1]

然后，在hosts.deny中写：

# /etc/hosts.deny # 默认拒绝所有其他 SSH 连接 sshd: ALL

这样，只有hosts.allow中明确列出的 IP 或网段才能连接sshd，其余全部被拒。这是真正的“最小权限”模型。但请千万注意：在写入sshd: ALL之前，你必须确保至少有一个你当前正在使用的 IP 地址在hosts.allow中！否则，保存后你将立刻失去 SSH 连接，只能通过 VNC 或物理控制台恢复。我建议的操作顺序是：

1. 先编辑hosts.allow，添加你的可信 IP。
2. scp或rsync一份备份到本地：scp /etc/hosts.allow backup_hosts.allow
3. 再编辑hosts.deny，写入sshd: ALL。
4. tail -f /var/log/messages监控，然后从另一终端测试连接。
5. 一切正常后，再添加其他拒绝规则。

4. 实战排错：为什么我的hosts.deny规则不生效？

4.1 第一步：确认 TCP Wrappers 是否真的在工作

这是 90% 问题的根源。不要猜，要验证。执行以下命令：

# 1. 检查 sshd 是否链接了 libwrap ldd $(which sshd) | grep wrap # 2. 检查系统是否加载了 tcp_wrappers 模块（RHEL/CentOS） lsmod | grep ip_tables # 确保 netfilter 基础模块存在（虽不直接相关，但常连带检查） # 3. 查看 TCP Wrappers 的运行时日志（需开启） # 编辑 /etc/sysconfig/tcpd（RHEL/CentOS）或 /etc/default/tcpd（Debian/Ubuntu） # 设置 TCPD_LOG=yes，然后重启 xinetd（如果使用）或等待 sshd 重新加载（通常无需重启） # 日志默认输出到 /var/log/messages 或 /var/log/secure

如果ldd命令无输出，那么无论你怎么写hosts.deny，它都不会生效。此时，你必须转向iptables方案。

4.2 第二步：检查规则语法与顺序——“先 allow 后 deny”的陷阱

最常见的错误是规则顺序和逻辑混淆。假设你的hosts.allow是空的，而hosts.deny是：

sshd: 203.0.113.42 sshd: ALL

你以为203.0.113.42会被拒绝，ALL会拒绝所有。但实际流程是：libwrap先查hosts.allow，没找到匹配项，于是去查hosts.deny，第一条sshd: 203.0.113.42匹配成功，执行拒绝，结束。第二条sshd: ALL根本不会被读取。所以，sshd: ALL在hosts.deny中，只有当它位于文件顶部，且你想实现“默认拒绝”时才有意义。

另一个经典陷阱是大小写和空格。SSHD:或sshd : 203.0.113.42（冒号前有空格）都是无效语法。TCP Wrappers 对格式极其敏感。正确的格式是<服务名>:<空格><地址>，冒号前后不能有空格，服务名小写。

4.3 第三步：用tcpdmatch工具进行离线模拟测试

tcpdmatch是 TCP Wrappers 自带的诊断工具，它能模拟libwrap的决策过程，无需真实发起连接。这是排查规则是否写对的终极武器。

安装（如未自带）：

# RHEL/CentOS yum install tcp_wrappers # Debian/Ubuntu apt-get install tcpd

用法：

# 模拟一个来自 203.0.113.42 的 sshd 连接 tcpdmatch sshd 203.0.113.42 # 输出示例： # client: hostname 203.0.113.42 # server: process /usr/sbin/sshd (server-side) # access: granted (because of /etc/hosts.allow rule) # or # access: denied (because of /etc/hosts.deny rule) # 模拟一个来自 192.0.2.100 的连接 tcpdmatch sshd 192.0.2.100

这个命令会精确告诉你，libwrap会根据你当前的hosts.allow和hosts.deny文件，对这个请求做出什么判断，以及依据哪条规则。它比反复ssh测试快十倍，也安全十倍。

4.4 第四步：检查 SELinux/AppArmor 的干扰（RHEL/CentOS/Ubuntu）

在强制访问控制（MAC）系统上，SELinux 或 AppArmor 可能会覆盖或阻止 TCP Wrappers 的行为。虽然不常见，但必须排除。

检查 SELinux 状态：

sestatus # 如果是 enforcing 模式，临时设为 permissive 测试 sudo setenforce 0 # 然后再次测试 ssh 连接 # 如果此时规则生效了，说明 SELinux 策略限制了 libwrap # 永久修复需调整 SELinux 策略，如：setsebool -P ssh_sysadm_login on

检查 AppArmor（Ubuntu）：

aa-status # 查看 sshd 是否在受限配置文件下运行 # 如果是，查看 /etc/apparmor.d/usr.sbin.sshd 中是否有冲突规则

注意：在生产环境，不建议长期关闭 SELinux/AppArmor。这只是为了快速定位问题。一旦确认是 MAC 干扰，应查阅对应文档，添加正确的策略，而非禁用安全模块。

5. 生产环境最佳实践与避坑指南——那些文档里不会写的细节

5.1 “拒绝”不等于“静默”：如何让攻击者知道他已被盯上？

hosts.deny默认拒绝时，客户端收到的是Connection refused，这是一个非常干净、标准的 TCP 错误。但有些高级扫描器会把这个当作“端口关闭”信号而跳过。为了让它们明确意识到“此服务存在，但你被拉黑了”，我们可以利用 TCP Wrappers 的spawn动作，在拒绝时执行一个命令，比如记录更详细的日志，甚至发送一个伪造的 banner。

在hosts.deny中这样写：

sshd: 203.0.113.42 : spawn (/bin/echo "`date` - BLOCKED SSH ATTEMPT from %a" >> /var/log/hosts_deny.log) : deny

这里%a是 TCP Wrappers 的内置宏，代表客户端 IP。spawn后面的命令会在拒绝发生时执行。这样，每次该 IP 尝试连接，你不仅能在hosts_deny.log中看到时间戳，还能在deny后加twist动作，返回一个自定义的错误信息（需twist支持）：

sshd: 203.0.113.42 : twist /bin/echo "Access denied by system policy. Your IP has been logged."

不过，twist有一定风险，因为它会向客户端返回数据，可能暴露服务器信息。我更倾向于只用spawn记录日志，保持“静默拒绝”的专业性。

5.2 自动化更新：用脚本定期同步威胁情报

手动维护hosts.deny很痛苦。好消息是，你可以用脚本自动下载公开的威胁情报（Threat Intelligence）列表，并将其转换为hosts.deny格式。例如，AbuseIPDB 提供免费的 CSV 格式导出。

一个极简的 Bash 脚本框架：

#!/bin/bash # fetch_abuseipdb.sh ABUSE_URL="https://api.abuseipdb.com/api/v2/blacklist?confidenceMinimum=90&limit=10000" OUTPUT_FILE="/tmp/abuseipdb_blacklist.txt" DENY_FILE="/etc/hosts.deny" # 下载最新黑名单（需 API key） curl -s -G "$ABUSE_URL" \ --data-urlencode "key=YOUR_API_KEY" \ -o "$OUTPUT_FILE" # 清理并转换为 hosts.deny 格式 awk -F',' 'NR>1 {print "sshd: " $1 "/32"}' "$OUTPUT_FILE" | sort -u > "$DENY_FILE".new # 合并手动规则（保留注释和原有结构） sed -n '/^#/p; /^$/p' "$DENY_FILE" > "$DENY_FILE".merged cat "$DENY_FILE".new >> "$DENY_FILE".merged # 原子化替换 mv "$DENY_FILE".merged "$DENY_FILE" # 通知管理员 echo "AbuseIPDB blacklist updated at $(date)" | mail -s "hosts.deny Updated" admin@example.com

将此脚本加入cron，每天凌晨 2 点执行。它能让你的hosts.deny始终保持最新，对抗全球范围的已知恶意 IP。

5.3 终极避坑：三个你绝对不能犯的致命错误

1. 错误一：在hosts.deny中写ALL: ALL
   这是灾难性的。ALL服务名会匹配所有支持 TCP Wrappers 的服务，包括sshd,vsftpd,sendmail,rpcbind等。一旦写入，你的服务器将瞬间变成一座孤岛，所有远程管理通道全部中断。永远只针对具体服务名写规则，如sshd: ...。

2. 错误二：忘记hosts.allow的存在，直接写sshd: ALL
   如前所述，sshd: ALL在hosts.deny中，会拒绝所有 SSH 连接，包括你自己的。除非你同时在hosts.allow中明确列出了你的 IP，否则这就是自杀式操作。永远遵循“先 allow，后 deny”的黄金法则。

3. 错误三：用hosts.deny替代强密码和密钥认证
   hosts.deny是网络层的访问控制，它无法防止社工、钓鱼、或内部人员的误操作。它只是纵深防御的一环。如果你的sshd还开着PermitRootLogin yes和PasswordAuthentication yes，那么hosts.deny再强大，也无法阻止一个知道 root 密码的合法用户干坏事。它必须和ssh-keygen,sshd_config的严格配置（Protocol 2,MaxAuthTries 3,LoginGraceTime 30）一起使用，才是完整的 SSH 安全方案。

最后分享一个小技巧：在/etc/hosts.deny文件末尾，加上一行# Last updated: $(date)。每次你手动编辑它时，用sed -i "\$s/^#.*/# Last updated: $(date)/" /etc/hosts.deny更新时间戳。这样，当你半年后回看这个文件，一眼就能知道它最后一次被维护是什么时候，避免用着一份早已过期的黑名单。安全不是一劳永逸的设置，而是一场需要持续校准的旅程。而这把古老的铜钥匙，只要擦得够亮，依然能为你打开通往稳定与安心的大门。