简介这是一份面向网络安全初学者、运维人员及安全培训讲师的PPT课件聚焦常见网络攻击类型与防范思路。内容从典型攻击的探测、渗透、驻留、传播、瘫痪五阶段入手系统梳理预攻击探测、漏洞综合扫描、木马攻击、拒绝服务攻击、欺骗攻击、蠕虫病毒攻击及其他攻击方式并详细讲解Ping扫描、TCP connect扫描、SYN半开放扫描、秘密扫描、操作系统指纹识别等技术原理同时对开放扫描、半开放扫描、秘密扫描等端口扫描模式进行了对比分析最后给出防火墙、入侵检测、防病毒等对应的防御措施。压缩包内仅含1个PPT文件大小约2.28MB页面结构完整、逻辑清晰便于直接用于个人学习或课堂分享。该资源已有2661人浏览学习适合希望快速建立常见攻击与防范知识体系的安全入门者也可作为高校网络安全课程的辅助教学材料。1. 最常见的网络攻击为什么总是防不住我刚处理完一次入侵复盘攻击路径让我印象很深对方没有用0day也没有复杂的定制工具就是一轮钓鱼邮件加一组泄露的SSH密码直接进了内网。这类剧情我已经见过很多次了问题不在于攻击有多高级而在于我们对最常见的网络攻击存在一种“已经防住了”的错觉。防御设备部署了但检测规则和生产流量之间隔着一层理想化假设规则只匹配GET请求里的完整关键字攻击者URL编码就绕过去统计只按源IP维度分布式慢速攻击就完全不触发。下面把几类高发攻击按攻击链拆开给出可以直接复制的检测规则、阈值和处置命令最后落在我真实踩过的一些细节上。2. 攻击链全景高频攻击的行为特征与判断依据写规则之前最好先把攻击链完整走一遍。不是走流程而是要在每个阶段想清楚同一个问题它的行为特征是什么和正常流量的差别在哪。这个差的值才是检测规则该抓的东西。下面把攻击链拆成四个阶段来讲每个阶段对应到具体的高频攻击类型。2.1 侦察与扫描可以分辨但不必急着封禁攻击者的第一步几乎都是侦察。外网层面用端口扫描确定开放的端口和服务Web层面用路径爆破找出后台入口、备份文件或源码泄露。这两类行为的共同点是请求模式明显偏离正常用户Nmap的TCP SYN扫描会产生大量只有SYN没有ACK的连接Web路径探测则表现为404响应集中爆发。正常用户的访问行为里404请求占所有请求的比例通常是个位数百分比而一次目录爆破在几十秒内就能产生几百上千条404。如果在Web访问日志里看到某个IP的404比例超过50%路径名还带明显的自动化特征比如/admin.php.bak、/.git/HEAD、/wp-login.php这类基本可以判断是一次侦察。处理扫描类告警我的原则是先观察再升级。一个外网IP每天扫几千次端口未必会真的发起利用真正危险的是扫描之后紧跟的利用尝试。所以我会把扫描告警放进低置信度池24小时后做汇聚。如果这个IP除了扫描还出现了暴力破解或Web攻击告警才提升为中危处置。不要试图封掉所有扫描源否则换来的是误报和业务投诉的叠加。2.2 Web注入与命令执行变形能力最强的攻击类型Web注入类攻击的难度在于同一个payload可以有几十种编码变体。以SQL注入为例union select可以被编码成%75nion%20select、union/**/select、UnIoN SeLeCtMySQL下还有/*!50000union*/ select这种内联注释写法。如果检测引擎不做参数提取和解码规范化直接拿原始请求做正则匹配等于在裸奔。XSS检测的难点是双向确认。反射型XSS的判断依据是请求参数里的脚本片段被原样拼进响应页面。只看请求侧容易误报因为搜索框、错误提示页都可能把用户输入反射回页面只看响应侧也不够因为页面里的脚本可能是正常业务逻辑生成的。只有把请求和响应关联起来同一个脚本片段在两个方向都出现命中才可靠。命令注入的特征是命令分隔符加命令关键字的组合。与SQL注入不同的是命令注入可以做得更精确因为业务参数里出现;cat /etc/passwd这种结构的概率很低。造成误报的往往是那些看起来无害的正常参数比如排序参数?sortasc;limit10。我的做法是限定在参数值的尾部做匹配命令注入的payload几乎总是追加在参数末尾而不是插在中间。2.3 暴力破解与撞库源IP维度为什么一定会漏暴力破解是检测系统最容易漏掉的攻击之一前提是攻击者用了分布式来源。现实中的攻击者会用节点池轮换出口IP每个IP只尝试三四次就切换单IP的失败次数永远不会超过阈值。这是我见过最多的翻车案例规则写得很认真阈值调得也算合理但就是漏了。撞库的识别更难因为撞库的成功率可能很高攻击者手里的密码就是从真实泄露数据里来的。这种情况下失败次数统计几乎抓不到什么。撞库的突破口在于成功登录后的异常行为一个账号在短时间内从多个地理区域登录或者在登录成功后立即访问了与原系统无关的其他系统。这些行为不符合正常用户的习惯可以做成关联规则的重要维度。我把暴力破解和撞库设计成一个双层统计模型先按账号聚合短时间窗口内的失败次数和来源IP数量超过阈值即告警再按源IP统计失败次数用于捕获单点高强度的攻击。账号维度优先级高于IP维度因为它更贴近攻击意图。攻击者眼里是账号系统眼里是IP统计口径不匹配检测就必然有心无力。2.4 驻留与横向移动比利用更值得警惕的阶段完成一次性利用后攻击者要做的是维持访问并扩大战果。WebShell是最典型的驻留手段。检测WebShell的关键不在于识别文件内容而在于文件变化和请求行为的关联。一个PHP文件在凌晨被修改紧接着被多次HTTP请求触发返回大小显著变化这个组合信号比单纯的内容特征可靠得多。横向移动阶段RDP和SSH的异常登录是关键信号。攻击者拿到一组内网凭据后会批量尝试登录其他主机特征表现为短时间内同一账号出现在多台主机上源IP分散但目标账号集中。这里再次体现了账号维度的重要性。从账号维度看这是明显的横向移动从单个主机的日志看可能每台都只有一两条失败记录完全不值得关注。我还建议给账号建立登录基线记录账号在正常情况下的登录源主机列表、时间分布和登录协议。当基线上的偏移量超过一定比例比如一个账号突然从之前从未出现过的主机登录或者高频跨主机登录不管登录是否成功都应该触发观察。3. 检测落地Web注入、暴力破解、钓鱼的具体规则与阈值3.1 SQL注入检测的Suricata规则与调参说明先用Suricata跑一条基础规则。下面这条规则的作用是在HTTP流量里抓取基于关键字“union select”的SQL注入特征。测试环境足够但要上生产建议配合参数解析。alert http any any - $HOME_NET any (msg:SQL Injection - UNION SELECT; flow:established,to_server; http.uri; content:union; nocase; within:50; content:select; nocase; distance:0; within:50; classtype:web-application-attack; sid:20250101; rev:1;)这条规则限定了http.uri只在URI里做匹配。within:50的含义是搜索窗口为50字节超过这个范围即使两个关键字都出现也不命中用来减少大字符串里的顺便命中。distance:0表示第二个关键字紧随第一个关键字的匹配位置开始。nocase让匹配大小写不敏感。用这条规则能抓到最常见的/index.php?id1 UNION SELECT这一类请求。但这条规则只能覆盖GET请求里的注入试探。POST请求的body不在http.uri范围里而真实攻击中大量的SQL注入都发生在POST参数中。因此生产环境建议同时启用ModSecurity和OWASP CRS这类参数级检测。以ModSecurity规则为例它对ARGS集合里的每个参数值做正则匹配SecRule ARGS rx (?i)(union.*select|select.*from.*information_schema|concat\s*\() \ id:942100,phase:2,deny,status:403,log,tag:attack-sqli这里的关键是ARGS——它是ModSecurity的解析集合会把POST body里的表单参数按拆分、按名称取出并解码。注意这个设计先做解析后做匹配原始流量即使URL编码过到了ARGS里已经变成解码后的明文规则只需要针对明文特征写。参数说明phase:2是请求体解析阶段这个阶段GET和POST都能被解析deny,status:403表示命中即拦截tag用于在告警日志里标记分类方便统计。直接从CRS整套启用会有一点水土不服的问题第5章展开讲。你只需要知道Suricata适合做全流量的粗筛ModSecurity类引擎做参数级的精细化两者不是替代关系。3.2 暴力破解检测脚本双维度统计与滑动窗口暴力破解检测我用一个Python脚本在登录日志上做滑动窗口统计。逻辑很简单但细节决定效果。#!/usr/bin/env python3 # 暴力破解检测按(源IP, 登录接口)聚合失败次数滑动窗口内超阈值告警 # 用法python3 brute_detect.py /var/log/nginx/access.log import re import sys import time from collections import defaultdict LOG_PATH sys.argv[1] if len(sys.argv) 1 else /var/log/nginx/access.log WINDOW_SECONDS 300 # 统计窗口5分钟 FAIL_THRESHOLD 10 # 窗口内失败次数的阈值需要按业务日志校准 fail_log defaultdict(list) auth_pattern re.compile( r^(?Pip\d\.\d\.\d\.\d).*?(?PmethodPOST) (?Ppath/login).*? (?Pstatus401|403) ) with open(LOG_PATH, r) as fh: for line in fh: match auth_pattern.search(line) if not match: continue now time.time() key (match.group(ip), match.group(path)) fail_log[key].append(now) # 只保留窗口内的时间戳让窗口时刻滑动 fail_log[key] [t for t in fail_log[key] if now - t WINDOW_SECONDS] if len(fail_log[key]) FAIL_THRESHOLD: print(f[ALERT] source{match.group(ip)} target{match.group(path)} ffails{len(fail_log[key])} window{WINDOW_SECONDS}s) del fail_log[key]核心逻辑从登录取日志按IP 登录路径做key把每次失败登录的时间戳加入列表。每次新记录到达时先剔除窗口外的旧时间戳再判断列表长度是否达到阈值。用滑动窗口的好处是在任意时刻都能反映最近5分钟的真实失败次数而不是固定整点窗口的失真统计。固定窗口的毛病是攻击者在窗口边界处分散请求可能每个窗口内都达不到阈值但在窗口交界处已经完成了大量尝试。参数校准要区分业务场景。在一个日登录量几千次的内网应用上5分钟内超过10次失败已经可疑但员工自助系统在密码重置高峰期5分钟内相同路径的请求达到几十次也很正常。我一般建议拿至少一周的生产登录日志做离线回放统计正常时段失败请求的分位值然后把FAIL_THRESHOLD调到p95以上再加一点缓冲。3.3 钓鱼URL检测域名相似度评分与Whois联动钓鱼URL检测有两个层面已经收录的恶意域名可以查信誉库新注册的可疑域名没有信誉记录只能靠行为特征。下面这段脚本用编辑距离识别与主域名高度相似的域名属于低成本但很实用的方法。#!/usr/bin/env python3 # 域名相似度检测与主域名编辑距离2的可疑域名进入告警 # 输入dns_query.log每行一个域名输出可疑域名列表 def levenshtein(a, b): if len(a) len(b): a, b b, a prev list(range(len(b) 1)) for i, ch_a in enumerate(a, 1): curr [i] [0] * len(b) for j, ch_b in enumerate(b, 1): cost 0 if ch_a ch_b else 1 curr[j] min(prev[j] 1, # 删除 curr[j-1] 1, # 插入 prev[j-1] cost # 替换 ) prev curr return prev[-1] PRIMARY_DOMAIN example.com MAX_DISTANCE 2 subdomain_suffix . PRIMARY_DOMAIN with open(dns_query.log, r) as fh: for raw in fh: domain raw.strip().lower() if domain PRIMARY_DOMAIN or domain.endswith(subdomain_suffix): continue # 排除主域名和合法子域名 if levenshtein(domain, PRIMARY_DOMAIN) MAX_DISTANCE: print(f[SUSPICIOUS] {domain})只计算编辑距离还不够。一个设计良好的钓鱼域名会模仿主域名但看起来合法比如examp1e.com把字母l换成数字1或者example-com.com加个横线。这些变体的编辑距离都在2以内能覆盖到大多数手工仿冒。但真正的防护必须结合注册信息。用whois查询域名的创建时间whois examp1e.com | grep -E Creation Date|Registered Date|Registrar注册时间离当前越近恶意概率越高。一个仿冒域名的注册时间往往不超过30天如果又命中相似度规则基本可以认定是钓鱼准备。反过来注册了3年的老域名即使长得像主域名也有很大概率是正常站点监控即可不用升级处置。提示钓鱼检测不能只看域名相似度还要看登录页的证书信息、页面表单提交的目标地址以及Referer来源。多信号关联后误报会明显下降。4. 从告警到处置日志关联、封禁与止损的实操步骤4.1 日志关联先拉出攻击时间线再动手拿到告警后最不该做的事就是直接封IP。封禁本身很容易但封完之后发现攻击者已经登录成功、数据已被拖走那就晚了。正确的第一步是把攻击源的时间线拉出来判断是否已经得手。# 提取某个IP在SSH日志中的失败与成功登录记录按时间排序 grep -E Failed|Accepted /var/log/auth.log | grep 192.0.2.10 | sort # 从Web访问日志提取该IP的请求路径和状态码还原访问序列 grep 192.0.2.10 /var/log/nginx/access.log | awk {print $4, $6, $7, $9} | head -100如果日志里出现了成功登录的记录说明攻击者已经突破认证层处置等级就要从封禁升级为主机隔离还要检查该主机上有没有新建账号或计划任务。如果只有失败记录风险相对可控封IP加收紧登录策略就够了。时间线拉出来后还需要判断攻击是否已经扩散。一种常见的做法是把该IP在过去24小时访问过的内网主机列表提取出来逐一排查是否有对应时间的成功认证记录。这个过程可以用SIEM里的关联查询完成如果没有SIEM就直接把各主机的auth日志打包后合并分析。4.2 封禁与止损边界设备上的快速拦截命令封禁命令本身的语法很简单复杂的是封禁位置和方向的选择。边界防火墙上的规则需要同时考虑入站和转发两个方向因为攻击源可能是从外网直接进来的也可能是通过中转主机转发访问的。# 边界防火墙封禁攻击源IP入站和转发方向同时处理 iptables -A INPUT -s 192.0.2.10 -j DROP iptables -A FORWARD -s 192.0.2.10 -j DROP # 用fail2ban做自动封禁时在jail.local里调整参数 # maxretry5是触发封禁的失败次数bantime600是封禁秒数findtime60是统计窗口 sudo systemctl restart fail2banmaxretry和findtime的比例需要根据登录并发度调整。内网运维机器的SSH登录频率会高于普通终端设置得太严格可能误封正常运维账号。我建议先在fail2ban的日志模式运行几天观察正常运维的失败次数分布再决定要不要切到主动拦截模式。封禁之后要验证规则是否真正生效。从另一台外部主机尝试访问目标端口确认连接超时。如果封禁的是Web攻击源还要继续观察Nginx访问日志中该IP是否还有新请求到达。有的话说明封禁层级不够高比如攻击者走的是CDN回源需要封的是源站的回源网段。4.3 取证与复盘日志保存和现场保留的注意事项处置完后最容易被跳过的是日志保存。生产环境的日志轮转会很快覆盖攻击前后的记录特别是Nginx访问日志高流量下可能半天就滚动一轮。我习惯在封禁后的第一时间做原始日志快照。# 保存攻击时间窗内的系统日志到独立证据目录 journalctl --since 2025-01-01 10:00:00 --until 2025-01-01 11:00:00 /evidence/20250101_ssh.log # 复制Web服务器原始访问和错误日志保留原始权限属性 cp -a /var/log/nginx/access.log /var/log/nginx/error.log /evidence/20250101/ chattr a /evidence/20250101/chattr a给证据文件加追加锁防止后续审计过程不小心修改内容。用cp -a保留原始属性和时间戳避免用vim直接打开另存这种操作破坏元数据。复盘时如果发现日志时间线有明显缺失先检查有没有轮转任务或清理脚本在中间作祟。取证阶段的另一个容易忽略的点是进程快照。如果主机上已经发现WebShell要第一时间记录当前运行的进程列表和网络连接状态而不是急着删除文件。先保存证据再清理顺序不能反。5. 避坑排查误报漏报与规则失效的5个真实原因5.1 现象合法爬虫被封禁业务方投诉原因频率统计没有排除已知爬虫的User-Agent或者只按请求总数判断。百度和Google爬虫的访问频率比普通用户高得多直接用阈值套会误伤。解决在统计前加一道UA白名单过滤把常见的搜索引擎爬虫放行。更可靠的做法是用会话维度判断正常用户访问会先初始化会话而爬虫请求往往没有会话维持。用“无Cookie请求的高频访问”作为特征比单纯比UA更抗伪造。5.2 现象SQL注入规则漏报率居高不下绕过流量抓不到原因规则只匹配URI不解析POST请求体而且没有做URL解码。攻击者把payload放进表单参数时URI完全看不到特征做了编码的payload未解码的原始流量完全不匹配。解决把检测覆盖面扩展到POST body在匹配前先做URL解码和Unicode规范化。%75nion在规范化后还原成union这一步做完最常见的一大类绕过就会失效。推荐用支持参数解析的引擎比如ModSecurity的ARGS集合避免自己在正则里去处理各种编码组合。5.3 现象封禁IP后攻击流量依旧到达原因封禁对象是CDN节点或负载均衡器IP源站真实IP被隐藏。另一个常见原因是IPv4和IPv6双栈环境下只封了其中一个协议栈的地址。解决封禁前先在WAF或反向代理日志里确认真正的回源IP必要时封整个回源网段。双栈环境必须同时生成IPv4和IPv6两条规则只封一半等于没封。规则落地后用外部测试连接的方式验证确认超时才算生效。5.4 现象检测规则上线后业务大面积报500原因规则误杀了正常业务参数。比如内部系统里合法的order by排序参数命中了SQLi特征或者商品描述里的HTML标签触发了XSS规则。拦截模式下WAF会把正常请求直接挡掉。解决先以检测模式运行至少一周收集所有命中规则的请求按业务域名分组分析。确认误报后在对应参数上做白名单或者缩小规则匹配范围。坚持先日志后拦截等误报率降到可接受比例再切拦截模式这个习惯能避开好几次生产事故。5.5 现象分布式暴力破解完全漏检单IP失败次数低于阈值原因统计模型只按源IP维度攻击者用节点池轮换IP每个IP只尝试几次。单IP的计数永远到不了阈值但全局的认证失败总数已经很大。解决增加账号维度的统计。记录每个账号在时间窗口内出现的来源IP数量比如一个账号在5分钟内出现了5个以上不同IP的登录请求即使密码错误次数不多也应该进入告警池。账号维度是横向移动和分布式暴力破解的共同特征我把它作为最高权重使用。6. 验证与固化用仿真流量和基线对比守住检测能力规则写完之后不能直接上线先用仿真流量验证一遍建立可对比的基线。我的做法是准备一台和业务接近的测试机用OWASP ZAP生成一批包含SQL注入、XSS、命令注入特征的请求同时录制一段正常业务流量。两股流量混合后回放观察检测系统的命中情况。# 用requests生成带攻击特征的测试请求发送到检测目标 import requests url http://test-target/index.php payloads [ 1 UNION SELECT username,password FROM users, scriptalert(1)/script, ;cat /etc/passwd #, ] for payload in payloads: r requests.post(url, data{param: payload}) print(r.status_code, len(r.content))回放完后统计三个数字攻击样本的命中率、正常流量的误报率、规则运行的时间开销。这三组数据作为当前版本基线记录到文档。之后每次修改检测规则都用同一份仿真流量回放对比基线的命中率有没有下降。如果某次修改后攻击样本命中率降了说明新规则引入了覆盖空洞需要回滚或补充。我实际工作中养成的习惯是每周做一次规则回归把所有历史攻击样本重新回放一遍。因为规则之间会互相影响为了压低某类误报调整匹配长度顺手就把另一类攻击的短特征给挡掉了。我自己就踩过一次——为了减少XSS误报加了一个内容长度限制结果把短payload的SQL注入规则给覆盖掉了回归测试第一时间暴露了问题。这套基线对比的思路帮助我把检测规则从看起来有效变成了可验证有效。如果你也在搭建检测体系建议从今天开始留一份攻击样本集和正常流量集每次改规则前回放一遍。希望这个流程能帮到你。本文还有配套的精品资源点击获取
