计算机网络：自顶向下方法 - Day 14 | 网络安全 | bc's club

📖 Day 14 / 15 · 《计算机网络：自顶向下方法》阅读笔记

每天 30 分钟，15 天读懂计算机网络。今天我们进入全书最「刺激」的一章——网络安全。前面 13 天我们学了网络怎么工作，今天来看看网络怎么被攻击、又怎么防御。加密、数字签名、SSL/TLS、防火墙、IDS/IPS，一次性安排上。你每天 SSH 登录服务器、frp 穿透内网、给网站配 HTTPS 证书，背后全是这些原理。

一、网络安全到底在防什么？#

在开始之前，我们先搞清楚一件事：网络安全不是一个单独的协议，而是一整套思维方式和工具组合。

想象你住在一个小区里：

有人可能偷听你和邻居的对话（窃听）
有人可能冒充快递员骗你开门（身份伪造）
有人可能否认自己签收过快递（抵赖）
有人可能往你家门缝里塞一堆垃圾直到你崩溃（DoS 攻击）

网络安全要解决的就是这四个问题：机密性（保密）、身份认证、数据完整性、访问控制。

🎯 一句话总结

网络安全 = 让正确的人拿到正确的数据，同时把坏人挡在门外。

二、加密基础：对称加密 vs 公钥加密#

2.1 为什么要加密？#

你在微信里给朋友发了一句”今晚吃火锅”，如果完全不加密，这句话在网络上一路裸奔——经过的每一个路由器、每一个 WiFi 接入点，理论上都能看到原文。

这就像你把明信片丢进邮筒，邮递员、分拣员、投递员……一路上看得到内容。你乐意吗？

加密就是把明信片变成只有收件人能看懂的乱码。

2.2 对称加密（Symmetric Key Cryptography）#

核心思想：加密和解密用同一把钥匙。

1	明文 --[密钥K加密]--> 密文 --[密钥K解密]--> 明文

🔑 生活类比

你和室友共用一个保险箱，两个人手里有一样的钥匙。你放进去的东西，他用同一把钥匙就能打开。

常见的对称加密算法：

算法	密钥长度	特点
DES	56 bit	元老级，已被暴力破解，别用了
3DES	168 bit	DES 的三重套娃，过渡方案
AES	128/192/256 bit	当之无愧的王者，全世界都在用
ChaCha20	256 bit	移动端友好，速度飞快

对称加密的优点是速度快，适合加密大量数据。缺点呢？钥匙分发是个大问题——你怎么安全地把同一把钥匙交给对方？

🧩 对称加密的密钥分发难题

你想给网友发加密消息，但你俩还没见过面。你用微信发密钥？万一微信被监听呢？你打电话？万一电话被窃听呢？这就是为什么我们需要公钥加密。

实战映射：你用的 frp 里 auth.token = "your-secret-token" 本质上就是一种对称密钥——frp 客户端和服务端用同一个 token 来验证身份。如果这个 token 泄露了，任何人都能连上你的 frp 服务端，这就解释了为什么 frp 文档反复强调要设置一个复杂的 token。

2.3 公钥加密（Public Key Cryptography）#

核心思想：每人有两把钥匙——一把公钥（全世界公开）和一把私钥（打死不给）。

公钥加密 → 只有私钥能解密（用于保密通信）
私钥加密 → 公钥能验证（用于数字签名，后面讲）

1	明文 --[接收方的公钥加密]--> 密文 --[接收方的私钥解密]--> 明文

🔑 生活类比

想象你有一个特殊的信箱和一把特殊的钥匙。信箱的地址（公钥）是公开的，任何人都能往里面塞信。但只有你手里的钥匙（私钥）能打开信箱取信。别人塞进去的信，连他自己都拿不出来了。

最常见的公钥加密算法：RSA（Rivest-Shamir-Adleman，三位大佬的姓氏首字母），基于大数分解的数学难题。还有 ECC（椭圆曲线密码学），用更短的密钥达到同样的安全级别。

公钥加密的优点是解决了密钥分发问题——公钥可以随便公开。缺点是计算速度慢（比对称加密慢 100~1000 倍）。

2.4 混合加密：现实中的完美方案#

既然对称加密快但密钥分发难，公钥加密能安全分发密钥但速度慢，那为什么不结合起来呢？

实际使用中（包括 HTTPS/TLS）的流程：

先用公钥加密协商出一个对称密钥（这个过程叫”密钥交换”）
后续大量数据全用这把对称密钥加密

🍔 生活类比

这就像你和朋友先通过复杂的验证程序换取一个保险箱钥匙（公钥加密），之后你们就用这把钥匙快速存取东西（对称加密），不用每次都走一遍繁琐的验证。

实战映射：你每次 SSH 连接服务器时，实际上客户端和服务器也在协商对称密钥。你看到的那些 fingerprint 提示：

1 2	The authenticity of host 'bc970321.cn (xxx.xxx.xxx.xxx)' can't be established. ED25519 key fingerprint is SHA256:xxxxx.

这就是服务器的公钥指纹。你第一次确认后，它就被保存在 ~/.ssh/known_hosts 里，以后每次连接都会验证——如果指纹变了，SSH 就会警告你”可能有人在中间人攻击！”

三、数字签名：你怎么证明你是你？#

3.1 为什么需要数字签名？#

假设你收到一封邮件，发件人写着”建设银行”，让你点击链接验证密码。你怎么知道这真的是建行发的，而不是钓鱼邮件？

我们需要一种机制来验证：这个消息确实来自声称的发送者，且中途没被篡改。

3.2 数字签名的原理#

还记得前面说的”私钥加密，公钥能验证”吗？这就是数字签名的核心。

签名过程：

对原始消息做散列（Hash），得到一个固定长度的摘要
用发送者的私钥加密这个摘要 → 这就是”数字签名”
把原始消息 + 数字签名一起发出去

验证过程：

接收方用同样的 Hash 函数对收到的消息计算摘要
用发送者的公钥解密数字签名，得到原始摘要
两个摘要一比——一样就是真的，不一样就是被篡改过

🔑 生活类比

就像古代的虎符。皇帝手里一半，将军手里一半，对上了才能调兵。数字签名就是”数学虎符”——你的私钥签出来的，只有你的公钥能验证。

⚠️ 注意

数字签名 ≠ 加密。签名是为了认证和防篡改，不是为了保密。你可以同时做签名 + 加密来兼顾两者。

3.3 散列函数（Hash Function）#

散列函数是数字签名的关键组件：把任意长度的输入变成固定长度的”指纹”。

好的散列函数必须满足：

单向性：从 Hash 值反推原文几乎不可能
抗碰撞：找到两个不同输入产生相同 Hash 值，几乎不可能
雪崩效应：输入改一个 bit，输出面目全非

常见算法：MD5（已不安全，别用！）、SHA-1（也不安全了）、SHA-256（目前推荐）、SHA-3（新一代标准）。

实战映射：你下载系统镜像的时候经常看到 SHA-256 校验值。比如下载 Ubuntu ISO，官方会给你一串 hash。你下载完本地算一遍 hash，两个一对比就知道文件有没有在传输中被篡改。这也是为什么 pip、npm 包管理器都会校验 hash。

3.4 公钥证书（PKI）#

这里有个鸡生蛋的问题：你说”这是我的公钥”，但别人怎么确认这真的是你的公钥，而不是中间人冒充的？

答案是证书颁发机构（CA, Certificate Authority）。

CA 的工作流程：

你生成一对公私钥
把公钥和你的身份信息提交给 CA
CA 核实你的身份后，用自己的私钥对你的公钥签名 → 生成数字证书
别人验证证书时，用 CA 的公钥验签，就能确认”这个公钥确实属于这个人”

🔑 生活类比

就像你办身份证。你说”我叫张三”没人信，但派出所（CA）给你发了一张带公章的身份证，别人看到公章就信了。而派出所的公章防伪技术，就是”CA 的公钥”（浏览器和操作系统内置了可信 CA 的公钥列表）。

实战映射：这就是你未来给 bc970321.cn 配 HTTPS 证书要做的事。Let’s Encrypt 就是一个免费的 CA 机构，它会验证你确实控制着 bc970321.cn 这个域名，然后给你颁发证书。浏览器信任 Let’s Encrypt 的签名，所以也就信任你的网站。

四、认证：证明”你是你”#

4.1 认证 vs 加密#

加密解决的是”别人看不到内容”的问题。认证解决的是”你是谁”的问题。这两个是正交的——你可以加密但不认证（比如匿名信），也可以认证但不加密（比如签字的明文信）。

4.2 认证方式#

三种经典认证因素：

你知道什么（Knowledge）：密码、PIN 码
你拥有什么（Possession）：手机验证码、U 盾、硬件密钥
你是什么什么（Inherence）：指纹、人脸、虹膜

两种因素组合就是”双因素认证（2FA）”，三种都有就是”多因素认证（MFA）”。

🔑 生活类比

去银行取钱：你知道密码（Knowledge）+ 你有银行卡（Possession）= 双因素认证。

4.3 挑战-响应认证（Challenge-Response）#

在网络安全中，最常用的认证协议模式是挑战-响应：

A 想认证 B 的身份
A 发一个随机数（挑战/challenge）给 B
B 用自己的私钥（或共享密钥）对随机数做运算，返回结果（响应/response）
A 验证结果——正确就认证通过

为什么用随机数？防止重放攻击。如果每次挑战都是一样的，攻击者录下上次的响应就能冒充。

实战映射：你 SSH 密钥登录服务器就是这个流程！

1. 客户端 → 服务器：我要连接（建立 TCP）
2. 服务器 → 客户端：这里是服务器公钥 + 一个随机挑战
3. 客户端 → 服务器：用我的私钥签了这个挑战（数字签名）
4. 服务器 → 客户端：验证通过，你的公钥我认识（在 authorized_keys 里）
5. 后续通信用协商的对称密钥加密

所以你在服务器上 ~/.ssh/authorized_keys 里添加的公钥，就是告诉服务器”信任这个公钥对应的人”。而 ~/.ssh/id_ed25519 是你的私钥，绝对不能泄露。

五、SSL/TLS：互联网安全的基石#

5.1 SSL/TLS 是什么？#

SSL（Secure Sockets Layer） 是 Netscape 在 1990 年代提出的，后来演变成 TLS（Transport Layer Security）。现在 SSL 已经废弃（最后版本 SSL 3.0，2015 年正式杀死），但大家习惯还是叫”SSL”。

TLS 是介于应用层和传输层之间的安全协议。HTTP over TLS = HTTPS。

┌─────────────────────┐
│    应用层 (HTTP)     │
├─────────────────────┤
│    TLS 安全层        │  ← 加密、认证、完整性
├─────────────────────┤
│    传输层 (TCP)      │
├─────────────────────┤
│    网络层 (IP)       │
└─────────────────────┘

5.2 TLS 握手流程（简化版）#

TLS 连接建立的过程就像一场精心编排的舞蹈：

Phase 1: Hello

Client → Server: ClientHello
  "我支持这些加密套件，这是我生成的随机数"
Server → Client: ServerHello
  "我们用这个加密套件，这是我生成的随机数"
  + 服务器证书（含公钥）

Phase 2: 密钥交换

1 2	Client → Server: 用服务器公钥加密一个 pre-master secret 双方各自用三个随机数算出相同的对称会话密钥

Phase 3: 切换到加密通信

1	双方: "好了，后面都加密了"

🔑 生活类比

就像你去银行开户：

你说”我想开户”（ClientHello）

柜员出示工作证（服务器证书）说”好的，我们用这种方式沟通”

你出示身份证验证身份（密钥交换）

双方确认后，后续所有对话都在保密的VIP室里进行（加密通信）

5.3 TLS 提供的三重保障#

机密性：所有数据对称加密，第三方看不到内容
认证：通过证书验证服务器身份，防中间人攻击
完整性：每个 TLS 记录都带 MAC（消息认证码），防篡改

5.4 HTTPS 证书的实战部署预演#

未来给 bc970321.cn 配 HTTPS，大致流程：

# 1. 安装 certbot（Let's Encrypt 的客户端）
sudo apt install certbot python3-certbot-nginx

# 2. 自动获取并部署证书
sudo certbot --nginx -d bc970321.cn -d www.bc970321.cn

# 3. certbot 会自动：
#    - 验证你确实控制着这个域名
#    - 获取证书和私钥
#    - 配置 Nginx 的 TLS
#    - 设置自动续期（证书有效期 90 天）

证书里包含什么？

你的域名（bc970321.cn）
你的公钥
CA（Let’s Encrypt）的数字签名
有效期

浏览器访问时会做完整的 TLS 握手，验证证书有效性（是否过期、是否被吊销、CA 是否可信），然后才展示那个绿色的小锁🔒。

六、防火墙：网络的大门卫#

6.1 防火墙是什么？#

防火墙是一种访问控制设备，放在网络的边界上，决定哪些流量能进、哪些流量必须挡住。

🔑 生活类比

就像小区门口的保安。保安有一张”允许进入的名单”：

业主（内部流量）→ 放行

快递（特定外部流量）→ 检查后放行

不明身份的人 → 拒绝

6.2 防火墙的分类#

传统防火墙分为三类：

无状态分组过滤器（ Stateless Packet Filter）#

逐个包检查，基于规则表决定放行还是丢弃。典型规则：

源IP | 目的IP | 源端口 | 目的端口 | 协议 | 动作
任何  | 内部    | 任何    | 80      | TCP  | 允许
任何  | 内部    | 任何    | 443     | TCP  | 允许
内部  | 任何    | 任何    | 23      | TCP  | 拒绝

通常在路由器上实现（ACL 访问控制列表）。

优点：速度快。缺点：不关心连接状态，容易被精心构造的包绕过。

有状态分组过滤器（Stateful Packet Filter）#

跟踪所有活跃的 TCP/UDP 连接状态，只允许属于已建立连接的包通过。

1	"你之前和我握手了吗？握了就放行，没握就滚蛋。"

🔑 生活类比

无状态防火墙 = 每个人进小区都要查证件
有状态防火墙 = 认识的业主进来一次就记住车牌号，下次直接放行

应用层网关（Application Gateway / Proxy）#

工作在应用层，理解协议内容。比如 HTTP 代理可以检查请求的 URL、过滤恶意内容。

🔑 生活类比

前两种是门口保安看身份证，应用层网关是安检机器——不仅要看你是谁，还要翻你包里装了什么。

6.3 防火墙的局限性#

防火墙不是万能的：

不能防范内部攻击（内鬼）
不能防范绕过防火墙的连接（比如你偷偷拨号上网）
难以处理加密流量（看不到内容）
零日攻击（规则还没更新就被打了）

七、IDS / IPS：网络的报警器和保镖#

7.1 IDS vs IPS#

IDS（Intrusion Detection System）入侵检测系统：只检测并报警，不主动阻断。像监控摄像头。
IPS（Intrusion Prevention System）入侵防御系统：不仅检测，还能主动阻断。像保安直接把可疑人员按倒。

7.2 检测方法#

基于签名的检测（Signature-based）#

维护一个已知攻击的”特征库”，网络流量中匹配到特征就报警。

🔑 生活类比

就像安检时用通缉犯照片比对。照片库里有的人一眼就能认出来。但如果是不认识的通缉犯（新型攻击），就认不出来了。

优点：准确率高，误报少。缺点：只能检测已知攻击，对新型攻击无能为力（零日漏洞）。

基于异常的检测（Anomaly-based）#

先建立”正常”行为的基线模型，一旦偏离基线就报警。

🔑 生活类比

就像你妈发现你突然晚上 11 点还在打游戏而不是写作业——虽然她不知道你在打什么游戏，但她知道”这不对劲”。

优点：能发现未知攻击。缺点：误报率较高（你怎么知道这不是正常的业务高峰？）。

7.3 部署位置#

1
2
3

互联网 ──→ [防火墙] ──→ [IPS] ──→ 内部网络
                              │
                         [IDS] （旁路监听）

IDS 通常旁路部署（镜像流量），不影响网络性能。IPS 串联部署，实时处理每个包。

7.4 常见 IDS/IPS 工具#

Snort：开源 IDS/IPS 的老前辈，基于规则的流量分析
Suricata：Snort 的现代化替代品，支持多线程
Zeek（原名 Bro）：强大的网络分析框架，不只是检测，还能做全流量分析

八、实战串联：你的系统安全分析#

把今天学的知识串起来，看看你的实际系统里都用了哪些安全技术：

SSH 密钥认证#

你的电脑                    服务器 (bc970321.cn)
   │                           │
   ├── TCP 连接 ──────────────→│
   │                           │
   │←── 服务器公钥 + 挑战 ──────┤  (认证服务器身份)
   │                           │
   ├── 用私钥签名挑战 ────────→│  (认证你的身份)
   │                           │
   │   双方协商对称密钥          │
   │                           │
   ├── 加密通信开始 ══════════→│  (机密性 + 完整性)

你用到的安全技术：

✅ 公钥加密：SSH 密钥对（ed25519/rsa）
✅ 挑战-响应认证：服务器发随机数，你用私钥签
✅ 对称加密：后续通信用 AES/ChaCha20 加密
✅ 散列函数：MAC 消息认证码保证数据完整性
✅ 数字证书：known_hosts 文件就是简化版的 CA

frp 的 auth.token#

frpc (客户端)                frps (服务端)
   │                           │
   ├── 携带 auth.token ───────→│
   │                           │
   │←── 验证 token 是否匹配 ───┤
   │                           │
   │   建立隧道                │

你用到的安全技术：

✅ 对称密钥认证：客户端和服务端共享同一个 token
⚠️ 潜在风险：如果 token 太简单（比如 “123456”），暴力破解就轻松了
💡 建议：用 openssl rand -hex 32 生成一个 64 字符的随机 token

未来给 bc970321.cn 配 HTTPS#

浏览器                     bc970321.cn (Nginx)
   │                           │
   ├── ClientHello ───────────→│
   │←── ServerHello + 证书 ────┤  (Let's Encrypt 签发的证书)
   │                           │
   │   验证证书（CA 链）         │
   │   ✓ 域名匹配               │
   │   ✓ 在有效期内             │
   │   ✓ CA 可信               │
   │                           │
   ├── 密钥交换 ──────────────→│
   │   协商出对称会话密钥         │
   │                           │
   ├── HTTPS 加密通信 ════════→│

你用到的安全技术：

✅ PKI / 数字证书：CA 签发的证书
✅ TLS 握手：完整的安全通道建立
✅ 混合加密：公钥交换密钥 + 对称加密数据
✅ 散列 + MAC：保证传输完整性

九、常见安全误区与避坑指南#

误区 1：”用了 HTTPS 就 100% 安全了”#

HTTPS 只保证传输过程的安全——中间人看不到内容。但如果你的服务器本身有漏洞（比如 SQL 注入），或者用户电脑中了木马，HTTPS 管不了。

🍔 就像快递全程冷链运输很安全，但如果你家门锁坏了，快递放进家门照样被偷。

误区 2：”密码设得很复杂就安全了”#

复杂密码防的是暴力破解，但如果你在钓鱼网站输入了密码，再复杂的密码也会泄露。密码复杂度 ≠ 安全，还需要：

不在不安全的地方输入密码
不同网站用不同密码
开启双因素认证

误区 3：”内网就是安全的”#

很多公司觉得”我们在内网里，外面进不来”。但实际上：

内部威胁（内鬼）往往比外部攻击更危险
一旦有一台内网机器被攻破，横向移动就变得容易
frp 这类内网穿透工具如果不加认证，等于给攻击者开了后门

误区 4：”MD5 可以用来加密密码”#

MD5 是散列函数，不是加密算法。而且 MD5 早已不安全，碰撞攻击已经被实际演示过了。密码存储应该用 bcrypt / scrypt / Argon2 这类专门的密码哈希函数。

十、关键知识点回顾#

概念	核心思想	记忆口诀
对称加密	加解密同一把钥匙	一把钥匙两把锁
公钥加密	公钥加密、私钥解密	信箱公开、钥匙私有
数字签名	私钥签名、公钥验签	数学虎符
散列函数	单向压缩、防碰撞	数字指纹
PKI/CA	可信第三方签发证书	网络身份证
TLS/SSL	应用层和传输层之间的安全协议	HTTPS 的安全底座
防火墙	网络边界访问控制	大门卫
IDS	检测并报警	监控摄像头
IPS	检测并阻断	直接按倒的保安

最重要的三张图记在脑子里：

TLS 握手流程（ClientHello → 证书 → 密钥交换 → 加密通信）
数字签名流程（Hash → 私钥加密 → 公钥验签）
混合加密思路（公钥换密钥，对称加数据）

Day 15 预告：全书知识脉络梳理 + 常见面试题#

🎉 恭喜你坚持到了 Day 14！明天是最后一天，我们将：

梳理全书知识脉络：从应用层到物理层，用一张图把 14 天的内容串起来
常见面试题精选：TCP 三次握手、四次挥手、HTTP/HTTPS 区别、对称加密 vs 非对称加密……面试常考的都在这
计算机网络思维导图：帮你建立全局视角

💬 最后留一个思考题：

你登录 GitHub 时，GitHub 怎么知道你就是你？整个过程用到了今天学的哪些安全技术？提示：HTTPS + SSH Key（或 OAuth Token）+ 可能的 2FA。

带着这个问题，我们 Day 15 见！

📖 本系列文章基于《计算机网络：自顶向下方法》（第 8 版），Kurose & Ross 著。本文是 Day 14 / 15 的阅读笔记。