加盐

加盐：在进行哈希计算之前，系统会为这个用户的密码生成一个随机的、独一无二的字符串（这就是“盐”，Salt）。然后，系统将这个“盐”附加到原始密码后面（或者前面，或者混合）。
哈希与存储：接着，系统对“密码 + 盐”这个组合体进行哈希计算。最后，将计算得到的哈希值和这个随机生成的盐两者都存储在数据库中，与该用户关联。
“没加盐时候，一轮字典就能搞定所有密码条目”

问题场景（无盐）：如果不加盐，那么所有使用相同密码（比如 “123456”）的用户，在数据库里存储的哈希值都是完全一样的。
攻击方式：攻击者如果拿到了数据库，他可以预先计算好常用密码（字典）的哈希值（比如计算 hash(“123456”)），或者使用预先计算好的“彩虹表”（一种用空间换时间，存储了大量密码及其对应哈希值的数据结构）。
效率：攻击者只需要用他计算出的 hash(“123456”) 在数据库里搜索一遍，就能找出所有使用 “123456” 作为密码的用户。对于字典里的每一个词，他只需计算一次哈希，就能匹配数据库里的所有相同密码的用户。这就是所谓的“一轮字典（的一个词）就能搞定（潜在的）所有（使用该密码的）密码条目”。
“加盐后，一轮字典只能搞定一个密码条目”

加盐后的效果：由于每个用户的盐都是随机且不同的，即使两个用户使用了相同的密码 “123456”，他们的组合体（”123456” + 盐A，”123456” + 盐B）也不同，因此计算出的哈希值也不同，存储在数据库里的记录也不同。
攻击难度：攻击者现在不能只计算一次 hash(“123456”) 来匹配所有人了。对于数据库中的每一条用户记录，攻击者必须：
获取该用户的盐（因为盐是和哈希一起存储的）。
将字典中的猜测密码（比如 “123456”）与该用户的特定盐组合。
计算组合后的哈希值。
与数据库中该用户的哈希值进行比较。
效率降低：这意味着，攻击者对字典中每一个词的尝试，其计算结果只能用来验证一个用户，而不能像以前一样验证所有使用相同密码的用户。破解整个数据库所需的时间大大增加。

安全访问控制模型

o DAC discretionary access control 自动访问控制
o MAC mandatory access control 强制访问控制
Bell-LaPadula 模型确保保密性No Read Up：主体只能读同级或低级的对象No Write Down：主体只能写高层或同层的对象
o RBAC role-based access control 基于角色的访问控制
包含五个基本数据客体
用户users
角色roles
客体objects
操作operations
许可permissions
o核心概念
角色一组用户的每个角色都与相关操作相关，用户所属角色有权执行这些操作
角色和组的区别
组——一系列用户
角色——一群用户+一群操作许可
关系多对多，用户被赋予特定的角色，角色被赋予特定的许可
会话sessions 匹配用户和激活的角色

RBAC提供许多类似于自我管理策略的访问控制。但是，管理权限的授权是RBAC的一个重要特性，DAC和MAC中不存在

SYN Flood 的原理来了！

🧨 攻击流程：
攻击者持续向服务器发出 SYN 请求包

每个 SYN 请求都使用伪造的源 IP 地址

让服务器无法回到真正的客户端

服务器收到后，按照协议：

回 SYN + ACK

并在内存中为每个连接创建“半连接状态”（称为 SYN 队列）

等待对方的 ACK —— 但它永远收不到

🚨 服务器是如何防御的？

方法	说明
SYN Cookie	不创建连接记录，而是把信息藏在 SYN+ACK 中，等对方回应才真正建连接
限制半连接数	限制某个 IP 同时创建多少未完成连接
防火墙丢弃异常 SYN	比如 SYN=1、ACK≠0 的包
反向验证源 IP	如果是内网 IP 或明显伪造的地址可丢弃
接入层限速或黑洞策略	在交换机/路由器层直接丢包