凌晨两点被值班电话叫醒说线上登录入口间歇性打不开监控面板上流量曲线像心电图的异常波动。我第一反应不是去看应用日志而是先拉网络层的会话记录——这个习惯是被一伙黑产反复撕咬出来的。后来确认对方手里捏着一个恶意域名通过不断换绑IP、切换解析线路的方式反复试探业务边界。整个过程处理完我突然觉得以前上课时总觉得抽象的“网络层”在实战里原来是这么具体的东西。这篇内容与其说是复盘处置报告不如说是我自己的一份网络层学习笔记从一次真实的恶意域名对抗出发把网络层的基本职能、阻断思路、DNS过滤、日志溯源、主机加固和长期监控串起来讲。适合正在做运维、安全运营或者刚接手防护工作的同学尤其是那种“明明上了防火墙、封了IP对方却换张皮又回来”的场景应该能对得上号。1. 一次真实攻击让我重新理解了网络层的职责1.1 网络层在TCP/IP体系里的位置和它实际干的事我们经常说的“三层”在OSI参考模型里对应的是网络层。大家都背过七层协议但真正遇到攻击时最容易犯的错就是把七层的事情拿到三层来做或者反过来。理解网络层到底管什么是处置恶意域名的前提。网络层最核心的任务就是两件事寻址和路由。寻址负责给每个设备一个“门牌号”路由负责决定数据从源到目的地走哪条路。在网络层眼里它不关心数据里装的是HTTP还是SSH它只看到源IP、目的IP、协议号、分片信息这些“信封”字段。IP协议是网络层的主体它做的事情包括IP地址分配、数据包封装、路由选择、分片与重组。除了IP之外ICMP差错报文、ping的工具、ARPIP到MAC的映射甚至GRE这类隧道协议也都算三层或者紧贴三层的角色。但要记住NAT也发生在网络层很多人容易把NAT误归到四层或者应用层。从安全视角看网络层的价值在于任何攻击不管最后打的是Web漏洞还是弱口令流量必须经过三层。三层是绕不开的“咽喉要道”。同时三层能看到的信息是有限的——它不拆包、不解码所以它适合做“粗粒度封禁”不适合做“细粒度判断”。这就是为什么处置恶意域名时网络层阻断要和DNS过滤、WAF规则配合起来各自负责擅长的部分。1.2 为什么安全处置必须先把网络层吃透面对 jjiiee.com 这类恶意域名时如果只盯着应用层会很被动。攻击者会在应用层疯狂变换URL路径、请求头、payload但是在网络层他的源IP、目标端口、DNS解析记录、连接频率这些特征会暴露出来。攻击者反复攻击的过程中我发现一个规律他换域名解析很快但网络层的指纹变化很慢。比如某个源IP段总是踩点凌晨时段发起连接某类TLS握手特征总是成批出现。这些都是在三层可观察到的实体特征不随网页内容而变。理解网络层能使处置思路更清晰封IP封的是三层黑洞路由走的是三层的路由表DNS过滤虽然发生在应用层但它的目的却是影响三层寻址结果日志溯源最终也要靠三层会话时间线把零散线索串起来。一个合格的安全人员不在于记得七层模型每一层的编号而在于出现问题时能快速判断“这个问题该在哪一层解决”。这需要我们平时对三层的机制有足够理解。2. 研判攻击链路jjiiee.com 这个“对手”是怎么打的2.1 黑产团伙的常规攻击节奏收到告警后我没有第一冲去封禁因为封禁只是止损要避免反复被撕咬必须先搞清楚对方怎么打的。黑产团伙攻击一个业务目标通常有几个阶段探测、入口突破、权限维持、变现。这次围绕 jjiiee.com 的动作明显是“入口突破权限维持”的组合。探测阶段会做端口扫描、目录爆破、版本探测。入口突破阶段会根据暴露面选择策略要么打Web漏洞要么撞数据库或后台的弱口令要么利用已知CVE对中间件下手。一旦拿到权限攻击者会植入webshell、添加计划任务、修改登录配置保证自己之后还能回来。jjiiee.com 在这次攻击里的角色更像是一个“调度中心”它不太可能直接用来发起扫描而是被攻击者用在攻击链条的中后段——让已经控制的主机去回连这个域名从那里拉取指令、下载工具。这就是为什么单纯封一个IP没用因为恶意域名才是锚点。2.2 从域名解析到流量命中的可疑点发现 jjiiee.com 的过程其实不复杂。我先是看到某台业务主机的网络连接里有大量外联请求目标端口是80和443但目的域名非常固定请求频率也很规律。去DNS服务器上翻解析日志发现这个域名的解析量不高但QPS很均匀明显是程序在定时回连不是真实用户访问。再看解析行为有两点非常可疑第一TTL设置得极低只有60秒上下正常站点很少这么设第二解析结果在多个IP之间轮换甚至有几个IP是刚从别的恶意域名迁移过来的历史IP。这种低TTL加IP轮换目的就是让静态封禁策略失效。在流量侧我们抓到的会话还有一个特点连接持续时间短、每个连接的流量很小但连接频次很高。这种“心跳式”外联是典型的受控主机行为特征。到这里基本可以断定这台主机已经被纳入某个黑产团伙的调度网络jjiiee.com 是它获取指令的通道。2.3 处置目标不是“打死”而是让攻击成本高于收益很多人处置攻击时的执念是“把它彻底打死”。但黑产是打不死的域名可以再注册、IP可以再租、C2服务器可以再换。真正有效的处置思路是提高对方的攻击成本和风险让攻击行为对黑产来说是亏本买卖。围绕 jjiiee.com 的处置我给自己定了四个层次的目标第一层阻断。切断受控主机与恶意域名的通信链路。第二层过滤。让整个网络环境内对恶意域名的解析请求无效化。第三层溯源。定位受控主机、漏洞入口、攻击路径。第四层加固与监控。缩小暴露面建立发现此类威胁的自动化能力。这四个层次对应到技术动作分别是网络层阻断、DNS过滤、日志溯源、主机加固与WAF/IDS策略配置。接下来逐个说。3. 网络层阻断与DNS过滤把攻击挡在业务之外3.1 边界设备上的IP/网段阻断操作梳理完攻击链路我首先在边界防火墙上做了网络层阻断。思路很简单把恶意域名当前解析到的源IP、以及攻击者常用的扫描源IP段统统封禁。但这里有几个极易踩的坑值得记下来。第一个坑直接把IP封死在防火墙入方向会误伤正常业务。因为恶意域名和服务商CDN、云厂商出口经常共用IP段尤其是那些段很大、包含大量正常站点的情况。我一般会先做“目的IP目的端口”的联合限制而不是全端口段拦截。第二个坑只封输入方向不封输出方向。受控主机往恶意域名回连是出方向流量如果你的防火墙默认放行出站那么仅仅封入站是没用的。我在边界防火墙上做了双向ACL出方向直接拒绝到已知恶意IP段的新连接。第三个坑IPv6被忽略。很多内部网络明明开着IPv6但安全策略只写了IPv4。攻击者完全可能让恶意域名只解析到IPv6地址来绕过。我检查了防火墙的v6规则发现确实是空的马上把封禁策略复制了一份到v6。实际操作中如果你的边界设备支持黑洞路由处置会更干净。把恶意IP指向黑洞接口而不是简单地DROP可以把会话处理的开销也省掉避免大量非法连接占用防火墙会话表。下面是我当时的操作思路示例# 假设恶意域名当前解析到 203.0.113.10示例地址实际按解析结果替换 # 入方向阻断恶意来源 iptables -A INPUT -s 203.0.113.10/32 -j DROP # 出方向阻断受控主机回连 iptables -A OUTPUT -d 203.0.113.10/32 -j DROP # 如果有NAT转发链路还需要在FORWARD链做限制 iptables -A FORWARD -d 203.0.113.10/32 -j DROP如果网络环境里有核心路由器更推荐用黑洞路由方式ip route blackhole 203.0.113.10/32这样所有去往该IP的流量都会在路由器上直接丢弃对后续会话压力最小。需要注意的是黑洞路由要确认不是全局生效而是只作用于需要防护的那张路由表否则会影响其他业务线访问正常目的地的判断。IP封禁是对抗恶意域名的第一步但绝不能只依赖它因为攻击者会不停改解析。3.2 DNS过滤在递归解析层做“假死”处理恶意域名最优雅的手段是DNS过滤。它不用去猜IP直接让域名解析失效让受控主机根本拿不到可用的地址。DNS过滤可以在几个层面做本机hosts文件适合应急临时处理内部递归DNS服务器适合网络环境统一管控域名注册商侧适合已经确定不再使用的恶意域名可申请暂停解析。我当时是在内部DNS服务器上加了阻断配置。用的是Unbound在local-zone里把恶意域名指向黑洞地址# 让 jjiiee.com 的解析直接返回不可用地址 local-zone: jjiiee.com redirect local-data: jjiiee.com A 0.0.0.0 local-data: jjiiee.com AAAA ::如果用的是别的DNS服务思路一样返回一个不可路由的地址比如0.0.0.0或者直接return nxdomain。我更推荐返回0.0.0.0而不是NXDOMAIN因为用NXDOMAIN虽然看起来更像“域名不存在”但有些攻击程序会持续重试返回0.0.0.0后连接建立会立即失败重试频率反而低。在做DNS过滤时我还额外记录了一份DNS日志专门观察哪些内网IP还在持续请求jjiiee.com的解析记录。这个动作帮助我找到了第一台受控主机。攻击程序发现域名解不出来之后有可能会退回到硬编码IP连接所以DNS过滤一定要和网络层IP阻断搭配使用让域名和IP两条路都走不通。3.3 对抗CDN套娃、IP轮换和域名随机化黑产不会坐以待毙。我们封了IP、过滤了域名之后观察到的攻击行为还在继续只不过形式变了。第一招是CDN套娃。攻击者发现某个IP被封后开始把恶意域名的解析切换到CDN节点上。如果直接封掉CDN节点IP会误伤大量正常站点。应对方式是把封禁动作从“IP精确匹配”改成“域名SNI指纹匹配”这一步需要借助后面的WAF层来完成。网络层则专注于封那些确认为攻击源的非CDN出口IP。第二招是IP轮换。恶意域名解析的值频繁变化每次都不同。这个时候纯人工封IP已经跟不上了需要把DNS解析结果自动化同步到防火墙。我当时写了个小脚本每5分钟拉取一次该域名的解析记录凡是有新增IP就自动追加到封禁列表。这种做法对叶子节点极多的CDN没有效果但对小规模IP轮换很管用。第三招是域名随机化。攻击者会在主域名之外生成大量相似子域名或者干脆换注册新的域名。DNS过滤的规则也要跟着扩展。我在内部DNS上开启了“可疑域名特征”匹配用关键词特征把一批相似域名一并加了进来。另外通过威胁情报平台订阅了这个恶意域名的关联域名基本能覆盖大部分变异。防御动作要形成体系单点阻断总有漏洞。这也是我后来反复跟团队强调的观点网络层阻断是“止血”DNS过滤是“阻断通信链路”但都要和策略联动形成自动化的闭环。4. WAF/IDS规则配置与日志溯源从“能挡”到“看得清”4.1 WAF规则怎么写才不容易被绕过网络层和DNS过滤解决问题之后我开始处理应用层的残留攻击。攻击者进不来不代表他不尝试。从WAF的告警上看针对后台登录口的爆破和针对某中间件漏洞的探测一直没有停。写WAF规则的第一步是明确防守对象哪些路径是核心资产哪些请求算异常。对这次场景我加了三个维度的规则第一个维度是请求路径的精确控制。除了业务白名单路径外对可疑的脚本上传路径、备份文件路径一律拒绝。比如攻击者常探测的 /config.bak、/www.zip、/shell.php 这类路径直接增强拦截规则而不是交给默认规则去猜。第二个维度是基于频率的会话限速。一个源IP对登录接口的请求如果超过每分钟20次马上触发告警和临时封禁。这里要注意的是不能简单按“IP”限速因为攻击者会用分布式IP来绕过。要做“IPUserAgent指纹”的联合维度同一UA模式下频率异常也拦截。第三个维度是针对恶意域名通信的SNI/域名检测。WAF日志里含有TLS握手时的SNI字段只要发现是对向jjiiee.com的请求无需等待其他特征就直接拦截。这个规则后来成为拦击CDN套娃的主要手段。用ModSecurity风格的规则写出来大概是这种感觉# 针对恶意域名的TLS SNI检测 SecRule TLS: sni contains jjiiee.com id:10001,phase:2,deny,status:403,msg:malicious domain TLS handshake blocked需要注意WAF规则一定要放到解析阶段之前尽量在头部阶段做拦截减少对后端服务的消耗。同时WAF规则要基于证据而非猜测否则误报会很高。我见过太多团队把UA里的几个关键词加进规则就上线结果业务正常用户的请求被打掉了一片。4.2 IDS/IPS告警的降噪与调优WAF管完应用层流量IDS/IPS负责的是网络层和协议层的异常检测。部署Suricata这类IDS时告警量会在处置过程中爆发式增长一半是真正与恶意域名相关的连接另一半是正常的误报和重复告警。降噪的第一思路是“把已知的正常行为先过滤掉”。我在IDS规则里加了一个白名单基线把内部监控系统、办公网段、正常版本升级的客户端流量排除在告警外。这个动作直接让告警量下降了70%。第二思路是“聚合类似告警”。同一源IP对同一恶意域名的多次连接不要一条一条告警应该聚合成一条在指定时间内重复N次的告警。Suricata里有threshold和suppress关键字可以这样配# 检测与恶意域名相关的HTTP请求 alert http $HOME_NET any - $EXTERNAL_NET any ( msg:malicious domain communication detected; content:jjiiee.com; http.host; threshold: type both, track by_src, count 5, seconds 60; sid:100001; rev:1; )这样60秒内同一来源IP对该域名的连接次数超过5次才产生一条告警既保留了攻击证据又不会刷屏。第三思路是告警分级。把所有和jjiiee.com相关的告警标记为高优先级其他可疑行为默认为中低优先级。运营时只盯高优先级中低优先级留作日志回溯不干扰值班节奏。4.3 日志溯源要采集什么把五类日志对齐到时间线阻断做完、告警平稳了我开始做完整溯源。溯源的目的不只是写份报告而是定位攻击者最初是从哪个口子进来的。在这一步日志的关联能力决定了溯源质量。我整理了五类日志你可以作为处置同类问题的参考防火墙会话日志记录所有内外网连接的五元组、时间戳和流量大小用于还原通信时间线。DNS解析日志记录内网所有解析请求的源IP和查询域名用于发现谁在请求恶意域名。Web访问日志记录URL、UA、Referer、状态码用于定位漏洞利用路径。主机系统日志记录登录事件、命令执行、计划任务变更用于判断主机是否被拿下。进程运行记录通过auditd或类似工具追踪进程启动、文件变更用于发现webshell和挖矿程序。把这些日志放到同一个时间轴里攻击过程会很清晰某台主机在某个时间点先出现登录失败记录过了几分钟成功登录紧接着Web日志里出现了上传接口的POST请求再过一会儿该主机开始主动向jjiiee.com发起DNS查询和连接。链路就完整了。溯源报告不需要写得很玄核心是把关键时间点、端口、进程、域名、账号一一列出给出每个证据的日志位置。负责处置的人拿到报告后能按图索骥才是一份合格的报告。5. 主机加固与长期监控让对手失去“反复横跳”的耐心5.1 主机加固的优先级清单找到被控制的机器之后主机加固是阻止二次入侵的重头戏。网上加固清单很多动辄几十条实际执行起来很容易疲劳。我在这次事件里总结了一个优先级思路先处理能被黑产快速利用的短板。第一优先是SSH和RDP等远程管理服务的暴露面收敛。把默认端口改掉、禁止密码登录、只允许指定来源IP登录这些动作成本低、见效快。建议把公钥认证作为唯一登录方式密码登录直接关闭。第二优先是Web服务运行账户的降权。很多攻击事件源于Web服务被提权后又拿到系统权限。Web服务运行账户应该是最小权限绝不能是root或者Administrator。如果发现部署的Web服务是以高权限运行立刻重建运行账户并把站点目录的所有权一并收掉。第三优先是补丁与组件版本。排查业务中间件和第三方组件的漏洞重点看是否存在可被远程利用的高危漏洞。没有条件立刻全部升级时先加WAF规则做漏洞利用特征拦截。攻击者最爱的就是已公开了PoC的老版本组件。第四优先是账号和隐藏后门清理。检查计划任务、开机启动项、SSH authorized_keys、Web目录下是否有多余文件。发现攻击者创建的账号直接禁用。特别提醒清理主机后要替换所有可能被利用的密码包括数据库口令、运维平台口令、API密钥。加固做完后还建议做一次基线重新复核把所有配置导出、记录变更点和加固前对比确保没有遗漏。组织内部如果条件允许可以做一个轻量级的基线扫描不需要上高成本产品用自动化脚本检查关键项即可。5.2 长期监控该盯哪三个指标攻击是持续的处置动作做完不能就撤了。我设计了一个长期监控方案核心归纳为三个指标团队日常运维盯好这三个数就够了。第一个指标是封禁命中率。如果防火墙的封禁规则越来越频繁地被触发说明攻击者还在尝试还在不断换IP打你。如果封禁命中率连续两周处于低位那是一次有效的压制。这个指标可以从防火墙策略命中统计里拿。第二个指标是恶意域名活跃度。持续监控 jjiiee.com 及其关联域名的解析变化同时关注是否出现了与其解析IP相同的“姊妹域名”。域名可能被弃用但攻击者租用的IP段和DNS服务商往往有惯性。一旦发现IP关联到新域名就要准备新一轮处置。第三个指标是告警复发率。以受控主机为对象观察同一主机是否重复出现类似的恶意通信行为。如果某台主机清理干净后再发告警说明根除没做到位或者攻击者预留了更隐蔽的后门。这不只是“告警又来了”的问题而是需要重新走一遍溯源流程。监控不必很复杂一张简单的趋势表就可以每日封禁次数、恶意域名解析次数、受控主机数量、WAF拦截数形成趋势变化就足够用了。5.3 回滚预案假设误封了怎么办处置过程中最容易翻车的是误封。误封正常IP、误封共享出口IP会导致部分用户访问异常。所以我强烈建议先备好回滚预案再动手。回滚预案包含三件事所有封禁动作必须留档记录封禁对象、封禁原因、操作时间和操作人规则要支持批量解封不能一条一条手删要有确认机制解封前先在测试环境验证目标IP是否已无恶意行为再在正式环境操作。我个人的习惯是封禁规则上都会加一个“观察到期时间”。比如源IP段封24小时到期自动清理如果攻击还在就重新评估加封。这样做的好处是避免把临时攻击源当永久黑名单时间一长遗忘埋下后来误伤业务的雷。回滚预案不要只做成文档最好在处置前演练一遍。真实故障时大家都很紧张按文档熟练操作能减少很多慌乱。6. 实战之后我对网络层的理解变了处理完 jjiiee.com 这轮攻击之后我重读了网络层的教材章节理解完全不同了。以前我会把网络层单纯理解成“IP和路由”考试也是这么背的。但现在我会说网络层是整个安全对抗中最先接触战场的地方。攻击者可以无限变化应用层的请求内容但他必须先让数据包在三层找对路。这个“找对路”的过程就是我们做防御的人的机会。网络层的阻断不是万能的但没有网络层动作后面的DNS过滤、WAF拦截都会事倍功半。反过来只有网络层动作而缺少日志和监控就只能疲于奔命地封IP陷入攻击者不断换域名换IP的消耗战。这次实战给我的核心经验是处理恶意域名攻击网络层是起点而不是终点把阻断、过滤、溯源、加固、监控串成一条完整闭环才有机会让攻击者失去反复试探的耐心。最后再分享一个个人习惯的调整现在我看到任何可疑域名第一反应不再是查whois里注册了多久而是先看它的解析行为——TTL多少、IP轮换频率、关联域名有哪些。这些网络层可见的指纹往往比了一堆注册信息更快告诉我们对手想干什么。