tcp/ip协议组中的安全问题

作者：默里希尔——新泽西(Murray Hill, New Jersey) AT&T Bell实验室07974

摘要

在我们广泛使用的tcp/ip协议组是在国防部的倡导下开发的。然而,协议中却含有相当数量与正确实现无关的安全缺陷。我们描述基于这些缺点上的多种攻击有：序列号欺骗，路由攻击，源地址欺骗，身份伪装。我们也介绍一些对这些攻击的防御，最后介绍以下广泛使用的防御如加密。

1.介绍

现在我们广泛使用的tcp/ip协议组[1][2]是在国防部的倡导下开发的，然而，因为主机通过源ip地址来验证，所以一些缺陷仍然存在。Berkeley的"r-utilities"[3]是一个值得关注的例子。很多其他的缺陷仍然存在，因为网络控制机制以及在特别的路由选择协议中只有少数或者根本没有身份证明。

在我们描述这些攻击的时候，我们假定攻击者或多或少的控制了接入互连网的一台计算机。这可能就是因为那台计算机自身防护机制的缺陷，或者它本身是台微型机，天生无防护。事实上，攻击者甚至可以得到系统管理员的权限。

1.1 讨论范围

我们不讨论协议本身的实现缺陷无关的问题，比如那些被用在互连网上的"worm"[4][5][6]。我们只讨论那些协议自身的一般问题。如你将看到的那样，细心的实现可以减少或防止这些问题的出现。我们讨论的一些协议起源于berkeley版的unix(R)操作系统，以及其他一般的互连网协议。

我们也不关心经典的网络攻击如：物理偷听，修改，注入信息等。我们只讨论那些因为协议问题，而被方便的利用或有利用可能的问题。

大多数情况下，我们不讨论具体出版商的协议。我们讨论berkeley协议的一些问题，因为他们事实上是许多商家的标准，并不仅仅是unix操作系统。

2.tcp序列号猜测

莫理斯[7]首次描述了一个或多个诱人的安全漏洞。简单的说，在没有得到服务器的任何回应的情况下，他利用tcp序列号请求构造了一个tcp包序列，这使得他可以欺骗一个局域网上的一个被信任的主机。

当前tcp连接的建立包括三次握手。客户选择并发送一个初始的序列号ISN C，服务器端承认他并发送服务器自身的序列号ISN S,然后客户端再承认他。通过这三个消息，数据传输可以开始了。交换过程可笼统的描述为：

C*S:SYN(ISN C) S*C:SYN(ISN S),ACK(ISN C) C*S:ACK(ISN S)

C*S:data或S*C:data

也就是说，为了会话的开始，C 必须首先监听ISN S(一个或多或少的随机数)。设想以下，如果一个入侵者 X通过某种方法预先知道ISN S，在这种情况下，他可能通过发送下列序列号来扮演信任机器I：

X*S:SYN(ISN X ) ,SRC = T S*T:SYN(ISN S ) ,ACK(ISN X ) X*S:ACK(ISN S ) ,SRC =T X*S:ACK(ISN S ) ,SRC = T,nasty - data

尽管消息S*T并非到达X ，X可以知道它的内容，因此可以发送数据。如果X 执行的这次攻击允许命令执行(如berkeley rsh服务器)，恶意的命令可能被执行。那么，怎样才能预先知道随机的ISN呢？在berkeley系统中，初始的序列号值每秒增长一个恒定的数值，有一半是每次连接开始的数值。这样，如果一方开始一个合法的连接并观察ISN S的使用情况，那么他可以计算，并通过高度的信任，在尝试下次连接时使用ISN S*。莫里斯指出那个回应消息S*T:SYN(ISN S ) ,ACK(ISN X )事实上不会在一个黑洞中消失，然而，真正的主机T将接受它并试图复位连接。这不算一个严重的障碍。莫里斯发现通过扮演服务器T 上的一个端口，并且洪水般的对它发送伪造的连接请求，它可能队列溢出,从而使S*T的消息可能丢失。作为选择，它可以等到T要么关掉服务进行常规维护，要么重起。

在这个tcp序列号攻击中的变量并不是莫里斯描述的，而是使用netstat[8]服务。在这个攻击中入侵者扮演的主机是被关掉。如果netstat在目标主机上可行，它可能提供可行的必要的序列号信息在另一个端口，这排除了所有必要的猜测。

防御很明显，攻击的钥匙是berkeley系统中相关的简单的初始序列号值的变化。tcp规范要求这变量被增加每秒的大致250,000次；berkeley却使用很慢的增长率。不管怎样，关键因素是间隔尺寸，而不是平均增长率。从4.2BSD中的128/秒到4.3BSD中的125000/秒的改变是没有意义的，尽管后者拥有2个具体增长率的因素。

(1),netstat协议是陈旧的，但是现在却仍然在一些互连网主机上出现。所关心的安全不是在排除之后。让我们思索一个计数器是否真实的工作在250000赫兹回有所帮助。为简单起见，我们不考虑发生在其他连接上的问题，仅仅考虑计数器的固定变化率。

为了了解一个当前的序列号，必须发送一个syn包，并收到一个回应如下：

X*S: SYN(ISN X ) S*X: SYN(ISN S ) ,ACK(ISN X ) (1)

引发下一个数据包的第一个欺骗包能立即跟着服务器的反应对探针包回答：

X*S: SYN(ISN X ) ,SRC = T (2)

在回应中序列号ISN S使用S*T:

SYN(ISN S ) ,ACK(ISN X )在发源信息(1)和服务器收到的信息(1)之间北唯一的确定。可这个数字正是在X和S之间的往返时间。这样，如果欺骗者能正确的测量出这个时间，就算一个4u-second的时钟也不能战胜这种攻击。往返时间怎样被正确测量的呢？如果我们假定稳定性很好，可以在10毫秒范围之内让它跳起来。

很明显，因特网不在很长时间里展示这方面的稳定性[9]，而往往是再短时间内很好。

(2),这样有ISN S 的2500不确定的可能值。如果一次花费5秒，那么为了测量往返时间，一个入侵者很可能在7500秒内取得合理的可能性，在一天内可以确定。更多的可预测的网络(比如：高质量)，或者正确的测量能够提高成功率，这是入侵者更喜欢的。很清楚，仅仅根据上面的文字，tcp的说明是不够的。

我们已经默认在目标主机上没有处理操作。事实上，当一些新的请求到达时，一些处理的确要发生。在处理中的变化数量很关键。在一个6MIPS的机器上，一个滴答--4 u-seconds--大约是25条指令。对精确被跟踪的指令线路是相当灵敏的。优先级高的中断或者一个稍微不同的TCB 分配序号将对下一个序列号的实际值有相当大的影响。这随机化的效果对目标有相当大的有利。应该注意的是，命令线路的可变性将花费更少的时间，因此增量的变化很少，所以速度快的机器更容易被攻击。当然，cpu速度在迅速的增加。

这里向序列号攻击提出另一种解决方案：

使增量随机化。必须小心使用足够的位；如果说仅仅低8位随机选中，并且间隔尺寸很粗糙，那么入侵者的工作因素只剩下乘以256了。一个合理的间隔尺寸增量和一个小的随机数发生器或者一个32位的发生器的组合更好。注意，很多的伪造的随级数发生器很容易倒转[10]。事实上，假定大多数这样的发生器通过它们的输出反馈，那么大多数敌人可以容易的计算出下一个被选中的“随机数”。一些复合型的技术承诺，用32位的发生器为例，单只有它的16位发出，暴力攻击能够在确定种子上成功。在每个增量中人们需要至少16位的随机数，或者更多来避免网络的探针，但是那可能留很少的位来警戒种子扫描，需要更多的研究和调查来确定合适的参数。

在当前，因特网短时期内可能没有稳定性，尤其在远距离连接方面。很遗憾网络的安全依靠的是低质量的服务。与其走这么多的弯路，到不如使用密码规则(或设备)的新一代ISN S简单。在电子密码模式[12]下数据加密标准[11](DES)通过一个简单的计数器作为输入，是作为ISN S源的一个吸引人的选择。

作为选择，数据加密标准能在没有额外计数器的输出反馈模式情况下使用，不管怎么说，我们必须细心使用钥匙。启动次数一天一次是不够的。对入侵者来说，关于重启次数的充分的信息是可利用的，因而可以暴力攻击。不过，如果重启次数用每个主机的私钥加密，那么计数器不会在任何合理的情况下被破解。

最初的序列号计数器执行不算问题，仅仅每次有连接时才需要新的序列号，单一的DES的软件实现都将足够了。在一个MIPS处理器上需要2.3毫秒的加密时间[13]。一个附加的防御措施是好的记录和报警机制。往返时间---攻击符合rfc主机的事项---的测量很可能通过icmp ping报文来实现。

"transponder"函数可以把众多的ping请求记录下来。另外，更实用的是，定时测量技术可以发现企图的tcp连接。这些连接十分的短暂，甚至还没完成syn处理。类似地，欺骗活动主机最终将产生不同类型的rst数据包。这些应该不会经常发生，应该记录下来。

3.路由的乐趣

路由机制和协议的滥用大概是最简单的可利用的基于协议的攻击。根据使用不同的路由协议，有多种攻击方法。一些攻击仅仅在一个远程主机进行身份验证时成功，别的可以用来为更大的攻击做准备。

有相当数量下面阐述的攻击可以通过迷惑主机或网关的路由表来实现拒绝服务。这些细节是渗透机制的必然结果，将不在重复描述。

3.1 源路由选择

如果可行，滥用的最简单的机制是ip源路由选择。假定为返回目标主机在tcp请求中使用路由与源路径相反选项，这样完全合法。如果连接请求方因为默认路径阻塞不通，而指定特定的路径，若一条不同的路径被指定，那么回答将不能到达请求方。然后攻击者可以随意选择包括主机所在网络上的信任主机地址在内所有源ip地址，这样，任何再这些机器上的信任都可以被攻击者利用。

防御这种攻击是很困难的的。最好的办法是让网关拒绝外来请求访问内部网的数据包。让以太网适配器选择接收自己的传输是不切实际的，这个特征依靠高层协议。此外，如果一个组织有两个互相信任的网络通过一个多组织的中枢网相连，那么这种方法将彻底失败。中枢网上的其他用户不可能达到局部网用户的信任度，或者也许它们对外部攻击的脆弱性更高。这样的有争议的拓扑应该在任何时候都被避开。

如果原路由消息出现，一个更简单的方法是拒绝预先授权的连接。这种推测是使用IP选项的极少的合法理由。

*以太网是赫罗克斯公司的注册商标。

比较通常的操作，只要信任的网关被列出，防御上的变化将是分析源路由并接受它。照那样，最终的网关为了把包传递给真正的目的地而被考虑进去。也许这种复杂的想法没有价值。一些协议(如：伯克利的rsh和rlogin)允许普通用户把信任延伸到远程主机或用户的组合。在这种情况下，单独的用户而不是整个系统可能被源路由攻击作为目标。可疑网关将不起作用，被欺骗的主机可能不在网关保护的安全域之内。

3.2 选路信息协议攻击

选路信息协议[15](RIP)用来在局部网络上传播路由信息，尤其是广播媒体。一般地，收到的信息将不被检查。这允许入侵者为了模仿特定主机，而对目标主机，或每个网关发送伪造的路由信息。这种最有可能的攻击将要求一个特定的未使用的主机路由，而不是一个网络。这使得所有发往那台主机的包被送到入侵者的机器上(整个网络的包转移可能太明显了，而模仿空闲工作站比较没有风险)。一旦这成功了，那些依赖地址证明的协议将有效地被危机到。

这攻击也能给攻击者产生更敏感，更严重，更有利的因素。假定攻击者声明一个到达活动主机或工作站的路由，那么所有发送那台主机的数据包将被发送到入侵者的机器上被检查或修改。接着他们不满足使用到达目的地的源IP地址选路，一个门外汉也会扑获口令和其他敏感性的数据。这种攻击方式是那些影响外部调用方面是唯一的。这样，目标主机上的一个用户就能被欺骗而泄露口令。大多数以前讨论的攻击是用来伪造一个源地址，这次聚焦在目标地址。

尽管防御RIP攻击和防御原路由攻击很相似，防御RIP攻击比防御源路由攻击容易一些。一个paranoid网关(能够过滤基于源地址和目的地址的网关)能够拦阻任何欺骗(包括tcp序列号攻击)，因为有危险的数据包将不能通过。但还有处理RIP问题的其他办法。

一种RIP问题防御措施是更仔细的检查它接受的路由信息。大部分情况下，没有必要给你自己的局部网增加新的路由。一个路由器能很容易的检测这种入侵尝试。不幸的是，一些实现为保留他们直接连接附属网络的信息依赖于它们自己的广播。大概想法是他们能使用网络在局部选路。当容错总的来说是好的想法的时候，这种技术的实际应用在很多情况下与冒险相比是低的。

能鉴别RIP数据包是很有用的，在没有廉价公钥签名的方案下，这对广播协议来说是很困难的。其实能实现，其实用性也是有限的。接受者仅仅能鉴别按次序向上被网关欺骗的直接发送者。即使本地路由器不实现防御机制，RIP攻击能带来另外的危险：在大范围内，伪造的路由入口是可见的。任何路由器(与主机相反)接收到这样的数据将重播它。多心的管理员几乎在网络的局部集任何地方都注意到了不规则。好的日志记录或许有用，但很难从路由的不稳定中分辨出真正的入侵，从而有可能导致网关崩溃。

*也许在不考虑协议的滥用情况下，在任何事件中允许普通用户扩展权限是错误的。但是，这超出了我们要讨论的范围。

3.3 外部网关协议

外部网关协议(EGP)[16]目的是核心网关和外部网关之间的通信。外部网关在获得相邻的协议之后，周期性的被核心网关选择。它用有关它提供的网络信息作回应。这些网络必须是这个独立系统的一部分。同样地，网关定期的向核心网关请求路由信息。数据除延迟延迟之外没有被正常发送。此外，在每个选择提供必须在回应中答复的序列号之后，入侵者更改路由是十分困难的。外部网关允许发送两个选择之间的自动更新。这也必须提供最后选择的序列号。因而干涉EGP会话是相当困难的。

一种可能攻击手段是模仿同一个独立系统的另外一个外部网关。这可能不会成功，因为核心网关可能拥有每个独立系统的网关列表。不过当前不做这样的检查。即使他们是，他们仅仅通过源ip地址就能鉴别了。

一种强力的攻击手段是在真实网关没开的情况下来请求网络的可达性。也就是说，如果网关G负责N的路由，并且G不在了，那么网关G*可以提供通向那个网络的路由。这样各种各样的机制都允许口令俘获。防御这样的攻击是不合实际的(并且也很有局限);外部网关必须和核心网关在同一个网络上。

这样，入侵者需要破坏的不仅仅是任何主机，而是一个直接接在核心网络的网关或者主机。

与攻击tcp类似，还可以尝试一种序列号攻击。困难在于预测核心网关当前正在使用的序列号。对tcp来说，我们可以通过探测信息来确定任何连接。而对于EGP仅仅一少部分主机能和核心网关通话。(更准确的说，尽管当前这种检查还没有实现，核心网关仅仅只能和一些特定的主机通信。)，这使得很难为这样的攻击得到原始数据。

3.4 因特网控制信息协议

因特网控制信息协议(ICMP)[17]是tcp/ip协议组的一个基本网络管理工具。他好象拥有很丰富的滥用潜力。出人意料的是，ICMP攻击却十分困难。而且有很多可以被利用的漏洞，第一，最明显的是ICMP重定向报文，它被网关用来为主机提供好的路由。这样，它能象RIP一样被滥用。复杂性是重定向报文必须约束在一个特定存在的连接上。它不能被用来给主机的路由表进行主动的变化。此外，重定向仅仅在限定的拓扑范围内适用。它们也许仅仅在沿路通往开始主人的第一个网关被发送。后续的网关不可以事先告诉那个主机，也不可以使用ICMP重定向来控制其他网关。

设想以下，入侵者已经攻破一个对目标主机来说可利用的次要网关，而不是基本网关。(可能他能够攻破一个目标主机网络上的一台普通主机，并声称该普通主机是一个网关)，进一步假定入侵者想通过有危险的次要网关给信任主机设置一个错误的路由。接下来的顺序如下：向目标主机发送一个错误的TCP打开包，声称来自T，目标主机将通过安全的基本网关选路，并回答自己的打开包。当这被传送的时候，一个错误的重定向可能被发送，声称自己来自基本网关，并咨询伪连接。这包将看起来是合法的控制信息，因此，它包含的选路变化将被接受。目标主机使这变为整体路由表，而不是每个连接隐藏的路由，入侵者可以继续哄骗主机T。

一些主机在TCP重定向报文上不实行有效的检查。在这种情况下，这攻击的影响和基于RIP的攻击相似。

另外，ICMP也可以被用来进行拒绝服务攻击。个别的报文如目标不可达以及超时可以用来重置目前的连接。如果入侵者知道TCP 连接的本地及远端端口号，将生成该连接的ICMP 报文。有时这样的信息可以通过NETSTAT服务来实现。一个更普遍的拒绝服务攻击是发送伪造的子网掩码回应报文。无论一些主机是否查询或否，它们将接受该报文，一个错误的报文能有效的阻塞目标主机的所有连接。

大部分的ICMP攻击的防御对少数偏执狂来说是很容易的。如果主机很细心的确定一个报文和一个特定的连接相关，大部分攻击将不会成功。就TCP来说，这包括确定ICMP包在返回包的一部分中的似是而非的序列号。这些攻击对UDP来说不那么适用。

这样的攻击可能很严重，所以重定向攻击的防御应该慎重。也许，最好的主意是把路由的变化限定在指定的连接。整体路由表应该不作为对ICMP 的重定向而被修改。最终，在今天的环境中考虑ICMP 的重定向很有用。通过一个或多个网关到外面仅仅在局域网有用。但是，完全控制和纠正局部路由信息是相当容易的。从中心网关到外部网关的重定向报文是十分重要的，因为它允许局部网关只知道因特网的部分信息。不过，这样的使用被拒绝承认。

如果回应包仅仅在适当的时候被重视，那么子网掩码攻击能被防止。一般来说，主机只在启动和允许查询时才想看到这样的报文。旧的回应或者主动的回应应该拒绝。对真正的子网掩码查询的伪造回答几乎没有什么防御，典型地发出这样查询的主机几乎没有为了使回应得到确认的资源。如果真实的回应每被入侵者阻塞，目标主机将收到多个回应。为了保证全部回应都一致的检查，也将注意管理员的错误。

4 "Authentication"服务器

象选择基于地址的证明一样，一些实现使用Authentication服务器。

想知道客户身份的服务器可以和客户主机的Authentication服务器7联络。并向它查询拥有特殊连接的用户信息。这种方法比简单的基于地址的证明更安全，它不在攻击者控制下使用第二个TCP连接。这样，它可以避免序列号攻击和源路由攻击。不过，还是有危险。

首先，很明显并不是所有主机都能使用Authentication 服务器。如果客户主机不安全，用户是不是所要求的并不是很关心，回应不能被信任。第二，证明信息本身能被路由表攻击所危及安全。如果RIP被用来更改怎样到达一些主机的目标建议，证明查询将依赖相同的更改选路数据。最终，如果目标主机不在，TCP序列号攻击上的变化将被利用。在服务器向推测的证明主机发送TCP打开请求之后，攻击者能完成打开序列号，并发送假的回应。如果目标主机运行一个netstat服务器，这将更简单。如同被说明的那样，netstat将在没必要猜测的情况下经常提供必要的序列号。

*实际上，这些程序现在是有用的，它们被用来作为超级管理工具使已掉线的TCP连接复位。

*另外，尤其是在ICMP初始路由变化没超时的情况下，这还有其他好处。作者已经了解RIP的不稳定性随着网关的崩溃将导致错误的ICMP重定向报文的情况。这些有永久的在其他主机上腐蚀路由表的影响。

*The Internet Activities Board当前不推荐证明服务器的实现[19]。不过由于安全问题，并没有决定。[5]。

*一个不明显的风险是假的证明服务器总是回应"NO"。这构成了拒绝服务攻击。想依赖另一个主机的服务器应该使用更加安全的防御方法如Needham-Schroeder规则[22][21][20]。TCP本身是不够的。

5.凶暴的入侵者

一些本身没有缺陷的协议然而容易被滥用。当提供服务的时候，英明的实现者将把这问题考虑进去。

5.1 "FINGER"服务

很多系统实现了FINGER 服务[23]，这服务将显示用户有用的信息如他们的全名，电话号码，办公室号码等等。不巧，这些数据给密码入侵者提供了有用的信息[24]。通过这样的服务，系统管理员将这数据发送出去。

5.2 电子邮件

也许电子邮件是因特网上最有价值的服务。然而，它却十分的脆弱。象正常的实现一样[25][26]，邮件服务器不提供证明机制。这给伪造信息敞开了大门。RFC822确实支持加密的标题，但是这没被广泛使用。(不过，参考RFC1040[27]电子邮件新加密标准提议的讨论)

5.2.1 POP

邮局协议POP[28]允许一个远程的用户获取存在中心服务器上的邮件。证明通过一个单一包括用户名和密码的指令实现。不过，在单一的指令中组合两者要求使用普通密码。并且，这样的口令更不怎么受欢迎。它们更容易被窃听或泄露等等。

很多站点采用过去的口令作为替代。用过去的口令，主机和用户可以利用的设备共同拥有一个秘钥。主机发出随机的口令，两边都加密这口令，用户传送回主机。随机之后，回应是唯一的，因而击败偷听者。并且，用户不知道口令--它被存在设备中--只有剥夺用户联机能力口令才能发送。

POP的最新版[30]，已经把用户名和口令分成了两个指令，这是很有用的。不过，它典型的使用伯克利机制，也为预证明的连接定义了可选择的机制。这变化性的安全风险在文件中清楚地被提起。

5.2.2 PCMAIL

PCMAIL协议[31]使用类似POP2的证明机制。在在主要的考虑中，PCMAIL更危险。它支持口令的修改。这请求需要未加密的新旧口令一起被传送。

*过去的口令首先被用做军事上的IEF(Identification Friend or Foe)系统[29]。

5.3 域名系统。

域名系统(DNS)[32][33]提供一个主机名到ip地址影射的分布式数据库。与dns适当操作连接的入侵者能进行多种攻击包括拒绝服务攻击和密码枚举。有相当数量的脆弱性。

在一些问题解决的实现中，对特殊用户进行序列号攻击是可行的。当目标用户试图连接一台远程主机时，攻击者能对目标主机的查询产生一个域名服务器的回应。这需要知道客户程序的udp使用的端口和查询所使用的DNS序列号。后者很容易实现，因为程序序列号是从0开始的。前者也可以通过netstat或者一些类似的命令来实现。

对域名服务系统和路由机制的综合攻击是危害很大的。入侵者实际上能截取从主机名到ip地址转换的所有请求，并提供一个另外机器的ip地址。这将允许入侵者侦察所有流通数据，并在需要的情况下建造好的口令集。正因为这个理由，域名服务器是高值的目标。充分准备的攻击者能够发现通过其他手段接管一台服务器是有用的，包括扰乱正在运行的机器或者物理性的妨碍它与因特网连接。没有网络防御反对建议域名服务器应只运行在高度安全的机器上的前者。后面的问题也许能通过在服务器回应上使用证明技术

谈到。

甚至正确运行的DNS能被一些侦察所使用。DNS的操作的正常方式是做具体的查询并收到具体的回应。不过，一个区域传输(AXFR)请求能下载整个数据库的部分。通过重复连接，一个名称空间的完全影射能被产生。这样的数据库存在潜在的安全风险。例如，如果入侵者知道主机或者操作系统的特别脆弱性，那么可以参考数据库找到所有这样的目标，这数据库的用途包括侦察。例如，特别的组织里机器的数字和类型能给出组织大小有用的数据，和为特定工程服务的资源。

幸好，域名系统包括“refused”的错误代码。这样的区域传输的权限限制明确的被认为是拒绝的合法理由。这代码应该被用做非二级服务器的区域传输请求，不巧，AXFR请求中没有提供证明机制。源地址证明是所能实现当中最好的。最近，马萨诸塞州理工学院设计出了对DNS扩展的兼容认证机制。

Hesiod名字服务器[34]使用Kerberos[35]券来认证查询和回应。查询的附加信息段中携带了一个加密的包括会话秘钥字段。只有Hesiod和客户知道的秘钥被用做计算查询和回应的加密校验和。另外，在信息段中这些校验和被发送。

5。4文件传输协议

文件传输协议(FTP)[36]本身没有缺陷，不过实现中的一些方面仍需要小心。

5.4.1 FTP认证

FTP通过注册名和密码的组合进行身份认证。如果人们关心的那样，简单的口令愈加不安全。越来越多的站点开始采用一次性口令。在FTP规范中都不排除这样的认证方法。然而，对用户命令回应“331”显示给用户是很关键的。这信息将可能包括挑战性。隐藏这个回应的FTP实现不能在这个模式下工作。如果这样的实现(或变的)普遍，有必要使用一个新的回应码来指出用户必须看的挑战性内容。

5.4.2匿名FTP

一个次要的问题是匿名FTP。当FTP不需要详细身份的情况下，匿名FTP是口头上的因特网传统的一个有用的部分。然而，它应该小心的实现。问题的一部分是所选用的实现技术。一些FTP 的实现需要目录树的部分复制生成。必须小心担保这些文件没有被危机安全，并且确保它们没有敏感性如密码等信息。

第二个问题匿名FTP 是真的匿名，并没有记录谁请求的什么信息。基于邮件的服务器将提供那样的数据。他们也提供有用技术如加载限制，后台传输等等。

5.5 简单网络管理协议

简单网络管理协议(SNMP)[37]最近为了方便网络管理而被定义。很明显，对该资源的访问必须被高度的保护。RFC阐述了该协议，但也允许空的认证服务，这是不好的想法。甚至只读模式也是很危险的。如果使用的管理信息库(MIB)[38]中包括序列号，它可以使目标主机受到netstat类型的攻击。(当前的标准版不存在，不过，MIB明确的声明是可扩展的)。

5.6 远程启动

现今两种协议被用做启动无盘工作站和网关，它们是使用小文件传输协议(TFTP)[40]的逆地址解析协议(RARP)和使用TFTP的BOOTP[41]。被启动的系统是诱人的目标。如果搅乱启动过程，那么将产生一个修改过保护机制的内核，因为它象网络那样依赖于以太网，拥有所有外在的脆弱性，所以基于RARP的启动更危险。可以通过担保启动机器使用随机的UDP端口号，适度的进行安全改进，否则，攻击者能模仿服务器并发送错误的数据包。BOOTP增加了一个包括4字节随机事务id的安全附加层。这能防止攻击者对重起的工作站发送错误的回应。这些数字随机是很关键的。这在充分保护的系统中是困难的，因而很少或者几乎不可能预测状态。当通过网关启动的时候应当小心。网络越是广泛，扮演的机会就越大。防护的最好方法是通常攻击者只有一次机会；被启动的系统不存在那样的状态。不过，如果在客户和标准服务器之间的会话被打断的情况下，将能发起更大规模的攻击。

6. 小型攻击

有些攻击太无足轻重以至于没必要提及，然而，完整却要求他们至少被注意到。

最近，主机暂时被大量的普通技术报告的ftp请求导致不能使用。如果这是有备的，它将被认为是成功的拒绝服务攻击。

6.1 局域网的脆弱性

一些局部网络，尤其是以太网络，很容易被偷听和欺骗。如果使用这些网络，应该严格控制物理访问。如果局域网的机器是不可靠机器所能访问的，那么信赖它是不明智的，除非有认证机制。

如果局部网络使用地址解析协议(ARP)，那么将有更多的主机欺骗的微妙手段可以被利用。特别地，与欺骗主机或者监听网络相比，拦截，修改，转发数据包变的无足轻重。

通过发起广播风暴进行拒绝服务攻击是可行的。有很多种这样实现的方法。如果网络上大多数或者全部主机都扮演网关的角色，那么实现是很容易的。攻击者可以向一个并不存在的主机广播一个定制的数据包，这样，每个主机一旦收到，将试图把他转交到适当的目的地。因为每个主机都要向目标主机发送一个ARP查询广播，所以单单这就能产生很大的流量。攻击者接着可以广播一个声明以太网地址是到达目标主机的适当方法的数据包。然后，每个可疑主机将重新发送那个伪造的数据包，同样它也将收到网络上很多其他可疑主机发送的数据包拷贝。

6.2 小文件传输协议

TFTP[40]允许文件在没有任何认证的情况下进行传输。这样，所有公共的可读文件都能访问。使空间尽可能小是实现者或者系统管理员的责任。

6.3 保留端口

源于伯克利的TCP和UDP有特定端口的概念。也就是说，端口号小于1024端口仅仅分配给特定进程了。这中限制可以作为认证机制的一部分。不过，TCP和UDP规范不包括这样的观念，在单用户计算机中也没有这样的观念。系统管理员在和这样的机器对话的时候从来不依赖伯克利认证机制。

7. 全面防御

到此为止，我们已经描述了对各种单个攻击的防御。许多技术是相当广泛的防御。全面防御不仅仅对这些攻击的防御，也可以对许多其他的攻击进行防御。

7.1 认证

许多记述的入侵成功是因为目标主机使用源地址认证，并且假定他是真实的。不幸的是，有很多充分的方法进行地址欺骗，这些技术几乎没有价值。从另一个角度看，这样的地址认证与使用S100的安全文件橱柜等同。它可以或多或少的减少诚实的外行人的尝试，但是它阻止不了稍微危险的人物进入。需要一些形式的加密认证机制，有几种可行的方法。

也许最有名的是十进制尼达姆规则[20][21][22]，它依赖每个主机和认证服务器共享的一个秘钥；希望进行连接的主机从认证服务器获取一个会话秘钥并把加密的译文发送给目标主机，对话结束时，两边都确信另一方的一致性。规则的译文包括私钥和公钥[43]加密体系。这样的方案是怎样和TCP/IP结合的呢？一个明显的回答是：使用他们，预认证的连接能安全地被实现，没有他们，将很危险；第二个回答是DNS提供认证机制的理想依据，因为它已经将必要的名称结构，庸余等等合并到内部。为了确认，发布的秘钥回应必须通过与/或加密认证。

如同大家关注的那样，前者在任何情况下都很必要，在一些情况下，必须小心使用秘钥加密整个会话。如果不这样攻击者可以通过早期的描述机制控制一个连接。

7.2加密

适当的加密能对大部分的在线攻击进行防御，但是加密设备很贵，经常很慢，管理起来困难，而且在普通的部门中并不常见。有几种不同的加密方法。每个都有它的好处和弱点。加密的所有优点远远超出了这篇文章的范围，有兴趣的读者可以参考Voydock和Kent[44]或者Davies和Price[45]。

连接层加密--在包离开主机时加密--是防止信息泄露很好的办法，它也可以拒绝物理入侵。比如进入以太网电缆的攻击者将不能注入伪造的数据包，同样，切断名称服务器的入侵者将不能扮演它。共享给定密码实体的数量决定网络的安全程度。典型地，秘钥发布中心将为每对通信的计算机分配秘钥。然而，连接层仍有一些缺陷。广播型数据包很难防御。在没有快速公钥加密系统的情况下，解码一个加密的广播型数据包意味着能够发送一个这样的数据包，从而可以扮演网络上的任何主机。此外，根据定义连接层加密不是端对端的。跨越网关通信的安全意味着信任网关，并且确信完全连接的互连网同样被保护。(后面的约束可以象军事部门一样加强管理)。如果没进行这样的约束，那样源路由攻击和RIP欺骗的攻击将成为可能。在安全域的入口可以配置Paranoid网关。这些可以拦截比如进来的RIP数据包或者源路由包。

许多DARPA网络使用连接层加密的形式。所有的全面防御网络(DDN)加强中继线使用DES加密，甚至不机密的通信。机密的通信使用更安全的加密系统[46]。然而，这些是比较容易保护的端对端线路。一种TCP/IP的多端连接加密设备是the Blacker Front End(BFE)[47]。BFE对主机来说象一个X.25 DDN接口，并且位于主机和真实的DDN线路之间。当它收到指定的新目的地请求时，它和访问控制中心(ACC)联系请求通过，并且向秘钥发布中心(KDC)请求秘钥。如果拒绝本地主机访问远程主机，将返回相应的诊断码。当KDC或者ACC不工作的情况下，和限定的目标集通信的特殊紧急模式时常被允许。许可检查在一定程度上能防御早期记述的DNS攻击。甚至如果主机被特定的目标主机误导，BFE将保证完全没有授权的主机不能收到敏感数据。也就是说，保证主机希望对一些主机发送的数据高度机密。DNS攻击可以误导主机去连接已被洞察的主机4.0.0.4，而不是1.0.0.1。如果4.0.0.4不是高机密的材料或者不允许和远程主机进行通信，那么连接尝试将失败。为了确认，拒绝服务攻击已经发生了。这样，在军事领域损失远远超出了信息泄露。

BFE使用ACC提供的转换表，把基本("RED")ip地址转换成加密后("BLACK")的地址。这能阻止多点连接加密机制的祸患，通信分析技术。

基于TCP层的端对端加密可以在忽略跳数或者连接质量的情况下，保持会话安全。这适用于集中网络管理应用程序或者其他的端对端传输。秘钥的发布和管理是一个更大的问题，因为包括很多的通信。此外，加密和解密是在初始化或者TCP处理的终端进行的，主机层的软件必须进行翻译。这意味着每个会话都要增加额外的开销。由于欺骗性注入的数据包可以饶过TCP校验和检查使它送到应用程序，端对端加密对拒绝服务攻击来说是脆弱的。可以通过端对端加密和连接层加密的组合来防止这问题。

一种诱人选择是加密TCP包的数据部分而不是TCP的头部。TCP校验和将在原文上计算，因而可以察觉虚假的包。不幸的是，这样的变更与其他的TCP实现相矛盾，不能在应用层透明的实现。

在忽略使用方法的情况下，加密通信的主要好处是它们所提供的认证机制。如果可以保证秘钥发布中心安全，发布秘钥的协议足够，相应的通信能力相应足够，则可以保证通过源主机IP地址进行认证。

这隐含的认证在高度危险的情况下很重要。路由攻击可以“接管”一个存在的连接。入侵者可以有效地阻断被掘乱机器的有效连接，并向远端发送危险的命令，并且翻译传送的数据包序列号来区分入侵。当然，应当注意，任何加密机制都不受干扰。时常，这是这样系统的最基本目标。

7.3 信任机制

假定TCP/IP是国防部协议组，值得询问黄皮书[48]和红皮书[49]标准在上面的描述中保护主机的程度。也就是说，假定目标主机(或网关)被评为B1或者更高。这些攻击还能成功吗？回答很复杂，依赖我们的假定，我们可以这样来回答。一般来说，被评为B2或更高的主机或路由器可以免疫这里描述的攻击，而C2系统容易受到影响。B1系统对这里的部分攻击有脆弱性，但不是全部。

为了明白TCP/IP在安全环境中怎样使用的问题，关于军事安全模型的简单指南是必要的。计算机系统的所有对象，比如文件或网络通道，和从它们输出的数据必须有标示它们中的敏感信息的标签。标签包括阶层性的(比如秘密，机密，高度机密)和无阶层的成分。主题例如在计算机系统中的处理被同样的标记。如果标签有更高或同样层次，并且如果在标签中包括所有无层次成分，那么主题将读取这个对象。换句话说，在文件中处理必须对信息有充分的清楚。同样，如果主题拥有更高或者同等水平并且主题的无层次成分包括主题的所有，那么主题将写入那个对象。也就是说，文件的敏感层必须至少和处理一样高。如果不这样，拥有高度清楚的程序可以向一个只能被低安全清楚的处理只读访问的文件写入机密的数据。这样的必然结果是对任何文件的读/写访问，它的安全必须和那个处理相匹配。这同样适用于进程通信层次的任何形式(比如：一个TCP虚拟线路)。两端必须有对等的标签。现在我们可以明白把这模型钳入TCP/IP协议组的方法。当进程创建一个TCP连接，连接被赋予进程的标签。这个标签在IP安全选项中被编码。远端的TCP必须担保收到的数据包中的标签与接收进程的标签匹配。我们假定TCP被主机处理，而不是前端处理器。在多种情况下，等候连接的服务器可以合法的运行。不过当举例显示连接的时候，必须强迫进程到连接请求包的层次。IP仍然使用安全选项。在不清楚的层次上的数据包将不能发送。如果连接被定为秘密传输，它将携带每分类的或者机密的通信，但它不能传输高度机密的数据。这样安全选项限制路由的选择。连接层的安全水平依赖于它本身固有的特性，以及使用的任何加密规则的力度，网络中主机层的的安全，甚至便利的定位。例如：位于潜水艇中的以太网电缆相对大学宿舍中的电缆相比是十分安全的。许多情况都有这些约束产生。首先，TCP层的攻击只能在攻击者的水平中实现穿透。也就是说，在忽略攻击使用哪种网络的情况下，在未定义层的攻击者只能实现目标系统未定义的权利。网关将拒绝带有危险性的数据包。基于任何形式的源地址认证也被拒绝。黄皮书要求系统提供安全的鉴定和认证手段。正象我们展示的那样，单单信赖ip地址是不够的。在B1情况时，当从一台机器传向另一台机器时，必须通过编码校验和来保护认证信息。认证服务器也存在问题，尤其在netstat允许的情况下，可以进行序列号欺骗攻击。这种攻击很容易和源路由组合起来进行交互式访问。另外，编码校验和能很好的提高安全度。B1水平的系统不能自动对路由攻击进行免疫。RIP欺骗能很容易的腐蚀路由表。如同看到的那样，这将允许入侵者捕获密码，甚至可能一些密码用在别的信赖系统中。为了确实，最初的渗透被安全标签所限制，但这并不能阻止将来通过这种手段捕获的信息的入侵。

另外，路由攻击也可以用做拒绝服务攻击。特别地，如果到达安全目标的路由被转换成使用不安全的连接，那么这两个主机将不能通信。这个改变将可能很快的被检测到，网关在不能路由的包中标记有安全问题的标签。在B2水平，路由控制信息的安全传输是必要的。相应的要求适用于其他的网络控制信息如ICMP报文。我们所描述的许多攻击都源自于信息服务器如netstat和finger。如果慎重的完成，这些将不会给我们意识中的直接穿透危险，它们时常表现在在一些秘密的通道中泄露信息。这样，许多B系统并不实现这样的服务。在实际的意识中，我们所描述的一些技术特性不能在军事领域内运用。管理规则[51]倾向于禁止危险性的连接。不清楚的人员不可能对包括高度机密的系统进行间接访问。这种规则很可能是任何人对计算机访问权限的正确描述。

8. 结论

通过分析，很多方面很明显。首先肯定的说，总体上依赖IP源地址进行认证是十分危险的。幸运的是，我们假定被穿透的系统自身没有错误，那么因特网将允许更深的访问。更精确的说，用户的认证信息必须使用数据敏感标签保护到一定程度。在当前红皮书的描述中，编码检查可以被忽略，但一般来说它们是必须的。该规则有一些例外。如果整个网络并且所有的组成部分(主机，网关，电缆等等)都物理性的被保护，并且如果所有操作系统都很安全，那么将没有什么危险。团体开始在超出智能水平的情况下开始接受这。伯克利手册[3]时常说明它的认证协议是很脆弱的，但最近严格的尝试(如：Kerberos[35])和SunOS 4.0的DES认证模式[52]更正了这些问题。Kerberos和SunOS 4.0也有他们的缺点，但是它们都比他们的前任好的多。最近，网络时间协议(NTP)[53]的扩展被提议使用编码校验和[54]。第二个大的问题是序列号攻击。如果协议依赖于序列号--大多数都是--它们预先不可推测是十分关键的。很值得努力担保序列号不被其他用户所知甚至本系统的其他用户。我们可以归纳为主机不应该无缘无故的发送信息。比如，finger服务器为所知道的用户提供信息比为所有用户提供信息安全。尽管那样，可能需要相应的审查机制。如果帐户不是最近被使用的，有必要拒绝提供最后登陆日期和其他的敏感信息。(从来不使用的帐号经常使用简单默认的密码，不经常使用的帐户经常被粗心的设定密码。)我们已经明白netstat可以被滥用。事实上，netstat和认证服务器的组合是使用标准因特网协议唯一很强的攻击。最后，网络控制机制是危险的，必须小心警惕。在大型的网络中静态的路由是不可行的，但是使用智能的默认路由和证实的端对端路由协议(如EGP)远没有基于广播的路由脆弱。

9. 感谢

Dave Presotto, Bob Gilligan, Gene Tsudik，尤其是Deborah Estrin 对草稿做了大量建议和改正。

*作者：默里希尔，新泽西07974600山路，美国电话电报公司贝尔实验室3c－536b房间

计算机通信评论(Computer Communication Review)再版, 19卷,第2, pp. 32-48,April 1989.

参考文献：

1. E.J. Feinler, O.J. Jacobsen, M.K. Stahl, C.A. Ward, eds. DDN

Protocol Handbook. DDN Network Information Center, SRI International, 1985.

2. Comer, D. Internetworking with TCP/IP : Principles, Protocols, and

Architecture. Prentice Hall, 1988

3. Computer Systems Research Group. UNIX User's Reference Manual (URM).

4.3 Berkeley Software Distribution Virtual Vax-11 Version. Computer Science

Division, Department of Electrical Engineering and Computer Science,

University of California, Berkeley. 1986.

4. Spafford, E.H. The Internet Worm Program: An Analysis. Purdue

Technical Report CSD-TR-823, Department of Computer Sciences Purdue

University, West Lafayette, IN. 1988

5. Seeley, D. A Tour of the Worm. Department of Computer Science,

University of Utah. 1988.

6. Eichin, M. and Rochlis, J. With Microscope and Tweezers: An

Analysis of the Internet Virus of November 1988. Massachussetts Institute of

Technology, 1988.

7. Morris, R.T. 1985. A Weakness in the 4.2BSD UNIX TCP/IP Software.

Computing Science Technical Report No. 117, AT&T Bell Laboratories, Murray

Hill, New Jersey.

8. Reynolds, J.K., and J. Postel. Assigned Numbers. RFC 990, 1986

9. Mills, D.L. Internet Delay Experiments, RFC 889, 1983.

10. Blum, M. and Micali, S. ``How to Generate Cryptographically Strong

Sequences of Pseudo-Random Bits''. SIAM J. Computing, vol. 13, no. 4, pp.

850-864, Nov. 1984.

11. US Federal Information Processing Standards Publication (FIPS

PUB) 46, Data Encryption Standard, 15 January 1977.

12. US Federal Information Processing Standards Publication (FIPS

PUB) 81. DES Modes of Operation, 2 December 1980.

13. Bishop, M. An Application of a Fast Data Encryption Standard

Implementation. Technical Report PCS-TR88-138, Department of Mathematics

and Computer Science, Dartmouth College, Hanover, NH. 1988.

14. Mogul, J. ``Simple and Flexible Datagram Access Controls for

UNIX-based Gateways'', Proceedings, Summer USENIX, 1989, Baltimore, Maryland

(to appear).

15. Hedrick, C. Routing Information Protocol. RFC 1058, 1988.

16. Mills, D.L. Exterior Gateway Protocol Formal Specification. RFC 904,

1984.

17. Postel, J. Internet Control Message Protocol. RFC 792, 1981.

18. St. Johns, M. Authentication Server. RFC 931, 1985.

19. Defense Advanced Research Projects Agency, Internet Activities

Board. IAB Official Protocol Standards. RFC 1083, 1988

19. Postel, J. Private communication. 1989.

20. Needham, R.M. and Schroeder, M.D. ``Using Encryption for

Authentication in Large Networks of Computers''. Communications of the ACM,

vol. 21, no. 12, pp. 993-999, December 1978.

21. Denning, D.E. and Sacco, G.M. ``Timestamps in Key Distribution

Protocols'', Communications of the ACM, vol. 24, no. 8, pp. 533-536, August

1981.

22. Needham, R.M. and Schroeder, M.D. ``Authentication Revisited'',

Operating Systems Review, vol. 21, no. 1, p. 7, January 1987.

23. Harrenstien, K. NAME/FINGER Protocol, RFC 742, 1977.

24. Grampp, F.T. and Morris, R.H. ``UNIX Operating System Security'',

AT&T Bell Laboratories Technical Journal, vol. 63, no. 8, part 2, October,

1984.

25. Crocker, D. Standard for the Format of ARPA-Internet Text Messages. RFC

822, 1982.

26. Postel, J. Simple Mail Transfer Protocol. RFC 821, 1982.

27. Linn, J. Privacy Enhancement for Internet Electronic Mail: Part

I: Message Encipherment and Authentication Procedures. RFC 1040, 1988.

28. Butler, M.; Postel, J.B.; Chase, D.; Goldberger, J.; Reynolds,

J.K. Post Office Protocol - Version 2. RFC 937, 1985.

29. Diffie, W. ``The First Ten Years of Public Key Cryptography''.

Proc. IEEE, vol. 76, no. 5, pp. 560-577, May 1988.

30. Rose, M. Post Office Protocol - Version 3. RFC 1081, 1988

31. Lambert, M.L. PCMAIL: A Distributed Mail System for Personal Computers.

RFC 1056, 1988

32. Mockapetris, P. Domain Names - Concepts and Facilities. RFC 1034, 1987.

33. Mockapetris, P. Domain Names - Implementations and Specifications. RFC

1035, 1987.

34. Dyer, S.P. ``Hesiod'', Proceedings, Winter USENIX, 1988, Dallas, Texas.

35. Steiner, J.G, Neuman, C., Schiller, J.I. ``Kerberos: An

Authentication Service for Open Network Systems'', Proceedings, Winter

USENIX, 1988, Dallas, Texas.

36. Postel, J. File Transfer Protocol. RFC 959, 1985.

37. Case, J., Fedor, M., Schoffstall, J., and Davin, J. A Simple

Network Management Protocol. RFC 1067, 1988.

38. McCloghrie, K. and Rose, M. Management Information Base for

Network Management of TCP/IP based Internets. RFC 1066. 1988.

39. Finlayson, R.; Mann, T.; Mogul, J.; Theimer, M. Reverse Address

Resolution Protocol. RFC 903, 1984.

40. Sollins, K.R. The TFTP Protocol (Revision 2). RFC 783, 1981.

41. Croft, W.J.; Gilmore, J. Bootstrap Protocol. RFC 951, 1985.

42. Plummer, D.C. An Ethernet Address Resolution Protocol. RFC 826, 1982.

43. Diffie, W. and Hellman, M.E. ``New Directions in Cryptography.''

IEEE Transactions on Information Theory, vol. IT-22, no. 6, pp. 644-654.

44. Voydock, V.L. and Kent, S.T. ``Security Mechanisms in High-Level

Network Protocols''. ACM Computer Surveys, vol. 15, no. 2, pp. 135-171, June

1983.

45. Davies, D.W. and Price, W.L. Security for Computer Networks: An

Introduction to Data Security in Teleprocessing and Electronic Funds

Transfer. Wiley. 1984.

46. Defense Communications Agency. Defense Data Network Subscriber Security

Guide. 1983.

47. ``Blacker Front End Interface Control Document'', in DDN Protocol

Handbook. DDN Network Information Center, SRI International, vol. 1, 1985.

48. DoD Computer Security Center. DoD Trusted Computer System

Evaluation Criteria, 1983, CSC STD-001-83.

49. National Computer Security Center. Trusted Network Interpretation of the

Trusted Computer System Evaluation Criteria. NCSC-TG-005, Version 1, July

31, 1987.

50. St. Johns, M. Draft Revised IP Security Option. RFC 1038, 1988.

51. DoD Computer Security Center. Technical Rationale Behind

CSC-STD-003-85: Computer Security Requirements, CSC-STD-004-83, 1983.

52. Taylor, B. and Goldberg, D. ``Secure Networking in the Sun

Environment''. Proceedings, Summer USENIX, 1986, Atlanta, Georgia.

53. Mills, D.L. Network Time Protocol (Version 1) Specification and

Implementation. RFC 1059, 1988.

54. Mills, D.L. Mailing list message <8901192354.aa03743@Huey.UDEL.EDU>,

January 19, 1989.