核心是确认服务是否被hosts劫持、谁在操控映射、劫持是否生效：一查getent与非root用户解析差异及抓包验证；二查精准伪造的内部服务映射和证书依赖条目；三查定时任务、systemd定时器及临时目录脚本；四查服务配置、网络连接及证书颁发者。
排查服务器中被非法修改的 /etc/hosts 引发的服务定向劫持，核心在于确认“哪些服务实际走的是 hosts 解析”“谁在背后操控映射”“劫持是否仍在生效”。这不是文件内容清理问题，而是服务身份链路被切断或重定向的安全事件。
一、验证关键服务是否正被 hosts 劫持
不能只看 ping 或 curl 是否通，要验证真实请求路径：
- 对目标服务域名（如
auth.api.example.com、registry.internal）执行：getent hosts auth.api.example.com—— 若返回非预期 IP，说明系统级解析已生效 - 用非 root 用户测试：
sudo -u nobody getent hosts auth.api.example.com，对比结果。若仅普通用户被劫持，可能 NSS 配置（/etc/nsswitch.conf中hosts: files dns顺序）或权限限制已遭干预 - 抓包确认无 DNS 查询：
sudo tcpdump -i any -n -c 3 port 53 and host auth.api.example.com，同时执行curl -v https://auth.api.example.com。若无输出，说明请求完全绕过 DNS，由 hosts 决定流向
二、检查 hosts 文件中是否存在服务级定向条目
重点不是“有没有恶意 IP”，而是“有没有精准针对内部服务的伪造映射”：
- 搜索形如
10.20.30.40 auth.api.example.com、127.0.0.1 metrics.internal的行——这些看似“内网地址”，实则可能指向攻击者控制的中间人节点 - 警惕拼写混淆域名：
gitlab-internal.corpvsgitlab-internal.corp.（末尾点）、api-gateway.prodvsapi-gateway-prod，部分服务 SDK 会严格匹配 - 检查是否屏蔽了证书校验依赖服务：
0.0.0.0 ocsp.int-x3.letsencrypt.org或127.0.0.1 ct.googleapis.com，这类条目会导致 TLS 握手失败或证书吊销检查绕过
三、定位服务劫持的源头与持续机制
服务定向劫持几乎必然伴随自动化、隐蔽化写入行为：
- 查定时任务：
sudo crontab -l（root）、sudo ls /etc/cron.d/ /etc/cron.hourly/ 2>/dev/null | xargs -r cat 2>/dev/null | grep -E "(echo|sed|cat.*>>|hosts)" - 查 systemd 定时器伪装：
systemctl list-timers --all --no-pager | grep -E "(host|dns|update)"，再用systemctl cat xxx.timer查触发逻辑 - 查可疑持久化脚本：
find /tmp /var/tmp /dev/shm -name "*.sh" -mmin -1440 -ls 2>/dev/null，特别关注含sed -i '/auth\|api/d'或echo "10.1.1.100 auth" >> /etc/hosts的内容
四、关联验证服务运行态是否已被污染
hosts 劫持常是结果，而非起点。需同步确认服务本身是否已失陷：
- 检查服务配置中硬编码的 endpoint：
例如 Nginx 的proxy_pass https://auth.api.example.com、Java 应用的spring.cloud.config.uri，确认其解析结果是否与getent hosts一致 - 查服务进程网络连接：
sudo lsof -i -P -n -p $(pgrep -f 'auth-server\|keycloak') | grep ESTABLISHED，看实际连向哪个 IP - 核验证书信任链：
对劫持域名执行openssl s_client -connect auth.api.example.com:443 -servername auth.api.example.com 2>/dev/null | openssl x509 -noout -issuer，若 issuer 非你信任的 CA，说明流量已被中间人截获
