攻击链始于探测：从ICMP到端口扫描的防御前移-北京尧图网络

简介这份PPT围绕常见网络攻击的识别与防范展开面向网络安全初学者、运维人员及需要补强攻防基础的学习者系统梳理从攻击步骤到典型手法的知识框架。内容以预攻击探测为起点依次覆盖漏洞扫描与综合扫描、木马攻击、拒绝服务攻击、欺骗攻击、蠕虫病毒攻击及其他常见攻击并结合攻击链中的探测、渗透、驻留、传播、瘫痪等阶段帮助读者建立对威胁路径和防护切入点的整体认识。资源包共1个PPT文件约2.28MB页面结构按章节与攻击类型组织便于课堂讲解或自学查阅。目前已有2676人学习说明其在网络安全入门与科普场景中具有一定参考价值。读者可从中获得常见攻击手法的分类脉络、攻击步骤拆解及对应防范思路适合用作课程提纲、培训素材或安全知识梳理的辅助材料。1. 攻击链的真正起点为什么多数入侵在第一个 ICMP 回包里就已注定网络攻击、病毒、安全这三个词摆在一起时多数人脑子里浮现的是漏洞被触发的那一瞬间——栈溢出、恶意附件被双击、某个服务被打穿。但从攻防的实际成本看真正决定结局的是更早的一步目标被“看见”的那一刻。一台主机只要对外回过一个 ICMP Echo Reply它在攻击者眼里就不再是 IP 段里的一个概率而是一个确定活着、值得继续问问题的对象。探测、渗透、驻留、传播、瘫痪这五个阶段里前一个的输出就是后一个的输入而防御成本随着阶段往后推呈指数上升——在探测阶段封一个端口是一行访问控制规则的事在驻留阶段清一个后门往往要重装系统。后面几章就按这个顺序拆先看目标是怎么被测绘成一张地图的再看扫描器在协议层到底发了什么包然后进入控制权之后的提权与驻留最后落到 DoS、欺骗和蠕虫为什么共享同一套前提。2. 预攻击探测Ping、端口与操作系统指纹如何把目标变成一张地图预攻击探测的核心不是“打”而是“问”。一次完整的探测会按顺序回答四个问题哪些地址活着、活着的机器开了哪些服务、这台机器跑的是什么系统、这台机器上有哪些人和哪些共享资源。四个问题的答案叠起来攻击者才能决定用哪个漏洞、走哪条路径、需要什么权限。2.1 Ping 的三层语义没回包到底是死是活ping的名字来自 Packet InterNet Groper它做的事情极其朴素发一个 ICMP Echo Request类型 8等一个 ICMP Echo Reply类型 0。包里带标识符和序列号用来把回包和请求对上带 TTL每经过一个路由器减一减到零就丢弃并回一个 ICMP 超时报文。所以一次 ping 的输出其实包含三层信息通不通有没有回包、多远TTL 剩余值反推跳数、稳不稳序列号连续性、丢包率、往返时延抖动。真正值得琢磨的是第一层。很多人把“ping 不通”直接等同于“主机不存在”这是排查里最常见的误判。常见的实现思路是探测方发一个 Echo Request如果目标主机在线但防火墙在入方向丢弃了 ICMP你会收到超时如果目标主机不存在但网关配置了“不可达”回应你会收到 Destination Host Unreachable如果中间某台设备限速了 ICMP你会看到时通时不通。同一个“失败”背后是完全不同的网络状态。观察到的结果可能的真实状态下一步验证正常回包TTL 稳定主机在线ICMP 未被拦进入端口扫描请求超时无任何回应主机不在线或 ICMP 被静默丢弃换 TCP 端口探测别只信 ICMPDestination Host Unreachable路由不可达或网关主动回绝查路由表与网关配置时通时不通时延抖动大ICMP 被限速或被 QoS 降级增大超时值、拉长采样窗口回包但 TTL 异常小中间经过了额外跳数或存在隧道结合路由追踪定位扫描方通常不会只 ping 一台。Ping Sweep 是对整个网段逐个发送 Echo Request把回包的地址收集成一张存活表图形化工具只是把这套循环包了个界面底层仍然是同一个 ICMP 报文。所以针对这类探测的防御是明确的做法在边界设备上限制进出网络的 ICMP 类型只放行必要的错误报文如 Path MTU 发现需要的 Fragmentation Needed同时对 ICMP 做速率限制并记录来源。完全没有 ICMP 会破坏路径 MTU 发现放得太开又等于把存活表直接送出去。还有一个历史包袱值得知道早期某些系统在重组超长 ICMP 报文时会崩溃这类攻击被叫做 Ping of Death本质不是 ping 的错而是 IP 分片重组实现里长度字段溢出的问题放在第 4 章讲分片时一起说。2.2 端口扫描的三种连接策略与它们的暴露面Ping 只回答了“活着”端口扫描回答的是“开着什么”。TCP 建立连接的标准过程是三次握手客户端发 SYN服务端回 SYN|ACK客户端再回 ACK。围绕这个流程扫描被分成三类区分标准只有一个——有没有真的把连接建起来。开放扫描Open Scanning走完整的三次握手。扫描器调用 socket 的connect()连接成功说明端口开放返回连接被拒说明端口关闭。它的可靠性最高因为结果直接来自协议栈的明确答复代价是服务端应用层会真的accept()到这个连接连接日志、访问日志、审计系统里都会留下记录。同一个源地址轮流对几百个端口发起连接这个行为模式在任何像样的日志分析里都极其显眼。半开放扫描Half-Open Scanning只完成前两步。扫描器发 SYN收到 SYN|ACK 就判定开放然后立刻发 RST 把连接掐掉永远不进入 ESTABLISHED 状态。因为没有完成握手应用层的accept()从未被调用绝大多数应用日志里不会有这条记录。代价是构造原始 TCP 包需要更高权限在类 Unix 系统上通常要求 root 或CAP_NET_RAW能力。秘密扫描Stealth Scanning连三次握手的任何一步都不走。它利用的是 RFC 对“收到不属于任何现有连接的分段”的处理规定理论上应该回 RST。于是扫描器发一个孤立的 FIN、或一个所有标志位全为 0 的包、或 FIN|URG|PSH 全置位的包然后根据“回不回 RST”反推端口状态。隐蔽性最好但不同协议栈对这个规定的遵守程度不一致结果需要反着读而且这类异常标志组合在中间设备上很容易被丢弃导致误判。这三类策略不是替代关系而是按场景选内网自查用开放扫描最省事权限足够且不想留痕用半开需要穿过只做无状态过滤的设备时才考虑秘密扫描。2.3 OS 指纹识别靠什么特征区分两种内核知道端口开放还不够同一个 80 端口在两种操作系统上对应的漏洞集完全不同。操作系统识别的原理是不同内核在实现 TCP/IP 协议栈时做了一堆“规范没强制”的选择这些选择会稳定地体现在报文里构成指纹。常见的判别维度有这几个。初始 TTLWindows 系常见 128Linux 系常见 64部分网络设备 255实际收到的值还要减去经过的跳数。TCP 初始窗口大小不同内核的默认窗口值差异明显且相对稳定。DF 位是否在 IP 头里设置 Dont Fragment。TCP 选项顺序与内容MSS、NOP、Window Scale、SACK Permitted、Timestamp 这些选项的排列组合和取值是最有区分度的特征之一。初始序列号生成方式是纯随机、时间相关递增还是按固定步长增长直接关系到序列号预测攻击是否可行。ICMP 错误报文的回显内容不同实现引用的原始报文长度不同。特征观察方式判别价值初始 TTL收包 IP 头 TTL 字段粗分操作系统大类TCP 窗口大小SYNACK 的窗口字段TCP 选项排列SYNACK 的选项段逐字节比对IP ID 增长规律连续发多个包看 ID 增量判断是否可做 ID 侧信道ICMP 错误回显长度触发不可达后看引用载荷辅助确认这类识别的准确率不是百分之百——中间有 NAT、负载均衡、代理时指纹会被改写成中间设备的。所以实操里通常把它当成“缩小范围”的手段而不是“确认结论”的手段。2.4 资源与用户枚举比端口更安静的信息泄露端口扫描至少还会产生连接资源枚举很多时候连连接都不需要。文件共享枚举会列出目标暴露的共享目录名目录名本身就能透露业务结构默认团体名未改的 SNMP 会直接把接口表、路由表、进程列表吐出来邮件系统的用户猜测通过 VRFY、EXPN 或 RCPT TO 的差异化回应能验证某个账号是否存在ident 服务TCP 113在连接建立后能反查连接属主从而暴露服务是否以高权限运行。这里有一个值得记住的规律元信息端口的危害常常大于业务端口。业务端口被打穿需要漏洞而 113、161 这类端口泄露的是“这台机器怎么组织的”它把后续所有攻击的试错成本拉低了一个量级。防御上这类服务的原则是“不用就关要用就只对可信源开放”而不是“改了默认口令就安全了”。3. 扫描器怎么写出来的SYN、FIN、XMAS 与 IP ID 扫描的协议层细节上一章讲的是扫描的分类这一章往下钻一层看每一类在协议层到底发了什么、收到了什么、为什么结论能成立。看懂这一层日志里那些“看不懂的孤包”就不再是黑匣子。3.1 TCP connect() 扫描最可靠也最吵的一条路开放扫描不需要任何特殊权限一个普通的 socket 就够了。它的实现骨架大致如下import socket, errno def connect_scan(host, ports, timeout1.0): open_ports, closed_ports [], [] for port in ports: s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(timeout) try: s.connect((host, port)) # 完整三次握手成功即开放 open_ports.append(port) except socket.timeout: pass # 超时 ≠ 关闭可能被过滤 except OSError as e: if e.errno errno.ECONNREFUSED: closed_ports.append(port) # 收到 RST明确关闭 finally: s.close() # 无论结果如何都要释放描述符 return open_ports, closed_ports这段代码里最关键的不是connect()而是两个异常分支的区别。ECONNREFUSED意味着对端协议栈回了 RST这是明确的否定socket.timeout意味着什么包都没回来这是信息缺失可能是防火墙丢弃、可能是中间设备黑洞、也可能是主机负载过高没来得及响应。把这两种情况混成一个“关闭”是扫描结果误判的最大来源。参数上timeout不能设得太小——跨运营商链路的正常往返时延就能吃掉几百毫秒设 0.2 秒会把大量开放端口误判成超时也不能设得太大否则一个 C 段扫下来要几十分钟。实践中按目标网段分档设置更合理同机房 0.5 秒跨区域 2 秒。另外这段代码是串行的真实扫描器会做成并发但并发数要控制否则本机的文件描述符和临时端口会先耗尽。3.2 TCP SYN 半开扫描为什么内核不记账才算隐蔽SYN 扫描要自己构造 IP 头和 TCP 头走的是原始套接字。核心思路是只发 SYN看回应然后主动 RST 终止绝不让连接进入 ESTABLISHED。import socket, struct, random def build_tcp_syn(src_ip, dst_ip, src_port, dst_port): seq random.randint(0, 0xFFFFFFFF) # 随机初始序列号 # 数据偏移 5 个 32 位字(20 字节) 12低 12 位放标志位SYN 0x002 offset_flags (5 12) | 0x002 tcp_header struct.pack( !HHIIHHHH, src_port, # 源端口 dst_port, # 目的端口 seq, # 序列号 0, # 确认号SYN 阶段为 0 offset_flags, # 数据偏移标志位 5840, # 窗口大小取值本身也是一种指纹 0, # 校验和实际必须基于伪首部计算 0 # 紧急指针 ) return tcp_header判定逻辑很干脆回 SYN|ACK 说明端口在监听、愿意建连回 RST 说明端口关闭、协议栈在拒绝什么都没有说明被过滤。这里有个容易忽略的细节——收到 SYN|ACK 之后必须补一个 RST否则目标内核的半连接队列里会挂着一个等待第三次握手的条目直到超时才释放。大量扫描不补 RST本质上就是一次小规模的 SYN Flood。隐蔽性的来源在于连接从未进入 ESTABLISHED应用层的listen队列虽然短暂收到过握手请求但accept()不会被调用因此应用日志里没有记录。这是一条明确的隐蔽性边界并且内核层的统计仍然会变——半连接队列的占用、SYN 收包计数、以及某些系统的 SYN Cookie 触发次数都会留下痕迹。所以“SYN 扫描不可见”只对应用日志成立对内核指标和网络层流量分析不成立。这段代码跑起来需要原始套接字权限校验和字段必须按 TCP 伪首部源 IP、目的 IP、协议号、TCP 长度计算示例里填 0 只是为了突出头部结构实际发送前必须补上否则目标协议栈会静默丢弃。3.3 秘密扫描族FIN、NULL、XMAS 依赖的 RFC 漏洞秘密扫描的共同前提是一条规定收到不属于任何已建立连接的分段应当回 RST。基于这条规定扫描器可以构造三类“非法”包FIN 扫描只置 FIN 位。关闭端口回 RST开放端口丢弃。NULL 扫描所有标志位全为 0。同样按“回不回 RST”判断。XMAS 扫描FIN、URG、PSH 全置位像一棵点亮的圣诞树。判定方式同上。问题是这条规定并非所有实现都遵守。部分系统对关闭端口回 RST、对开放端口也回 RST结果就完全失去区分度另一些系统对所有端口一律丢弃。所以这类扫描的结论必须结合已确认的操作系统类型反着读不能单独使用。扫描类型发送的标志位开放端口典型回应关闭端口典型回应主要风险SYNSYNSYN|ACKRST半连接队列被占用FINFIN丢弃RST结果依赖协议栈实现NULL全 0丢弃RST同上且易被中间设备丢弃XMASFINURGPSH丢弃RST同上ACKACKRSTRST只用于探测过滤规则不判端口ACK 扫描单独说明一下它对开放和关闭端口都回 RST所以判不了端口状态但它能判断“有没有状态化防火墙”——如果 RST 没回来而是被丢弃说明中间设备在按连接状态过滤这本身就是有价值的情报。3.4 IP ID “dumb scan”与分片借别人的影子扫描这是整套扫描技术里设计最巧妙的一种。它的思路是不直接用自己地址去扫而是伪造第三方主机的源地址让第三方替自己“接话”再通过观察第三方的 IP ID 增长规律反推结果。具体机制分三步。第一步先向那台第三方主机业界叫“僵尸机”发一个探测包记录它当前的 IP ID 值再发一个看增量——如果增量是稳定的小步长说明它的 IP ID 是全局计数器可以当“影子”。第二步伪造源 IP 为僵尸机地址向目标端口发 SYN。第三步再测一次僵尸机的 IP ID。如果端口开放目标会向僵尸机回 SYN|ACK僵尸机收到这个不属于任何连接的包会回一个 RST这个 RST 让它的 IP ID 加一如果端口关闭目标直接向僵尸机回 RST僵尸机收到 RST 不会回应IP ID 不变。所以两次测量之间的 ID 增量就是端口状态的答案。这套机制的隐蔽性极高目标主机看到的扫描源是僵尸机自己的地址从未出现僵尸机只是个无辜的计数器。代价是对僵尸机的要求苛刻——IP ID 必须全局递增且增量可预测很多现代系统已经把 IP ID 随机化这条路基本被堵死。分片则是另一种绕过思路。把 SYN 包拆成多个 IP 分片第一个分片里只放 TCP 头的前 8 字节源端口、目的端口第二个分片里放标志位。只检查首片的包过滤设备会看到“一个没有标志位的合法 TCP 头”而放行目标主机重组后才看到真正的 SYN。这种手法依赖设备不做重组检查一旦中间设备做了完整重组分片就会被拦下。3.5 一个最小 SYN 扫描器的实现骨架把上面的零件拼起来一个能跑的最小扫描器需要这几步用socket.socket(AF_INET, SOCK_RAW, IPPROTO_TCP)创建原始套接字开启IP_HDRINCL自己填 IP 头。按目标列表循环为每个端口构造 SYN 包并发送记录发送时的序列号。用recvfrom收包解析回来的 IP 头和 TCP 头用目的端口和确认号匹配到具体的探测请求。按标志位分类SYN|ACK 记为开放、RST 记为关闭、超时记为过滤。每个结果无论开放关闭都补发 RST 释放目标半连接。收尾时输出三态结果而不是二态。第 6 步是三态还是二态直接决定这份扫描结果能不能用。把“过滤”和“关闭”混为一谈后面的漏洞映射就会把“可能存在的服务”当成“不存在”漏掉真正的风险点。这也是很多自动化扫描报告看起来全面、实际一问三不知的原因。4. 从控制权到破坏力提权、驻留、拒绝服务与欺骗的共同前提扫描完成之后攻击进入第二个阶段渗透。拿到一个低权限 shell 只是中点不是终点。这一章把提权、驻留、拒绝服务、欺骗和蠕虫放在一起看是因为它们共享同一个前提——系统对某个输入的信任超过了对它的验证。4.1 拿到 shell 之后口令文件与本地提权的两条路第一个动作通常是拿更多权限。最直接的路是口令类 Unix 系统的/etc/shadow里存着哈希Windows 的 SAM 数据库里存着本地账户哈希一旦读到就能离线爆破。防御这件事的关键不在密码复杂度策略写得多漂亮而在于哈希文件的读取权限是否真的收紧了以及是否存在用同一口令复用到多台机器的情况。第二条路是本地漏洞。最经典的一类是栈溢出函数把用户输入拷进固定长度的栈缓冲区没有做边界检查超出部分就会覆盖栈上相邻的数据。void copy_input(char *src) { char buf[64]; strcpy(buf, src); /* 无长度检查src 超过 64 字节即溢出 */ }这段代码的问题不在strcpy本身而在于栈帧的布局buf之后紧挨着保存的帧指针和函数返回地址。输入超过 64 字节后多出来的字节会依次覆盖这些位置函数返回时 CPU 从被覆盖的返回地址取指令控制流就落到了输入内容指定的位置。参数上唯一能限制长度的就是调用方而调用方一旦把这个函数暴露给网络输入边界就彻底失守了。现代的缓解手段是一整套组合栈保护金丝雀、地址随机化、不可执行栈、控制流完整性它们的作用不是让溢出不可能而是让溢出之后“跳到哪里”变得不可预测。还有一类更容易被忽略配置错误。某个以高权限运行的可执行文件权限设置过宽、某个服务用默认口令、某个计划任务脚本可被低权限用户改写。这类问题的特点是不需要漏洞就能提权扫描器扫不出来只能靠基线核查。4.2 后门的四种落点注册表、服务、文件、隐蔽通道权限到手之后要考虑“下次还能进来”。后门的落点基本可以归成四类每一类的检测难度不同。自启动项是最常见的Windows 上是注册表的 Run 键类 Unix 上是 rc 脚本、crontab、systemd 单元。这类后门的特点是有明确的位置用基线比对就能发现新增项。系统服务更进一步把后门注册成一个服务获得开机自启和特定权限检测要看服务列表和二进制路径。文件替换是把自己伪装成合法程序替换掉某个不常用的系统工具检测依赖文件完整性校验。隐蔽通道最难查它不创建新文件也不改自启动项而是把数据编码进正常协议的载荷里——比如 ICMP 的 Echo 报文数据段正常 ping 只有几十字节且内容规律一旦有人把命令输出切成小块塞进这些报文字段从流量上看仍然“像 ping”只有做载荷熵分析和长度分布统计才看得出来。这四类的检测成本是递增的前两类靠清单比对第三类靠哈希校验第四类只能靠行为基线。这也解释了为什么安全建设里“资产清单”这件事的优先级远高于大多数人的直觉。4.3 拒绝服务耗尽带宽、耗尽连接表、耗尽 CPU 是三件事拒绝服务的本质是资源耗尽但“资源”至少有三种对应的攻击手法和防御手段完全不同。带宽耗尽用远超目标出口带宽的流量把链路塞满。单台机器做不到所以要么用分布式流量要么用放大——伪造源地址向大量开放递归查询的服务器发小请求让它们把大得多的响应打向目标。防御只能在上游做流量清洗本地设备无能为力。连接表耗尽典型是 SYN Flood。目标每收到一个 SYN 就分配一个半连接条目等第三次握手攻击者只发 SYN 不回 ACK半连接队列很快占满正常用户的 SYN 被丢弃。防御手段是 SYN Cookie——不预先分配条目而是把连接信息编码进序列号收到 ACK 时再验证。这个设计的巧妙之处在于它把“状态”从内存挪到了报文里。CPU 与内存耗尽应用层慢请求。一个需要查库、需要计算、需要等锁的接口被高频调用就能把工作线程全部占住。这类攻击的流量可能很小从带宽监控上完全看不出来只能靠接口级的耗时和并发指标。三种耗尽的排查入口完全不同带宽看出口流量图连接表看netstat的半连接计数和 SYN 重传率应用层看接口 P99 和线程池排队长度。混着看就会得出“流量不大所以没被攻击”的错误结论。4.4 Ping of Death 与分片重组越界发生在重组缓冲区这个攻击值得单独讲因为它是“协议善意假设被利用”的教科书案例。IP 头里的总长度字段是 16 位理论上单个 IP 数据报最大 65535 字节。分片时偏移字段也是 16 位但单位是 8 字节所以最大偏移是 65528。一个攻击者可以构造一组分片最后一个分片的偏移接近上限同时自身还带一段载荷重组之后的总长度就超过了 65535。问题出在早期实现里重组缓冲区按 16 位长度字段来管理超长数据写进去就发生溢出轻则崩溃重则执行代码。修复方式很直接——重组时校验总长度上限超过就丢弃。但这类问题的模式值得记住任何一个“长度字段”和“实际可写入长度”不匹配的地方都是潜在的越界点。后来的分片重叠攻击、IPv6 分片头链式攻击都是同一模式的变体。4.5 IP 欺骗与序列号预测信任模型是怎么被拆掉的IP 欺骗本身不复杂源地址字段是发送方自己填的伪造没有任何技术门槛。它难的地方在于收不到回包——响应会发到被伪造的地址去所以欺骗只能用于不需要看回应的场景或者需要“盲猜”的场景。盲猜的经典目标是 TCP 序列号。早期实现用时间相关的计数器生成初始序列号可预测性很强。攻击者伪造源地址发出 SYN猜一个序列号发 ACK如果猜中连接就被建起来了而真正的源主机全程不知情。后来序列号改成加密随机生成这条路才被堵上。这条链路真正拆掉的是“基于源地址的信任”这个模型。早期很多服务允许“来自可信主机的连接免密登录”配置文件里写的是 IP 地址。一旦源地址可伪造、序列号可预测这个信任模型就完全失效。现代的做法是把认证从网络层挪到应用层——密钥、证书、令牌都是这个迁移的产物。4.6 蠕虫把上面所有步骤编译成一个不需要人操作的程序蠕虫和普通病毒的区别不在感染方式而在传播是否需要人。传统病毒要等人拷贝文件、执行附件蠕虫自己完成扫描、利用、复制、再扫描的循环不需要任何人工决策。它的结构其实就是前面几章内容的自动化串联一个扫描模块负责找存活主机和开放端口一个利用模块负责对匹配的目标发起攻击一个复制模块负责把自身写到新主机上并启动然后回到第一步。因为每一台新感染的主机都成为新的扫描源感染数量在理想条件下呈指数增长——这也是为什么蠕虫的处置窗口以小时计。从防御角度看蠕虫最怕的是“同质化程度低”和“横向移动受限”。前者让一个漏洞打不下整个网络后者让单点失陷无法快速扩散。这两件事都不是靠装一个检测设备能解决的而是靠网段划分、最小权限和服务收敛一点点堆出来的。5. 排查与避坑五个“以为防住了其实没有”的现场前面几章讲的都是机制这一章讲机制在真实环境里以什么形式让人误判。以下五条都来自实际排查中的典型情形按“看到什么现象、为什么会这样、该怎么处理”来写。5.1 只封了 ICMP就以为关掉了探测入口现象边界设备上禁用了所有 ICMP监控显示“没有 ping 扫描”于是判断探测阶段已被阻断。原因ping 只是探测的一种。端口扫描走的是 TCP跟 ICMP 一点关系都没有而且禁用全部 ICMP 会破坏 Path MTU 发现导致大包在链路上被静默丢弃表现为“某些网站打不开但能 ping 通”这类玄学故障。解决不要全禁按类型控制。放行必要的错误报文Destination Unreachable 中的 Fragmentation Needed、Time Exceeded对 Echo Request 做速率限制并记录来源同时对 TCP 层的异常扫描行为做检测——比如短时间内同一源对大量端口的 SYN 尝试。5.2 防火墙放行了“已建立连接”SYN 扫描照样穿过去现象规则里写的是“只允许内网主动发起的连接外部主动发起一律拒绝”但外部扫描仍然能拿到端口状态。原因状态化防火墙的“已建立”判定依赖会话表。SYN 扫描只发了第一个包会话表里没有对应条目按理应被拒绝但如果规则写得过宽比如允许任意源访问某几个端口或者设备对“只有 SYN 无后续”的包处理不严扫描的第一个包就已经拿到了 SYN|ACK 回应。更常见的情况是设备只检查了 TCP 标志位组合的合法性没做频率和目的端口分布的分析。解决把“默认拒绝”落实到具体端口而不是笼统的“内网可信”对入向 SYN 做速率限制开启会话表超时收敛避免半连接长期占用用外部视角定期实测别只看规则文本。5.3 应用日志里没有连接记录就以为没被扫过现象Web 服务日志干干净净没有任何异常访问于是认为这台机器没被扫描。原因SYN 半开扫描和秘密扫描都不会进入应用层的accept()日志里当然什么都没有。应用日志只能证明“没有完成的应用层交互”不能证明“没有探测”。解决探测行为的可见性在网络层和内核层不在应用层。要看的指标包括单位时间内收到的 SYN 数量与来源分布、半连接队列峰值、被拒绝的连接数、以及 ICMP 不可达报文的突增。把这些指标接进监控比翻应用日志有效得多。5.4 只盯业务端口忽略了元信息端口现象对外只开了 80 和 443自查报告写“暴露面极小”结果被人从 161 端口拿到了完整的接口表和路由表。原因业务端口的安全靠代码和框架元信息端口的安全靠配置而配置往往是最容易被遗忘的地方。SNMP 的默认团体名、文件共享的匿名访问、ident 服务的连接属主反查这些东西不会出现在业务代码评审里。解决做一次全端口的外部视角实测把结果和“应该开放的端口清单”逐条比对而不是和“上次扫描结果”比对。清单之外的端口要么关掉要么限制来源没有第三种选择。5.5 只看出方向流量不看入方向之外的东西现象入向流量监控一切正常没有任何攻击特征但内网某台机器在持续向外发送加密流量。原因失陷之后的动作全部是出方向的——回连命令控制端、外带数据、被当作反射源参与放大攻击。只盯入向的设备在这里是完全失明的。解决出方向要做两件事。一是目的地址白名单内网主机不该主动连陌生外部地址二是流量特征基线包括单位时间连接数、非工作时段流量、DNS 查询的域名熵值。这两件事都不需要解密流量就能做成本远低于全流量检测。6. 设计取舍为什么把预算压在探测阶段比买检测设备更划算把前面五章串起来看会发现一个不对称攻击者只需要找到一个入口防御者需要覆盖全部入口攻击者的每一步都可以复用工具防御者的每一条规则都要单独维护。这个不对称决定了安全投入的边际收益在链路上是递减的——越靠后的环节单位成本能挡住的东西越少。具体算一笔账。在探测阶段关掉一个不需要的端口成本是一次配置变更在渗透阶段挡掉一个已知漏洞成本是一次补丁窗口和一次回归测试在驻留阶段清除一个后门成本是重装、重建信任、以及无法量化的数据泄露到了瘫痪阶段成本是业务中断的时间和声誉。同样是“挡住一次攻击”在第一个环节做和在第四个环节做投入产出比差一个数量级以上。这也解释了为什么“默认拒绝、最小暴露面”这类看起来笨拙的原则实际效果远好于堆检测规则。检测的本质是“已知攻击模式的匹配”它对新型攻击天然滞后而收敛暴露面的逻辑是“不给我不知道的东西留入口”它不依赖对攻击的了解。前者要不断追后者一次做对能管很久。有一个验证方法我常用拿一份“应该对外开放的端口清单”从外部真实网络做一次全端口探测把结果和清单做差集。差集里的每一个端口都要能回答“为什么它在”。回答不上来的就是可以被砍掉的攻击面。这个动作不依赖任何检测设备也不依赖威胁情报纯粹是自我审视但它比大多数安全产品的告警更能降低实际风险。从那以后我每次上线新服务都强制走一遍这个自问这个端口真的需要对外吗能不能只对特定来源开放开放之后有没有对应的探测监控。三个问题里有一个答不上来就先不放行。这套习惯没什么技术含量但它把我踩过的坑基本都挡在了门外。希望帮到你。本文还有配套的精品资源点击获取

攻击链始于探测：从ICMP到端口扫描的防御前移

相关推荐

网络安全攻击链全景：预攻击探测、端口扫描与防御落点

TR-369 USP 设备管理协议：传输解耦与消息级寻址

从探测到瘫痪：网络攻击链视角下的攻击手法与防御落点

更多资讯

训练到部署：Model-Optimizer打通深度学习模型优化全流程

一周8k+用户：高性价比人生指南衍生站的内容结构化与静态生成实践

静态站+客户端检索：5天打造高转化轻量工具站实战

AI工程从零开始：理论学习、实战项目与部署落地的完整指南

GBase 8a数据库智能运维管理系统GDOM实战解析

C++冒泡排序原理、优化与实战应用

今日更新

淘宝商品详情API开发实战与性能优化指南

Unity Package Manager刷新错误排查与解决方案

Java record 规范构造器能否被反序列化或反射绕过

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？