确认服务器正在主动扫描内网，应优先执行ss -tunp | grep -v "127.0.0.1\|::1"查看出向连接，结合netstat -ant | awk '$6=="SYN_SENT" {print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -10统计未完成握手的远端IP；若大量目标位于私有地址段（如10.0.0.0/8）且进程路径异常（如/tmp/.X11-unix/），基本可判定为恶意扫描。
怎么确认服务器正在主动扫描内网
如果一台 Linux 服务器被攻陷后用作跳板，它通常不会监听外部端口，而是悄悄向外发包——尤其是向内网其他 IP 的常见端口（如 22、3389、445、3306）发起连接或探测。最直接的判断依据是：本该只响应请求的业务服务器，却在持续建立大量短连接、SYN 包或 TCP 扫描痕迹。
关键操作不是看“谁连我”，而是看“我连谁”：
-
ss -tunp | grep -v "127.0.0.1|::1"—— 过滤掉本地回环，专注查看当前所有出向连接和监听进程 -
netstat -ant | awk '$6=="SYN_SENT" {print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -10—— 统计正在尝试连接但未完成三次握手的远端 IP，这是 SYN 扫描典型特征 -
tcpdump -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and dst port 22' -c 20 -w /tmp/syn_scan.pcap 2>/dev/null &—— 抓取 20 个发往内网22端口的 SYN 包，确认是否为批量探测
注意：ss 比 netstat 更可靠，因为后者可能已被 rootkit 替换；若发现大量连接目标集中在 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 范围内，且对应进程路径在 /tmp、/dev/shm 或用户家目录下，基本可锁定为扫描行为。
怎么定位扫描行为背后的进程或脚本
扫描工具本身往往不落地（比如内存中执行的 Python 一行命令），或伪装成合法进程（如 python3 /tmp/.X11-unix/update.py）。不能只信 ps 显示的 CMD，要查真实入口：
- 对可疑 PID，运行
ls -l /proc/<pid>/exe</pid>—— 若显示deleted，说明二进制文件已被删，但进程仍在内存中运行（常见于无文件攻击） - 运行
cat /proc/<pid>/cmdline | tr ' ' ' '</pid>—— 查看完整启动命令，常能暴露curl、nc、nmap、masscan或自定义 Python/Go 扫描器调用参数 - 检查该进程打开的文件：
lsof -p <pid></pid>—— 特别关注是否打开了/dev/random（生成随机 IP）、/proc/net/tcp（读取连接状态）、或大量 socket 文件 - 若进程是
bash或sh，用strings /proc/<pid>/mem 2>/dev/null | grep -E "(nmap|masscan|nc|curl|wget)"</pid>尝试提取内存中的命令片段
很多扫描脚本会通过 crontab 或 /etc/cron.d/ 定时拉起，所以别漏掉：crontab -l; cat /etc/crontab; ls /etc/cron.d/ | xargs -I{} sh -c 'echo {}; cat /etc/cron.d/{}'。
怎么判断扫描流量是否来自恶意持久化模块
高级跳板可能绕过用户态进程，直接用内核模块或 eBPF 程序发包，此时 ps、ss 都看不到源头。需要从底层网络栈和模块层交叉验证：
- 运行
lsmod | grep -E "(rootkit|hide|sock|nf_)"—— 检查是否有非常规内核模块，尤其名称含sock、nf（netfilter）、ipt的模块 - 检查 netfilter 规则是否被篡改：
iptables -t raw -vnL PREROUTING; iptables -t mangle -vnL OUTPUT—— 攻击者可能用OUTPUT链做透明代理或流量重定向 - 运行
find /lib/modules/$(uname -r)/ -name "*.ko" -exec md5sum {} ; 2>/dev/null | grep -v "No such file"—— 对比已知模块哈希，异常哈希值可能指向植入模块 - 检查是否有隐藏的 eBPF 程序：
bpftool prog list | grep -E "(socket|trace|xdp)"（需 kernel ≥ 4.18）—— 若看到非系统管理工具（如 cilium、bpftrace）加载的程序，高度可疑
这类模块级跳板极难清除，一旦确认存在，应立即隔离服务器并考虑重装系统，而非仅 kill 进程。
怎么防止服务器被当成跳板反复利用
排查只是止血，真正堵住漏洞要从权限、网络、日志三方面收紧：
- 禁用不必要的网络能力：
sysctl -w net.ipv4.ip_forward=0（关闭 IP 转发），并写入/etc/sysctl.conf永久生效 - 限制出向连接：
iptables -A OUTPUT -d 10.0.0.0/8 -m state --state NEW -j REJECT（按需调整内网段），避免横向扩散失控 - 审计所有具备网络能力的账户：
getent group netdev,adm,sudo | cut -d: -f1,4—— 检查哪些组能调用原始套接字，再查这些组里有哪些非运维人员 - 启用命令执行日志：
auditctl -a always,exit -F arch=b64 -S connect,sendto,sendmsg -k outbound_net—— 记录所有出向网络调用的 UID/PID/命令路径，便于事后溯源
最关键的遗漏点是：很多人只查“有没有扫描”，却忽略“谁授权了扫描”。/var/log/secure 里一条 Accepted password for hacker from 192.168.1.100，可能比一百个 SYN_SENT 更早暴露入侵起点。
