模块6：网络安全、加密及安全通信实战

面向 Linux 云计算工程师的网络安全与密码学实战笔记。所有命令输出均来自真实运行：
概念类脚本在本地 bash 5.3.9 / OpenSSL 3.5.6 / python3 实跑；主机侧证据由 paramiko 实连
你提供的 4 台华为云 ECS（Ubuntu 24.04）+ atomcode 部署机（Ubuntu 22.04）以 root 只读巡检 + /tmp 下非破坏性加密实战 得到。
全程未修改任何生产主机的防火墙、sshd 配置或业务文件。

0. 实验环境与开篇说明

主机 角色 公网 IP 私网 IP 系统 规格
ecs-146b-0001 Web/DNS 113.44.140.3 192.168.0.90 Ubuntu 24.04 8vCPU/16G
ecs-146b-0002 Web(apache2) 123.60.217.187 192.168.0.230 Ubuntu 24.04 8vCPU/16G
ecs-146b-0003 NFS/rpcbind 114.116.226.73 192.168.0.229 Ubuntu 24.04 8vCPU/16G
ecs-146b-0004 基础 120.46.91.123 192.168.0.248 Ubuntu 24.04 8vCPU/16G
atomcode 部署机 117.72.182.3 172.16.0.3 Ubuntu 22.04 —

安全约定：巡检命令全部只读（ufw/iptables/nft/ss/sshd -T/last/lastb/配置 cat）；
加密实战在 /tmp 下生成临时密钥/证书/密文，不触碰任何业务文件与系统配置、不重启服务。

1. 本篇使用的提示词（Prompt）与工具

提示词（即本次任务指令，节选）：

参考教学目标：掌握网络安全、加密及安全通信。
关键技能：对称/非对称加密、哈希、PKI 与数字证书、SSH 安全通信、
防火墙(ufw/iptables)、TLS/HTTPS、主机安全基线、VPN/隧道。
提供 4 台 ECS + atomcode 部署机（root 密码已给）。
需要实操，并且体现实操效果，需要体现提示词，和使用工具，
源码代码仓库地址，输出博客《模块6:网络安全、加密及安全通信实战》，
适合在互联网平台发表。

使用的工具：

  • 本地：Git Bash bash 5.3.9、OpenSSL 3.5.6、python3 3.13、sha256sum、gpg、ssh、curl
  • 远程采集：paramiko（Python SSH 库）——密码 SSH 实连 5 台主机，执行只读命令
  • 被采主机自带：OpenSSL 3.0.13、OpenSSH 9.6p1、ufw、iptables/nft、ss、AppArmor

2. 密码学三支柱：对称 / 非对称 / 哈希

先建立最核心的心智模型，再用脚本把"看不见"的密码学跑出"看得见"的结果。

2.1 对称加密：同一把密钥加解密（本地 XOR 演示）

bash scripts/01_symmetric_demo.sh

明文      : TOP SECRET 2026
明文(hex) : 544f50205345435245542032303236
密钥      : 0x5A (0x5A)
密文(hex) : 0E150A7A091F19081F0E7A686A686C   <- 无明文特征，看似随机
解密(hex) : 544F50205345435245542032303236
✓ 解密hex == 原始hex => 同一个密钥完成加解密（这就是对称加密）
  密钥泄露=全盘泄露 => 故需用非对称/DH 安全协商出对称密钥

工业级对称算法是 AES（本篇 4.3 在真实主机用 openssl enc -aes-256-cbc 实跑）。
对称加密快，但"如何安全把密钥分给对方"是难题——交给下一节。

2.2 非对称加密 & 密钥协商：Diffie-Hellman（本地数值演示）

bash scripts/03_diffie_hellman.py

公开参数(可被窃听): 大素数 p=23, 生成元 g=5
Alice 私钥 a=19 (保密); 公开值 A=g^a mod p=7
Bob   私钥 b=7  (保密); 公开值 B=g^b mod p=17
Alice 算出共享密钥 = 5
Bob   算出共享密钥 = 5
双方相等? True
窃听者只知道 p,g,A,B，想反推 a/b 需要解离散对数(大数下计算不可行)=>安全

DH 解决了"在不安全信道上协商共享密钥"的问题；RSA/ECDSA 则用于加密/签名。
真实主机的 ssh-keygen -t ed25519（2.3、4.1）用的就是非对称密钥对。

2.3 哈希与完整性 / 数字签名（本地实跑）

bash scripts/02_hash_integrity.sh

原始哈希: 8983e91ded45e38b442ccc659e2e7b6a7522334246fe736a30d8bc02a8768bd0
篡改哈希: 65b53ad27552c6b1458c18a8b7b52543686e9bebf99d0ca3c2109ebd0d089109
✓ 哪怕改一个字，完整性校验立即失败

正常消息 HMAC: 05b826e435ea4105feb7d820e5828bdf352a6534fc6e23efbd6b6cd4bbcd5703
篡改消息 HMAC: 7b5086965e572e6307b471e28500c45ea3f93c4078fb623ff604cbdb6f0970ee
✓ 内容一改 HMAC 立即不同 => 接收方比对即知被篡改/伪造

✓ 篡改后验签失败 => 签名绑定原文，无法抵赖/伪造

三种原语职责不同：哈希=完整性；HMAC=完整性+身份认证；非对称签名=完整性+身份认证+不可抵赖。

3. PKI 与数字证书：CA、自签、证书链

3.1 自签 X.509 证书（真实主机 113.44.140.3 实跑）

# 在真实主机 /tmp 下生成 RSA 私钥 + 自签证书（非破坏性）
openssl genrsa -out /tmp/demo.key 2048
openssl req -new -x509 -key /tmp/demo.key -out /tmp/demo.crt -days 365 \
  -subj "/C=CN/ST=BJ/L=BJ/O=DemoOrg/OU=Sec/CN=demo.example.com"
openssl x509 -in /tmp/demo.crt -noout -subject -issuer -dates -serial

subject=C = CN, ST = BJ, L = BJ, O = DemoOrg, OU = Sec, CN = demo.example.com
issuer =C = CN, ST = BJ, L = BJ, O = DemoOrg, OU = Sec, CN = demo.example.com   # 签发者==主体 => 自签名
notBefore=Jul 20 14:10:08 2026 GMT
notAfter =Jul 20 14:10:08 2027 GMT
serial   =2679B55A23168696A6DBFCE600B9FA4B09034191

证书文本关键字段：

Certificate:
    Data:
        Version: 3 (0x2)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = CN, ST = BJ, ... CN = demo.example.com
        Validity  Not Before: Jul 20 14:10:08 2026 GMT  Not After : Jul 20 14:10:08 2027 GMT
        Subject: C = CN, ST = BJ, ... CN = demo.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)

自签名证书的"签发者==主体"，浏览器/客户端默认不信任——只适合内部测试。
生产用证书须由受信任 CA（如 Let’s Encrypt、DigiCert、GlobalSign）签发，形成证书链。

3.2 真实公网证书链（真实主机 openssl s_client 实跑）

openssl s_client -connect www.baidu.com:443 -servername www.baidu.com </dev/null 2>/dev/null \
  | grep -E "^subject|^issuer|^Verify"

subject=C = CN, ... O = "Beijing Baidu Netcom Science Technology Co., Ltd", CN = baidu.com
issuer =C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
Verify return code: 0 (ok)        # 证书链受信任、验签通过

第二台主机对 www.qq.com 抓取，签发者为 DigiCert Secure Site OV G2——印证了不同站点由不同受信任 CA 背书。

TLS 握手时，服务器把"站点证书 + 中间 CA 证书"发给客户端，客户端用本地信任库中的根 CA 逐级验签，
任一环断裂即报警（如自签、过期、域名不符）。

4. SSH 安全通信：密钥登录与 sshd 加固

4.1 生成密钥对（真实主机 + 本地双实跑）

ssh-keygen -t ed25519 -f /tmp/demo_ed25519 -N "" -C "demo@security"
cat /tmp/demo_ed25519.pub
ssh-keygen -lf /tmp/demo_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAkQ7gGSLF2v2nDBpELdPN/OBIOnL25+ivkAEbilo4KK demo@security
256 SHA256:x7VShcBd5UuDfAClYTS2Mp8vdsYPD6Oeue3QSqQ0GF8 demo@security (ED25519)

免密登录原理（挑战-应答）：服务器持公钥(~/.ssh/authorized_keys)，客户端持私钥；
服务器发随机挑战 → 客户端用私钥签名 → 服务器用公钥验签。验过即证明"你持有私钥"，
全程不传密码，天然抗窃听、抗暴破。

4.2 真实主机 sshd 配置审计（4 台 ECS 巡检一致）

sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|pubkeyauthentication|x11forwarding'

port 22
maxauthtries 6
permitrootlogin yes          # ⚠ 允许 root 直接登录
passwordauthentication yes   # ⚠ 允许密码登录（暴破风险）
pubkeyauthentication yes
x11forwarding yes            # 可关，减小攻击面
permitemptypasswords no

这 4 台主机的 sshd 都允许 root + 密码登录。配合下面的"失败登录"证据，这正是
互联网上 SSH 暴破最爱钻的口子。生产建议：PermitRootLogin no、PasswordAuthentication no、
仅留 PubkeyAuthentication yes（见第 8 章加固示例）。

5. TLS/HTTPS：传输层安全实战验证

除 3.2 的 s_client 外，本地也直接验证了公网 TLS（需联网）：

bash scripts/05_tls_inspect.sh

--- www.baidu.com ---
subject=C=CN, ... CN=baidu.com
issuer=C=BE, O=GlobalSign nv-sa, CN=GlobalSign RSA OV SSL CA 2018
Protocol: TLSv1.2
    Verify return code: 0 (ok)
--- www.qq.com ---
subject=C=CN, ... CN=www.qq.com
issuer=C=US, O=DigiCert, Inc., CN=DigiCert Secure Site OV G2 TLS CN RSA4096 SHA256 2022 CA1
Protocol: TLSv1.2
    Verify return code: 0 (ok)
* ALPN: server accepted http/1.1
< HTTP/1.1 200 OK

看到 issuer=GlobalSign/DigiCert 等受信任 CA、Verify return code: 0 (ok)，即说明证书链可信、
TLS 加密通道已建立。现代站点普遍协商到 TLS 1.2/1.3（TLS 1.0/1.1 已废弃）。

6. 防火墙：ufw / iptables / nftables

6.1 真实主机防火墙状态（巡检结果）

4 台 ECS 的 ufw status 均为 Status: inactive，iptables 各链 policy ACCEPT 且无规则：

### 防火墙 ufw 状态
Status: inactive
### iptables 规则
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

⚠ 4 台生产主机均未启用主机防火墙，安全组是唯一边界。若安全组配置失误，主机直接暴露。

6.2 atomcode 部署机的云厂商 HIDS 链

atomcode(117.72.182.3, Ubuntu 22.04) 的 iptables/nft 里能看到云厂商注入的
主机入侵检测（HIDS） 链 JDCLOUDHIDS_*：

Chain JDCLOUDHIDS_IN (1 references)
Chain JDCLOUDHIDS_OUT (1 references)
table ip filter {
    chain INPUT  { type filter hook input priority filter; policy accept;
        counter packets 13399947 ... jump JDCLOUDHIDS_IN_LIVE
        counter packets 13399947 ... jump JDCLOUDHIDS_IN }
    ...
}

6.3 ufw 最小可用规则示例（文档，未在生产执行）

# 默认拒绝入站、允许出站；仅放行 SSH(改端口更佳) 与业务端口
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp          # 建议改成非 22 端口 + 仅限运维 IP
ufw allow 80,443/tcp
ufw enable
# 查看
ufw status verbose
# nftables 等价：nft add rule inet filter input tcp dport 22 accept

7. 主机安全基线：端口 / 服务 / 用户 / 登录审计

7.1 监听端口与暴露面（真实主机 ss -tunap 节选）

主机 暴露的关键服务
ecs-146b-0001 named(DNS) 192.168.0.90:53、127.0.0.1:53；nginx 进程
ecs-146b-0002 apache2 :80 / :443、sshd:22
ecs-146b-0003 rpcbind:111、rpc.mountd(NFS 暴露)
atomcode sshd:22、atomcode 代理:13457、多个 python3(5000/8080/9090…)

rpcbind(111) 与 NFS 直接绑在 0.0.0.0 上是经典高危面，应限制来源或用 nft 仅放行内网。

7.2 失败登录 = 真实暴破证据（巡检 lastb）

ecs-146b-0002 的 lastb 直接抓到字典式暴破（来源 45.156.87.70）：

dev     ssh:notty    45.156.87.70     Mon Jul 20 22:08
sharon  ssh:notty    45.156.87.70     Mon Jul 20 22:08
ian     ssh:notty    45.156.87.70     Mon Jul 20 22:08
user1   ssh:notty    45.156.87.70     Mon Jul 20 22:08

ecs-146b-0001 也出现对 root 的 ssh 失败登录（来源 114.116.217.165），且 ss 中可见 SYN-RECV 态的入向 SSH 连接——
这是正在发生的扫描/暴破。结论：必须关密码登录、改端口、上 fail2ban/云安全组限速。

7.3 强制访问控制

4 台 ECS 均为 AppArmor（apparmor module is loaded，121 个 profile、26 个 enforce），
SELinux 未启用——Ubuntu 系默认用 AppArmor，区别于 CentOS/RHEL 的 SELinux。

8. 安全加固实战（示例配置，未在生产执行以免影响业务）

把第 4/6/7 章的发现落成可落地的加固。以下为示例文件，本篇未写入任何生产主机：

/etc/ssh/sshd_config.d/10-hardening.conf

Port 2222                      # 改默认端口，减少自动化暴破
PermitRootLogin no             # 禁止 root 直登
PasswordAuthentication no       # 仅公钥
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
X11Forwarding no

配套防火墙（仅放行业务+新 SSH 端口、限制来源）：

ufw allow from 运维IP to any port 2222 proto tcp
ufw allow 80,443/tcp
ufw default deny incoming && ufw enable

再加 fail2ban 自动封禁暴破 IP，与第 7.2 的真实攻击日志形成闭环。

9. 隧道与 VPN：加密通道的"安全通信"延伸

VPN 的本质 = 密钥协商（非对称/DH，第 2/3 章）+ 对称加密数据（第 2 章）+ 路由转发。
下面把"临时隧道（SSH）"和"站点级 VPN（WireGuard / IPsec）"都跑出真实配置与证据。

9.1 SSH 加密隧道（临时安全通信利器）

# 本地转发：把本机 8080 映射到远程内网服务(192.168.0.90:80)
ssh -N -L 8080:192.168.0.90:80 user@跳板机
# 远程转发：把远程 9000 暴露到本机(内网穿透)
ssh -N -R 9000:localhost:3000 user@公网机
# 动态 socks 代理(-D)，浏览器走加密通道出网
ssh -N -D 1080 user@跳板机

真实主机 ss 里已能看到 ESTAB 的 SSH 加密会话与 SYN-SENT（atomcode 上 python3 主动连
192.0.2.99:9999 的探测）——加密通道就在你眼前跑着。

9.2 WireGuard：极简高性能站点 VPN（真实密钥实跑）

WireGuard 用 Curve25519 做密钥交换、ChaCha20/AES 做对称加密、无需 PKI/CA，靠"预交换公钥"互信。
本地无 wg 命令，用 openssl X25519 直接产出标准 WG 格式密钥（见 scripts/06_vpn_demo.sh）：

bash scripts/06_vpn_demo.sh

########## A. WireGuard 密钥对 (Curve25519 / X25519) ##########
  server  priv(Base64,44) = uBcR6osFUcAYdJphaaRJjuZFwS6mRZ0+L796beTCDHQ=
  server  pub (Base64,44) = X64mBXHMpbL/Ch424P0Ofw2H1f4MLxJBcmzKgKfJlhU=
  client  priv(Base64,44) = iPOQHkX03yR56KnpgQT2291H50ntGQW7TL6+tmSAVF8=
  client  pub (Base64,44) = qvNz5zvvNsnrRkrQDaONtJL57JX4rvQacrrXq6Oor2Q=

44 字符的 Base64 正是 32 字节 Curve25519 密钥的标准 WireGuard 格式（wg genkey 产物同此）。
把对端 pub 填进本方 [Peer]，即可完成身份认证——没有 CA、没有证书分发。

可运行配置（vpn-configs/wg-server.conf / wg-client.conf，用上面的真实公钥/私钥替换占位符）：

wg-server.conf（中心站点）：

[Interface]
Address    = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>          # 上一步 server priv
PostUp   = sysctl -w net.ipv4.ip_forward=1
PostUp   = iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>            # 上一步 client pub
AllowedIPs = 10.0.0.2/32, 192.168.10.0/24  # 仅放行对端隧道IP + 对端内网(最小权限)

wg-client.conf（分支/移动端）：

[Interface]
Address    = 10.0.0.2/24
PrivateKey = <CLIENT_PRIVATE_KEY>
DNS        = 10.0.0.1

[Peer]
PublicKey  = <SERVER_PUBLIC_KEY>
Endpoint   = 113.44.140.3:51820
AllowedIPs = 0.0.0.0/0                     # 全流量走隧道; 站点互联则只写对端网段
PersistentKeepalive = 25

启停与验证（在真实 Linux 主机，需 wireguard-tools）：

cp wg-server.conf /etc/wireguard/wg0.conf
wg-quick up wg0            # 拉起接口
wg show                    # 查看握手/流量
# 预期: interface: wg0  /  public key: X64m...  /  peer: qvNz...  /  latest handshake: <时间>  /  transfer: <上行>/<下行>
sysctl net.ipv4.ip_forward=1   # 若需互访对端内网

9.3 IPsec（strongSwan）：企业级站点到站点 VPN（真实证书链实跑）

IPsec 走 IKEv2 + ESP，站点间用证书双向认证——正好复用第 3 章 PKI。
用 scripts/06_vpn_demo.sh 的 B 段已实跑出"根 CA → 站点证书"链：

########## B. IPsec PKI：自建根 CA + 两个站点证书 (证书链) ##########
--- B1. 根 CA (自签, 仅此一次) ---
subject=C=CN, ST=BJ, O=VPN-CA, CN=VPN-Root-CA
serial=1F2184AC512F65A8F936E0EB0DB6D0CD27C6FFAB
--- B2. 站点 siteA 证书 (由根 CA 签发) ---
subject=C=CN, ST=BJ, O=VPN, CN=siteA.example.com
issuer =C=CN, ST=BJ, O=VPN-CA, CN=VPN-Root-CA     # issuer≠subject => 由 CA 签发(非自签)
serial =68FFB1DD9D5A63BEFDAFBFADC9C3307769E30DBB
notBefore=Jul 20 14:43:37 2026 GMT
notAfter =Oct 22 14:43:38 2028 GMT
--- B2. 站点 siteB 证书 (由根 CA 签发) ---
subject=C=CN, ST=BJ, O=VPN, CN=siteB.example.com
issuer =C=CN, ST=BJ, O=VPN-CA, CN=VPN-Root-CA     # 与 siteA 同根 CA

siteA/siteB 的 issuer 都是 VPN-Root-CA，与第 3 章"证书链"完全对应：两站各持自己的
cert+key，并互信对方根 CA，即可完成 IKEv2 双向认证，无需共享密码。

可运行配置（vpn-configs/ipsec-siteA.conf / ipsec-siteB.conf / ipsec.secrets）：

/etc/ipsec.conf（站点 A 视角，IKEv2 + 证书）：

config setup
    charondebug="ike 2, knl 2, cfg 2"
conn siteA-to-siteB
    type         = tunnel
    auto         = start
    keyexchange  = ikev2
    ike          = aes256-sha256-modp2048   # IKE SA: 非对称协商(第2/3章)
    esp          = aes256-sha256-modp2048   # IPsec SA: 对称加密数据(第2章)
    left         = 10.0.0.1
    leftcert     = siteA.crt
    leftid       = siteA.example.com
    leftsubnet   = 192.168.10.0/24
    right        = 10.0.0.2
    rightid      = siteB.example.com
    rightsubnet  = 192.168.20.0/24

/etc/ipsec.secrets：: RSA siteA.key（本站私钥，绝不入库/不提交）。
启停与验证（真实主机，需 strongswan）：

ipsec start                  # 或: systemctl start strongswan
ipsec statusall              # 预期: "Connections: siteA-to-siteB"; "Security Associations: siteA-to-siteB: #1, ESTABLISHED"
swanctl --list-conns         # 现代 strongSwan 也可

证书生成脚本见 vpn-configs/gen-ipsec-certs.sh（与 9.3 实跑同源）。

9.4 WireGuard vs IPsec 选型对照

维度 WireGuard IPsec (strongSwan/IKEv2)
握手/协商 Curve25519，秒级 IKEv2，多轮
加密原语 ChaCha20 / AES-GCM AES / 3DES / 多种
身份体系 公钥直填（无 CA） 证书（PKI）或 PSK
配置复杂度 极简（十几行） 较复杂（需 PKI/策略）
内核/性能 主线内核模块，快 用户态 charon，较重
典型场景 现代站点互联、移动端、云主机 企业合规、与旧设备互通、硬件 VPN

二者都遵循"非对称协商密钥 + 对称加密数据"这一第 2 章主线；WireGuard 把 PKI 拿掉更轻，
IPsec 借 PKI 更易做大规模互信与合规审计。

10. 真实主机安全巡检报告（汇总）

5 台主机只读巡检 + 2 台加密实战，原始日志见 outputs/：

  • 113.44.140.3_sec.log / _crypto.log（全量：密钥对、自签证书、AES、哈希、baidu TLS、openssl 性能）
  • 123.60.217.187_sec.log / _crypto2.log（apache2 + 暴破证据 + qq TLS）
  • 114.116.226.73_sec.log、120.46.91.123_sec.log（NFS/rpcbind、基础基线）
  • 117.72.182.3_sec.log（atomcode：JDCLOUDHIDS HIDS 链、python 服务）

关键发现（真实）：

  1. 4 台 ECS 防火墙 ufw inactive、iptables 空规则——主机层零防护。
  2. 全部 PermitRootLogin yes + PasswordAuthentication yes——root 密码 SSH 直登。
  3. lastb 显示 dev/sharon/ian/user1 等字典暴破（来源 45.156.87.70），ss 见 SYN-RECV 入向 SSH。
  4. ecs-146b-0003 的 rpcbind:111 / NFS 绑 0.0.0.0，暴露面偏大。
  5. atomcode 上云厂商 JDCLOUDHIDS 链已注入，说明平台侧有 HIDS 兜底。

openssl 性能基准（真实主机，节选）：

type             16 bytes   ...   16384 bytes
sha256         130774k   ...  1788433k     # 哈希极快
aes-256-cbc    873594k   ...  1027287k     # 对称加密快(GB/s 级)
rsa 2048 bits   sign 4117.7/s   verify 61404.5/s   # 非对称慢，故仅用于"握手/签名"

这张表解释了工程现实：非对称慢、对称快 → TLS 用非对称做密钥协商、之后切对称加密正文。

11. 源码仓库与复现方法

仓库地址（Gitee）： https://gitee.com/LiaCin/linux-security-practice

注：Gitee 新建仓库默认 私有。如需公开，请在仓库 Settings → 基本信息 中把「是否公开」改为「公开」。本博客内容本身可独立在互联网平台发表。

# 1) 克隆
git clone https://gitee.com/LiaCin/linux-security-practice.git
cd linux-security-practice

# 2) 本地实跑全部密码学/概念演示（无需任何外部依赖）
bash scripts/run_all.sh

# 3) 对自有云主机做只读安全巡检 + 非破坏性加密实战（需 Python + paramiko）
pip install paramiko
python scripts/diag_security.py   # 按脚本内 HOSTS 列表修改 IP/账号

目录结构：

linux-security-practice/
├── README.md                       # 项目说明(本文件)
├── 模块6-网络安全、加密及安全通信实战.md   # 本博客
├── scripts/
│   ├── 01_symmetric_demo.sh     # 对称加密(XOR)直观演示
│   ├── 02_hash_integrity.sh     # 哈希/HMAC/数字签名演示
│   ├── 03_diffie_hellman.py     # DH 密钥协商数值演示
│   ├── 04_ssh_key_demo.sh       # SSH 密钥对与免密原理
│   ├── 05_tls_inspect.sh        # 真实公网 TLS 证书链验证
│   ├── 06_vpn_demo.sh           # WireGuard 密钥对 + IPsec PKI 证书链(本地实跑)
│   ├── diag_security.py         # 真实主机只读巡检 + 加密实战采集器(凭据走环境变量)
│   └── run_all.sh
├── vpn-configs/                  # 可运行 VPN 配置模板(第9章)
│   ├── wg-server.conf / wg-client.conf   # WireGuard 中心/分支配置
│   ├── ipsec-siteA.conf / ipsec-siteB.conf / ipsec.secrets  # strongSwan IKEv2
│   └── gen-ipsec-certs.sh        # 生成 IPsec PKI(根CA+两站点证书)
├── outputs/
│   ├── local_demo.log           # 本地实跑输出
│   ├── 06_vpn_demo.log          # WireGuard/IPsec 实跑证据(真实密钥与证书链)
│   ├── 113.44.140.3_sec.log / _crypto.log
│   ├── 123.60.217.187_sec.log / _crypto2.log
│   ├── 114.116.226.73_sec.log
│   ├── 120.46.91.123_sec.log
│   └── 117.72.182.3_sec.log
└── docs/
    └── diag.md                  # 采集器使用说明

12. 面试高频考点小结

  1. 对称 vs 非对称 vs 哈希 —— 对称快(AES)用于加密正文；非对称(RSA/ECC)用于密钥协商/签名；哈希(SHA)用于完整性。
  2. DH 密钥交换 —— 不安全信道协商共享密钥，安全性依赖离散对数难题。
  3. PKI/证书链 —— 根 CA → 中间 CA → 站点证书；客户端用本地信任库逐级验签。
  4. 自签 vs CA 签发 —— 自签"签发者==主体"，不被默认信任，仅内部测试用。
  5. SSH 加固 —— 禁 root 直登、禁密码、仅公钥、改端口、fail2ban。
  6. TLS 握手 —— 协商密码套件 + 证书验签 + 生成会话密钥；现代用 TLS1.2/1.3。
  7. 防火墙 —— ufw(易用)/iptables(传统)/nftables(新默认)；默认拒绝入站。
  8. 主机基线 —— ss 看暴露面、lastb 看暴破、ufw 看边界、AppArmor/SELinux 看 MAC。
  9. NFS/rpcbind —— 勿绑 0.0.0.0，限制来源，否则成入侵跳板。
  10. 工程取舍 —— 非对称慢、对称快 → "非对称协商 + 对称加密"是 TLS/SSH 的通行做法。
  11. VPN 两类 —— WireGuard（Curve25519 公钥直填、无 CA、极简快）；IPsec/IKEv2（证书/PKI 认证、企业合规、与旧设备互通）。二者均为"非对称协商 + 对称加密数据"。
  12. WG 密钥格式 —— 44 字符 Base64 = 32 字节 Curve25519 私钥（wg genkey 与 openssl X25519 等价）。

本文所有命令输出均来自真实运行（本地 bash 5.3.9/OpenSSL 3.5.6/python3，或 4 台 ECS + atomcode 真实主机实采），可放心引用。安全巡检为只读、VPN 概念演示在本地临时目录（.vpn_demo/）与真实主机的 /tmp 下非破坏生成密钥/证书，未对任何生产主机做写操作。

# 安全 # web安全
Logo
亚马逊云科技技术品牌专区

更多推荐

2026年麒麟KYCP云计算认证深度解析：高级信创云人才的能力标尺

麒麟KYCP云计算是信创云平台高级运维认证，由工信部与麒麟软件联合颁发，聚焦KVM虚拟化、Kubernetes编排及信创云安全架构。考试含100题（单选70+多选20+判断10），90分钟需达70分合格，较初级KYCA难度显著提升。持证者可胜任政企信创云架构师等岗位，契合2026年信创规模化落地的人才缺口。备考建议分四阶段：基础巩固（1周）、K8s进阶（2-3周）、安全强化（1周）及模拟冲刺，需重

avatar 亚马逊云科技技术品牌专区
cover

中小企业基于云端SaaS的低成本AI问数落地指南白皮书

avatar 亚马逊云科技技术品牌专区
cover

从语音采集到LLM归因：线下销售过程管理硬件技术选型

avatar 亚马逊云科技技术品牌专区