1. 为什么你的服务器在“裸奔”从两个不起眼的风险说起前几天帮一个朋友检查他的云服务器他用的是CentOS 7跑着几个内部业务系统。他自认为安全做得不错改了SSH端口也设置了强密码。但我用最基础的扫描工具一跑报告里赫然躺着两条“低风险”漏洞ICMP timestamp请求响应漏洞和允许Traceroute探测。朋友不以为然“低风险嘛问题不大。”这可能是很多运维新手甚至有一定经验的朋友都会有的想法。但在我看来安全就像给房子装防盗网你堵住了大门SSH却忘了关上一扇扇小窗户攻击者依然有隙可乘。今天要聊的这两个“低风险”漏洞恰恰就是这样的“小窗户”。ICMP时间戳Timestamp漏洞听起来有点学术。简单说就是你的服务器会老老实实地告诉任何一个询问者“现在是北京时间2023年X月X日X时X分X秒。”这有什么用呢很多系统的身份验证、日志记录、甚至一些加密协议的同步都依赖于精确的时间。攻击者拿到你的系统时间就可能为后续更复杂的攻击铺路比如针对时间同步协议的攻击。虽然直接危害不大但它泄露了系统信息属于“没必要暴露的细节”。允许Traceroute探测这个就更直观了。Traceroute这个命令大家常用用来查看到目标IP中间经过了哪些网络节点。反过来如果别人能对你的服务器成功进行Traceroute就等于把你的网络“路径图”给画出来了。攻击者能知道你的服务器前面经过了几层防火墙、是哪个运营商的线路、大概的网络拓扑结构。在真正的攻击中了解网络结构是发起精准攻击的第一步。所以安全加固的核心思想之一就是“最小信息泄露原则”只暴露必须暴露的其他一律隐藏。让服务器在网络上尽可能“隐身”减少攻击面。接下来我就手把手带你用Linux系统自带的两个防火墙利器——iptables和firewalld把这两扇“小窗户”牢牢关上。整个过程不需要额外安装软件全是原生命令操作理解了原理后你会发现其实非常简单。2. 认识我们的工具iptables与firewalld不是二选一在开始敲命令之前我们得先搞清楚手头的工具。很多刚接触Linux防火墙的朋友会被iptables和firewalld搞晕以为它们是非此即彼的关系。其实不然它们更像是“底层引擎”和“管理前端”的关系。iptables是Linux内核中Netfilter框架的用户空间命令行工具你可以把它理解为防火墙的“底层引擎”和“原生命令行接口”。它直接、强大规则怎么写就怎么生效但规则管理比如保存、恢复需要你自己处理。它的规则结构像一条条链Chain数据包在这些链上被匹配和处理。firewalld则是Red Hat系列CentOS、RHEL、Fedora等在较新版本中引入的动态防火墙管理器你可以把它看作一个更友好的“管理前端”或“配置管家”。它的底层其实还是调用iptables或者nftables但它引入了“区域Zone”和“服务Service”的概念让管理更直观。它最大的优点是规则可以动态修改而无需重启服务并且配置能永久保存。那么该用哪个呢我的建议是如果你追求极致的控制、清晰的规则逻辑或者环境比较老比如一些旧系统直接使用iptables。它的规则一目了然学习它有助于你真正理解Linux包过滤的原理。如果你在使用CentOS 7/8、RHEL 7/8或Fedora等系统并且希望配置更易于管理和持久化那么firewalld是更现代的选择。特别是通过--direct参数你依然可以直接向底层iptables注入规则兼顾了方便与灵活。在本文中我会对同一个安全目标分别用两种工具演示你可以根据你的系统偏好和习惯来选择。放心无论选哪个最终达到的安全效果是一样的。3. 实战一阻断ICMP时间戳让服务器“忘记”时间好了理论铺垫完毕我们开始动手。第一个目标是让服务器不再响应ICMP时间戳查询。ICMP时间戳请求和回复对应的类型号分别是13和14。我们的策略很简单在INPUT链处理进入服务器的数据包上直接丢弃DROP这两种类型的数据包。3.1 使用iptables进行配置首先我们看看用原生的iptables怎么操作。操作前最好先看一眼现有的规则避免重复添加。# 查看当前iptables的过滤规则-n表示用数字显示端口和IP更清晰 sudo iptables -L INPUT -n --line-numbers如果列表很长你可以用grep过滤一下或者直接看有没有相关的ICMP规则。如果没有我们就可以直接添加了。# 丢弃进入本机的ICMP时间戳请求type 13 sudo iptables -A INPUT -p icmp --icmp-type timestamp-request -j DROP # 丢弃进入本机的ICMP时间戳回复type 14 sudo iptables -A INPUT -p icmp --icmp-type timestamp-reply -j DROP我来拆解一下这条命令-A INPUT表示在INPUT链的末尾追加一条规则。-p icmp指定协议为ICMP。--icmp-type timestamp-request匹配ICMP类型为“时间戳请求”。这里也可以用数字13。-j DROP匹配上述条件的数据包执行的动作是“丢弃”也就是直接扔掉不给任何回应。添加完后强烈建议再查看一次规则确认它们已经加上了。sudo iptables -L INPUT -n你应该能看到类似这样的两条规则DROP icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 13 DROP icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 14这里有个非常重要的坑我踩过iptables规则默认是临时生效的重启系统就会消失为了让规则永久生效我们需要保存它。在不同的Linux发行版上保存命令不同CentOS/RHEL 6/7:sudo service iptables save # 它会将规则保存到 /etc/sysconfig/iptablesUbuntu/Debian: 通常需要安装iptables-persistent包。sudo apt-get install iptables-persistent sudo netfilter-persistent save如果哪天你需要删除这两条规则也很简单。先用--line-numbers查看规则编号然后用-D删除指定链名和编号。sudo iptables -L INPUT -n --line-numbers # 假设timestamp-request规则编号是5 sudo iptables -D INPUT 53.2 使用firewalld进行配置对于使用firewalld的系统我们有两种方式。一种是使用firewalld自身的富规则rich rule但针对这种特定的ICMP类型使用--direct参数直接操作底层iptables规则更直接、更通用也更容易和iptables的知识对应上。首先同样先查看一下现有的直接规则sudo firewall-cmd --direct --get-all-rules如果返回为空或者没有相关的ICMP规则我们就可以添加了。注意firewalld的直接规则需要指定是ipv4还是ipv6以及表table和链chain。我们操作的是filter表的INPUT链。# 添加永久规则阻断入站的时间戳请求和回复 sudo firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p icmp --icmp-type timestamp-request -j DROP sudo firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p icmp --icmp-type timestamp-reply -j DROP命令解析--permanent表示这是永久规则不加则只对当前运行时生效。--direct --add-rule指示firewalld添加一条直接规则。ipv4 filter INPUT 0指定规则添加到IPv4的filter表的INPUT链优先级为0数字越小优先级越高。-m comment --comment deny ICMP timestamp这是一个非常好的习惯给规则加个注释以后维护时一目了然。虽然上面的命令示例里我为了简洁没写但实际使用时强烈建议加上。添加永久规则后必须重载firewalld配置才能生效sudo firewall-cmd --reload重载后你可以再次查看直接规则确认它们已经存在。删除规则的方法也很类似把--add-rule换成--remove-rule其他参数保持不变即可。sudo firewall-cmd --permanent --direct --remove-rule ipv4 filter INPUT 0 -p icmp --icmp-type timestamp-request -j DROP sudo firewall-cmd --reload4. 实战二禁用Traceroute探测隐藏网络路径搞定时间戳我们来看第二个目标让Traceroute探测失效。Traceroute工具的工作原理是发送一系列TTL生存时间递增的数据包通常是UDP或ICMP请求。当TTL减到0时路径上的路由器会返回一个“ICMP超时Time Exceeded type 11”消息。当数据包最终到达目标主机时如果端口不可达目标主机会返回一个“ICMP目标不可达Destination Unreachable type 3”消息。而经典的ping命令使用的“回显回复Echo Reply type 0”有时也会被用于某些Traceroute变种。因此要阻断Traceroute探测我们需要在OUTPUT链处理从服务器发出的数据包上阻止服务器发出这些类型的ICMP响应。注意这里的方向和阻断时间戳不同时间戳是阻止进入INPUT而Traceroute是阻止发出OUTPUT因为我们是让服务器不要回复那些用于路径探测的特定ICMP报文。4.1 使用iptables进行配置按照这个思路iptables的配置命令如下# 阻止本机发出ICMP回显回复ping应答 sudo iptables -A OUTPUT -p icmp --icmp-type echo-reply -j DROP # 阻止本机发出ICMP目标不可达报文 sudo iptables -A OUTPUT -p icmp --icmp-type destination-unreachable -j DROP # 阻止本机发出ICMP超时报文 sudo iptables -A OUTPUT -p icmp --icmp-type time-exceeded -j DROP添加后使用sudo iptables -L OUTPUT -n查看OUTPUT链应该能看到新增的DROP规则。同样别忘了执行保存操作如sudo service iptables save使规则永久生效。这里有一个非常重要的技术细节和常见误区只配置OUTPUT规则实现了“对外隐身”。即别人无法通过Traceroute探测到你的服务器路径也无法ping通你的服务器因为你不回复echo-reply。但是这并不影响你从服务器内部去ping通或traceroute外部网络因为你只是阻止了服务器发出某些类型的响应包并没有阻止它接收外部的ICMP请求或发出探测请求。这个策略的精妙之处就在于此。4.2 使用firewalld进行配置在firewalld中我们同样使用--direct模式来配置OUTPUT链规则。# 添加永久规则阻断出站的Traceroute相关ICMP响应 sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p icmp --icmp-type echo-reply -j DROP sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p icmp --icmp-type destination-unreachable -j DROP # time-exceeded类型可能没有直接的名字可以用类型号11 sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p icmp --icmp-type 11 -j DROP记得给规则加上清晰的注释例如-m comment --comment block outbound traceroute这是一个好习惯。添加完毕后重载配置sudo firewall-cmd --reload你可以通过sudo firewall-cmd --direct --get-all-rules来确认所有规则都已就位。5. 效果验证与深度排查你的规则真的生效了吗配置完不验证等于白干。我们需要用工具来检验一下加固效果。验证ICMP时间戳阻断我们可以使用nmap这个强大的网络扫描工具。在另一台机器上对目标服务器执行nmap -PP -sn 你的服务器IP-PP选项就是发送ICMP时间戳请求。如果配置成功你将收不到任何时间戳回复扫描会显示主机状态为“filtered”被过滤或超时。验证Traceroute探测阻断同样在另一台机器上使用traceroute命令Linux/Unix或tracert命令Windowstraceroute 你的服务器IP如果配置成功你会看到探测包在到达你的服务器之前或之后响应就中断了无法显示完整的路径最终可能显示为一系列* * *超时。这证明你的服务器没有返回关键的ICMP超时或目标不可达报文。更深入的排查技巧有时候规则加了但好像没效果可能是规则顺序问题。iptables规则是按顺序匹配的如果前面有一条允许所有ICMP的规则那后面的DROP规则就永远不会被匹配到。所以一定要用iptables -L -n --line-numbers仔细检查规则顺序。通常具体的拒绝规则应该放在通用的允许规则之前。另一个常见问题是你的云服务商如AWS、阿里云、腾讯云的安全组Security Group或网络ACL可能也在起作用。这些是位于你的虚拟机外层的防火墙。你需要在云控制台确认没有在这些地方允许相关的ICMP协议类型。系统内的防火墙和云平台的安全组是双重防护思路是一致的。6. 企业级部署与自动化管理思考对于单台服务器手动配置一下就可以了。但在实际的企业生产环境中我们面对的是几十、上百甚至上千台服务器。手动登录每台机器去敲命令不仅效率低下而且极易出错更无法保证配置的一致性。这时我们就需要将安全加固方案自动化、标准化。配置管理工具是首选比如Ansible、SaltStack、Puppet、Chef等。以Ansible为例你可以编写一个简单的playbook将上述的iptables或firewalld规则作为任务推送到所有目标服务器。下面是一个Ansible playbook的片段示例用于配置iptables规则- name: Harden server by blocking ICMP timestamp and traceroute hosts: all_servers become: yes # 使用sudo权限 tasks: - name: Drop ICMP timestamp requests and replies (INPUT) iptables: chain: INPUT protocol: icmp icmp_type: {{ item }} jump: DROP comment: Deny ICMP timestamp loop: - timestamp-request - timestamp-reply - name: Drop ICMP replies for traceroute (OUTPUT) iptables: chain: OUTPUT protocol: icmp icmp_type: {{ item }} jump: DROP comment: Block outbound traceroute loop: - echo-reply - destination-unreachable - time-exceeded - name: Save iptables rules permanently (for CentOS/RHEL) shell: service iptables save when: ansible_os_family RedHat通过这样的自动化脚本你可以确保整个服务器集群的安全基线是统一和可重复的。版本控制如Git可以管理这些配置脚本的变更实现审计和回滚。此外在制定企业安全策略时需要权衡安全性与便利性。完全阻断所有ICMP可能会影响一些合法的网络诊断工具。因此更精细的策略可能是在面向公网的生产服务器上实施严格的阻断而在内部管理网络或测试环境中可以适当放宽。你可以利用firewalld的“区域Zone”概念为不同网络接口分配不同安全级别的区域从而实现差异化的策略控制。最后任何安全规则都不是一劳永逸的。定期的安全扫描和渗透测试是检验这些防火墙规则是否持续有效的必要手段。将本文所述的加固措施纳入你的服务器初始化清单和持续安全运维流程中才能构建起主动防御的城墙。安全无小事从堵住每一个微小的“信息泄露”开始你的服务器才能真正地从网络上“隐身”让潜在的攻击者无从下手。