hosts被非法修改是入侵明确信号，需排查“谁改、怎么改、改了什么、是否持续”：先比对内容与默认值（127.0.0.1 localhost等），查修改时间及哈希；再用inotifywait或auditd定位源头进程；同步检查异常定时任务、可疑文件、SSH日志及二进制完整性；最后恢复备份、重设权限（644/root:root）、加固服务并部署监控告警。
服务器中 /etc/hosts 被非法修改，往往不是孤立现象，而是入侵或恶意软件落地的明确信号。排查重点不在“改没改”，而在“谁改的、怎么改的、改了什么、是否还在持续”。以下是务实、可操作的排查路径。
确认 hosts 文件是否已被篡改
直接比对当前内容与系统默认状态：
- 执行
sudo cat /etc/hosts，检查是否存在非预期条目，如大量指向127.0.0.1或私有IP的知名域名（github.com、cloudflare.com、updates.*等）； - 对比原始默认内容：标准 Linux hosts 至少应包含
127.0.0.1 localhost和::1 localhost，其余行均需有明确业务依据； - 用
ls -l /etc/hosts查看修改时间（Modify），若时间点与运维操作不吻合（如凌晨2点、无发布窗口期），高度可疑； - 运行
sudo md5sum /etc/hosts，与已知可信备份或同版本系统基准哈希比对，差异即为实质性篡改。
定位修改行为的源头进程
静态查看只能发现结果，动态监控才能锁定元凶：
GitHub Hosts CN
下载
GitHub Hosts 更新工具（仅限中国用户），安全更新系统hosts文件，保留原有非GitHub条目，仅替换GitHub相关地址。支持备份恢复和风险提示。用于解决GitHub访问问题。
- 在测试环境或低峰期，使用
inotifywait实时监听：sudo inotifywait -m -e modify,attrib /etc/hosts； - 若无法安装工具，可用
auditd持续审计（推荐）：sudo auditctl -w /etc/hosts -p wa -k hosts_mod，之后用ausearch -k hosts_mod | aureport -f -i查看完整调用链； - 重点关注触发进程的父进程、用户UID、执行路径——恶意脚本常通过
/tmp、/dev/shm或伪装成curl、wget、sed启动。
关联排查系统入侵痕迹
hosts 被改，大概率伴随其他失陷指标：
- 检查异常定时任务：
sudo crontab -l（root）、sudo ls /etc/cron.*、sudo systemctl list-timers --all，留意每小时/每分钟执行的curl或echo ... >> /etc/hosts类命令； - 扫描可疑文件：查找最近修改的可执行脚本，尤其是
/tmp、/var/tmp、/dev/shm下的.sh、.py、.elf文件； - 检查 SSH 登录日志：
sudo grep "Accepted" /var/log/auth.log | tail -20，确认是否有非常规IP、非运维时段、或使用弱口令/密钥登录后立即执行修改操作； - 验证关键二进制是否被替换：
md5sum /bin/sed /usr/bin/awk /usr/bin/curl，若哈希异常，说明攻击者已植入后门级工具。
恢复与加固措施
修复不是简单覆盖文件，而是阻断再发生路径：
- 先停止所有可疑进程，再用干净备份恢复：
sudo cp /etc/hosts.default /etc/hosts或手动重建最小配置； - 重设权限防止普通用户写入：
sudo chmod 644 /etc/hosts && sudo chown root:root /etc/hosts； - 禁用非必要服务（如未用到的 HTTP 代理、远程管理面板），关闭默认端口（如 SSH 的 22 → 改为高位端口）；
- 部署基础防护：启用
fail2ban防爆破，限制/etc/hosts的 inotify 监控告警，将审计日志同步至远程 SIEM。
