源站端口持续被探测时，核心处置原则是：先隔离封禁，再分析溯源，最后调整架构隐藏源站真实IP，并配合云防火墙或高防产品收敛暴露面。这是所有应急响应的基本顺序，顺序错了，后续操作都可能是白忙活。
源站端口被探测时，如何判断这是扫描还是攻击
很多站长一看到安全日志里大量SYN包就慌,其实先要分清对方是“路过看一眼”还是“瞄准了打”，端口探测本身是网络攻击的前置动作，但不同特征对应完全不同的处置强度。
判断依据一：看端口范围是否离散
如果对方在短时间内尝试连接你的20、21、22、23、25、80、443、3306、3389等常见端口，这多半是全网随机扫描，这类扫描通常来自某些漏洞搜索引擎的爬虫，或者蠕虫病毒的自动化行为，它们不针对你，只是恰好扫到了你。
如果对方只盯着你的8123、9200、6379这类非默认端口，而且反复尝试，说明对方已经通过某种渠道拿到了你的端口开放信息，属于定向探测。
判断依据二：看来源IP的分布
- 来源IP来自多个国家、多个网段，且每个IP只发几个包，大概率是分布式扫描器。
- 来源IP固定,且持续一段时间内反复探测同一端口，那就是有人工参与的定向行为。
判断依据三：看是否伴随实际攻击载荷
单纯探测只是握手或连接请求,一旦出现畸形包、SQL注入片段、路径穿越尝试，那就已经从探测升级到了攻击，此时处置优先级要立刻提高。
行业共识认为,多数源站端口被持续探测的情况，都是因为源站IP曾在DNS历史记录或证书透明度日志中暴露过，导致被自动化工具盯上。
紧急止损：三步操作，立刻让探测行为失效
无论对方意图如何,当探测频率已经影响到服务器负载或让你心神不宁时，先执行以下三个动作，这三个动作按顺序做，不需要额外工具，所有云服务器控制台都能完成。
第一步：在安全组或防火墙中临时封禁来源IP
云服务商的安全组规则是实时生效的,打开控制台，找到该服务器所属的安全组，添加入方向拒绝规则。
- 协议：TCP
- 端口：被探测的端口
- 来源：攻击者的IP或IP段
- 策略：拒绝
如果是多IP轮换扫描,可以暂时在安全组中只放行你办公网的IP，其他全部拒绝，注意不要误伤CDN节点或API调用方的IP，否则网站会直接打不开。
第二步：修改SSH或远程管理端口号
22端口被探测几乎是所有Linux服务器的日常,与其天天封IP，不如把SSH端口改到高位随机端口，修改/etc/ssh/sshd_config中的Port参数，然后重启sshd服务，这里有个细节：
- 修改前先放行新端口,再重启服务，避免把自己关在门外。
- 修改后通知团队所有成员,并更新运维文档。
- 如果是Windows云服务器,3389端口被探测就改注册表或使用防火墙端口转发。
第三步：临时禁用或限制被探测的业务端口
如果被探测的端口对应某个内部管理后台、数据库、redis服务，直接将该端口的外部访问权限收窄到内网，具体做法：
- 使用iptables或firewalld限制来源IP段。
- 更彻底的方案是让服务只监听内网IP,不监听公网IP。
执行完这三步,你的源站对外暴露的端口已经大幅收敛，但注意，这治标不治本，对方如果真盯上你了，换个IP接着扫是必然的。
根因溯源：从探测流量里挖出背后信息
封IP只是被动防御,搞清楚对方为什么盯上你，才能真正解决问题，这一步需要看日志和抓包。
用tcpdump抓取探测包特征
如果探测还在持续,可以在服务器上执行：
tcpdump -i eth0 tcp port 你的端口 -c 200 -w probe.pcap
抓取200个包之后,用Wireshark打开分析，重点看：
- TCP窗口大小和TTL值,可以推测对方操作系统类型。
- 载荷中是否包含已知漏洞利用特征。
- 包的时间间隔是否规律,判断是脚本还是人工。
检查云平台的安全告警日志
大多数云厂商的日志服务里都有“入侵检测”或“DDoS防护”标签页，找到对应时间段的探测记录，看云平台是否已经给出攻击来源的地域、运营商、历史威胁情报，这些信息比自己分析要权威得多。
检查源站IP是否泄漏在公开渠道
最常见的泄漏点有三个：
- DNS历史解析记录：换过CDN后，源站IP可能还残留在历史DNS记录里。
- 证书透明度日志：为源站IP申请过SSL证书，证书信息会被公开。
- 邮件头信息：网站发送的邮件中可能包含源站IP。
用搜索工具查一下你的域名和证书指纹,如果确实泄漏了，务必按下一节的办法隐藏源站IP。
长期防御：从源站IP隐藏到源站防护产品选型
应急处置做完,接下来要搭建一套让探测失效的长期架构，核心思路是：让公网永远看不到你的源站端口。
修改源站架构，让源站只回源不对外
这是最彻底的办法,将网站接入CDN或云WAF，源站只接收来自CDN或WAF的回源请求，拒绝所有其他来源的IP。
具体操作步骤：
- 在CDN控制台接入域名,将回源方式设置为回源HOST或回源IP。
- 在源站安全组中,添加只允许CDN节点IP段的访问规则。
- 关闭源站所有非必要公网端口,只保留80/443（或自定义回源端口）。
- 设置回源鉴权,例如配置回源SNI或自定义Header校验。
这样,外部探测者直接访问源站IP时，所有端口都是关闭或拒绝状态，探测自然失效。
源站端口持续被探测如何防护，高防IP和云WAF怎么选
当探测伴随着大流量攻击时,单靠隐藏IP不够，你需要专业的流量清洗能力，这里有个选择参考：
| 场景 | 建议方案 | 适用条件 |
|---|---|---|
| 单纯的端口扫描、低频探测 | 安全组白名单+端口收敛 | 零成本，秒级生效 |
| 探测伴随CC攻击、应用层攻击 | 云WAF | 网站业务，需要防御SQL注入、XSS等 |
| 探测伴随DDoS大流量攻击 | 高防IP或高防CDN | 攻击流量超过带宽峰值，且源站带宽小 |
| 源站IP已完全暴露，且被持续攻击 | 更换源站IP + 全套防护 | 配合CDN隐藏新IP，彻底切断原有路径 |
关于高防IP价格,不同服务商差异较大，包年计费模式下，30Gbps防护能力的高防IP，市场价通常在几千元/月；按量计费或弹性防护会便宜一些，但超出保底防护峰值后的费用会按流量叠加，选择时重点看清洗能力和回源带宽，不是看谁家宣传的防护峰值有多高。
业内专家指出,源站防护的核心不是买最贵的防御，而是让攻击者找不到源站，即使攻击者打穿高防IP，只要源站IP没有暴露，业务就能快速恢复。
日常巡检：让探测死在入口
长期防御建立后,还需要养成定期检查的习惯，这里给出一份可以照着做的检查清单：
- 每季度用在线端口扫描工具（如Shodan、Zoomeye）自查一次源站IP的开放端口，看到意外端口立刻处理。
- 定期检查SSL证书,避免因证书泄漏源站IP。
- 维护一份端口白名单表,明确每个端口对应的业务、访问来源、负责人。
- 开启云平台的安全组变更审计日志,防止误开放端口。
这套流程走下来,源站端口持续被探测的情况就会从“被动的你来一下我挡一下”变成“我压根不给你看到的机会”，最后再强调一遍：先封禁，再改端口，最后隐藏源站IP，顺序不能乱，只要源站IP在公网上“隐身”了，端口探测就失去了目标。
源站端口被扫描怎么办？常见问题解答
端口探测频繁但业务正常，需要处理吗
需要,探测本身不可怕，但探测往往是攻击的侦察信号，如果对方发现某个端口有响应，接下来就可能尝试暴力破解或漏洞利用，即使业务正常，也建议至少完成安全组封禁和端口收敛两步操作，成本不到10分钟，能避免后期被动。
修改端口后，服务连不上了怎么办
先检查云平台安全组是否放行了新端口,再检查服务器本地防火墙（iptables/firewalld），常见问题是没有在新端口生效前就重启了ssh服务，如果已经断开，可以通过云服务商提供的VNC或控制台管理终端进入系统，恢复原配置，稳妥做法是先用会话保持工具如screen或tmux，或者同时开两个ssh连接，防止配置错误导致失联。
隐藏源站IP后，为什么后台管理入口也访问不到了
隐藏源站IP的核心思路是让源站只接受CDN回源请求,此时你的办公网IP不在白名单里，自然无法直接访问后台，解决办法是将管理后台绑定单独的域名，并设置额外的访问控制，比如只允许特定IP访问该域名，这样业务域名走CDN隐藏源站，管理后台走独立受限入口，两者互不干扰。