排查疑似异常端口占用的进程时，lsof 是常用工具，但需注意其基于 /proc 文件系统工作。如果系统底层已被 Rootkit 感染并挂钩了系统调用，lsof 的输出可能不可信。因此，使用前应先验证命令完整性，并结合多种工具交叉核对。
先说结论：lsof 能识别大多数常规网络绑定进程，但无法检测内核级 Rootkit 隐藏的端口。若怀疑系统被深度入侵，需使用静态编译工具或离线环境核查。
- 先判断：确认 lsof 命令未被篡改，当前用户具备 sudo 权限
- 优先做：使用 sudo lsof -i -P -n 扫描，并用 ss -tulpn 交叉验证
- 再验证：核对进程路径，优先尝试 kill -15 温和终止
命令完整性验证
在信任 lsof 输出前，需确认命令二进制文件未被替换。
RPM 系系统（CentOS/RHEL）：
rpm -V lsof
若无输出则表示文件完整；若有输出表明文件可能被修改。
DEB 系系统（Ubuntu/Debian）：
debsums lsof
若无此命令，可对比官方源 checksum 或从可信环境复制静态编译版本。
命令速用版
确认命令安全后，使用 sudo 权限查看网络连接及其对应的进程。不加 sudo 只能看到当前用户的进程，容易漏掉特权进程。
sudo lsof -i -P -n
如果怀疑特定端口（例如 8080）被占用，可以指定端口号：
sudo lsof -i :8080
建议同时使用 ss 命令交叉验证，避免单一工具被欺骗：
sudo ss -tulpn | grep 8080
分步处理
1. 确认工具可用性
检查系统是否安装了 lsof。部分最小化安装的服务器可能默认没有该命令。
which lsof
如果没有输出，需要通过包管理器安装。安装前建议核对软件包签名，防止源被污染。
2. 扫描异常连接
执行全量扫描，重点关注状态为 LISTEN 或 ESTABLISHED 的陌生连接。
sudo lsof -i -P -n | grep -i listen
记录下可疑的 PID 和 COMMAND 列。
3. 定位进程文件
根据上一步获取的 PID，查看该进程对应的可执行文件真实路径。这是判断是否为恶意程序的关键。
ls -l /proc/<PID>/exe
如果路径指向临时目录（如 /tmp、/var/tmp）或名称随机生成的文件，风险较高。
4. 处置进程
确认无误后，优先尝试温和终止进程，避免数据丢失或状态不一致。
sudo kill -15 <PID>
等待数秒观察进程是否退出，若未响应再强制终止：
sudo kill -9 <PID>
怎么验证是否生效
执行完处置操作后，再次运行 lsof 命令检查该端口是否仍处于监听状态。同时观察系统负载和对外网络流量是否恢复正常。
sudo lsof -i :<端口号>
如果命令输出为空，说明端口已释放。建议同时检查系统日志（如 /var/log/secure 或 /var/log/auth.log），确认是否有异常登录痕迹。
Rootkit 迹象处置
如果 lsof 与 ss 输出不一致，或发现进程路径异常但无法杀死，可能涉及内核级隐藏。
- 使用静态编译的网络工具（如 busybox netstat）从可信 U 盘运行。
- 检查内核模块列表：
lsmod，排查可疑模块。 - 必要时断开网络，备份数据后重装系统。
常见坑
1. 命令本身被篡改
如果系统已经被深度入侵，lsof 命令二进制文件可能被替换，导致输出虚假信息。此时需要使用静态编译的工具或从可信环境复制命令进行核查。
2. 权限不足
不使用 sudo 运行 lsof 只能看到当前用户的进程，容易漏掉以 root 或其他用户身份运行的恶意程序。
3. 短连接遗漏
lsof 展示的是当前时刻的连接状态。如果是瞬间完成的恶意连接，可能抓取不到，需要配合历史日志分析。
参考来源
- lsof 官方仓库：https://github.com/lsof-org/lsof
- Linux lsof 手册页：https://man7.org/linux/man-pages/man1/lsof.1.html
原文链接：https://www.zjcp.cc/ask/11385.html