简介：这份文档面向计算机网络初学者与信息安全入门者，系统梳理常见网络攻击类型及其防范思路，帮助读者建立对网络安全威胁的整体认知。内容围绕拒绝服务型攻击、弱口令攻击等典型攻击方式展开，分析其原理与危害，并探讨相应的主动防护措施，适合作为课程学习、安全知识普及或复习备考的参考材料。资源包内含1个docx文档，压缩包整体约10KB，体积轻巧便于下载与本地阅读，文档结构清晰，围绕攻击分类与防范技术逐层展开，便于快速定位重点。目前已有115人学习浏览，说明其在网络安全入门领域具有一定参考价值。读者可从中了解常见攻击的识别方法与防护要点，为后续深入学习网络安全技术打下基础。
1. 从一份 2012 年的文档说起：网络攻击类型与防范的底层逻辑
翻到一份 2012 年发表的《计算机网络中常见安全攻击与防范技术》文档，页码标注是 TP393.08，文献编号 1007-9599（2012）23-0000-02。乍一看年份很久，但把里面的攻击分类和防范思路拉出来对照今天的网络环境，会发现底层逻辑几乎没变——拒绝服务、弱口令、木马病毒这几类攻击至今仍是最高频的安全事件来源。这份文档的价值不在于它有多新，而在于它用极短的篇幅把攻击类型、攻击原理和对应防范措施串成了一条线，适合刚接触网络安全的人建立第一层认知框架，也适合运维和开发在排查线上问题时快速定位攻击类别。它解决的核心问题是：面对一台被攻击的服务器或一套异常的网络服务，你该从哪里判断攻击类型、用什么手段做第一轮防护。如果你正在准备计算机网络期末复习、做安全实验报告，或者需要一份能直接引用的攻击分类素材，这份文档能省掉大量翻教材的时间。
2. 拒绝服务型攻击：从 TCP/IP 漏洞到流量清洗的实操路径
2.1 DoS 攻击的原理与识别方法
拒绝服务型攻击（DoS，Denial of Service）的核心逻辑并不复杂：攻击者利用 TCP/IP 协议栈中的某个漏洞，或者目标系统本身的资源瓶颈，持续发送大量分组，让服务器无法正常提供服务。文档里写得很直白——目的是拒绝服务访问、破坏组织的正常运行、最终使系统的部分 Internet 连接和网络系统失效。
常见做法是攻击者先通过 SYN Flood 消耗服务器的半连接队列。TCP 三次握手中，客户端发送 SYN 后服务器回复 SYN-ACK 并分配资源等待最终 ACK，如果攻击者只发 SYN 不回 ACK，服务器的半连接队列就会被占满，正常用户连不进来。另一种是 UDP Flood，利用 UDP 无连接的特性直接灌大量数据包，占满带宽。还有 ICMP Flood，用 ping 请求把出口带宽打满。
识别 DoS 攻击的几个信号：服务器 CPU 和内存不一定高，但网络连接数异常飙升；netstat看到大量 SYN_RECV 状态的连接；正常用户反馈连接超时但服务器本身没挂；带宽监控显示入站流量突然拉满。这几个信号同时出现两三个，基本可以判定是 DoS 或 DDoS。
2.2 基于 iptables 和内核参数的防护配置
防护 DoS 的第一层思路是在操作系统层面做限制。Linux 下最直接的手段是调整内核参数加 iptables 规则。下面是一套我常用的基础配置：
# 开启 SYN Cookie 防护，半连接队列满时用 cookie 机制应对 sysctl -w net.ipv4.tcp_syncookies=1 # 减少 SYN-ACK 重试次数，加快半连接释放 sysctl -w net.ipv4.tcp_synack_retries=2 # 增大半连接队列上限 sysctl -w net.ipv4.tcp_max_syn_backlog=4096 # 限制单个 IP 每秒新建连接数，超出则丢弃 iptables -A INPUT -p tcp --syn -m limit --limit 10/s --limit-burst 20 -j ACCEPT iptables -A INPUT -p tcp --syn -j DROP # 限制单个 IP 的并发连接数，防止单点占满 iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j REJECT # 防御 ICMP Flood iptables -A INPUT -p icmp -m limit --limit 1/s -j ACCEPT iptables -A INPUT -p icmp -j DROP逻辑说明：tcp_syncookies=1是核心，它让服务器在半连接队列满时不丢弃新 SYN，而是用加密 cookie 代替资源分配，等客户端回 ACK 时再验证。tcp_synack_retries=2减少重试等待时间，加速队列释放。iptables 的--limit 10/s表示每秒最多放行 10 个新建连接，--limit-burst 20是突发容忍量，超过的直接 DROP。connlimit-above 50限制单 IP 对 80 端口的并发连接不超过 50 个。
参数调整的边界：tcp_max_syn_backlog不是越大越好，设太大反而消耗内存，4096 对中小型服务够用。--limit的阈值要根据业务实际 QPS 来定，设太低会误杀正常用户。如果服务器前面有负载均衡或 CDN，iptables 规则要放在后端机器上，同时确认负载均衡层是否已经做了清洗。
2.3 流量清洗与 CDN 层面的缓解思路
单机 iptables 只能扛小规模攻击，遇到大流量 DDoS 必须靠上游清洗。常见做法是把域名解析切到带 DDoS 防护的 CDN 或高防 IP，让攻击流量在边缘节点被识别和丢弃，只有正常流量回源到服务器。这个切换过程需要注意 TTL 设置——如果 DNS TTL 设了 3600 秒，切换后要等一小时才全网生效，攻击期间这个延迟很致命。我一般会把关键域名的 TTL 提前调到 60 秒，出问题时能快速切走。
高防 IP 的回源配置里有一个坑：源站 IP 如果暴露过，攻击者可能绕过高防直接打源站。所以源站防火墙要只放行高防回源 IP 段的流量，其他全部拒绝。这个规则用 iptables 写就是：
# 只允许高防回源 IP 段访问，其余全部拒绝 iptables -A INPUT -p tcp --dport 443 -s 高防回源IP段 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j DROP把「高防回源IP段」替换成服务商提供的实际网段。这条规则加上之后，即使攻击者拿到源站 IP，直接打过来也会被丢弃。
3. 弱口令攻击与木马病毒：从口令策略到主机加固的落地清单
3.1 弱口令攻击的常见入口与检测手段
文档里提到「Internet 上的很多入侵是由于接受了弱口令」，这句话放到今天依然成立。弱口令攻击的入口主要有几个：SSH 远程登录、数据库服务（MySQL、Redis、MongoDB）、Web 后台管理面板、以及各种中间件的默认账户。攻击者用字典跑一遍常见用户名密码组合，命中就直接登录。
检测自己系统是否存在弱口令，可以用 hydra 做内部自查（仅限自己拥有的资产）：
# 对内部测试机的 SSH 做弱口令自查，-l 指定用户名，-P 指定字典 hydra -l root -P /usr/share/wordlists/rockyou.txt -t 4 ssh://192.168.1.100 # 对 MySQL 做自查 hydra -l root -P /usr/share/wordlists/rockyou.txt -t 4 mysql://192.168.1.100逻辑说明：-l指定单个用户名，-P指定密码字典文件，-t 4表示并发 4 个线程避免把目标打挂。这个命令只应该对自己有权限的机器跑，对外部资产使用属于违规操作。
检测到弱口令后的修复优先级：先改密码，再限制登录来源，最后上密钥认证。SSH 的加固配置改/etc/ssh/sshd_config：
# 禁止 root 直接登录 PermitRootLogin no # 禁用密码认证，只允许密钥登录 PasswordAuthentication no # 限制登录用户白名单 AllowUsers deploy admin # 修改默认端口（降低被扫描概率，但不是安全边界） Port 22022改完systemctl restart sshd生效。注意：改端口和禁密码之前，先确认自己的密钥已经配好并且能登录，否则会把自己锁在外面。这个翻车场景我见过不止一次。
3.2 木马与病毒的攻击链路拆解
文档把木马和病毒列为网络安全的主要威胁来源，这个判断在 2012 年成立，在今天依然成立，只是传播方式变了。早期的木马主要靠邮件附件和恶意下载传播，现在更多是通过供应链投毒、钓鱼链接、以及未修补的漏洞批量植入。
木马攻击的典型链路分四步：投递（通过钓鱼邮件或漏洞利用把木马放到目标机器上）、执行（木马运行并建立回连通道）、持久化（写注册表或 crontab 保证重启后还能运行）、横向移动（以内网跳板身份扫描其他机器）。防范的关键节点在投递和执行两步——邮件网关拦截恶意附件、终端 EDR 阻止可疑进程执行、漏洞及时修补。
主机层面的排查命令：
# 查看异常定时任务，木马常在这里做持久化 crontab -l cat /etc/crontab ls -la /etc/cron.d/ # 查看异常网络连接，重点关注 ESTABLISHED 状态的外连 netstat -antp | grep ESTABLISHED # 查看异常进程，关注 CPU 或内存占用高但名字陌生的进程 top -c ps aux --sort=-%cpu | head -20 # 检查常见木马藏身目录 ls -la /tmp /dev/shm /var/tmp逻辑说明：crontab -l看当前用户的定时任务，/etc/cron.d/下的文件也要逐个检查。netstat -antp里的-p显示进程 PID，方便定位是哪个程序在对外连接。/tmp、/dev/shm、/var/tmp是木马最喜欢放的目录，因为这些目录通常可写且不容易被注意。
3.3 主机加固的检查清单
把文档里的防范思路落成可执行的加固清单，按优先级排列：
| 加固项 | 操作 | 验证方式 |
|---|---|---|
| 口令强度 | 最小 12 位，含大小写数字符号 | chage -l username看策略 |
| SSH 加固 | 禁 root 登录、禁密码认证 | sshd -T | grep permitrootlogin |
| 防火墙 | 只放行必要端口 | iptables -L -n检查规则 |
| 补丁管理 | 内核和关键组件及时更新 | uname -r对比最新版本 |
| 日志审计 | 开启 auth.log 和 syslog | tail -f /var/log/auth.log |
| 文件完整性 | 对关键目录做 hash 基线 | aide --check或tripwire |
这张表里的每一项都可以独立执行，不需要全部做完才生效。我的习惯是先做 SSH 加固和防火墙，这两项挡住大部分自动化扫描；再做口令策略和补丁管理，挡住针对性攻击；最后上日志审计和文件完整性，用于事后追溯。
4. 避坑与排查：安全防护中容易翻车的五个场景
4.1 改了 SSH 端口却忘了更新防火墙
现象：改完sshd_config的 Port 字段，重启 SSH 服务后自己连不上了。原因：防火墙只放行了 22 端口，新端口没加规则，流量被 DROP。解决：改端口之前先在 iptables 里放行新端口，确认能连上之后再关掉 22 端口。顺序反了就是把自己关在门外。
4.2 iptables 规则顺序导致防护失效
现象：加了限制连接数的规则，但攻击流量还是能进来。原因：iptables 是从上往下匹配的，如果前面有一条ACCEPT all的规则，后面的限制规则永远不会命中。解决：用iptables -L -n --line-numbers查看规则顺序，把限制规则插到放行规则之前，或者把默认策略设为 DROP 再逐条放行。
4.3 内核参数改了但没持久化
现象：用sysctl -w改了tcp_syncookies，重启服务器后防护失效。原因：sysctl -w只改运行时参数，重启就丢。解决：把参数写进/etc/sysctl.conf或/etc/sysctl.d/下的配置文件，然后sysctl -p加载。这个坑很隐蔽，因为改完当时是生效的，只有重启后才暴露。
4.4 弱口令自查把生产库跑挂了
现象：用 hydra 对生产 MySQL 跑字典，并发没控制好，数据库连接数被打满，业务中断。原因：hydra 的-t参数默认并发不低，生产环境扛不住。解决：自查只在测试环境做，或者把-t降到 1 到 2，并且在业务低峰期跑。更稳妥的做法是用专门的审计工具而不是暴力破解工具。
4.5 只防外网没防内网横向移动
现象：外网防护做得很严，但一台机器被钓鱼之后，攻击者在内网畅通无阻。原因：内网默认信任，没有做微隔离，一台失陷等于全部失陷。解决：内网也做访问控制，关键服务之间只放行必要端口，数据库不允许从办公网直接访问。常见做法是用 VLAN 划分加 ACL 规则，或者在主机层面用 iptables 限制来源 IP。
5. 从文档到实战：把攻击分类映射到监控告警的具体技巧
文档里把攻击分成拒绝服务、弱口令、木马病毒几类，这个分类本身没问题，但落到实际运维中，你需要的是「看到什么信号就判断是哪类攻击」的映射能力。我自己的习惯是在监控系统里配几条核心告警规则，每条对应一种攻击类型。
第一条：SYN_RECV 连接数超过阈值。这条对应 DoS 攻击的早期阶段。在 Zabbix 或 Prometheus 里采集netstat -ant | grep SYN_RECV | wc -l的值，超过 500 就告警。正常业务服务器这个值通常是个位数。
第二条：单 IP 短时间内大量失败登录。这条对应弱口令攻击。从/var/log/auth.log里提取Failed password记录，按来源 IP 聚合，5 分钟内超过 20 次就告警。这个规则能抓住大部分 SSH 暴力破解。
第三条：新增对外 ESTABLISHED 连接且进程名陌生。这条对应木马回连。用ss -antp定期采集，对比基线，发现新出现的对外连接且进程不在白名单里就告警。
第四条：关键文件 hash 变化。这条对应木马持久化。用 aide 或自己写脚本对/etc/passwd、/etc/crontab、/root/.ssh/authorized_keys做 hash 基线，变化就告警。
这四条规则不需要复杂的 SIEM 系统，用 cron 加脚本就能跑起来。下面是一个最小化的实现：
#!/bin/bash # 检查 SYN_RECV 连接数 syn_recv=$(netstat -ant | grep SYN_RECV | wc -l) if [ "$syn_recv" -gt 500 ]; then echo "ALERT: SYN_RECV count is $syn_recv, possible DoS attack" | mail -s "Security Alert" admin@example.com fi # 检查 SSH 失败登录 failed=$(grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -5) echo "$failed" | while read count ip; do if [ "$count" -gt 20 ]; then echo "ALERT: $ip has $count failed SSH logins" | mail -s "SSH Brute Force Alert" admin@example.com fi done # 检查关键文件 hash md5sum /etc/passwd /etc/crontab /root/.ssh/authorized_keys > /tmp/security_baseline.txt # 下次运行时对比 /tmp/security_baseline.txt 的差异逻辑说明：第一段用netstat统计 SYN_RECV 状态连接数，超过 500 发邮件告警。第二段从 auth.log 提取失败登录的来源 IP，按次数排序，超过 20 次的发告警。第三段做文件 hash 基线，下次运行时用md5sum -c对比。这个脚本放在 cron 里每 5 分钟跑一次，覆盖了文档里提到的三类主要攻击。
参数调整的边界：SYN_RECV 阈值 500 适合中小型服务器，如果业务本身并发就高，要往上调。SSH 失败登录阈值 20 次/5 分钟，如果公司有大量开发人员频繁登录跳板机，可能要放宽到 50 次。文件 hash 基线要排除正常变更——比如运维改了 crontab 加了个备份任务，hash 就会变，这时候需要人工确认而不是直接当攻击处理。
从那以后我每次配完安全规则，都会先在自己的测试机上跑一遍完整流程：改配置、重启服务、验证功能、检查日志、确认告警能触发。这套流程走完再上生产，能挡掉大部分「改完就连不上」的翻车场景。希望帮到你。
本文还有配套的精品资源，点击获取
