209.htm

unix高级编程原吗

根据FTP STD 9定义，FTP的目标包括：[PR85] <br>
1) 促进文件（程序或数据）的共享 <br>
2) 支持间接或隐式地使用远程计算机 <br>
3) 帮助用户避开主机上不同的 <br>
4) 可靠并有效地传输数据 <br>
    关于FTP的一些其他性质包括：FTP可以被用户在终端使用，但通常是给程序使用的 <br>
。FTP中主 <br>
要采用了传输控制协议(Transmission Control Protocol,TCP)[PJ81]，和Telnet 协议 <br>
[PJ83]。 <br>
1.2 重要历史事件[PR85] <br>
1971年，第一个FTP的RFC(RFC 114)由A.K. Bhushan在1971年提出，同时由MIT与Harvar <br>
d实验实 <br>
现。 <br>
1972年，RFC 172 提供了主机间文件传输的一个用户级协议。 <br>
1973年2月，在长期讨论（RFC 265，RFC 294，RFC 354，RFC 385，RFC 430）后，出现 <br>
了一个官方 <br>
了一个官方 <br>
文档RFC 454。 <br>
1973年8月，出现了一个修订后的新官方文档 RFC 542。确立了FTP的功能、目标和基本 <br>
模型。当时 <br>
数据传输协议采用NCP。 <br>
1980年，由于底层协议从NCP改变为TCP，RFC 765 定义了采用TCP的FTP。 <br>
1985年，一个作用持续至今的官方文档RFC 959(STD 9)出台。 <br>
1.3 FTP模型[PR85] <br>
就模型而言，从1973年以来并没有什么变化。下图是FTP使用模型： <br>
------------- <br>
|/---------| <br>
|| User || -------- <br>
||Interface|<--->| User | <br>
|----^----/| -------- <br>
---------- | | | <br>
|/------| FTP Commands |/----V----| <br>
||Server|<---------------->| User || <br>
|| PI || FTP Replies || PI || <br>
|--^---/| |----^----/| <br>
| | | | | | <br>
-------- |/--V---| Data |/----V----| -------- <br>
| File |<--->|Server|<---------------->| User |<--->| File | <br>
|System| || DTP || Connection || DTP || |System| <br>

-------- |------/| |---------/| -------- <br>
---------- ------------- <br>
Server-FTP USER-FTP <br>
注: 1. data connection 可以双向使用（双工） <br>
2. data connection 不需要一直存在. <br>
图一 FTP使用模型 <br>
术语 <br>
User PI(user-protocol interpreter): 用户协议解释器 <br>
Server PI(Server-protocol interpreter): 服务协议解释器 <br>
control connection：控制连接 <br>
Data connection：数据连接 <br>
FTP Commands：FTP命令。描述Data connection的参数，文件操作类型 <br>
FTP Replies：FTP命令 <br>
在图一描述的模型中，User PI创建control connection。control connection <br>
遵从Telnet协议。在用户初始化阶段，标准FTP命令被User PI生成并通过 <br>
control connection 传到服务器处理。Server PI将相应的标准FTP应答通过 <br>
control connection回传给User PI。数据传输由Data connection完成。 <br>
User DTP 在特定端口监听，由Server DTP 用指定参数初始化连接。 <br>
另一种情形是用户希望在两台非本地的主机上传递文件。用户与两个服务器建立contro <br>
l <br>
connection，安排两个服务器间的文件传输。下图描述了这样的模型。 <br>
Control ------------ Control <br>

---------->| User-FTP |<----------- <br>
| | User-PI | | <br>
| | "C" | | <br>
V ------------ V <br>
-------------- -------------- <br>
| Server-FTP | Data Connection | Server-FTP | <br>
| "A" |<---------------------->| "B" | <br>
-------------- Port (A) Port (B) -------------- <br>
图二 服务器间交互模型 <br>
2.FTP协议的安全扩展[HL97] <br>
2.1 一些安全地进行文件传输实践 <br>
a. 通过FTP传输预先被加密的文件 <br>
b. 通过E-mail传输预先被加密的文件 <br>
c. 通过PEM消息 <br>
d. 通过使用Kerberos的rcp命令. <br>
2.2 在RFC 2228 之前的FTP并不安全 <br>
虽然FTP采用 TELNET 协议执行connection control操作，而且 TELNET 协议后来又增补 <br>
了认证和 <br>
加密选项，但在RFC 1123 中禁止在connection control <br>
中进行 TELNET 选项协商。另外 TELNET 协议也没有提供完整性保护，而且也没有data <br>
  <br>
connection 的保护。 <br>

2.3 扩展命令 <br>
AUTH (Authentication/Security Mechanism),认证与安全机制 <br>
ADAT (Authentication/Security Data),认证与安全数据 <br>
PROT (Data Channel Protection Level),数据通道保护层次 <br>
PBSZ (Protection Buffer Size),保护缓冲大小 <br>
CCC (Clear Command Channel),清空命令通道 <br>
MIC (Integrity Protected Command),完整性保护命令 <br>
CONF (Confidentiality Protected Command), 保密保护命令 <br>
ENC (Privacy Protected Command),私有性保护命令 <br>
一种新的返回类型(6yz)也被引入以保护返回值。 <br>
2.4 协议状态图 <br>
下图描述了在一个提高了安全性的FTP实现中认证和和授权的流程。方形的块 <br>
表示客户端需要发出的命令的状态，菱形的块表示服务器需要发出响应的状态。 <br>
,------------------, USER <br>
__| Unauthenticated |_________ <br>
| /| (new connection) | /| <br>
| `------------------' | <br>
| | | <br>
| | AUTH | <br>
| V | <br>
| / | <br>
| 4yz,5yz / 234 | <br>

|<--------< >------------->. | <br>
| / | | <br>
| _/ | | <br>
| | | | <br>
| | 334 | | <br>
| V | | <br>
| ,--------------------, | | <br>
| | Need Security Data |<--. | | <br>
| `--------------------' | | | <br>
| | | | | <br>
| | ADAT | | | <br>
| V | | | <br>
| / | | | <br>
| 4yz,5yz / 335 | | | <br>
`<--------< >-----------' | | <br>
/ | | <br>
_/ | | <br>
| | | <br>
| 235 | | <br>
V | | <br>
,---------------. | | <br>
,--->| Authenticated |<--------' | 当客户与服务器 <br>

| `---------------' | 完成了认证，如 <br>
| | | 果存在完整性就 <br>
| | USER | 必须对命令进行 <br>
| | | 完整性保护。CCC <br>
| |<-------------------' 命令可以用来放松 <br>
| V 这个限制。 <br>
| / <br>
| 4yz,5yz / 2yz <br>
|<--------< >------------->. <br>
| / | <br>
| _/ | <br>
| | | <br>
| | 3yz | <br>
| V | <br>
| ,---------------. | <br>
| | Need Password | | <br>
| `---------------' | <br>
| | | <br>
| | PASS | <br>
| V | <br>
| / | <br>
| 4yz,5yz / 2yz | <br>

|<--------< >------------->| <br>
| / | <br>
| _/ | <br>
| | | <br>
| | 3yz | <br>
| V | <br>
| ,--------------. | <br>
| | Need Account | | <br>
| `--------------' | <br>
| | | <br>
| | ACCT | <br>
| V | <br>
| / | <br>
| 4yz,5yz / 2yz | <br>
`<--------< >------------->| <br>
/ | <br>
_/ | <br>
| | <br>
| 3yz | <br>
V | <br>
,-------------. | <br>
| Authorized |/________| <br>

| (Logged in) | <br>
`-------------' <br>
3. 协议的安全问题及防范措施[AO99] <br>
3.1 防范反弹攻击(The Bounce Attack) <br>
a. 漏洞 <br>
FTP规范[PR85]定义了“代理FTP”机制,即服务器间交互模型。支持客户建立一个FTP控 <br>
制连接，然 <br>
后在两个服务间传送文件。同时FTP规范中对使用TCP的端口号没有任何限制，而从0－1 <br>
023的TCP端 <br>
口号保留用于众所周知的网络服务。所以，通过“代理FTP”，客户可以命令FTP服务器 <br>
攻击任何一 <br>
台机器上的众所周知的服务。 <br>
b. 反弹攻击 <br>
客户发送一个包含被攻击的机器和服务的网络地址和端口号的FTP“PORT”命令。这时客 <br>
户要求FTP <br>
服务器向被攻击的服务发送一个文件，这个文件中应包含与被攻击的服务相关的命令（ <br>
例 <br>
如:SMTP、NNTP）。由于是命令第三方去连接服务，而不是直接连接，这样不仅使追踪攻 <br>
击者变得 <br>
困难，还能避开基于网络地址的访问限制。 <br>
c. 防范措施 <br>
最简单的办法就是封住漏洞。首先，服务器最好不要建立TCP端口号在1024以下的连接。 <br>

如果服务 <br>
器收到一个包含TCP端口号在1024以下的PORT命令，服务器可以返回消息504([PR85]中定 <br>
义为“对 <br>
这种参数命令不能实现”)。 <br>
其次，禁止使用PORT命令也是一个可选的防范反弹攻击的方案。大多数的文件传输只需 <br>
要PASV命 <br>
令。这样做的缺点是失去了使用“代理FTP”的可能性，但是在某些环境中并不需要“代 <br>
理 <br>
FTP”。 <br>
d. 遗留问题 <br>
光控制1024以下的连接，仍会使用户定义的服务（TCP端口号在1024以上）遭受反弹攻击 <br>
。 <br>
3.2 有限制的访问(Restricted Access) <br>
a. 需求 <br>
对一些FTP服务器来说，基于网络地址的访问控制是非常渴望的。例如，服务器可能希望 <br>
限制来自 <br>
某些地点的对某些文件的访问（例如为了某些文件不被传送到组织以外）。另外，客户 <br>
也需要知道 <br>
连接是有所期望的服务器建立的。 <br>
b. 攻击 <br>
攻击者可以利用这样的情况，控制连接是在可信任的主机之上，而数据连接却不是。 <br>
c. 防范措施 <br>
c. 防范措施 <br>
在建立连接前，双方需要同时认证远端主机的控制连接，数据连接的网络地址是否可信 <br>
（如在组织 <br>
之内）， <br>
d. 遗留问题 <br>