从网络层阻断到DNS过滤：恶意域名C2回连事件完整处置复盘

从事网络安全这些年，我对网络层（Internet Layer）的认识一直在变。刚入行时觉得它就是IP分组的转发逻辑、路由协议的堆叠，直到真正跟黑产团伙正面对抗，才意识到网络层才是最容易被忽略、也最该优先利用的防御阵地。前阵子处置了一个典型事件：恶意域名 jjiiee.com 被黑产团伙用来做C2回连，内网几十台主机反复外联，封了解析、清了进程，第二天又冒出来。今天就用这个案例，从网络层阻断、DNS过滤、日志溯源、主机加固、WAF/IDS规则配置到长期监控方案，完整复盘一遍处置思路和实操细节。这篇内容适合企业安全运维、网络管理员、等保合规相关工作的朋友参考，也适合刚接触安全应急的同学建立分层防御的概念。

1. 为什么网络层是应对黑产攻击的第一道战线

1.1 从协议栈定位看网络层的防御价值

TCP/IP协议栈里，网络层解决的核心问题是"数据该往哪儿去"。IP地址寻址、路由选择、分片重组都在这一层完成。它不像传输层那样关心端口和连接状态，也不像应用层那样理解HTTP、DNS、SQL这些协议语义，但它站的位置最靠近流量入口和出口——一个路由器的入接口如果直接把恶意流量丢弃，后面所有层级的设备和系统都不会感知到压力。

黑产团伙的恶意行为最终大部分要通过IP连接来兑现：受控主机向C2服务器发起心跳、木马下载后续载荷、外传窃取的数据，流量必定经过网络层。因此，网络层最核心的防御价值在于"快"和"广"。

一台边界路由器上敲一条黑洞路由，几秒钟内就能把所有发往恶意IP的流量全部丢进null0；而如果单纯依赖应用层封禁，规则加载、连接跟踪、业务影响评估都要花时间。真实处置现场往往是凌晨两三点的告警轰炸，这时候你需要的不是写复杂规则，而是先用网络层手段快速止血，保住业务不瘫、数据不再外泄，再慢慢做溯源和根除。

1.2 黑产团伙为什么偏爱网络层对抗手法

理解攻击者怎么用网络层，才知道怎么防。这次事件里，jjiiee.com 这个域名的解析记录就充分体现了黑产的对抗意识。他们用了短TTL和快闪IP的手段，域名解析记录最短只设60秒，每隔几分钟就换一批IP，服务器分布在多个国家的低价VPS甚至被入侵的普通站点上。

这种手法给防御者造成的直接困境是：如果你只封一个IP，黑产几分钟后又换一个，你必须不断追着封；如果你只封域名，木马程序里可能内置了多个备用域名，封一个它切到另一个。所以对抗必须在多个层次同时展开。网络层阻断解决"IP是会变的，但路径可以掐断"的问题；DNS过滤解决"域名是入口，让它解析到无效地址"的问题；主机加固和日志溯源解决"已经感染了，要把根拔掉"的问题。这四件事环环相扣，少一件都可能让前面的努力白费。

2. 拆解恶意域名攻击画像：先搞清楚对手出招套路

2.1 一次典型C2回连事件的行为特征

jjiiee.com 这类恶意域名最常见的角色是远控木马或僵尸程序的回连服务器。感染链通常是：内网某个用户打开了钓鱼邮件附件，或者下载了一个被投毒的破解软件，恶意代码落地后释放后门，随后受害主机开始周期性向该域名发起请求，等待C2服务器下发指令、上传窃取的数据、下载加密矿工程序或勒索组件。

从监控上看，这类行为有几个典型特征。请求频率有规律，有的木马固定每5分钟请求一次固定路径；流量大小不对称，回连时请求包很小，响应或上传时流量突增；DNS解析高频发生，因为域名IP老变，木马需要频繁查询。用NetFlow或防火墙会话日志能很快看到内网主机到可疑目的IP的连接聚合关系，把所有机器往外连的IP并在一起看，那个高频、批量"出头"的IP十有八九就是C2。

2.2 分层防御地图：网络层之外的完整处置脉络

这次处置我没有一上来就全盘封禁，而是先画了一张分层防御地图，确定每个层级要干什么、用什么工具、期望达到什么效果。大致是这样一个思路：

这张图的核心思想是：封禁只是插曲，根除才是正题。每一层都有独立的战术目标，但所有层加在一起才构成完整的战略闭环。下面我按这张图逐层讲实操。

3. 网络层阻断实操：把恶意流量摁在边界之外

3.1 黑洞路由与空路由的落地细节

最快、最暴力的网络层阻断手段是黑洞路由。把恶意IP的路由下一跳指向null0接口，设备收到这些IP的流量后直接丢弃，不再查路由表、不再转发，性能开销几乎为零。在核心出口路由器或防火墙上，针对jjiiee.com当时解析出的十几个IP，我一条条做了空路由。

以不同设备为例，思科系的路由器用ip route 1.2.3.4 255.255.255.255 Null0；华为和H3C的设备用ip route-static 1.2.3.4 32 NULL0；Linux服务器直接ip route add blackhole 1.2.3.4/32。网管型交换机如果支持三层路由，同样可以配。关键在于接口必须是null0或黑洞，而不是指向一个不存在的下一跳——指向不存在下一跳的路由不会转发，但会一直尝试解析ARP，占用资源。

有人会问，直接封IP不就行了，为什么还要做黑洞路由？因为在大型网络里，ACL规则是逐条匹配的，规则多了转发性能会明显下降；黑洞路由是查询路由表，效率高得多。对于应对大量恶意IP的突发场景，黑洞路由比堆ACL更实用。

3.2 防火墙ACL配置与方向选择

黑洞路由是对路由器的全局处置，防火墙ACL则更精细，可以按源、目的、端口、协议过滤。如果内网有主机已经在和恶意C2通信，我希望立刻断掉这条链路，同时又不想误伤正常业务，就需要配ACL。在边界防火墙上，以出口方向的入接口为例，拒绝内网访问恶意IP的流量。

不同品牌的防火墙写法和界面差异较大，但思路一样。华为USG上配置ACL 3000，加一条rule 5 deny ip destination 10.20.30.40 0，再在安全策略里引用；思科ASA加access-list OUTSIDE_IN extended deny ip any host 10.20.30.40。国产防火墙如深信服、山石，一般先建恶意IP地址对象，再配置拒绝策略。

新手最常踩的坑是ACL加错方向。防火墙ACL要区分流入和流出：你要拦的是内网主机主动访问外网恶意IP，ACL应该应用在"从内网到外网"的那个方向，而不是外网到内的方向。我在实际处置中吃过这个亏，第一版规则加反了，告警流量没有任何变化，排查了半天才发现方向错了。加规则之前务必先把设备拓扑和接口域搞清楚。

3.3 快闪IP场景下的自动封禁脚本

只靠人工封IP肯定跟不上黑产换IP的速度。jjiiee.com的解析记录每隔几分钟就会变，所以我写了个脚本，定时查询该域名的所有A记录，把新IP自动加入防火墙黑名单或黑洞路由。核心逻辑很简单：

import socket import subprocess import time domain = "jjiiee.com" blocked = set() while True: try: answers = set(socket.gethostbyname_ex(domain)[2]) except Exception: answers = set() new_ips = answers - blocked for ip in new_ips: subprocess.run(f"ip route add blackhole {ip}/32", shell=True) subprocess.run(f"iptables -A OUTPUT -d {ip} -j DROP", shell=True) blocked.add(ip) time.sleep(60)

这个脚本放在一台管理机上，每60秒解析一次域名，发现新IP就自动封禁。跑了两天后把域名关联过的所有IP都拉进了黑名单。需要注意的是，这种脚本必须要有日志记录，谁在什么时间封了什么IP要留痕，方便后续排查和回溯。

4. DNS过滤：让恶意域名实实在在变成"查无此站"

4.1 DNS沉洞的原理与意义

IP可以快速切换，但域名是攻击者甩不掉的标识。DNS过滤的思路是：在内网DNS解析链路里，把恶意域名直接重写到一个无效或受控的IP地址。这样不管木马换多少IP，域名解析这关就过不去。

在DNS解析里把恶意域名指向一个无路由地址，让回连请求消失在网内——这个技术就是DNS沉洞（DNS Sinkhole）。安全团队常用它来"诱捕"僵尸网络：当恶意域名被解析到沉洞IP时，所有请求都会被记录，攻击者看到了一个"假C2"，我们则通过这些连接记录找出所有被感染的主机。但要小心：沉洞IP要选一个公网路由不可达的地址，比如RFC 5737保留地址或内网专用的测试网段，不能随便指向一个真实IP，否则会把恶意流量引到别人家去。

4.2 dnsmasq、BIND、企业DNS的配置示例

不同的DNS环境有各自的写法。我自己用得最多的是这几类。

dnsmasq是最轻量的，直接在配置里加一行：

address=/jjiiee.com/0.0.0.0

这行的意思是，所有匹配jjiiee.com及其子域名的查询都解析为0.0.0.0。0.0.0.0在大多数系统上不会被正常路由，请求直接失败，这就达到了阻断目的。

BIND用的是RPZ（响应策略区域）或直接建zone。临时应急可以直接建个zone：

zone "jjiiee.com" { type master; file "/etc/bind/db.jjiiee"; };

db.jjiiee内容里写一条A记录指向127.0.0.1。企业Windows DNS服务器也可以用类似思路，创建一个同名区域，添加A记录指向沉洞IP。RPZ更适合长期运营，它能做到按域名、按客户端、按解析结果进行策略覆盖，不会干扰其他正常域名的解析服务。

另一个兜底方案是hosts文件。通过域控组策略下发，把jjiiee.com和已知子域名全部指向127.0.0.1。hosts方案的好处是不依赖DNS服务器改造，应急时几分钟就能推全网，但缺点是管理分散、只对Windows为主的环境有效、移动设备覆盖不了。我一般只把它当应急兜底，不当作长期方案。

4.3 绕过DNS过滤的两个高频坑

做完DNS过滤后，有个问题必须立刻检查：内网终端是否用了DNS over HTTPS加密解析。如果浏览器启用了DoH，系统解析DNS时会绕过内网DNS服务器，直接向远程DoH服务器发起加密查询，域名黑名单就形同虚设。企业办公网如果对安全要求较高，建议在客户端策略或防火墙层面禁用外部DNS和DoH，只允许内网DNS服务器对外递归。

另外，DNS过滤只解决"域名解析"，不解决"IP直连"。有些木马会把C2的IP直接硬编码在内存里，根本不走DNS查询。所以做完DNS过滤后，还要回到第3章的网络层IP封禁，观察是否有主机绕过DNS端口53直接向外发起连接。两个手段互相配合，才能真正堵住回连通道。

5. 日志溯源：把攻击链从头到尾翻个底朝天

5.1 溯源的第一步：回答三个问题

处置到这一步，攻击者的通道基本是被掐断了，但事情还没完。必须搞清楚三件事：哪些主机被感染了？攻击是什么时候进来的？通过什么路径进来的？这三个问题的答案都藏在日志里。开始溯源之前，先明确一个原则：不要只搜jjiiee.com这个名字，要把思路放宽到"所有可疑域名、所有陌生IP、所有非工作时间的高频外联"，否则漏掉备用的C2域名，过几天又会复发。

拿这次事件举例：我先在DNS日志里搜索所有包含"jjiiee"的查询记录，拿到了第一波疑似主机名单；然后用这些主机的IP去NetFlow日志里反查它们连接过哪些目的IP，发现了若干个与jjiiee.com共用同一批C2服务器的其他域名；再结合邮件网关日志和终端EDR日志，找到了最早的一个恶意样本下载行为——一封带Excel宏的钓鱼邮件，附件里还捆绑了一个.Net的远控木马。

5.2 日志源清单与关联分析技巧

做关联溯源，手上必须有一份日志源清单，缺哪个补哪个。我整理了这次用到的关键日志源：

关联分析的技巧在于"以时间轴串联"。选出最早的那条可疑日志作为时间起点，往前推7天（木马通常会有潜伏期），往后拉到现在，把所有主机的行为事件按时间排列，往往能看到一条完整链条：钓鱼邮件到达 -> 用户点击 -> 宏执行 -> 下载载荷 -> 进程运行 -> 开始外连 -> 横向扫描其他主机。每个环节都对应一条日志记录，链条闭合了，攻击画像也就完整了。

5.3 溯源结果反哺防御策略

溯源不是只为了写报告。这次溯源中，我发现了攻击者藏在jjiiee.com背后的另一组备用域名，以及木马用于横向移动的SMB爆破行为。这些信息直接转化为防御策略：备用域名全部加入DNS黑名单，SMB爆破行为写入IDS检测规则，钓鱼邮件的附件哈希同步到邮件网关黑名单。

这一步做完，防御就不再是"针对一个域名"的单点对抗，而是"围绕攻击者的基础设施和行为工具"的全面封锁。黑产团伙要换新的C2基础设施，成本和耗时都会显著增加。

6. 主机加固：清理残留、堵住漏洞，把水位降下来

6.1 恶意进程排查与清除

网络层和DNS层只能断链，不能消毒。被感染的主机如果不处理，杀完进程又会被任务计划唤醒，或者等网络恢复后再换一个C2域名回连。主机加固的第一步是排查恶意进程。

Windows环境我用任务管理器结合命令行工具查。重点关注CPU占用异常、无签名但驻留内存的进程、路径在临时目录或用户目录下却以服务方式运行的进程。配合Autoruns，把所有启动项、计划任务、服务、驱动、WMI事件订阅全部过一遍。Linux环境则是查看连接状态和进程树：

ss -antp netstat -antop ls -l /etc/init.d/ /etc/rc*.d/ crontab -l && ls /var/spool/cron/ ls -l /etc/ld.so.preload

查可疑连接的技巧是：先看ESTABLISHED状态里目的IP是否是已知恶意IP，再看CLOSE_WAIT和TIME_WAIT里是否有到境外异常端口的连接。端口443、80这类看着正常，但连接频次极高的，也可能是C2心跳。

6.2 持久化清理的完整链路

很多新手杀了木马进程后以为完事了，结果第二天又复活。问题出在持久化机制没有清除干净。恶意代码最常用的持久化手段包括：注册表Run键、启动文件夹、计划任务、Windows服务、WMI事件订阅、Linux的crontab、rc.local、systemd服务、动态链接库劫持。排查时务必逐项核查。

我在这次事件里就遇到过：木马以Windows服务方式启动，服务名称伪装成"WindowsUpdateService"，删除服务文件之前必须先停止服务、删除服务注册表项，再清理对应的DLL文件。如果在清理过程中发现文件被占用删不掉，多半是还有进程在运行，先在任务管理器结束进程树，或者从安全模式下清理。清理完重启所有受影响主机，再全盘杀毒扫描一遍。

6.3 攻击入口修复和基线加固

清理完残留，还要回答一个现实问题：攻击者是怎么进来的？这次事件是从钓鱼邮件进来的，但我也遇到过通过Web应用漏洞进来的情况。入口不修，等于把门敞着迎接下一次攻击。

针对不同类型的入口，修复动作不同。如果是钓鱼邮件，出入口要升级邮件网关的附件检测规则，给员工开安全意识培训，对高权限账号启用多因素认证；如果是Web漏洞被利用，要升级中间件版本、修复已知漏洞、在WAF上补充对应的攻击特征；如果是弱口令爆破进来的，要强制密码策略、启用登录失败锁定、封禁可疑来源IP。最后做一遍主机安全基线：关闭不需要的端口、禁用高危服务、启用主机防火墙、统一日志收集。我习惯在加固完成后做一次端口扫描验证，确认对外暴漏面确实收窄了。

7. WAF/IDS规则配置：让设备认识黑产的指纹

7.1 从攻击样本提取规则特征

前几层的防御思路是"不让流量出去"，WAF和IDS则是"让设备认识黑产的指纹"，即便攻击者换了域名和IP，只要行为特征没变，一样能识别出来。好规则必须来自对样本的分析，而不是凭感觉写。我在分析jjiiee.com的通信样本时发现几个特征：木马的心跳路径固定为/api/ping；User-Agent伪装成老版本浏览器Mozilla/4.0，明显不是正常用户；DNS查询频率极高，平均每5分钟查一次。

这些特征最终提炼成规则的匹配条件。写IDS规则我习惯用Suricata，它是开源IDS/IPS，规则语法和Snort兼容，支持DNS、HTTP、TLS等应用层协议字段解析，比只看五元组的传统规则更精准。针对这次事件，我写了两条规则做验证：

alert dns any any -> any any (msg:"jjiiee malware domain detected"; dns.query; content:"jjiiee"; nocase; sid:10000001; rev:1;) alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"C2 beacon path detected"; flow:established,to_server; content:"GET"; http_method; content:"/api/ping"; http_uri; fast_pattern:only; content:"Mozilla/4.0"; http_user_agent; metadata:service http; sid:10000002; rev:1;)

第一条规则检测DNS查询中出现的"jjiiee"字符串，第二条检测HTTP请求里的特征路径和浏览器标识。两条规则都先放在alert日志模式下跑了一周，确认命中流量确实是恶意样本产生的，才切到drop模式。

7.2 WAF自定义拦截规则的配置

Web应用防护的WAF规则配置，核心思路同样是"特征越具体越好"。如果你的架构在Nginx后面，ModSecurity是一个可靠的选择。针对恶意域名回连和扫描行为，我加过类似规则：

SecRule REQUEST_HEADERS:Host "@contains jjiiee.com" "id:20001,phase:1,deny,status:403,log" SecRule REQUEST_HEADERS:User-Agent "@pm Mozilla/4.0 (compatible; MSIE 6.0)" "id:20002,phase:1,deny,status:403,log"

需要注意，WAF规则一定不要匹配得太宽泛。比如上面用@contains jjiiee.com一定要带完整域名，而不是只用jjiiee几个字符，否则一个合法域名的某个子串可能误伤。User-Agent规则更危险，Mozilla/4.0这种特征很多老旧系统还在用，直接deny会导致正常用户被拦。这种规则我先放log阶段观察误报率，确认没有正常业务流量后，再改成deny动作。

7.3 规则调优中容易翻车的三个问题

第一，规则放在错误的位置。IDS探针要接在能"看到"流量的位置，如果接在SPAN端口上但SPAN端口没有镜像核心流量，规则写得再好也白搭。第二，特征太宽泛导致误报爆炸。宁可先用多个条件组合缩小范围，也不要用一个宽泛条件把所有流量都拦了。第三，规则只覆盖了已知域名和路径，对变种攻击没有感知。我会定期从威胁情报平台拉取最新的恶意域名和C2特征指标，批量转换为Suricata规则再导入，保持规则库的更新节奏。

8. 长期监控方案：从应急响应走向常态化对抗

8.1 定义需要盯防的关键指标

应急响应做完了，真正的考验是"它还会不会回来"。黑产团伙不会因为一次失败就放弃，换一个域名、换一批IP就能卷土重来。长期监控方案的目的，是把"发现—封禁—清除—加固"这套流程自动化、常态化。

我按网络层、DNS层、终端层、应用层四个维度各定义了几个关键监控指标。网络层看是否有内网主机再到已知恶意IP的外联；DNS层看是否有主机突然高频查询新注册域名；终端层看是否有进程异常创建、计划任务突变；应用层看WAF/IDS规则命中告警的频次。这些指标通过日志平台汇总，设置阈值后接入告警。比如，某个内网IP突然在5分钟内对外发起超过20次不同目的IP的SYN连接，直接触发中级告警。

8.2 自动化封禁与人工复核的配合

自动化是长期监控的必然选择，但必须留好"后悔药"。我可以写脚本定时解析可疑域名的新IP、自动拉黑，但每次拉黑前必须确认IP是否与正常业务有关联。这里有个亲身教训：某次脚本误把一个云厂商共享出口IP拉黑了，导致几个访客访问公司官网出现间歇性失败，那次之后我对所有自动化动作都加了"先写审计日志，再在运维群通知，人工可一键回滚"的兜底机制。

另一个需要注意的是自动化封禁的粒度。对恶意域名IP的封禁可以直接在网络层做，但对疑似IP的封禁建议放到防火墙应用层阶段，用会话数限制而不是直接deny，降低误伤概率。

8.3 威胁情报联动和专项封禁池

长期运营还需要引入威胁情报。把jjiiee.com相关的域名、IP、文件哈希统一提交到本地威胁情报平台，这样以后任何主机再访问这些指标，都能提前预警。同时，订阅商业威胁情报源，把"新注册域名""活体恶意域名"等维度的数据同步到DNS系统，做到域名级管控。

最后，我还维护了一个"专项封禁池"，把历次处置提取的IOC集中管理。每次新增IOC（域名、IP、哈希）都会自动推送到防火墙、DNS、WAF和IDS四个系统，形成一张覆盖边界、解析、应用、终端的纵深防护网。黑产每换一次马甲，我这边就多积累一次情报，对抗成本只会越来越高。

9. 常见问题与排查技巧实录

9.1 域名封了为什么内网还有回连流量

这是处置中最常遇到的问题，原因有两类。其一，DNS有缓存。终端和本地DNS解析服务器会把解析结果缓存一段时间，TTL设了60秒，但Windows的DNS缓存默认存活时间可能更长，实际上会有延迟。处理方式是在终端执行ipconfig /flushdns，或在内网DNS上强制刷新区域。其二，木马绕过DNS直接使用硬编码IP。如果封域名后仍有连接，就要通过防火墙会话日志查目的IP，把硬编码的IP也封禁。两个手段都做了还有流量，就说明有其他主机还没被发现，需要重新走一遍日志溯源流程。

9.2 规则加了为什么没生效

排查思路按顺序来：第一，规则是否真的下发到了所有节点。有的防火墙有多个集群节点，只在主节点配置了但没有同步。第二，规则方向是否正确。第三，设备是否有session复用机制，已有连接不受新规则影响，需要先清掉旧会话或等会话老化。第四，是不是硬件转发与软件策略不一致，个别设备修改策略后需要commit或激活才生效。这些坑我一个一个都踩过，现在配置完规则会主动做一次验证，用测试机模拟访问一下恶意IP或域名，确认规则确实拦截了才算完。

9.3 封禁规则误伤正常业务怎么处理

担心误伤是很多人不敢下手封禁的原因。我的做法是"分级封禁"：第一级是黑洞路由，只用于确认无争议的恶意IP；第二级是防火墙ACL，针对可疑IP做deny但允许白名单IP绕过；第三级是WAF/IDS规则，先用log模式观察再逐步收紧。同时，所有封禁都要有时效性，比如临时封禁24小时，到期自动确认是否继续保留，避免一次失误永远阻断。真发生误伤了，别慌，把源IP从封禁池移除，观察业务流量恢复正常即可。关键是前期的分级策略能极大减少这种事故。

9.4 黑产反复攻击，怎么建立可持续的防御心态

做安全最怕的是疲劳战。黑产团伙有自动化工具，几百个域名和IP轮着来，人工盯肯定盯不过。我的建议是把SOP化：所有处置流程写成文档，IOC集中管理，告警级别区分清楚，对级别低的告警交给自动化封禁，只有级别高的才需要人工介入。处置完复盘一次，把新总结的检测项沉淀到监控策略里。安全不是一夜清完就没有了，它是一个持续收敛的过程。每次处置都让下一轮攻击的难度变大，这就是长期对抗的胜利逻辑。

这次处置jjiiee.com，我个人体会最深的一点是：技术动作反而都是常规操作，真正拉开差距的是能不能把网络层、DNS层、主机层和应用层的动作串成一条线。单给防火墙加几条规则，只要域名/IP一变，防线立刻破功；只有把IOC沉淀、自动化封禁、日志溯源和长期监控串成体系，后续同类事件的处理时间才能从几小时压缩到半小时以内。如果你所在的企业还在靠人工盯告警，建议先把这次案例里的分层地图抄下来，按自己环境把工具补齐，下次遇到问题就不会手忙脚乱了。