端口检查本身不告警，真正触发告警的是异常扫描行为；排查关键在于查“谁在扫、怎么扫、扫了什么、是否合法”，需根据fail2ban日志、iptables限速、自定义脚本或siem等不同告警来源，结合tcpdump、ss、日志分析等手段交叉验证并分类处置。
端口检查本身不会“告警”，它只是查看状态的手段；真正触发告警的是检测到异常扫描行为——比如某IP在短时间内狂扫上百个端口。排查这类告警，关键不是查“端口开没开”，而是查“谁在扫、怎么扫、扫了什么、是否合法”。
确认告警来源是哪类工具
不同机制产生的告警，排查路径完全不同：
-
Fail2ban 类日志分析告警：通常来自
/var/log/auth.log（SSH）、/var/log/nginx/error.log（Web）等。先看告警邮件或journalctl -u fail2ban输出，定位被封禁的 IP 和匹配的 filter 名称（如[nginx-badbots]） -
iptables/nftables 连接限速告警：若用了
recent或limit模块，需查dmesg | grep -i "DROP"或iptables -L -n -v | grep DROP，确认是否因 SYN/NEW 连接超限触发 -
自定义脚本告警（如 arp/port/icmp 监控）：检查
/var/log/scan-alert.log或脚本中指定的日志路径，看是 ARP 异常、端口连接突增，还是 ICMP 请求超标 -
SIEM 或安全设备告警：需结合原始流量（如 tcpdump 抓包）或
ss -tuln+netstat -antp快照比对，验证是否真有密集探测流量
快速验证是否真是恶意扫描
别急着拉黑，先做三步交叉验证：
- 用
ss -tn state established | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -10查当前高频连接源IP，看是否与告警IP一致 - 用
tcpdump -i eth0 src and port 80 -c 50 -nn抓包（替换为实际网卡和端口），观察请求是否规律性强（如连续 GET /wp-login.php、/admin.php、/phpmyadmin）、User-Agent 是否为空或含 Nikto/nmap 字样 - 查该IP是否出现在合法运维清单里：对比 Ansible 日志（
/var/log/ansible.log）、Zabbix agent 主动检查记录、备份脚本执行时间，排除定时任务误报
定位扫描行为的技术特征
根据告警类型，聚焦对应痕迹：
-
全端口扫描（TCP/UDP）：执行
nmap -sS -p-的典型表现是ss -tuln看不到新监听端口，但tcpdump -i eth0 'src <ip> and (tcp or udp)'</ip>显示大量不同目标端口的 SYN 或 UDP 包 -
服务识别扫描（-sV）：会在 TCP 握手后立刻发探测载荷，表现为
tcpdump -i eth0 'src <ip> and port 22' -A -c 20</ip>中出现 SSH banner 读取、HTTP Server 头探测等 -
隐蔽扫描（-sS、-sN、-sF）：不完成三次握手，需用
tcpdump查看 SYN、NULL、FIN 等异常标志位组合，配合iptables -L INPUT -v -n看对应规则命中数
收尾：判断处置方式
确认是真实扫描后，按风险等级响应：
- 内网IP扫内网其他主机：立即查该主机是否中毒（
ps auxf看异常进程、crontab -l查可疑定时任务），并通知负责人 - 外网IP扫你暴露的 80/443/22：用
whois <ip></ip>和 VirusTotal 查历史记录；若多次出现，加入防火墙黑名单（iptables -I INPUT -s <ip> -j DROP</ip>） - 告警IP是云厂商健康检查或 CDN 回源地址：加白名单，避免误封；可在 Fail2ban 的
jail.local中用ignoreip配置段排除 - 无法确认来源且频率不高：暂不处置，但开启
auditd记录其后续行为，命令如auditctl -a always,exit -F arch=b64 -S connect -F key=port-scan
