【信息安全原理】——期末复习（冲刺篇）

📖 前言：快考试了，做篇期末总结，都是重点与必考点。

题型：简答题（4×5分）、协议分析题（2×10分）（给一个报文或工作流程，分析存在的问题）、应用题4-5题（60分）（范围：Web应用、电子邮件PGP收发过程、DNS、SSL）

课本：
在这里插入图片描述

🕒 1. 网络层安全
- 🕘 1.1 IPsec安全策略
- - 🕤 1.1.1 安全关联（SA）
  - 🕤 1.1.2 安全策略（SP）
- 🕘 1.2 AH协议
- 🕘 1.3 ESP协议
- 🕘 1.4 IKE
- - 🕤 1.4.1 IPsec密钥管理
  - 🕤 1.4.2 密钥确定协议
  - 🕤 1.4.3 IKE消息格式
- 🕘 1.5 IPsec工作过程
- 🕘 1.6 SA组合
- 🕘 1.7 IPsec的应用
- 🕘 1.8 IPv6安全问题
🕒 2. 路由安全
🕒 3. 传输层安全
- 🕘 3.1 安全问题
- 🕘 3.2 SSL
- - 🕤 3.2.1 SSL记录协议
  - 🕤 3.2.2 SSL密码变更规格协议
  - 🕤 3.2.3 Alert协议
  - 🕤 3.2.4 握手协议☆
  - 🕤 3.2.5 密钥生成
  - 🕤 3.2.6 SSL的安全性分析
- 🕘 3.3 SSL/TLS VPN
🕒 4. DNS安全
- 🕘 4.1 DNS面临的安全威胁
- - 🕤 4.1.1 协议脆弱性
  - 🕤 4.1.2 实现脆弱性
  - 🕤 4.1.3 操作脆弱性
- 🕘 4.2 DNSSEC
🕒 5. Web应用安全
- 🕘 5.1 SQL注入☆
- 🕘 5.2 跨站脚本（XSS）攻击☆
- 🕘 5.3 HTTPS
🕒 6. 电子邮件安全
- 🕘 6.1 安全电子邮件标准PGP☆
- 🕘 6.2 WebMail
🕒 7. 拒绝服务攻击
- 🕘 7.1 定义
- 🕘 7.2 剧毒包型DoS
- 🕘 7.3 风暴型DoS
- - 🕤 7.3.1 直接风暴型DDoS
  - 🕤 7.3.2 反射风暴型DDoS
- 🕘 7.4 重定向型DoS
- 🕘 7.5 防御
- - 🕤 7.5.1 检测
  - 🕤 7.5.2 响应
🕒 8. 入侵检测
- 🕘 8.1 概述
- 🕘 8.2 特征检测
- 🕘 8.3 异常检测（误用检测）
🕒 9. 网络欺骗
- 🕘 9.1 概述
- 🕘 9.2 蜜罐

🕒 1. 网络层安全

在这里插入图片描述
安全性分析：

IPv4协议没有认证机制：
- 没有消息源认证：源地址假冒
- 没有完整性认证：篡改
IPv4没有加密机制：
- 无机密性：监听应用数据
- 泄露拓扑等信息：网络侦察
无带宽控制：
- DDoS攻击

IPsec（IP Security）

端到端的确保 IP 通信安全：认证、加密及密钥管理
最初为IPv6制定（必选），也支持IPv4（可选）

Q：上面的IP数据报有什么安全问题，如果有解决方案是什么？

IPsec 协议族 :

两种工作模式：
- 传输模式（Transport）
- 隧道模式（Tunnel）
两个通信保护协议：
- 鉴别首部协议（ AH , Authentication Header ）
- 封装有效载荷协议（ ESP , Encapsulation Security Payload ）
互联网密钥交换协议（ IKE , Internet Key Exchange ）：
- 阶段1（两种基本模式）
  - 主模式
  - 积极模式
- 阶段2（快速模式）
两个数据库：
- 安全策略数据库SPD （ Security Policy Database ）
- 安全关联数据库SAD （ Security Association Database ）
解释域DOI（Domain of Interpretation）

🕘 1.1 IPsec安全策略

IPsec操作的基础是应用于每一个从源端到目的端传输的IP包上的安全策略。

IPsec安全策略主要由两个交互的数据库（SAD和SPD）来确定

在这里插入图片描述

🕤 1.1.1 安全关联（SA）

一个SA：发送端和接收端之间的单向逻辑连接，为数据流提供安全服务；经过同一SA的数据流会得到相同的安全服务，如AH或ESP
SA对：双向安全数据交换
同时支持AH、ESP且双向：需两对SA

一个SA由以下参数确定：

安全参数索引（Security Parameters Index, SPI）：32位，接收方根据SPI选择合适的SA处理接收到的数据包
IP目的地址：仅允许单播地址
安全协议标识（Security Protocol Identifier）：AH / ESP

SAD定义了所有SA相关的参数，每个SA：

在这里插入图片描述

🕤 1.1.2 安全策略（SP）

指定对IP数据包提供何种保护，并以何种方式实施保护
主要根据源IP、目的IP、入数据还是出数据等来标识
用户设定自己的安全策略的粒度：IP地址，传输层协议，TCP/UDP端口号
操作：Discard（丢弃）、Bypass（通过）、Protect（保护）

SPD中的每一条SP包括：

本地IP
远程IP
下一层协议
名称
本地或远程端口

主机SPD示例：
$\begin{array}{|c|c|c|c|c|c|c|} \hline \text { 协议 } & \text { 本地 IP } & \text { 端口 } & \text { 远程 IP } & \text { 端口 } & \text { 动作 } & \text { 备注 } \\ \hline \text { UDP } & 1.2 .3 .102 & 500 & \text { * } & 500 & \text { Bypass } & \text { IKE } \\ \hline \text { ICMP } & 1.2 .3 .102 & \text { * } & \text { * } & \text { * } & \text { Bypass } & \text { 错误消息 } \\ \hline \text { * } & 1.2 .3 .102 & \text { * } & 1.2 .3 .0 / 24 & \text { * } & \text { Protect: ESP 传输模式 } & \text { 加密内部网流量 } \\ \hline \text { TCP } & 1.2 .3 .102 & \text { * } & 1.2 .4 .11 & 80 & \text { Protect: ESP 传输模式 } & \text { 加密到服务器的流量 } \\ \hline \text { TCP } & 1.2 .3 .102 & \text { * } & 1.2 .4 .11 & 443 & \text { Bypass } & \text { TLS: 避免双重加密 } \\ \hline \text { * } & 1.2 .3 .102 & \text { * } & 1.2 .4 .0 / 24 & \text { * } & \text { Discard } & \mathrm{DMZ} \text { 的其它流量 } \\ \hline \text { * } & 1.2 .3 .102 & \text { * } & - & \text { * } & \text { Bypass } & \text { Internet } \\ \hline \end{array}$

🕘 1.2 AH协议

AH协议功能：IP包的数据完整性、数据来源认证和抗重放攻击服务

AH首部：
在这里插入图片描述
AH运行模式：

在这里插入图片描述

完整性检验：
算法：在SA中指定

HMAC-MD5-96
HMAC-SHA-1-96

96表示鉴别数据默认字段长，由HMAC计算出完整校验值后再被截短，取前96位。

哪些字段参与计算？如何处理IPv4和IPv6首部中的三种字段：不变字段，可变但可预测字段，可变不可预测字段？

IP首部：只包括在传输期间不变的字段或接受方可预测的字段，其余不定的字段全置为0；
AH：除“鉴别数据”字段外其他的所有字段，“鉴别数据”字段被置为0；
IP数据包中的所有的上层协议数据。

抗重放攻击：序列号 + 滑动窗口机制

在这里插入图片描述

AH无法与NAT兼容，因为AH认证的是整个IP包，如果修改IP地址（NAT功能），则无法通过完整性检测。

🕘 1.3 ESP协议

ESP协议功能：除了提供IP包的数据完整性、数据来源认证和抗重放攻击服务，还提供数据包加密和数据流加密服务

ESP首部：
在这里插入图片描述

ESP传输模式：
在这里插入图片描述
ESP隧道模式：

ESP不对IP包首部（含选项字段）进行认证，因此不存在和NAT不兼容的问题。

ESP与AH对比：

安全性	AH	ESP
协议号	50	51
数据完整性检验	支持	支持（不验证IP头）
数据源认证	支持	支持
数据加解密	不支持	支持
抗重放服务	支持	支持
NAT-T（nat穿透）	不支持	支持

Q：IPsec体系结构文档中指出，当两个传输模式SA被绑定，在同一个端对端流中允许AH和ESP两种协议，但认为只有先施ESP协议再实施AH协议才合适，为什么？
A：主要是性能上的考虑，由于解密处理需要大量占用CPU和内存，在通过认证（完整性验证）后再进行解密处理会更好一些，如果认证没有通过就不需要执行耗时的解密操作了。

🕘 1.4 IKE

🕤 1.4.1 IPsec密钥管理

IPsec支持以下两种密钥管理方式：

手动
自动（automated）：系统通过IKE（Internet Key Exchange）协议自动为SA创建密钥。

🕤 1.4.2 密钥确定协议

Diffie-Hellman回顾：

缺点：
- 没有提供双方身份的任何信息，因此易受中间人攻击；
- 算法是计算密集型的，容易遭受阻塞性攻击；
- 易受重放攻击。

IKE对Diffie-Hellman的改进：

允许双方协商得到一个组（group），相录于Diffie-Hellman密钥交换的全局参数；
允许交换Diffie-Hellman的公钥值；
对Diffie-Hellman交换进行身份认证，以阻止中间人攻击
采用Cookie机制来防止拥塞攻击；
使用现时值来阻止重放攻击；

🕤 1.4.3 IKE消息格式

IKE协议定义了建立、协商、修改和删除安全关联的过程和报文格式。
IKE报文由首部和一个或多个载荷组成，并包含在传输协议（规范要求在实现时必须支持UDP协议）

在这里插入图片描述

🕘 1.5 IPsec工作过程

协商过程分成：

第一阶段：交换密码算法、验证身份，建立IKE SA，保护第二阶段通信
第二阶段：双方认证，建立IPsec SA（IKEv1有，IKEv2没有）

采用模式：

第一阶段：主模式（6条消息）/积极模式（3条消息）
第二阶段：快速模式（3条消息）

IKEv1交换过程：
在这里插入图片描述

①中安全提议有加密算法、认证算法、DH组、身份认证方法、存活时间。
③④交换DH参数和时变值。

简答题：简述IKEv1第一阶段中主模式和积极模式的区别
答：两种模式都有协商提议、密钥交换、身份认证的阶段。
主模式的第一阶段是协商密码，而积极模式第一阶段是协商提议、密钥交换、身份认证都包含。主模式需要6条消息，积极模式只需要3条消息。主模式在第三阶段（身份认证）是有加密保护的，而积极模式没有保护。

IKEv2交换过程：
在这里插入图片描述

🕘 1.6 SA组合

Q：为什么要组合SA？
A：单个SA只能实现AH协议或ESP协议，而不能同时实现这两者。但在实际应用中，一些流量需要同时调用由AH和ESP提供的服务，某些流量可能需要主机间的IPsec服务的同时还需要在安全网关（如防火墙）间得到IPsec提供的服务。在这些情况下，同一个流量可能需要多个SA才能获得想要的IPsec服务。

提供特定IPsec服务集而组合在一起的SA系列称为“安全关联束（Security Association Bundle）”

安全关联束中的SA可以在不同节点上终止，也可在同一个节点上终止
两种方式将多个SA组合成安全关联束：传输邻接（transport adjacency）与隧道迭代（Iterated Tunneling）

在这里插入图片描述

🕘 1.7 IPsec的应用

IPsec在IP层对所有流量进行加密和/或认证，因此能够保护各种基于IP的应用

终端用户通过互联网实现安全的远程访问
分支机构通过互联网构建一个安全的虚拟专用网络
与合作者建立企业间联网和企业内联网接入

将IPsec应用于上述场景的实质就是构建基于IPsec的虚拟专用网（Virtual Private Network, VPN）

🕘 1.8 IPv6安全问题

IPv4向IPv6过渡技术的安全风险
无状态地址自动配置的安全风险
IPv6中PKI管理系统的安全风险
IPv6编址机制的隐患

🕒 2. 路由安全

路由协议的脆弱性：

协议设计上的问题
协议实现上的问题
管理配置产生的安全问题

🕒 3. 传输层安全

🕘 3.1 安全问题

在这里插入图片描述

UDP协议可用于风暴型DDoS。

由于UDP协议不需要与目标建立连接，因此攻击者很容易通过伪造源地址的方式向目标发送攻击报文，进行DOS攻击。
攻击者利用控制的僵尸网络中的大量主机向攻击目标（主机或网络设备）发送大量的 UDP数据包，使其忙于处理和回应 UDP 报文，导致目标设备不能提供正常服务或者直接死机，严重的会造成全网瘫痪。

在这里插入图片描述

利用TCP协议三次握手的安全性分析：

端口扫描（TCP Connect扫描、TCP SYN扫描、TCP FIN扫描、Xmas扫描和Null扫描）
拒绝服务（DoS）攻击（TCP SYN Flooding）
TCP会话劫持攻击（第三方伪造身份）
- 只要TCP包中的源端口、目的端口、Seq、Ack正确，即可被正确接收。当得到入侵者构造的TCP数据包，协议会假设数据包是来源于TCP连接中另一方的合法数据包，并且发送响应包到（入侵者构造的数据包中设置的IP地址）。随后，原来的TCP连接会由于计数器不匹配而断开连接。
- 关键：猜测Seq、Ack，如果是旁路劫持还需猜测源端口号

🕘 3.2 SSL

SSL利用TCP协议为上层应用提供端到端的安全传输服务，包括认证和加密

在这里插入图片描述

SSL几个协议之间的关系是：

使用握手协议协商加密和MAC算法以及保密密钥，以及身份认证
使用密码变更规格协议变更连接上使用的密码机制
使用记录协议对交换的数据进行加密和签名
使用告警协议定义数据传输过程中出现的问题并通知相关方

SSL两个重要概念

连接（connection）：是指一种能够提供合适服务类型的传输通道。对SSL来说，这种连接是点对点、暂时的。每条连接都与一个会话关联
会话（session）：是指客户与服务器之间的一种关联，由握手协议创建，定义了一组多个连接共享的密码安全参数。定义会话的目的主要是避免为每次建立连接而进行复杂的密码参数协商过程

任何一对通信实体（如客户和服务器上的HTTP应用）之间可以有多条安全连接，理论上也允许一对实体之间同时有多个会话，实际上很少出现

每个会话有多种状态，一旦会话建立，就进入当前操作（发送和接收）状态。在握手协议执行期间，会进入读（接收）挂起状态和写（发送）挂起状态。握手完成，挂起状态又回到当前操作状态

SSL保障的安全属性：

机密性：SSL 客户机和服务器之间传送加密数据。
完整性：SSL 可避免服务器和客户机之间的信息被破坏。
认证性（不可否认性）：SSL 握手时要求交换证书，通过验证证书来保证对方身份的合法性。

🕤 3.2.1 SSL记录协议

记录协议在SSL握手协议完成客户端和服务器之间的握手过程后使用，即客户端和服务器完成双方的身份鉴别并确定安全信息交换使用的算法后执行。作用是负责将用户数据进行加密传输。

保密性：使用握手协议得到的传统加密共享密钥来加密SSL载荷来实现保密性
完整性：使用握手协议得到的MAC共享密钥对SSL载荷进行消息完整性检验

记录协议对应用数据的处理过程：
在这里插入图片描述
操作：

第一步，分段
- 上层消息的数据被分片成2¹⁴字节大小的块，或者更小
第二步，压缩（可选）
- 必须是无损压缩，如果数据增加的话，则增加部分的长度不超过1024字节
第三步，MAC计算
- hash(MAC_write_secrte||pad_1||seq_mum||SSLCompressed．type||SSLCompressed．length||SSLCompressed．fragment)
第四步，加密
- 将压缩消息和MAC用对称算法加密。加密增加的长度不超过1024字节。

说明：

如果是流密码算法，则不需要填充，MAC在加密之前计算，然后将MAC和明文或压缩后的明文一起被加密。
对分组加密而言，填充应在MAC之后、加密之前进行。填充的格式是一定长度的填充字节后跟1字节的填充长度。

🕤 3.2.2 SSL密码变更规格协议

协议由一个仅包含1字节且值为1的消息组成，使得连接从挂起状态改变到当前状态，用于更新此连接使用的密码组

🕤 3.2.3 Alert协议

当客户端和服务器发现错误时，需要通过告警协议向对方发送一个告警消息

同应用数据一样，SSL告警协议报文同样交由SSL记录协议进行压缩和加密处理后发送

🕤 3.2.4 握手协议☆

SSL握手协议是客户端和服务器用SSL连接通信时使用的第一个子协议，在开始传输上层应用数据之前使用。

该协议允许服务器和客户端相互验证，协商加密和MAC算法以及加密密钥，用来保护在SSL记录协议中发送的数据

在这里插入图片描述
客户端与服务器之间建立逻辑连接的初始交换过程包括四个阶段

第一阶段：建立安全功能

客户端将自己支持的算法列表（密钥组）、用于生成密钥的随机数和压缩方法列表一起发送给服务器
服务器从列表中选择加密算法，压缩方法发给客户端

client_hello

版本：客户端支持最高版本的SSL版本
随机数：32位时间戳+28字节随机数
会话标志：非0：更新参数/为当前会话创立新连接；0：为新会话创立新连接
密码组：按优先级降序排列的密码算法列表（含密钥交换方法和密码说明）
压缩方法：客户端支持的压缩方法列表

server_hello

版本：客户端支持的最高版本的SSL版本号和服务器端支持的最低版本的SSL版本号
随机数：32位时间戳+28字节随机数
会话标志：非0（客户端）：相同值；0（客户端）：新会话的值
密码组：从密码算法列表中选择出的密码组
压缩方法：从压缩方法列表选出的压缩方法

密钥交换方法：

RSA：用接收方RSA公钥加密的密钥，必须拥有接收者公钥的公钥证书
固定Diffie-Hellman：签证机构签发公钥证书，证书中包含D-H公钥参数
瞬时Diffie-Hellman：用发送者私钥签名D-H公钥交换过程
匿名Diffie-Hellman：使用D-H公钥不需要认证
Fortzza

第二阶段：服务器认证和密钥交换

服务器将自己公钥的证书发给客户端，密钥交换消息、证书请求，和服务器完成消息发送给客户端
在此阶段，如果使用了瞬时Diffie-Hellman、匿名Diffie-Hellman、 Fortzza、RSA密钥交换的密钥交换方法，则客户端已经能计算出主密钥。
证书和密钥交换消息
- 不需要证书：匿名Diffie-Hellman
- 需要密钥交换消息：瞬时Diffie-Hellman、匿名Diffie-Hellman、Fortzza、RSA密钥交换（仅使用签名）
- 不需要密钥交换消息：固定Diffie-Hellman

服务器完成消息：表明服务器的HELLO和相关消息结束了。

第三阶段：客户端认证和密钥交换

客户端验证服务器证书并检查有效，告知服务器自己的证书，无证书情况下，发送无证书警报
客户端发送密钥交换信息，提供对自己证书的验证消息
- RSA：生成预备主密钥，用服务器公钥证书中的密钥交换信息中的公钥加密
在此阶段，如果使用了瞬时Diffie-Hellman、匿名Diffie-Hellman、 Fortzza、RSA密钥交换的密钥交换方法，则服务器端已经能计算出主密钥

第四阶段：完成

客户端发送改变密码规范消息，新的完成消息finished。
服务器发送改变密码规范消息，新的完成消息finished。

此消息不是握手协议的一部分，而是使用修改密码规范协议发送的。

完成消息的作用：确认已经生成主密钥，验证前边所有握手消息完整性

至此，握手过程完成，客户端和服务器可以开始交换应用层数据了。

🕤 3.2.5 密钥生成

共享主密钥是利用安全密钥交换为此会话建立的一个一次性48字节的值，生成过程分两步：

第一步交换预备主密钥（握手协议的“阶段3”）
第二步双方计算主密钥。

两类密钥交换算法：RSA、Diffie-Hellman

计算主密钥：
在这里插入图片描述

客户和服务器使用相同的算法和参数计算出对称加密密钥（主密钥）和参数：

主密钥计算：
在这里插入图片描述
密钥分组计算：

生成密码参数：

需要主密钥生成密钥分组
4个用于数据保护的会话密钥：
- 服务器写加密密钥(Esc)、服务器写MAC密钥(Msc)：分别用于服务器发出数据的加密和消息验证码计算。
- 客户端写加密密钥(Ecs)、客户端写MAC密钥(Mcs)：分别用于客户端发出数据的加密和消息验证码计算。

计算过程步骤如下:

由预主密钥、客户端随机数和服务器端随机数共同生成主密钥。
由主密钥、客户端随机数和服务器端随机数共
同生成密钥分组。
把密钥分组分成6块，按照所需的密钥长度依次
截取得到Mcs、Msc、Ecs、Esc、lVcs(客户端初始向量)、和IVsc（服务器初始向量）。

🕤 3.2.6 SSL的安全性分析

SSL协议的安全性隐患：
1）预主密钥→master_secret→SSL会话密钥
2）能否保证随机数质量也是SSL的安全隐患。
3）有可能遭受中间人攻击。
4）利用SSL的攻击无法被IDS检测和FW过滤到。
5）Web服务器使用SSL时，吞吐量会显著下降。
6）不能保证Web浏览器和服务器自身安全。

增强SSL安全性：

增强master_secret的保密性
- 预主密钥的口令加密方法和硬件加密方法。
提高随机数的质量
- 用硬件随机数发生器产生的随机数作为产生随机数的软件方法PRNG的种子，进行高强度处理。
提高证书CA的可靠性
- 在服务器认证阶段，CA控制所有证书的颁发和有效性判断。

🕘 3.3 SSL/TLS VPN

IPsec VPN也有一些不足之处：

无法实现基于用户的授权
可能泄露内部网络结构

利用基于SSL/TLS的VPN可以很好解决远程终端访问内部网络时存在的上述问题(SSL/TLS VPN简称为SSL VPN)

应用场景：Web代理、端口映射、IP连接

🕒 4. DNS安全

🕘 4.1 DNS面临的安全威胁

除了域名解析外，现代DNS还具有：

应用层路由：DNS把用户的访问指向离用户最近的那个CDN服务器节点，负载均衡；Email服务器利用DNS服务器中的MX记录作为路由，找到企业内部真正的服务器
DNS作为信任的基础：防伪造邮件、域名作为验证证书申请者身份的信任基础
DNS作为PKI：防止CA在未经网站所有者授权的前提下签发非法的证书

在这里插入图片描述

🕤 4.1.1 协议脆弱性

域名欺骗：域名系统（包括 DNS 服务器和解析器）接收或使用来自未授权主机的不正确信息，包含事务 ID 欺骗和缓存投毒。

劫持例子：
在这里插入图片描述
黑客抢在根域名服务器之前答复递归DNS服务器，并且把它引导到了一个黑客搭建的权威DNS服务器上。

之后，递归DNS服务器会把黑客搭建的DNS服务器误认为是顶级DNS服务器大娃，并且记在小本本里。

于是，黑客接替了大娃的工作。当然，黑客也可以冒充其他权威DNS服务器，总之，葫芦娃中出了个叛徒。

DNS缓存：
在这里插入图片描述
网络通信攻击：针对 DNS 的网络通信攻击主要是DDoS攻击、恶意网址重定向和中间人(man-in-the-middle, MITM)攻击

劫持解析路径，并伪装成指定的DNS应答：
在这里插入图片描述

🕤 4.1.2 实现脆弱性

DNS 软件，BIND 的漏洞和缺陷无疑会给 DNS 系统带来严重的威胁，其缓冲区溢出漏洞一度占据 UNIX 及 Linux 操作系统相关安全隐患的首位。

🕤 4.1.3 操作脆弱性

由于人为操作或配置错误所带来的安全隐患：域名配置攻击、域名注册攻击和信息泄漏等

攻击目标网站域名注册服务提供商→修改目标网站域名记录→申请网站证书→伪装成目标网站

🕘 4.2 DNSSEC

DNSSEC可以防止针对DNS系统的缓存投毒，以得到广泛支持的RFC4033-4035版本为例简要介绍DNSSEC的基本内容

提供数据来源验证：DNS数据来自正确的域名服务器；
提供数据完整性验证：数据在传输过程中没有任何更改；
提供否定存在验证：对否定应答报文提供验证信息

DNSSEC中新增的四种类型的资源记录：DNSKEY (DNS Public Key)、RRSIG（Resource Record Signature）、DS (Delegation Signer)、NSEC (Next Secure)

DNSKEY：存储服务器的公开密钥
RRSIG：存储对资源记录集合（RR Sets）的数字签名
NSEC：为了应答那些不存在的资源记录而设计
DS ：记录存储DNSKEY的散列值，用于验证DNSKEY的真实性，从而建立一个信任链

DNSSEC新增的4种资源记录，这些记录的长度远远超过了最初的DNS协议标准规定的512字节，而要求DNS报文大小必须达到1220字节，甚至是4096字节。因此DNS服务器如果要支持DNSSEC，则首先需要支持扩展DNS机制（EDNS）

DNS保密性保护：DoT（DNS over TLS）和DoH（DNS over HTTPS)

🕒 5. Web应用安全

在这里插入图片描述
Web应用体系结构潜在弱点：

Web客户端
- 活动内容执行，客户端软件漏洞的利用，交互站点脚本的错误
传输
- 偷听客户-服务器通信，SSL重定向
Web服务器
- Web服务器软件漏洞；
Web应用程序
- 攻击授权、认证、站点结构、输入验证，以及应用程序逻辑
数据库
- 通过数据库查询运行优先权命令，查询操纵返回额外的数据集。

Web应用程序功能与安全隐患的对应关系
在这里插入图片描述

HTTP协议安全问题：

HTTP协议是一种简单的、无状态的应用层协议

无状态使攻击变得容易
基于ASCII码，无需弄清复杂的二进制编码机制，攻击者就可了解协议中的明文信息
互联网中存在的大量中间盒子，HTTP标准的理解如果不一致，就有可能导致一些新的攻击发生

Cookie的安全问题：

为什么需要Cookie？

解决无状态问题：保存客户服务器之间的一些状态信息
Cookie是指网站为了辨别用户身份、进行会话跟踪而储存在用户本地终端上的一些数据（通常经过编码）。

Cookie中包含了一些敏感信息，如用户名、计算机名、使用的浏览器和曾经访问的网站等，攻击者可以利用它来进行窃密和欺骗攻击

🕘 5.1 SQL注入☆

定义：利用Web应用程序对特殊字符串过滤不完全的缺陷，通过把精心构造的SQL命令插入Web表单递交或输入域名或页面请求的查询字符串中，欺骗服务器执行恶意的SQL命令，最终达到非法访问网站数据库内容、篡改数据库的数据，绕过认证、浏览或者编辑文件等目的。

例子：

通过用户提供的参数来查询表中的数据
"SELECT * FROM USERS WHERE SSN=‘" + ssn + "’“

SSN参数来自于用户的输入：

参数未经验证或编码
黑客输入： 1234’ OR ‘1’=‘1

应用程序构造查询语句：

SELECT * FROM USERS WHERE SSN=‘1234’ OR ‘1’=‘1’ （永真逻辑）（此处是字符串型）
结果返回数据库中的每一个用户

整型参数时的SQL注入漏洞探测
通过输入：1 and 1=1和1 and 1=2判断是否进行正常回显，如果前者正常，后者不正常，说明是整型

字符串型参数时的SQL注入漏洞探测
通过输入：1’ and ‘1’=‘1 和1’ and ‘1’=‘2 判断是否进行正常回显，如果前者正常，后者不正常，说明是字符串型

SQLMAP是SQL注入的自动化探测工具

防御注入漏洞：

使用特定语言的库函数来代替shell命令和系统调用；
对用户输入的信息进行严格检查和过滤：
- 数据类型（字符串、整数等）正确吗？
- 使用的是允许的字符集吗？
- 输入满足格式要求吗？
- ……
使用“最小权限”限制数据库用户的权限

🕘 5.2 跨站脚本（XSS）攻击☆

不当的服务器端输入检查，从而允许用户输入可被客户端浏览器解释的脚本命令。攻击者通过运行脚本进而实现用户session劫持等。

XSS是最普遍的Web程序安全问题。

对网页进行跨站脚本攻击探测：使用<script>alert</script>观察是否有弹窗。（可以选择的方案，也可以有其他方案）

反射式XSS：

也称为非持久性跨站脚本攻击，是一种最常见的跨站脚本攻击类型。
与本地脚本漏洞不同的是Web客户端使用Server端脚本生成页面为用户提供数据时，如果未经验证的用户数据被包含在页面中而未经HTML实体编码，客户端代码便能够注入到动态页面中。
在这种攻击模式下，Web程序不会存储恶意脚本，它会将未经验证的数据通过请求发送给客户端，攻击者就可以构造恶意的URL链接或表单并诱骗用户访问，最终达到利用受害者身份执行恶意代码的目的。

储存式XSS：

储存式跨站脚本攻击，也称为持久性跨站脚本攻击。如果Web程序允许存储用户数据，并且存储的输入数据没有经过正确的过滤，就有可能发生这类攻击。
在这种攻击模式下，攻击者并不需要利用一个恶意链接，只要用户访问了储存式跨站脚本网页，那么恶意数据就将显示为网站的一部分并以受害者身份执行。

DOM式XSS：

DOM式XSS 攻击并不是按照“数据是否保存在服务端”划分的，它是反射式XSS 的一种特例，只是由于DOM式XSS的形成原因比较特殊，因此把它单独作为一个分类。
DOM式XSS 攻击是通过修改页面DOM节点数据信息而形成的。

防御XSS：

对Web应用程序的所有输入进行过滤，对危险的HTML字符进行编码：
- ‘<’ , ‘>’ → ‘<’ , ‘>’
- ‘(‘ , ‘)’ → ‘(’ , ‘)’
- ‘#‘ , ‘&’ → ‘#’ , ‘&‘
对用户，谨防不明链接；
防止访问已知的恶意网站；
执行手工或自动化代码扫描，确定并消除潜在的XSS漏洞。

🕘 5.3 HTTPS

服务器端的HTTPS部署情况：
在这里插入图片描述

HSTS (HTTP Strict Transport Security)

IETF提出的一种新的Web安全协议，其目的是强制客户端（如Web浏览器）使用HTTPS与服务器进行通信。使用HSTS协议的网站将保证浏览器始终使用HTTPS连接到服务器，不需要用户在浏览器的地址栏中手工输入HTTPS。当客户端通过HTTPS向服务器发出请求时，服务器在返回的超文本传输协议响应头中包含Strict-Transport-Security字段。

🕒 6. 电子邮件安全

在这里插入图片描述
基于SMTP、POP3/IMAP等协议的电子邮件系统没有采取必要的安全防护措施，导致：

邮件内容被窃听
垃圾邮件（Spam）
邮件炸弹
传播恶意代码（钓鱼邮件）
电子邮件欺骗

安全措施：

端到端的安全电子邮件技术，保证邮件从发出到接收的整个过程中，内容保密、无法修改且不可否认
传输安全增强技术，在网络层或传输层使用安全协议（IPsec, SSL/TLS）来保证应用层的电子邮件在安全的传输通道上进行传输
邮件服务器安全增强，采用安全防护设备（防火墙、入侵检测系统）保护邮件服务器；增加邮件服务器攻击检测和防护能力。
邮件发送方身份验证
- 发件人策略框架SPF
- DKIM协议
- DMARC协议

🕘 6.1 安全电子邮件标准PGP☆

PGP既是一个特定的安全电子邮件应用软件，也是一个安全电子邮件标准。

PGP最常用于安全电子邮件传输，但它也可以用于任何需要保证传输机密性、完整性和认证（不可否认性）的应用中。

在这里插入图片描述

☆ Q：签名、加密、压缩的顺序问题？
A：在PGP中，是对未压缩的邮件正文进行散列计算后，再对散列值进行签名。然后将邮件正文和签名拼接后进行压缩后加密。

在压缩之前进行签名的主要原因有两点：一是对没压缩的消息进行签名，可便于对签名的验证，如果在压缩后再签名，则需要保存压缩后的消息或在验证时重新压缩消息，增加了处理的工作量；二是由于压缩算法ZIP在不同的实现中会在运算速度和压缩率之间寻求平衡，因而可能会产生不同的压缩结果（当然，直接解压结果是相同的），因此压缩后再进行签名就可能导致无法实现鉴别（接收方在验证签名时可能会因压缩的原因而出现验证失败）。

PGP 对加密前的明文（含签名）进行压缩，而不是在加密后再压缩的主要原因也有两点：一方面因为先压缩再加密方案缩短了报文大小，从而减少了网络传输时间和存储空间；另一方面经过压缩实际上是经过了一次变换，变换后减少了明文中上下文的关系，比原始消息的冗余信息更少，再加密的安全性更高，而如果先加密，再压缩，效果会差一些。

概括上述：PGP发送邮件先进行签名，再进行压缩，最后进行加密。先进行签名的目的是为了后边验证的准确性。压缩后进行加密是为了减少数据体量，提高加密效率。

在这里插入图片描述

公开密码算法密钥管理：

PGP采用密钥标识符（密钥ID，Key ID）来表示密钥，并建立密钥标识和对应公钥/私钥间的映射关系
私钥存储方法：加密私钥的口令短语（passphrase）p，加密后存储在私钥环中

PGP信任模型：以用户为中心的信任模型（信任网模型，Web of Trust）

没有一个统一的认证中心来管理用户公钥，每个人都可以作为一个CA对某个用户的公钥签名，以此来说明这个公钥是否有效（可信）
当用户接收到新的公钥时，首先要检查公钥证书的签名者，然后根据这个签名者的信任程度计算出该公钥的合法性，如果合法才能把它插入到自己的公钥环中
公钥环中每一个公钥项都有表示信任度的字段，包括：
- 密钥合法性字段：合法和不合法
- 签名可信性字段：不信任、部分信任、一直信任和绝对信任
- 拥有者可信性字段：不信任、部分信任、一直信任和绝对信任，由用户自己指定。

由拥有者可信性决定签名可信性，由公钥上的多个签名的可信性一起决定密钥合法性。有一个绝对信任的签名，则密钥合法。至少有x个一直信任的签名，则密钥合法。至少有y个部分信任的签名则密钥合法。x和y值由用户决定。

多选题：用户A对用户B和C的公钥拥有者可信性字段打的都是部分信任，D是完全信任，系统要求，两个部分信任或者一个完全信任的签名才能让公钥合法，当前A收到了G的公钥，上边的签名来自于B，Z的公钥签名来自D，以下说法正确的是( )
A. B对G公钥的签名信任性字段为部分信任
B. D对Z公钥的签名信任性字段为部分信任
C. Z的公钥合法
D. G的公钥不合法
答案：ACD

Q：当用户A往公钥环中插入一个新的公钥时，PGP必须为该公钥的拥有者可信性字段设定一个标志，指示公钥拥有者的信任程度。如果用户A插入的新公钥不是自己的公钥，应该由谁制定该公钥拥有者的可信任性字段?
A：用户A

🕘 6.2 WebMail

安全问题：

WebMail暴力破解
- 防范：禁用账户、禁止IP地址、登录检验
恶意HTML邮件
- 利用HTML邮件，攻击者能进行电子邮件欺骗，甚至欺骗用户更改自己的邮箱密码
- 在HTML邮件中嵌入恶性脚本程序，攻击者还能进行很多破坏攻击，如修改注册表、非法操作文件、格式化硬盘、耗尽系统资源、修改“开始”菜单等，甚至能删除和发送用户的邮件、访问用户的地址簿、修改邮箱帐户密码等
Cookie会话攻击
- 攻击者获取用户WebMail的Cookie信息后，就能很容易地侵入用户的WebMail。攻击者获取用户WebMail的Cookie信息的方法主要有内网监听和XSS攻击
- 含有恶性脚本程序的HTML邮件能使攻击者获取WebMail的Cookie信息
- WebMail系统应该避免使用持久型Cookie会话跟踪，使攻击者在Cookie会话攻击上不能轻易得逞

🕒 7. 拒绝服务攻击

🕘 7.1 定义

定义：攻击者通过某种手段，有意地造成计算机或网络不能正常运转从而不能向合法用户提供所需服务或者使服务质量降低

服务(Service)：系统提供的，用户在对其使用中会受益的功能
拒绝服务(DoS: Denial of Service)：任何对服务的干涉如果使得其可用性降低或者失去可用性称为拒绝服务，如: 计算机系统崩溃；带宽耗尽；硬盘被填满
攻击方式：消耗系统或网络资源；阻断访问路径；更改系统配置

DDoS（Distributed Denial of Service）：如果处于不同位置的多个攻击者同时向一个或多个目标发起拒绝服务攻击，或者一个或多个攻击者控制了位于不同位置的多台机器并利用这些机器对受害者同时实施拒绝服务攻击。

特点: 攻击来源的分散性、协同性，攻击力度的汇聚性

DDoS为什么能成功？

TCP/IP协议存在漏洞，可以被攻击者利用
网络提供Best-Effort服务，不区分数据流量是否是攻击流量
网络带宽和系统资源是有限的

按攻击机制来分

剧毒包型：利用协议木身或其软件实现中的漏洞
风暴型：通过大量的“无用”数据包占用过多的资源
重定向型：通过修改网络中的一些参数或ARP表等，使得数据包被重定向到了其它地方

🕘 7.2 剧毒包型DoS

剧毒包或杀手包（Killer Packet) DoS攻击：利用协议本身或其软件实现中的漏洞，通过一些畸形的数据包使受害者系统崩溃，也称为“漏洞攻击”或“协议攻击”。

WinNuke攻击
泪滴(Teardrop)攻击
Land攻击
Ping of death 攻击
循环攻击

🕘 7.3 风暴型DoS

风暴型DoS攻击：通过大量的“无用”数据包占用过多的资源以达到拒绝服务的目的，也称为“带宽攻击”

直接风暴型攻击
反射攻击（DRDoS）

🕤 7.3.1 直接风暴型DDoS

定义：攻击者直接控制僵尸网络对受害者主机或服务器进行攻击。

攻击原理：
在这里插入图片描述

PING风暴攻击(直接型)
SYN风暴攻击(直接型)
TCP连接耗尽攻击(直接型)
UDP风暴攻击(直接型)
HTTP风暴攻击(直接型)
HTTP/2 PING Flood
对邮件系统的DoS攻击(直接型)

🕤 7.3.2 反射风暴型DDoS

定义：攻击者直接控制僵尸网络利用反射服务器，伪造原IP，使得反射服务器向受害者主机或服务器响应大量数据包。

攻击原理：
在这里插入图片描述

用作反射型DDoS的协议一般具有的特点

互联网上有很多可探测到的支持该协议的服务器
部分协议的请求报文大小远小于响应报文的大小
协议具有无连接特性

用于反射型DDoS的协议：NTP、SSDP、DNS等

NTP：利用monlist进行攻击，请求与 NTP 服务器进行过时间同步的最后 600 个客户端的 IP
SSDP：用于在局部网里发现通用即插即用（UPnP)网络设备，使用discover报文进行攻击

🕘 7.4 重定向型DoS

通过修改网络中的一些参数或ARP表、DNS缓存，使得受害者发出的或者发向受害者的数据包被重定向到了其它地方。

常被用于窃听或中间人攻击。因此，通常在网络窃听中研究，很多人不把它当作DoS攻击。

🕘 7.5 防御

🕤 7.5.1 检测

依据DDoS攻击工具的特征标志检测
- 特定端口。例如，著名的DDoS工具trinoo使用的端口分别为：TCP端口27655, UDP端口27444和31335；NTP DRDoS检测123端口。
- 标志位。例如，Shaft攻击所用的TCP分组的序列号都是0x28374839。
- 特定数据内容。
统计检测
主机网络连接特征检测
根据异常流量来检测：
- 当DDoS攻击一个站点时，会出现明显超出该网络正常工作时的极限通信流量的现象。
- 特大型的ICMP和UDP数据包。
- 不属于正常连接通信的TCP和UDP数据包。
- 数据段内容只包含文字和数字字符（例如，没有空格、标点和控制字符）的数据包。
- 反向解析目标IP主机名的PTR查询请求。