简介这是一份系统梳理常见网络攻击类型与防范措施的PPT课件面向网络安全初学者、高校学生及运维人员帮助读者快速建立网络攻击与防御的整体认知。压缩包内包含1个PPT文件整体大小仅2.28MB内容精炼便于随时查阅。课件围绕典型攻击步骤展开详细讲解了预攻击探测、漏洞扫描、木马攻击、拒绝服务攻击、欺骗攻击、蠕虫病毒攻击及多种其他攻击方式并对端口扫描、操作系统识别、Ping探测等关键手段做了图解式分析。通过学习读者能够了解攻击者从信息收集、漏洞利用到权限提升、痕迹清除的完整链路掌握常见攻击的识别与防范要点为后续安全加固和应急响应打下基础。该资源目前已有2664人学习下载适合用于安全培训、课程教学或自学入门。1. 网络攻击最常撞上的那几类先认全敌人再谈怎么防半夜两点告警响登录一看内网一台服务器在往外疯狂发包CPU 跑满业务端口全部超时。查了半天是几个月前没打补丁的 JBoss 被挖矿程序当成了跳板。这种场景在中小公司里反复上演真正干的活儿不是研究 0day而是把最常见的那几类网络攻击认全、堵住、能发现。这个标题要解决的就是让你从“听说过攻击类型名字”到“能说出它怎么进来、用什么特征识别、拦在哪一层、误报怎么处理”。文章面向运维、安全工程师和刚转行做等保合规的人圈定在高频、真实、造成过重大损失的攻击方式上漏洞利用与勒索软件、DDoS、Web 应用层攻击、暴力破解和钓鱼投递。能覆盖一个中小团队对“常见网络攻击”的主要防御诉求也能在老板问你“这个告警要不要处理”的时候给出一个不心虚的判断。下面按攻击手法和防御落地的顺序展开重点放在能复现的检测配置和踩过的坑上。2. 从 WannaCry 到 Log4j常见网络攻击是怎么一步步拿到权限的2.1 勒索软件与漏洞利用从永恒之蓝看完整杀伤链2017 年的 WannaCry 是绕不开的样本。它利用 MS17-010 永恒之蓝漏洞在内网里像蠕虫一样主动传播加密文件后索要比特币。直到现在基于漏洞利用的勒索攻击依然是企业最头疼的一类网络攻击因为入口往往不是员工点错一个链接而是公网暴露的服务端口没修复。攻击的完整流程可以拆成七个阶段侦察、武器化、投递、利用、安装、指挥控制、行动。侦察阶段扫端口和版本比如用 Nmap 看 445 是否开放、SMB 版本是否老旧武器化阶段把漏洞利用代码打包成恶意样本投递阶段可以是钓鱼邮件附件也可以是直接对开放端口发起漏洞请求利用成功后写入计划任务或服务实现持久化然后回连 C2 服务器等待指令最后加密磁盘、横向扩散。对应的检测点其实很清晰。漏洞利用阶段会有特征明显的流量包例如 EternalBlue 会用特定的 SMB 头结构和管道名称Snort/Suricata 规则里能看到IPC$、Trans2请求异常执行阶段会有进程创建行为cmd.exe /c后跟着一串 Base64 编码的 PowerShell横向移动阶段会看到同一账号从多台机器登录。早期做检测主要靠特征但现在更靠谱的是行为基线某台机器突然扫描大量 445 端口、短时间内尝试登录多台主机这些比单纯匹配特征更能抓到变种。2.2 DDoS 与 Web 应用攻击流量和请求里的隐形刀DDoS 分两种一种打网络层比如 SYN Flood 把半连接队列打满UDP Flood 直接把带宽塞死另一种打应用层比如 HTTP Slowloris 用慢速请求占住连接不释放CC 攻击频繁请求动态接口耗尽数据库连接。网络层 DDoS 的特征是流量突增、来源 IP 分散、协议栈行为异常应用层 DDoS 更难防因为请求本身合法只是频率太高。Web 应用攻击则是冲着业务逻辑去的。SQL 注入通过拼接参数绕过认证或拖库XSS 把恶意脚本存进数据库再在别人浏览器里执行文件上传漏洞直接传一个 WebShell 拿到服务器权限。这类攻击的特点是单看流量包很小混在正常业务里不起眼必须结合 HTTP 语义去分析。比如id1 AND SLEEP(5)这种时间盲注普通流量监控根本看不出问题只有 WAF 或数据库审计日志才能定位。2.3 为什么传统防火墙经常防不住工具选型的现实逻辑传统防火墙基于五元组做访问控制在边界清晰、端口固定的年代很好用。但现在的网络攻击大多绕过了这个模型攻击者直接打应用层漏洞流量走 80/443 端口防火墙只会放行内网横向移动发生在已经放行的内部流量里钓鱼邮件和恶意附件更是防火墙看不到的内容。这就是为什么现实中要引入 NDR 或 IDS/IPS、WAF、终端防护工具来补齐。选型的现实逻辑是分层而不是替换。边界防火墙负责收敛暴露面只放行业务必须的端口IPS 或 Suricata 部署在核心交换机的镜像口负责发现漏洞利用和横向扫描WAF 前置在 Web 服务前过滤应用层攻击终端 EDR 负责查杀和异常进程行为。这样一套下来无论攻击从哪个入口进至少有一层能发现。对预算有限的小团队优先级是先把公网端口收敛了再把 Web 服务套上 WAF最后才考虑全流量分析——这和你面临的真实风险顺序一致。3. 用 Suricata 和 ModSecurity 本地复现检测最小可运行配置3.1 用 Suricata 在本地跑通最小检测环境Suricata 是目前最常见的开源 IDS/IPS 之一多线程处理性能比旧版 Snort 好规则集兼容还能输出 JSON 格式告警方便对接日志平台。在一个只有 CPU 和内存的普通云主机上就可以做最基础的检测验证。# 安装以 Debian/Ubuntu 为例 sudo apt-get install -y suricata # 检查版本确认安装完成 suricata --build-info | grep version # 把抓取的流量包文件放上来先用离线模式跑一遍规则 sudo suricata -r attack.pcap -S /etc/suricata/rules/local.rules -l /var/log/suricata这个命令的意思是用local.rules这个规则文件对attack.pcap文件进行离线检测告警写到/var/log/suricata/目录。先离线跑的好处是可以用真实攻击流量包验证规则是否生效不会影响在线业务。在线模式则是监控网卡流量核心参数是定义在/etc/suricata/suricata.yaml里的HOME_NET必须把它改成自己的内网网段例如192.168.1.0/24否则内网横向流量的源和目的都会被当成“外部”规则判定和日志可读性都会出问题。# 在线监控网卡 eth0 sudo suricata -i eth0 --set default-rule-path/etc/suricata/rules --set classification-file/etc/suricata/classification.config # 查看告警记录 sudo tail -f /var/log/suricata/eve.json | jq select(.event_typealert) | {timestamp, rule: .alert.rule, src_ip, dest_ip, severity: .alert.severity}eve.json是 Suricata 的核心输出每条告警是一个 JSON 对象。jq命令只筛出告警事件并提取时间、规则名、源目 IP 和严重级别用来看实时告警比翻文本日志效率高得多。如果你没有 jq先apt-get install -y jq装上。监控网卡时务必确认网卡名字Cloud 主机常见的是eth0但有些新实例是ens5或enp1s0用ip addr看一眼再下手。3.2 用 ModSecurity 模拟 WAF 拦截 SQL 注入ModSecurity 是目前使用广泛的 Web 应用防火墙引擎搭配 OWASP Core Rule Set简称 CRS可以拦截大多数常见 Web 攻击而且能跑在 Nginx 或 Apache 前面。为了快速演示效果我一般直接用官方 Docker 镜像起一个 Nginx ModSecurity 的实例再把 CRS 规则集挂进去。# docker-compose.yml services: modsec: image: owasp/modsecurity-crs:nginx ports: - 8080:80 environment: - PARANOIA1 - ERRORLOG/var/log/modsec_audit.log参数说明PARANOIA是 CRS 的检测等级从 1 到 4。等级 1 只开基础规则误报少适合默认开启等级 4 会检查非常细节的协议异常漏报少但误报率极高生产环境不建议直接开建议先 1 跑一周看告警误报情况再往上调。容器起来后用 curl 模拟 SQL 注入请求curl -v http://127.0.0.1:8080/user?id1%27%20OR%20%271%27%3D%271正常情况下请求会被 WAF 拦截返回 403 Forbidden同时日志里会记录命中的规则编号和原因。CRS 的规则覆盖很广从路径遍历、命令注入到 XSS 都有对应规则不需要自己写规则就能对常见 Web 网络攻击形成第一道防线。需要注意的是ModSecurity 自己是“检测”引擎能不能真正拦截取决于 Nginx 与它之间的接法容器镜像里默认是OnBlock模式即直接返回 403但如果你自己编译 Nginx 接 ModSecurity 模块需要在配置里显式打开拦截否则默认只记录不拦截。3.3 验证攻击流量是否真的被发现从造数据到查日志部署之后最关心的就是“规则到底能不能拦到攻击”自己造一批恶意流量是关键一步但要注意攻击模拟必须在你自己的测试环境里做绝不能在业务网络上扫。# 模拟端口扫描会被 Suricata 的扫描检测规则逮到 nmap -sS -p 1-1000 192.168.1.10 # 模拟 SQL 注入请求打到本机 WAF 上 curl -v http://127.0.0.1:8080/login?usernameadmin%27%20--%20 # 模拟暴力破解 SSH挑两个失败次数就够不要真打字典 ssh -o PreferredAuthenticationspassword -o PubkeyAuthenticationno root192.168.1.10造数之后去eve.json看是否有对应告警。常见问题是扫描流量有告警但应用层攻击没触发。原因通常是 Suricata 的规则集里没有针对 HTTP 的规则或者系统没启用http日志模块。检查方法是在suricata.yaml里确认app-layer的protocols下http的enabled为yes。如果用的是最小规则集建议直接换用 ET Open 规则集或 PT Open 规则集覆盖更全。另外要养成一个习惯每次更新规则集后用suricata -T测试规则文件语法再重启否则规则写错会导致 Suricata 启动失败而日志里看不到任何错误提示的情况也发生过通常要手动到journalctl -u suricata找原因。4. 攻击检测与防御里的常见问题排查4 个典型踩坑现场4.1 现象IPS 规则没触发扫描流量畅行无阻原因之一是规则文件没有加载。Suricata 默认从/etc/suricata/rules读取规则但suricata.yaml里有default-rule-path和rule-files两个配置项前者是规则目录后者是具体加载列表。曾经遇到过rule-files忘了把用户自己的local.rules加进去导致写好的规则根本没被读入另一个常见原因是自定义规则格式写错比如正则没转义规则校验直接失败。解决方法是先跑suricata -T -c /etc/suricata/suricata.yaml echo OK做语法检查再运行suricata -i eth0 --list-rules | grep 本地规则名确认加载成功。如果规则已加载但仍不触发要把eve.json里的event_type为alert的日志打开如果完全没有任何记录说明流量没到 Suricata需要检查交换机镜像口配置或网卡是否开启混杂模式。4.2 现象WAF 误报拦截正常业务用户大面积报错这种情况最常见。开启 CRS 的PARANOIA2后业务系统里用户昵称含单引号、搜索内容里含script字符串、正常订单金额带小数点的请求都会被拦尤其在下拉框参数多、富文本内容多的站点上特别明显。原因不是 WAF 不行而是检测强度和业务形态不匹配。解决首选给 WAF 配置白名单对特定 URL 或特定参数重置检测级别。ModSecurity 的规则用ctl:ruleEngineOff对精确匹配的RequestURI生效但使用前要评估这个接口是不是真的安全否则等于给攻击者留了后门。再一个做法是把拦截模式改成检测模式跑一周收集误报样本再回归调整——误报分析一定放在联动封禁之前。生产环境建议从 Paranoia 1 起步等告警稳定了再逐级上调。4.3 现象日志里有告警但没人处理安全设备形同虚设这个现象不是技术问题是流程问题。告警日志动辄每天几百条真实攻击一条没有误报几百条时间长了运维人员就不会再看了。问题出在没有按资产重要性和攻击危害度做分级一台测试机被扫描的告警级别不应该和核心数据库被注入的告警同级别推送。建议做法是把告警分成三个级别高危数据库、核心应用服务器上的命令执行和注入类、中危内网扫描、异常登录、低危外网扫描用规则里的priority字段做区分EPS 里只推送高危低危汇总成日报。这套分级机制可以用eve.json里的alert.severity字段对接告警平台让真正要人处理的网络攻击事件从噪音里浮出来。4.4 现象旁路部署检测不到加密攻击日志全绿但已经出事现在主流业务流量都是 HTTPS端口镜像出去的流量是加密的Suricata 看到的是一堆 TLS 密文HTTP 规则自然全不失效。这就是旁路 IDS 的现实局限。很多团队在出事后回看流量才发现攻击早就发生了只是在旁路设备上只看到 TLS 握手没有内容可分析。解决路径有三条第一是在 WAF 或负载均衡上做 TLS 卸载解密后再把明文流量镜像给 IDS第二是如果必须在旁路解 TLS就配置 Suricata 的 TLS 解密并导入服务器私钥但只对受控的内部域名做否则私钥放在旁路设备上本身就是新的隐患第三是针对无法解密的流量退而求其次只检测 TLS 握手阶段的特征比如 JA3 指纹、证书异常、会话时长虽然看不到内容但至少能发现异常 C2 回连。优先选第一条部署和排查成本最低。5. 把攻击分析做成可复盘的能力验证方法与三个进阶技巧到这一步基础检测能力已经搭起来了。但如果只停留在“跑通”层面下次遇到变种还是会翻车所以最后一个环节是把整个分析流程做成可重复验证的体系。第一招是把历史告警留成 PCAP 包。Suricata 配置里打开pcap-file的日志记录或者在检测到高危告警时用tcpdump同步抓包保留攻击发生时的原始流量。我在处理 APT 类告警时一定先找对应时段的 PCAP才能确认攻击是打进来了还是只做了扫描试探。没有原始报文你手里的线索就只剩日志没办法溯源。第二招是引入自动化的攻击模拟周期性验证规则是否还有效。用 Dude 或简单的 Scapy 脚本按季度分别模拟扫描、注入、暴力破解流量打到测试环境里检查告警是否能正常产生这样能及时发现规则集误更新、日志链路断了这类隐藏问题。规则集的“生命力”是用持续验证养出来的不能等出事再看。第三招是把告警跟资产信息关联起来。告警里只有源 IP 和目的 IP太单薄一旦 IP 换段就找不到对应负责人。把资产台账、应用负责人、业务等级打进 ES 索引每次告警触达时自动带上这些上下文响应效率是一倍以上的提升。回头说一个这几个月刚在处理的事一个高危告警指向内网一台旧应用服务器从抓包的 PCAP 里确认了攻击者利用的是 ThinkPHP RCE 漏洞已经写入 WebShell。因为告警里有明确的资产归属团队十五分钟就找到负责人完成了隔离和重置没有造成扩散。这个结果不是靠某一个工具牛而是从前置的风险评估、旁路检测、分级告警到资产关联每一个环节都提前铺好了路。希望这套思路也能帮你把网络攻击应对从被动救火变成可控的日常。本文还有配套的精品资源点击获取