服务器dns被劫持怎么办？最快的处理路径是：先切断劫持链路保住业务，再排查入侵源彻底清理，最后加固DNS配置防止复发。
最近不少站长遇到一种情况：网站后台和服务器都能正常登录，但用户访问域名时跳到赌博或博彩页面，反复刷新也没用，这不是网站文件被改，而是服务器上的DNS配置出了问题，比起网站被挂马，DNS被劫持更隐蔽，它直接篡改域名解析结果，让访客绕开你的服务器,去到了一个完全陌生的地方。
怎么判断服务器dns被劫持
先别急着改文件,按下面的步骤确认是不是DNS层面的问题。
症状特征：多数情况下有这三个信号
- 用手机流量访问域名能正常打开，用服务器同线路的宽带访问却被跳转
- 直接访问服务器IP地址一切正常，走域名绕一圈就出问题
- 域名解析记录在域名商后台看是正常的，但本机或服务器上解析出来的IP不对
这与域名被劫持有本质区别，域名被劫持是域名商后台的解析记录被改，而服务器dns被劫持大多是服务器上的/etc/resolv.conf、本地hosts文件或内部DNS缓存被污染，行业共识认为,国内相当一部分网站打开异常属于后两类情况。
用命令做dns劫持检测
登录服务器执行以下操作,三分钟内能定位问题：
cat /etc/resolv.conf
重点看nameserver指向的IP是否为你机房分配的DNS地址，如果你的服务器在国内机房，正常的nameserver通常是内网IP（如10.x.x.x）或特定公网DNS,出现陌生公网IP就要警惕。
cat /etc/hosts
检查是否有可疑的域名映射记录，攻击者在入侵后往hosts里塞一行“受害域名 + 恶意IP”就能完成劫持,这种方式在配置了CDN的站点上更容易实现。
dig 你的域名 @223.5.5.5
用公共DNS（这里以阿里DNS为例）手动查询解析结果，如果返回的IP与你源站IP不一致，说明公网侧解析已被干预，而如果返回正常,则问题锁定在服务器本地解析环节。
dns被劫持怎么修复：应急处理三步走
确认被劫持后，按优先级依次执行以下操作,切勿跳过第一步直接重装系统。
第一步：立刻切换DNS出口
场景描述：你某台服务器的DNS指向被人改成了境外IP，正常的上网行为和API调用全部被重定向,此时最快的止损办法是：
echo -e "nameserver 223.5.5.5nnameserver 119.29.29.29" > /etc/resolv.conf chattr +i /etc/resolv.conf
第二行命令给配置文件加锁，防止进程或攻击脚本再次修改，这个操作在简米云和酷番云标准CentOS、Ubuntu环境中均实测有效，但Debian系部分版本重启网络服务会覆盖配置，需要同时修改/etc/network/interfaces或systemd-resolved服务设置。
第二步：检查并清除网络层劫持残留
- 查看路由表，重点检查是否有到特定IP段的特殊路由（
route -n） - 查看iptables规则，看是否有NAT转发、流量复制痕迹（
iptables -t nat -L -n） - 检查routing规则，看策略路由是否被改（
ip rule list）
很多网站在服务器dns被劫持的同时，防火墙规则也出现了脏数据，一次性暴力清除所有规则，网站还能不能访问存在较大概率的不确定性这正是不少运维人员踩过的坑，更稳妥的做法是先把规则导出备份，再逐条排查,只干掉可疑条目。
第三步：溯源入侵方式
DNS配置不会自己变，修复配置锁上文件只是治标，找出改动这道配置的入口才是根治,重点排查方向和操作路径：
- 查看登录日志，重点看sshd的Last failed login记录（
lastb） - 查看redis、memcached、mongodb等非关系型数据库是否有公网监听（
ss -lntp） - 查看bash历史记录，确认是否执行过奇怪的wget或curl命令（
history） - 检查定时任务，攻击者常把反向shell写成cron任务（
crontab -l）
这里说一个真实场景：某电商网站多次被dns劫持，每次改完配置第二天又变，最后发现是redis以root权限跑在0.0.0.0:6379上，攻击者用未授权访问写入cron反弹shell，整个链路绕过了所有安全软件,这类攻击手法在近年来海量的入侵事件中占比较大。
服务器dns被篡改的深层原因与配置加固
入侵入口的常见分布
- 弱口令爆破：SSH或数据库端口暴露公网，暴力破解后直接进去改配置
- Web中间件漏洞：包括但不限于反序列化、文件上传、命令注入，拿到shell后修改系统配置
- 第三方组件后门：部署的某个开源项目里藏有恶意代码，运行后自动改写解析设置
- 运维人员误操作：曾经手动改过DNS做调试，事后没有恢复
加固操作列表
安全收尾阶段,建议在服务器上完整走一遍以下配置：
- 禁止所有非必要端口对外监听，用安全组加防火墙双重控制
- 修改SSH默认端口，关闭密码登录，改用密钥登录
- 对redis、mongodb等数据库启用密码认证并绑定内网IP
- 安装并启用SELinux或AppArmor，给进程划分访问边界
- 定期用
rkhunter扫描rootkit，检测系统关键文件是否被篡改
长期防护：避免dns劫持卷土重来
自建内网DNS回落机制
大型一点的服务器集群可以用内网DNS服务（如dnsmasq或CoreDNS）做解析缓存，然后在内网层面锁定上游DNS指向，这样即使某台服务器的resolv.conf被改动，解析请求仍会被强制转发到可信DNS，内网DNS配合配置管理工具（Ansible、SaltStack）做统一分发,效果拉满。
对解析结果做主动校验
写一个定时脚本，每5分钟对域名解析结果做一次权威DNS与当前结果对比，出现差异立即告警,伪代码逻辑如下：
# 伪代码示意 权威IP = 解析自(你的域名, 使用DNSPod) 当前IP = 解析自(你的域名, 使用本地解析) 权威IP ≠ 当前IP，则触发告警和修复脚本
行业共识认为，自动化校验是把劫持事件从“事后发现”变成“分钟级处置”的有效前提，在代码实现时建议将SNMP监控平台联动起来,将检测结果作为自定义监控项持续上报。
备份和恢复预案
- 对/etc/hosts、/etc/resolv.conf、/etc/nsswitch.conf等关键文件做checksum快照
- 将快照同步到对象存储或另一台安全服务器上保存
- 在应急预案里写明恢复脚本的路径和执行方式，避免事发时现查命令
- 域名系统本身的账户开启二次验证，避免攻击者通过域名商后台对DNS解析记录做二次篡改
服务器dns被劫持处置的补充注意事项
不要在未确认来源时重装系统
很多人在排查无果后选择重装服务器系统，这在绝大多数情况下无效，如果入侵入口是网络层或中间件层面的漏洞，重装系统后，新系统再部署同样配置的组件，依然会被二次入侵，先定位入口，再执行修复,这个顺序不能颠倒。
关于CDN场景的特殊情况
如果你的网站接了CDN，现象表现会更复杂一点：用户访问被劫持，但源站回国线路解析正常，这种情况下除了排查服务器本机，还需要同时查询CDN节点解析记录与回源HOST配置，部分CDN客户会在回源配置里填写一个解析异常的域名，导致回源链路被劫持,可用第三方拨测工具对比全国各地的解析结果差异来辅助定位。
网站打开速度变慢与dns劫持
有一种不跳转但速度变慢的劫持方式：攻击者在DNS层把解析结果指向一个高延迟的中间节点，该节点转发流量并窃听内容，这种劫持不会改变页面内容，但会显著拖慢加载速度，此场景下前述的dig对比法已无法识别，需要通过对比国内外运营商网络的Traceroute路径，找出额外跳数，国内部分省份的运营商近年来在个别情况下也存在对特定域名解析结果的干扰行为，如果排查后发现是运营商层面问题,需要通过备案渠道向属地通管局反馈。
日常巡检命令清单
建议每周执行一次以下操作,将输出内容保存到日志系统备查：
cat /etc/resolv.conf cat /etc/hosts crontab -l ss -lntp ps aux 检查陌生进程 md5sum /etc/resolv.conf /etc/hosts
把这些命令写成一个shell脚本加入cron，输出重定向到远程日志服务器,本地被入侵清迹后还是有异地备份可查。
服务器dns被劫持的核心矛盾点在于：问题出在系统配置层面，容易被误判为网络故障，快速切换可信DNS并锁定配置文件，同步追查入侵入口，再配合自动化校验机制，才是完整的处置闭环。
服务器dns被劫持相关问题
dns被劫持后网站还能恢复HTTPS访问吗
可以恢复，DNS劫持发生在域名解析层，与传输加密协议无关，劫持可能导致访客的HTTPS证书校验失败，但这只是表象，清理完劫持链路的全部脏数据后，重新测试iisnode或Nginx配置中的证书链完整性，按原路径配置即可恢复，若劫持期间攻击者借机植入了伪造证书,还需要更新证书信任列表并作废旧证书。
云服务器的安全组配置能防止dns劫持吗
不能完全防止，安全组本质是网络层的访问控制，能阻断攻击者对特定端口的直接访问，但无法阻止攻击者在已入侵的Web应用中通过命令注入修改DNS配置，服务器的安全组应配合主机入侵检测系统使用，网易易盾、简米云安骑士等产品可对系统文件变更和进程行为做实时监控，关键文件被篡改时第一时间回滚并通知管理员,这是对抗DNS配置被反复篡改的常用组合方案。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e6%9c%8d%e5%8a%a1%e5%99%a8dns%e8%a2%ab%e5%8a%ab%e6%8c%81%e4%ba%86%e6%80%8e%e4%b9%88%e5%8a%9e%ef%bc%8c%e6%9c%89%e4%bb%80%e4%b9%88%e5%8d%b1%e5%ae%b3%ef%bc%9f/
