确认服务器正在主动扫描内网，应优先执行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//exe —— 若显示 deleted，说明二进制文件已被删，但进程仍在内存中运行（常见于无文件攻击）
• 运行 cat /proc//cmdline | tr '' ' ' —— 查看完整启动命令，常能暴露 curl、nc、nmap、masscan 或自定义 Python/Go 扫描器调用参数
• 检查该进程打开的文件：lsof -p —— 特别关注是否打开了 /dev/random（生成随机 IP）、/proc/net/tcp（读取连接状态）、或大量 socket 文件
• 若进程是 bash 或 sh，用 strings /proc//mem 2>/dev/null | grep -E "(nmap|masscan|nc|curl|wget)" 尝试提取内存中的命令片段

很多扫描脚本会通过 crontab 或 /etc/cron.d/ 定时拉起，所以别漏掉：crontab -l; cat /etc/crontab; ls /etc/cron.d/ | xargs -I{} sh -c 'echo {}; cat /etc/cron.d/{}'。

Obsidian (Linux)

操作 Obsidian 库（纯 Markdown 笔记），并通过 notesmd-cli 实现自动化。

下载

怎么判断扫描流量是否来自恶意持久化模块

高级跳板可能绕过用户态进程，直接用内核模块或 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 更早暴露入侵起点。