简介这是一份面向网络安全初学者及高校计算机专业学生的《计算机病毒与防护拒绝服务攻击》教学PPT聚焦DoS与DDoS攻击的原理与分类系统讲解死亡之ping、ICMP洪水攻击、泪珠攻击的分片报文异常组合、Smurf攻击的欺骗放大机制等典型攻击方式并结合IP头、UDP头、偏移量等示意图解帮助学习者直观理解攻击数据包构造过程及防御思路。资源为1个PPT文件压缩包大小为1.69MB体量精简但内容模块完整适合课堂演示、课后自学或教师备课参考。截至目前已有363人学习下载被较多学习者用于网络攻防入门。通过学习可系统掌握拒绝服务攻击的各类变种原理、检测特征与基础防护策略并理清正常分片与攻击分片的区别是一份高性价比的速成课件。1. 从一次网页访问受阻说起DDoS离我们并不远可能每个人都有过这种经历打开某个网站页面没有正常加载却弹出一个提示——本网站使用安全服务防护恶意自动程序正在验证您不是自动程序请稍候。如果你还遇到过正在安全验证、验证码刷不出来、甚至直接超时白屏那大概率是网站正在挨打。学计算机病毒与防护课程的同学前几章多半还在讲病毒原理、木马特征、杀毒软件机制到拒绝服务攻击这一节往往会被绕晕病毒和DDoS明明是两回事为什么放进同一个课件原因在于拒绝服务攻击虽然不是传统意义上的计算机病毒但它是最常见、最容易上手、也最难彻底防御的网络攻击类型之一。它的核心目的不是偷数据而是让你服务不可用——把人家的店铺门口堵住不让顾客进门。这几年我帮朋友处理过好几次网站被打瘫的事故也从看到验证页就烦躁的访客变成了一看这页面就明白是怎么回事的运维人员。这一篇就把拒绝服务攻击的原理、分类、防护思路从头捋一遍希望能给正在学网络安全的同学、刚接手网站运维的新手、以及对企业安全体系感兴趣的朋友一些实际参考。2. 攻击花样太多先分清对手的类型和手法2.1 三种最经典的流量洪水SYN Flood、UDP Flood、ICMP FloodSYN Flood 是教科书级的老牌DDoS手法。TCP建连需要三次握手客户端发 SYN服务端回 SYNACK客户端再回 ACK连接建立。SYN Flood不完成最后一步只不停发送伪造源地址的SYN请求。服务端每收到一个SYN都要分配一块内存维护半连接状态结果就是半连接队列被塞满正常用户的连接请求进不来。我在实验室里用Python脚本模拟过这种攻击几十秒就能把一台内存不大的测试服务器打到拒绝服务。你可以用一条命令测试自己的Linux机器在半连接爆满时的表现观察ss -s里的SYN-RECV数量暴涨、netstat中出现大量半连接这就是攻击开始的信号。UDP Flood 更简单粗暴向目标服务器端口疯狂发送UDP包。服务器收到UDP数据报后要检查是否有应用监听该端口如果没有就回送ICMP端口不可达。这个过程消耗CPU和带宽流量一大就把链路打满。ICMP Flood 则是原来的Ping洪水通过海量ICMP Echo请求压垮对方。如今大多数云厂商会直接限制ICMP速率这类纯洪水攻击已经不算主流但它经常作为混合流量的一部分掺在其他攻击里云防火墙里看到ICMP占比突然升高就要警惕了。2.2 反射放大用别人的机器打你SYN、UDP、ICMP这三种洪水都是直来直去的攻击者用自己的真实IP很容易被抓到。反射放大类攻击就聪明得多攻击者伪造受害者的IP地址向大量第三方服务器发送小流量请求第三方服务器把响应发回受害者流量被放大几十甚至几百倍。DNS反射放大是典型代表。攻击者向开放递归的DNS服务器发送伪造源IP的查询请求一个几十字节的查询可能换来数KB的DNS响应放大倍数轻松达到50倍以上。NTP网络时间协议反射放大更夸张monlist命令的响应甚至能达到数千倍放大。Memcached反射曾在2018年打出过1.7Tbps的破纪录攻击。这类攻击的可怕之处在于攻击者只需占用很小的带宽受害者的带宽和链路资源却被瞬间耗尽。清洗时最难处理的也是它因为来源IP分散在成千上万个合法服务器上根本无法用简单的IP黑名单解决。2.3 协议漏洞型攻击不靠洪水靠聪明除了流量型攻击还有一类依靠协议漏洞的非洪水攻击。最典型的是Slowloris——攻击者建立HTTP连接后慢慢发送请求头每次只发一两个字节让服务器一直等着请求结束。Apache这类老服务器默认允许大量并发连接一百个Slowloris连接就能把所有worker线程占满正常人再也挤不进去。CC攻击Challenge Collapsar是更精细的应用层攻击。攻击者模拟真实用户行为不断请求网站的搜索接口、登录接口、或者那些消耗数据库查询资源的动态页面。这种攻击流量不大但每一个请求都让服务器做大量计算效果奇好。很多中小企业网站就是被CC打死的——看流量统计才几兆每秒CPU却已经100%了。这类应用层攻击的防御难度远高于流量洪水。流量洪水靠带宽清洗就能解决而CC攻击需要靠行为分析、频率限制、JS挑战验证码等手段区分真人和机器误杀率控制不好的话正常用户也会被挡在门外。3. 流量清洗与多维防护一套组合拳的思路3.1 为什么挡在门外比扛下来更重要很多新手有一个误区觉得加带宽就能扛住DDoS。我先泼一盆冷水——想靠钱堆死攻击者多半是堆不过的。带宽成本高而攻击者可以轻松发动比你的总带宽大十倍、百倍的流量。正确的思路是分层防御把攻击流量挡在到达源站之前。云服务商提供的DDoS高防IP从根本上改变了游戏规则高防IP会发布自己的路由把攻击流量全部吸引过去然后通过流量清洗系统剥离出正常流量再转发给真实源站。源站的真实IP如果隐藏得好攻击者甚至连你的实际服务器在哪都找不到。这就像一个高档小区快递和外卖统一送到大门口保安亭由保安分类后通知业主来取而不是让所有陌生人直接涌进单元楼。攻击者对着小区大门狂轰滥炸业主在楼里照样正常工作。3.2 四层防护如何协同工作一套完整的DDoS防护体系通常由四层协同完成第一层是网络层清洗解决带宽型和反射放大型攻击。ISP或云清洗节点在流量到达源站前识别并丢弃恶意数据包把攻击流量从大管网里洗掉。DNS、NTP反射攻击造成的带宽拥塞在这一层就能被拦截大部分。第二层是传输层防护主要处理SYN Flood等协议型攻击。高防设备通过SYN Cookie机制、源IP限速、连接速率限制等方式不分配本地资源就完成握手验证让半连接队列无法被塞满。第三层是应用层防护专门对付CC攻击。通过频率限制、验证码挑战、JS挑战、人机识别等手段识别并拦截高频率的恶意请求同时允许正常浏览行为通过。这层是误杀率最容易出问题的地方——规则设太紧自己用户被验证码烦死设太松攻击漏进来。最后一层是源的自身加固包括隐藏源站IP、最小化对外开放端口、数据库接口单独加白名单、服务器资源参数调优等。万一前三层被穿透这层还能扛一阵。3.3 一个容易被忽略的环节防护能力是算出来的选择防护方案时有个关键指标叫防护能力单位是Gbps带宽和QPS每秒请求数。但光看这个数字没有意义要看清洗节点的地理位置和线路质量。2019年有个客户买了100Gbps的高防结果攻击峰值才30Gbps就把他打挂了。排查下来才发现高防节点在华东他的服务器在华南攻击流量和高防清洗后转发的正常流量挤在同一条跨省链路上高防还没开始洗链路先堵死了。后来把高防节点迁移到就近地域才解决问题。另外做容量规划时的安全系数至少要留出2到3倍冗余——你平时业务峰值是20Gbps带宽至少要按50-60Gbps买高防因为攻击流量里掺杂的脏流量也要占清洗带宽清洗完之后正常流量还有一个回源的过程两者都会消耗资源。4. 一次真实攻击来袭防护实战日志复盘4.1 攻击前的迹象服务变慢、验证页突然出现去年帮朋友处理过一次真实攻击整个过程非常典型。朋友运营一个电商导购站点平时日活不算高服务器配置也就是一台4核8G的云主机。那天下午我在后台看监控先发现带宽使用突然从平时的2-3Mbps飙到50Mbps以上随后网站访问变慢图片加载半天出不来。大概五分钟后网站直接弹出了云服务商的安全验证页——本网站使用安全服务防护恶意自动程序这是服务商在流量异常时自动开启的主动防御机制。很多站长第一次看到这个页面会以为是网站被黑了其实这是高防系统在正常工作它识别到异常的流量特征后自动对所有访问者发起验证挑战。真实用户在几秒内完成验证就能继续访问而攻击脚本大多不会执行JS挑战直接被拦在门外。4.2 从被打到基本恢复的完整链路第一件事是登录高防控制台确认攻击类型。控制台上看流量曲线明显是突刺型脉冲攻击持续几分钟、停几分钟、再打几分钟。这种脉冲手法是为了绕过那些只在连续攻击N分钟后才触发告警的防护策略属于攻击者常用的时间差技巧。第二件事是开启紧急模式。我把防护等级调到最高同时开启了区域封禁、IP黑名单联动和访问频率限制。这三板斧下去攻击流量立刻被清洗掉大半。但是问题出现了正常用户也受到了影响。朋友反馈说有客户在微信里抱怨你们网站怎么老让输验证码。这就是我前面说的误杀问题——频率限制设得太紧正常用户点两下商品详情就被限速了。第三件事是定位攻击来源。通过高防平台的事件分析我看到攻击源IP主要来自海外集中在某个时间段内高频请求搜索接口。这显然是有人恶意定向攻击不是普通爬虫。我把搜索接口单独加了一层应用层防护对非登录用户单IP五分钟最多搜索10次超出就弹验证码。事后证明这个策略效果很好攻击请求被挡在搜索逻辑之外服务器负载立刻降了下来。攻击在一个多小时后停止总流量消耗大约几十GB。朋友问我这算是防护住了吗我的回答是算是扛住了但真正的攻防还在后面。因为DDoS攻击经常是波段式的对方看你不倒后面可能换更猛的手法再来。我给的建议是短期内保持高防护模式同时准备备用的弹性资源观察一周之后再把防护策略调回常规水平。5. 从课堂到实战给新手和中小团队的落地建议学计算机病毒与防护这门课的时候很多人觉得DDoS离自己很遥远——服务器都没几台谁会打你这个想法很危险。DDoS攻击的一大特点是攻击成本低租一个botnet集群、或者买一个小时的DDoS攻击服务可能只需要几十块钱。攻击者盯上你未必因为你是大目标也许只是随机扫描、按剧本敲诈勒索甚至是对手恶意竞争。所以哪怕你只是一个个人博客站长也应该有一个最基本的安全意识底线把高防服务和源站的账号安全做到位。云控制台的账号开启二次验证API密钥不要暴露在代码仓库里源站安全组规则最小化只对外开放80、443等必要端口。隐藏源站IP是最容易被忽略的事——如果网站打了高防CDN但SSH端口直接暴露在公网攻击者扫一眼就能拿到你的真实IP绕过高防直接打源站那就前功尽弃了。应用层的安全加固永远不应该停。拒绝服务攻击不是只存在于网络层的洪水SQL注入、XSS、越权攻击同样可以导致服务不可用。做Web开发的至少要掌握基本的注入防范、参数校验、频率控制、Session防护和输入输出过滤。安全不是安全工程师一个人的事是每个写代码的人的事。日志和监控一定要有。日志不全的攻击复盘基本等于瞎猜。我在实际处理中踩过一个大坑因为之前没有保留完整的访问日志攻击结束后想溯源攻击者、分析攻击手法什么都查不到。后来我把所有业务服务器的访问日志统一接入日志平台保留180天以上。下次再发生类似事件就能清晰看到攻击流量来自哪些IP段、命中哪些接口、落点在哪些时间区段这些细节是后续优化防护规则最重要的依据。监控层面建议给带宽使用率、CPU使用率、TCP连接数、HTTP请求错误率这几项都加上阈值告警。带宽和CPU的突增往往比网站打不开早五到十分钟报警这五分钟足够你做很多应对动作——提前开启防护、调整限流策略、给服务商提交工单。最后从个人体会的角度说一件事防护一定要做在平时不要等被打挂之后再慌慌张张找方案。高防配置、限流策略、备用切换方案这些东西在没有攻击的时候就要准备好、测试好。大部分人总觉得我没那么倒霉但真等到倒霉的那一天临时抱佛脚的成本往往是提前准备的十倍以上。拒绝服务攻击这场攻防战防守方的底牌永远是准备得越早、被打穿的机率越低。本文还有配套的精品资源点击获取