网络安全之网络基础知识

主动模式：不同发起

被动模式：相同发起？？？？

FTP知识点

一、FTP的核心结构：为什么需要"两条连接"？

FTP要解决一个基本问题：文件传输过程中，用户可能随时发出新指令（比如中断、查看目录、删除文件）。

如果只用一个连接来做所有事，传输大文件时，控制指令会被阻塞。

解决方案：分离控制与数据

控制连接：传输命令与响应（如登录、列出目录、上传、下载）

数据连接：真正传输文件内容或目录列表

多通道协议：一个FTP会话 = 一条控制通道 + 若干条临时数据通道。

二、端口与连接建立过程（基础）

控制连接 ：客户端主动连接服务器的 TCP 21 端口，整个会话期间保持。

数据连接：按需建立，传输完成后关闭。

关键理解点：

谁主动发起数据连接？(注意是数据连接)

→ 这就是 主动模式 与 被动模式 的核心区别。

三、主动模式（Active Mode）------ 服务器主动连客户端

工作过程

客户端从随机高端口（1024+）连接服务器21端口 → 控制连接建立。

客户端要下载文件时，通过控制连接告诉服务器：
PORT 192,168,1,100,12,34

意思是：请连接我IP 192.168.1.100 的端口 12*256+34 = 3106。

服务器从自己的 20端口 主动连接客户端的 3106端口 → 数据连接建立。

数据传输。

为什么要有20端口？

规范约定：服务器端数据连接 源端口 = 20（便于防火墙识别FTP数据流）。

主动模式的问题（安全/网络角度）

客户端必须开放高端口 给服务器连接 → 很多客户端防火墙会拦截。
NAT环境下会有问题：

普通NAT（只转换IP头/端口）无法让主动模式正常工作，因为FTP的PORT命令里携带的是应用层IP地址，NAT不会自动修改它。

只有支持FTP ALG的NAT才能改写PORT命令中的地址，但即使如此，主动模式仍然存在安全与兼容性问题，因此实际很少这样用。

✅ 主动模式适合：服务器与客户端都在公网，且客户端防火墙允许入站高端口。

》》》》》》》》》》

为什么NAT环境下会有问题

1. 普通NAT做了什么（网络层）

假设客户端内网IP 192.168.1.100，通过NAT访问公网服务器 203.0.113.5。

客户端发出TCP SYN：源IP 192.168.1.100:12345 → 经过NAT后变成 公网IP:22345。

服务器看到的连接来源是 公网IP:22345，控制连接正常建立。

这一步NAT确实转换了网络层地址。

2. 主动模式中PORT命令的问题（应用层）

客户端要下载文件，通过控制连接发送：

bash 复制代码

PORT 192,168,1,100,48,57

意思是：请服务器连接我的IP 192.168.1.100，端口 48*256+57 = 12345。

关键点 ：这条命令是FTP应用层协议的内容，普通NAT不会窥探或修改TCP payload。

所以服务器收到的就是 192.168.1.100:12345。

服务器看到这个IP后想：192.168.1.100 在哪？不在我所在的路由表里（这是私有地址），无法建立TCP连接。

结论：普通NAT下，主动模式必然失败。

3. 那FTP ALG是怎么解决的？

FTP ALG（应用层网关） 会：

解析控制连接中的 PORT 或 PASV 命令。

将PORT命令中的内网IP+端口 替换为 NAT公网IP+对应映射端口。

同时动态创建NAT映射规则，确保后续数据连接能正确转换。

示例：

客户端发 PORT 192.168.1.100,48,57

ALG改为 PORT 公网IP,某,某 并记住：公网IP:转换后端口 对应内网 192.168.1.100:12345

服务器从20端口连接 公网IP:转换后端口 → NAT根据映射转给内网客户端。

所以理论上主动模式也可以在NAT下工作，前提是NAT设备支持FTP ALG且正确配置。

4. 为什么现实中主动模式在NAT下"几乎必死"？

即使有ALG，主动模式仍被抛弃，原因如下：

问题	说明
客户端防火墙	客户端需要开放一个高端口给服务器主动连接，很多个人防火墙或企业策略禁止入站。
多层NAT	如果客户端背后还有多层NAT（如运营商级NAT），ALG只能处理第一层，后续仍可能失败。
安全风险	允许外部服务器主动连接客户端内部端口，容易被攻击者利用做端口扫描或反弹shell。
配置复杂	需要ALG、NAT策略、防火墙放行，而被动模式几乎不需要客户端侧任何改动。

因此，实际部署中，只要客户端在NAT后，首选被动模式 。主动模式只在双方都是公网IP且防火墙开放时才会用。

《《《《《《《《《《《《《《

四、被动模式（Passive Mode）------ 客户端主动连服务器

为了解决主动模式的"服务器回连客户端"问题，被动模式诞生。

工作过程

客户端连接服务器21端口（控制连接）不变。

客户端要求进入被动模式：发送 PASV 命令。

服务器打开一个 临时高端口 （如50000），并通过控制连接告诉客户端：
227 Entering Passive Mode (192,168,1,10,195,128)

表示：请连接我IP 192.168.1.10 的端口 195*256+128 = 50048。

客户端从另一个随机高端口 主动连接 服务器的50048端口 → 数据连接。

数据传输。

关键特点

数据连接始终由客户端发起，完美穿越客户端防火墙。

服务器不再使用20端口，而是使用动态高端口。

被动模式的数据连接是由客户端发起的，服务器处于"被动等待连接"的状态。为了同时服务多个客户端，服务器必须为每个客户端分配一个临时、唯一的端口来监听。如果所有客户端都去连同一个端口。

被动模式的问题（服务器侧）

服务器防火墙需要开放 大量临时端口（如49152--65534）给客户端连接 → 安全策略配置复杂。

容易被攻击者扫描利用。

✅ 被动模式适合：客户端在防火墙/NAT后面，是现在实际中最常用的模式。

五、从安全工程师角度：FTP 的"麻烦"与应对

1. 防火墙为什么"讨厌"FTP？

因为防火墙只能看懂IP/端口，看不懂FTP控制连接里的 PORT / PASV 指令 。

如果不做特殊处理：

主动模式：防火墙不知道客户端会开放哪个端口等服务器连。

被动模式：防火墙不知道服务器会开放哪个临时端口。

"防火墙不知道X会开放哪个临时端口"中的"临时端口"，指的是被连接一方（等待入站连接的一方）**临时打开并监听的端口。

主动模式：客户端临时打开一个端口等服务器连 → 防火墙不知道客户端这个端口号。

被动模式：服务器临时打开一个端口等客户端连 → 防火墙不知道服务器这个端口号。

至于发起连接的一方使用的源端口，对防火墙来说不关键（通常是随机的，且出站连接默认允许）。

数据连接中，谁是"被连接方"（监听方）

模式	被连接方（监听端口）	发起连接方（使用随机源端口）
主动模式	客户端（PORT命令指定）	服务器（从20端口）
被动模式	服务器（PASV响应指定）	客户端（随机高端口）

关键：被连接方需要提前开放一个端口并处于LISTEN状态，才能接受对方的连接请求。

》》》》》》》》》》》》》》》》》》》》》》

FTP主动被动模式防火墙的处理

一、先明确三种防火墙/安全设备的位置

客户端防火墙：运行在客户端主机或客户端网络出口（如家用路由器）。

服务器防火墙：运行在FTP服务器主机或服务器网络出口。

中间防火墙/安全网关：位于客户端与服务器之间的路径上（如企业边界防火墙、NAT设备、IPS）。

在FTP的主动/被动模式讨论中，真正核心的"防火墙问题"通常指的是中间防火墙（尤其是NAT/ALG设备），但客户端和服务器自身的防火墙也会参与。我们分别讲。

二、被动模式：哪个防火墙会出问题？

被动模式下，客户端主动连接服务器临时端口（如50048），客户端发出的是出站连接，客户端的防火墙通常允许出站，那问题在哪？

答案：问题不在客户端防火墙，而在服务器防火墙（或中间防火墙对入站连接的限制）。

详细过程

服务器打开临时端口50048监听。

客户端从随机端口12345发起连接 → 目的：服务器50048。

服务器防火墙 看到：外部客户端IP:12345 → 服务器IP:50048。这是一个入站连接。

服务器防火墙通常默认禁止入站到非标准服务端口（如只允许21、80等）。50048不在白名单内 → 服务器防火墙拦截。

所以被动模式下的"防火墙不知道服务器会开放哪个临时端口"指的是：服务器防火墙需要放行大量临时端口入站，但无法提前知道具体号码。

问题发生在服务器侧入站。

三、主动模式：哪个防火墙会出问题？

主动模式下，服务器主动连接客户端临时端口（如3106）。

客户端防火墙看到：外部服务器IP:20 → 客户端IP:3106。这是入站连接。

客户端防火墙通常禁止入站 → 拦截。

同时，中间防火墙（如企业边界墙）也可能拦截，因为它看到的是外部主动连接内部一个未预先声明的端口。

所以主动模式的问题主要在客户端防火墙（或中间防火墙对入站连接的限制）。

四、统一对比表（按设备位置）

模式	客户端防火墙问题	服务器防火墙问题	中间防火墙问题
主动模式	需要允许外部服务器（20端口）入站到客户端临时端口 → 通常被拦截	无（服务器主动出站，通常允许）	需要允许外部入站到内部临时端口 → 需ALG动态放行
被动模式	无（客户端出站，通常允许）	需要允许外部客户端入站到服务器临时端口 → 需开放大量高端口或ALG	需要允许内部出站到外部临时端口 → 若严格限制出站目标端口，可能被拦截

核心结论：

主动模式的瓶颈在客户端侧入站。
被动模式的瓶颈在服务器侧入站。

《《《《《《《《《《《《《《《《《《《《《《

FTP相关知识点

一、被动模式是在主动模式之后发明的吗？

是的。

FTP协议最初版本（RFC 114, 1971年） 只有主动模式，当时网络环境简单，主机都在公网，没有NAT和客户端防火墙。

主动模式的问题：客户端需要开放随机高端口等待服务器连接 → 随着客户端防火墙普及，越来越难以工作。

被动模式 ：在RFC 1579（1994年）中正式标准化为"Firewall-Friendly FTP"，目的是让FTP能穿越客户端防火墙和NAT。

所以顺序是：先有主动模式 → 发现问题 → 发明被动模式。

二、既然两种模式都有问题，为什么实际中被动模式用得更多？

因为问题的性质和可控性完全不同。

对比维度	主动模式的问题	被动模式的问题
问题发生在哪一侧	客户端侧（需要入站连接）	服务器侧（需要入站连接）
谁控制环境	客户端通常不可控（用户在家、出差、防火墙策略未知）	服务器通常可控（管理员可以配置防火墙开放高端口范围或开启ALG）
解决方案难度	要求每个客户端开放入站端口 → 几乎不可行	管理员配置一次服务器防火墙 → 可行
安全性影响	客户端暴露临时端口给外部 → 安全隐患	服务器暴露临时端口给外部 → 但服务器本身就是对外服务，可以通过端口范围限制+ALG最小化风险

一句话 ：被动模式把"麻烦"集中到了服务器侧 ，而服务器是管理员可以掌控的；主动模式把"麻烦"推给了每个客户端，这在现实世界中无法解决。

三、一个典型场景说明

公司内部FTP服务器：管理员可以配置服务器防火墙开放高端口范围（如49152-65534）并开启FTP ALG。外部客户端（任意用户）无论在哪里，都可以用被动模式连接进来。

如果只用主动模式：每个外部用户必须手动配置自己的防火墙开放临时端口，这根本做不到。企业也无法要求所有外部用户配合。

因此，被动模式成为了事实标准，几乎所有现代FTP客户端默认使用被动模式（如FileZilla、WinSCP、curl等）。

FTP考题

题目1（多通道与协议基础）

FTP协议采用控制连接与数据连接分离的多通道模型。下列关于两者特性的描述，正确的是？（多选）

A. 控制连接使用TCP 21端口，由客户端主动发起，整个会话期间保持

B. 数据连接在主动模式下，服务器端的数据端口固定为20

C. 被动模式下，服务器通过PORT命令告知客户端临时数据端口号

D. 无论主动还是被动模式，数据连接在传输完成后立即关闭，但控制连接保持

题目1 答案：A、B、D

A正确：控制连接由客户端主动发起（TCP 21），保持会话。

B正确：主动模式服务器数据连接源端口固定20（标准规定）。

C错误 ：被动模式下，服务器通过PASV命令的响应（227报文） 告知客户端临时端口，而非PORT命令（PORT用于主动模式）。

D正确：数据连接按需建立，用完即释放，控制连接持续。

题目2（NAT穿越与主动模式故障）

某公司内部用户（IP 192.168.1.100）通过NAT上网，尝试以主动模式访问公网FTP服务器（203.0.113.5）。用户能成功登录并列出目录，但执行下载文件操作时卡住并超时。下列原因分析最准确的是？

A. 服务器防火墙阻止了来自客户端源端口20的访问

B. 客户端发送的PORT命令中包含内网IP 192.168.1.100，服务器无法建立数据连接

C. NAT设备未转换控制连接的端口号，导致服务器无法识别

D. 主动模式下客户端必须开放TCP 20端口入站，但客户端防火墙未放行

题目2 答案：B

A错误：服务器主动连接客户端时，源端口为20，但服务器防火墙通常允许出站，问题不在源端口20。

B正确 ：主动模式客户端发送PORT 192.168.1.100,48,57，服务器收到内网IP后无法路由（除非有FTP ALG改写地址）。能登录列出目录说明控制连接正常，下载超时说明数据连接失败，这是主动模式+NAT的典型故障。

C错误：NAT能正常转换控制连接的端口，问题在于应用层载荷未修改。

D错误：客户端不需要开放20端口，而是需要开放一个临时高端口（如12345）等待服务器连接。

控制连接为什么能成功建立

控制连接的建立过程：

客户端（192.168.1.100:12345）发出TCP SYN → 目的：服务器（203.0.113.5:21）。

数据包经过NAT设备时，NAT会转换网络层的源IP和端口：

源IP：192.168.1.100 → 公网IP（如 1.2.3.4）

源端口：12345 → NAT分配的映射端口（如 22345）

服务器收到的连接请求是：源IP=1.2.3.4，源端口=22345，目的IP=203.0.113.5:21。

服务器响应时，目标地址是1.2.3.4:22345，NAT再反向转换回192.168.1.100:12345。

所以控制连接能成功，因为NAT在网络层（IP+TCP头）做了完整的双向地址转换。

服务器根本看不到客户端的真实内网IP，只看到NAT后的公网IP。

二、主动模式的数据连接为什么失败？

数据连接建立过程（问题所在）：

客户端通过控制连接发送 PORT 192,168,1,100,48,57（告诉服务器"请连接我的IP 192.168.1.100，端口12345"）。

这条命令是FTP应用层协议的内容 ，普通NAT设备不会修改TCP payload。

NAT已经修改了IP头（把源IP改为公网IP），但它不会去解析FTP命令并修改里面的IP地址。

服务器收到PORT命令后，看到的是 192.168.1.100:12345。

服务器尝试从自己的20端口主动连接 192.168.1.100:12345。

但 192.168.1.100 是一个私有地址，服务器所在公网无法路由到该地址 → 连接失败。

核心差异：

控制连接成功：因为NAT修改了IP头（网络层）。
数据连接失败：因为NAT没有修改FTP命令载荷中的IP地址（应用层）。

总结：
控制连接成功是因为NAT转换了IP头；数据连接失败是因为NAT没有转换PORT命令载荷中的内网IP。两者互不影响，这是应用层网关（ALG）需要额外处理的原因。

题目3（被动模式防火墙策略设计）

某企业对外提供FTP下载服务，采用被动模式。安全管理员希望最小化服务器防火墙暴露的端口，同时保证正常服务。以下哪项策略最合理且符合安全最佳实践？

A. 在服务器防火墙上开放TCP 21及整个临时端口范围（49152--65534）入站

B. 仅开放TCP 21，并启用FTP ALG，由ALG动态放行数据连接

C. 将FTP服务器改为主动模式，并开放客户端侧所有高端口

D. 将FTP服务器置于DMZ，并关闭所有入站防火墙策略

题目3 答案：B

A：开放整个临时端口范围风险大，易被扫描利用。

B正确：仅开21，启用FTP ALG。ALG动态解析PASV响应中的临时端口，临时放行具体IP+端口，用完即关。最小权限原则。

C：改为主动模式要求所有客户端开放入站端口，不可行。

D：关闭防火墙策略严重违规。

题目4（FTP ALG工作原理）

关于FTP ALG（应用层网关）在处理被动模式时的行为，下列描述正确的是？

A. ALG会解密SSL加密的FTP控制连接，从中提取PASV响应

B. ALG解析控制连接中的227报文，动态创建防火墙规则允许外部客户端访问服务器临时端口

C. ALG将服务器返回的内网IP地址替换为公网IP，但端口号保持不变

D. ALG只在主动模式下需要，被动模式因为客户端发起连接所以不需要ALG

题目4 答案：B

A错误：标准FTP ALG不支持解密SSL/TLS（那是FTPS场景，需要另外配置）。

B正确：ALG解析227报文中的IP和端口，动态通知防火墙创建临时放行规则。

C错误 ：ALG在被动模式下主要处理端口号，若服务器返回内网IP也会替换，但题目强调的是端口动态放行，且C中说端口号保持不变是错误的（ALG可能会修改端口映射）。

D错误：主动和被动模式都需要ALG来动态处理。

题目5（综合演进与安全替换）

某公司现用FTP（被动模式）进行文件传输，防火墙开放了TCP 21和被动端口范围10000--11000。近期安全审计指出FTP存在凭据明文传输、端口范围过大等风险。要求在不改变客户端使用习惯的前提下，提升传输安全性。最佳方案是？

A. 将被动端口范围缩小至50000--50005，并启用IP白名单

B. 升级为FTPS（隐式TLS），并保留被动模式，同时在防火墙上开启FTP ALG对加密流量的检测

C. 改用SFTP（SSH文件传输协议），并将防火墙开放端口改为TCP 22

D. 继续使用FTP但强制要求用户使用VPN接入，所有流量走加密隧道

题目5 答案：C

A：缩小端口范围略好，但FTP本身明文、认证风险仍在。

B：FTPS（隐式TLS）加密控制连接后，传统ALG无法解析227报文，防火墙无法动态开放数据端口，需要改为显式TLS或固定端口范围，实施复杂且兼容性差。

C正确：SFTP基于SSH，单通道（22端口），天然加密、无需额外端口范围、防火墙策略简单，是FTP的理想替代。虽然客户端需要改用SFTP客户端（如FileZilla已支持），但用户习惯变化小。

D：VPN+传统FTP可以加密传输，但增加了VPN部署和运维成本，且仍保留明文认证路径（若VPN内部有嗅探）。相比SFTP不是最优。

被动模式

防火墙下 FTP 主被动差异与局限

一、主动模式的根本局限性（为什么它"先天不足"）

主动模式要求服务器主动连接客户端，客户端必须开放一个临时端口并监听。问题在于：

客户端防火墙默认拦截入站连接

个人防火墙、家用路由器、企业边界墙默认策略都是"禁止外→内"。主动模式恰恰需要外→内。

NAT环境下几乎不可行（除非ALG改写PORT命令）

客户端发送PORT 192.168.x.x:临时端口，服务器收到私有地址无法路由。即使NAT设备支持FTP ALG，也需要额外配置，且多层NAT会失败。

客户端不可控

无法要求每个用户去配置防火墙、开启端口转发、关闭安全软件。

结论：主动模式在现实网络环境中（99%的客户端都在防火墙/NAT后）可用性极低。

二、被动模式为何成为事实标准（它解决了什么）

被动模式把数据连接的方向反过来：客户端主动连接服务器。这带来了：

客户端无需开放入站端口 → 完美穿越客户端防火墙/NAT。

服务器侧可控 → 管理员可以配置服务器防火墙开放临时端口范围或启用FTP ALG。

对客户端完全透明 → 用户无需任何额外操作。

所以被动模式不是没有缺点，而是把"麻烦"集中到了可控的服务器侧，从而成为实际部署的首选。

三、被动模式自身的局限性（它也有问题）

被动模式并非完美，它的局限性包括：

服务器防火墙需要开放大量临时端口

如果服务器使用默认临时端口范围（如49152-65534），防火墙必须允许这些端口入站。这会扩大攻击面。

服务器资源消耗

每个被动数据连接占用一个临时端口和对应的套接字，高并发时可能耗尽端口资源。

依然需要ALG或固定端口范围才能与防火墙友好

没有ALG时，管理员只能手动开放一个大的端口范围（如10000-11000），不够精细。有ALG则能动态放行，但ALG需要设备支持且正确配置。

控制连接仍明文

用户名、密码、命令都是明文，容易被嗅探。这是FTP本身的缺陷，与主动/被动无关。

被动模式的局限性主要体现在服务器侧的安全管理复杂度，以及FTP协议自身的明文风险。

四、为什么"被动模式在主动模式之后出现"依然更常用？

历史顺序：

主动模式（RFC 114, 1971）→ 互联网发展，客户端防火墙/NAT普及 → 主动模式失效 → 被动模式（RFC 1579, 1994）被发明来解决客户端入站问题。

被动模式虽然带来了服务器侧的新问题，但问题的可解决性不同：

主动模式的问题在客户端侧 → 几乎无解。

被动模式的问题在服务器侧 → 管理员可配置端口范围、启用ALG、限制访问源IP等。

因此，即使被动模式也有局限，它仍然是实际环境中最可行的方案。

五、一句话终极总结（考场答题用）

主动模式要求客户端开放入站端口，在防火墙/NAT环境下不可行；被动模式将入站要求转移到服务器侧，虽然需要管理临时端口范围或ALG，但服务器可控，因此成为事实标准。

SFTP

SFTP 是解决 FTP 安全性不足而设计的，是备考中的重点，也是现代企业环境的优先选择。

核心一：架构的本质区别 (SFTP vs. FTP)

传统 FTP 有"控制"和"数据"两条通道，带来防火墙麻烦；而 SFTP 基于 SSH 协议，是全新设计的"文件传输子系统"。它将命令与数据合并进 一条加密的SSH隧道 传输，架构简单且天生安全。

核心二：如何实现"真正"安全

SFTP 的安全依靠 SSH 协议，默认自动实现 端到端加密 和 完整性校验 ，防窃听篡改。它支持更强的 公钥认证（私钥保管在客户端，无需在网络上传输），安全性远超明文密码。

核心三：为何对"防火墙更友好"

这是对比传统 FTP 的关键考点。由于 SFTP 只用一条连接和一个端口（默认 TCP 22），所以：

无需 ALG：防火墙无需 ALG 动态解析命令开放数据端口。

NAT 无障碍：无需处理被动模式端口范围等复杂问题，策略简单。

策略简单：仅需放行"目的地址：TCP 22"的出站规则，配置方便安全。

维度	FTP (文件传输协议)	SFTP (SSH文件传输协议)
核心架构	独立协议，双通道 (21控制 + 20数据)	基于 SSH 的子系统，单通道
安全性	明文传输，极度不安全	全程加密 (命令+数据)
防火墙/NAT	复杂 (需开放数据端口或配置ALG)	简单 (仅放行TCP 22)
认证方式	用户名/密码 (明文传输)	公钥认证 / 加密后的密码
默认端口	TCP 21 / 20	TCP 22 (与SSH共用)
标准化时间	1970年代	1990年代后期

核心四：SFTP 的局限性

速度略慢：加密解密带来额外开销，传输速度不如明文 FTP。
密钥管理难：在大规模企业环境中，公钥的分发、吊销和审计是巨大挑战。
配置需谨慎：默认端口 22 易受暴力破解攻击，建议修改或加强防护。

核心五：进阶对比 (SFTP vs. FTPS)

SFTP 主要和另一种安全方案 FTPS（FTP over TLS）对比：

FTPS ：通过在 FTP 协议上叠加 SSL/TLS 加密实现安全，但 继承了 FTP 的双通道、防火墙不友好和NAT麻烦问题，常需额外开放端口或依赖ALG。
结论：对于新建项目，SFTP 是更现代、安全且运维简单的首选。

STenlnet

STelnet 和 SFTP 都是基于 SSH 协议的不同应用

一、先明确核心概念：SSH 是什么？

SSH（Secure Shell）是一个加密的网络协议，用于在不安全的网络上安全地访问远程主机。它提供：

加密传输（防窃听）

完整性校验（防篡改）

身份认证（密码或公钥）

SSH 协议本身并不直接提供具体的应用功能 ，而是作为一个安全隧道，承载各种上层应用。

二、STelnet 的本质

STelnet = SSH + Telnet 的"安全外壳"版本

Telnet：传统的远程登录协议，明文传输（用户名、密码、命令全暴露）。

STelnet ：将 Telnet 的交互逻辑（终端会话）放到 SSH 隧道中传输，从而实现加密的远程登录。

端口：SSH 默认监听 TCP 22，STelnet 也使用这个端口，因为 STelnet 就是 SSH 协议中的一个子功能（通常称为 ssh 命令行登录）。

当你执行 ssh user@host 时，实际上就是 STelnet。

特点：

单端口（22）、单连接。

提供交互式命令行 shell。

加密、认证、完整性保护。

三、SFTP 的本质

SFTP = SSH + FTP 的"安全文件传输"版本

注意：SFTP 不是 FTP over SSH（那是 FTPS 或 FTP+SSH隧道）。SFTP 是 SSH 协议内部的一个独立的子系统，专门用于文件操作（上传、下载、列目录、删除、重命名等）。

它和 STelnet 共享同一个 SSH 连接，但使用不同的子系统通道。

端口：同样使用 TCP 22（与 SSH 共用）。

特点：

单端口、单连接。

文件传输协议，不是交互式 shell。

完全加密，无需额外开放数据端口。

四、STelnet 与 SFTP 的关系图

bash 复制代码

                SSH 协议（TCP 22）
                      │
        ┌─────────────┼─────────────┐
        │             │             │
    STelnet        SFTP         SCP
   (远程登录)    (文件传输)    (简单复制)

STelnet：为用户提供远程命令行环境。
SFTP：为用户提供安全的文件访问和传输。
两者可以共用同一个 SSH 连接（多路复用），也可以独立建立连接。

五、"sftp=ssh+sftp，stelnet=ssh+telnet"？

这是一种便于记忆的公式化表达，强调：

SFTP 不是 FTP 加上 SSH 隧道，而是 SSH 内置的文件传输子系统。

STelnet 也不是 Telnet 加上 SSH 隧道，而是 SSH 内置的终端会话功能。

但严格从技术实现看：

STelnet 更准确的叫法是 SSH 交互式会话，只是行为上替代了 Telnet。
SFTP 是 SSH 的一个子系统，独立于 shell 会话。

SSH的"子系统"是一个为扩展特定服务而设计的"插件"机制。 在这个框架下，STelnet（远程Shell）是SSH的内置核心功能，不属于子系统；而SFTP（文件传输）则是利用这个"插件"机制实现的、最成功的扩展服务。

STelnet (SSH交互式会话)

本质：它是SSH协议中最基础、最核心的功能，主要用于为用户提供一个通用的、交互式的远程Shell环境。

与子系统的关系 ：它不属于"子系统"。它不依赖外部程序，而是SSH服务器自身为客户端提供的核心服务。

SFTP (SSH文件传输协议)

本质：它不是一个通用环境，而是一个为特定目的服务 的独立程序（sftp-server）。

与子系统的关系 ：它是SSH子系统的典型代表 。在SSH服务器的配置文件 sshd_config 中，通常可以看到类似 Subsystem sftp /usr/libexec/sftp-server 的配置，正是这行代码将SFTP注册为了一个"子系统"。

非对称加密

一、什么是非对称加密？

非对称加密是一种加密方式，它使用一对数学上关联的密钥：公钥和私钥。

公钥：可以公开分发给任何人。

私钥：必须严格保密，只有所有者知道。

用公钥加密的数据，只能用对应的私钥解密；反过来，用私钥加密的数据（签名），只能用对应的公钥验证。

这与对称加密（只有一个密钥，加密解密都用它）形成对比。

》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》

场景一：SSH免密登录（客户端私钥，服务器公钥）

公钥在哪？ 存在服务器 上（~/.ssh/authorized_keys）。

私钥在哪？ 存在客户端 上（~/.ssh/id_rsa）。

公钥用来干什么？ 服务器用公钥加密一个随机数（挑战）发送给客户端。

私钥用来干什么？ 客户端用私钥解密这个随机数，证明自己持有私钥。

所以在这个场景中，确实是"公钥在服务器，私钥在客户端，公钥用于加密，私钥用于解密"。

场景二：HTTPS访问网站（服务器私钥，客户端公钥？不，客户端没有公钥）

HTTPS的核心设计------非对称加密只用来安全地交换一个临时对称密钥，后续大量数据传输改用对称加密。

一、证书在哪？

证书存储在服务器上，但在TLS握手过程中会发送给客户端。

服务器配置了证书文件（包含公钥、域名、有效期、签发机构等信息）。

当客户端（浏览器）连接服务器时，服务器会主动把证书发送给客户端。

客户端收到证书后，验证证书是否可信（检查签名、域名、有效期等）。

所以证书的物理存储位置是服务器，但客户端会临时拿到一份副本。

二、客户端用服务器公钥加密一个对称密钥，这是为什么？

因为非对称加密太慢，不适合加密大量数据；对称加密快得多，但需要双方拥有同一个密钥。

TLS握手过程（简化版）：

客户端验证服务器证书后，从证书中取出服务器的公钥。

客户端自己随机生成一个临时的对称密钥（比如 AES 256 密钥，称为"预主密钥"）。

客户端用服务器的公钥对这个对称密钥进行加密，然后发送给服务器。

服务器用自己的私钥解密，得到这个对称密钥。

此后，双方都用这个对称密钥加密通信内容（HTTP请求、响应等）。

目的：安全地让客户端和服务器拥有同一个对称密钥，同时利用非对称加密保证这个密钥在传输过程中不会被窃听（只有服务器私钥能解开）。

《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《

二、为什么需要公钥和私钥？为什么不能只有一个密钥？

》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》

非对称加密在双向通信中的一个关键点：公钥必须属于接收方。

《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《

TLS协议

TLS（Transport Layer Security，传输层安全协议）是SSL（Secure Sockets Layer，安全套接层） 的继任者，它是目前互联网上最核心的安全协议之一，专门用于在两个通信应用程序之间提供保密性 、数据完整性 和身份认证。

简单说，TLS 就是在 TCP/IP 协议栈的传输层（TCP） 和应用层（如 HTTP）之间，插入一个安全层，让原本明文的流量变成加密隧道。

一、TLS 协议要解决什么问题？

在没有 TLS 之前，很多应用层协议（HTTP、FTP、SMTP、Telnet）都是明文传输，存在三大风险：

窃听：中间人能看到通信内容（比如密码、信用卡号）。

篡改：中间人可以修改传输中的数据。

冒充：无法确认对方就是声称的服务器（可能连到钓鱼网站）。

TLS 通过三种核心机制解决这些问题：

加密：混合使用非对称加密（交换密钥）和对称加密（加密数据），防止窃听。

消息认证码（MAC，Message Authentication Code）：保证数据在传输过程中未被篡改。

数字证书：通过 CA 签发的证书验证服务器身份，防止冒充。

二、哪些协议/场景会用到 TLS？

TLS 本身不直接提供特定应用功能，而是作为一个安全层被其他协议封装使用。最常见的形式就是在协议名后面加一个 S（Secure）：

协议	原始协议（明文）	加 TLS 后	默认端口	说明
HTTP	HTTP（80）	HTTPS	443	最典型的应用，保护网页浏览、在线支付等
FTP	FTP（21）	FTPS	990（隐式）或 21（显式）	FTP over TLS，注意不是 SFTP（SFTP 走 SSH）
SMTP	SMTP（25）	SMTPS	465	邮件发送（提交）
POP3	POP3（110）	POP3S	995	邮件接收
IMAP	IMAP（143）	IMAPS	993	邮件接收（更现代）
LDAP	LDAP（389）	LDAPS	636	目录服务（如 Active Directory）
RDP	RDP（3389）	可启用 TLS	3389	远程桌面，可通过 TLS 加固
Syslog	Syslog（514）	Syslog over TLS	6514	安全日志传输
数据库	MySQL（3306）、PostgreSQL（5432）等	支持 TLS	原端口	防止数据库连接被嗅探

此外，很多 VPN 协议 也基于 TLS，例如：

OpenVPN：默认使用 TLS 进行控制通道加密。
DTLS：基于 UDP 的 TLS 变种，用于 VoIP、视频通话等实时通信。

DNS

TCP端口和UDP端口虽然是同一个数字（比如53），但它们是独立且不冲突的。

一、TCP端口和UDP端口是两套独立的"门牌号"

可以把 IP 地址想象成一栋大楼的地址（比如 203.0.113.5）。

大楼里有两套完全独立、互不干扰的"门牌系统"：

TCP 门牌系统：TCP 端口 21、22、23、53、80、443......

UDP 门牌系统：UDP 端口 53、67、68、123、161......

它们共用同一个数字范围（0-65535），但属于不同的协议栈。

所以 TCP 53 和 UDP 53 是两个完全不同的入口，可以绑定给不同的服务，甚至同时使用。

举个例子：

一台服务器可以同时：

在 TCP 53 上监听 DNS 的区域传输（TCP DNS）。

在 UDP 53 上监听普通的域名查询（UDP DNS）。

这两个服务互不冲突，因为客户端请求时会明确指定协议类型（TCP 或 UDP）。

二、为什么 DNS 需要同时使用 TCP 和 UDP？

DNS 设计之初为了效率，默认使用 UDP （无连接，速度快）。

但在某些情况下必须用 TCP：

场景	使用协议	原因
普通域名查询（响应 < 512 字节）	UDP 53	快速，一个请求一个响应，无连接开销
响应数据过大（如 DNSSEC、大量 TXT 记录）	TCP 53	UDP 最大只能传 512 字节，超过后需要用 TCP 分段传输
DNS 区域传输（主从服务器同步）	TCP 53	数据量大，需要可靠传输，保证完整性
DNS 安全扩展（DNSSEC）	常用 TCP 53	签名较大，易超 UDP 限制

所以 DNS 协议同时支持两种传输方式，客户端根据情况选择。