单数据包授权全面提升安全系数

来源：51CTO.com 作者：Michael Rash/黄永兵出处：巧巧读书 2008-03-13 进入讨论组

无数软件、协议、复杂的内部互相依赖一起构成了一个系统，这样的话就很难保障任何一个特定的属性—特别是安全，甚至出现了专门加强安全的软件，如果你经验丰富还可以应付，但是不幸地的是在几乎所有的安全软件中也发现了漏洞，从防火墙到ssh协议，

例如：OpenSSH是由一些呆在世界各个角落安全意识好的开发者开发的，但是偶尔也会暴出一个远程攻击漏洞，这应该引起足够的注意，因为看起来安全目标是很难实现的，因此，支持深度防御，本文将探索作为下一代密码认证技术的单数据包授权的原理。

当一个攻击者悄悄试图攻击一个服务端软件的漏洞时，第一步是侦查；攻击者需要锁定一个目标，这个过程已经可以由nmap自动完成，因此创建一个有漏洞的目标系统列表非常容易，如果一个攻击者发现了一个你正在运行的服务器软件0day攻击程序，你肯定不想在这个列表中露面！端口碰撞和单数据包授权使用一个放置在默认删除位置的包过滤器配，同时，只对那些能通过一个被动机制证明它们的身份ip地址提供服务，默认情况下TCP/IP堆栈访问不需要通过这种被动方法认证远程ip地址，当用这种方法保护起来后，nmap甚至不能弄清楚服务器是否在运行，即使攻击者有0day攻击程序在手也不要紧。

本文是关于单数据包授权系列的第一部分，主要解释了单数据包授权的理论基础以及为什么它超过端口碰撞而成为下一代被动认证技术，下一篇文章将描述用fwknop进行实战演练提供单数据包授权来保护ssh服务进程。

端口碰撞介绍

端口碰撞是使用TCP和UDP数据包头中的端口字段进行通讯保护的第一代保护技术，正常地，这些协议用于封装应用程序层数据，但是数据包的序列中有许多端口的编码信息，这些数据包可以通过一个包捕获机制如libcap被监视，典型地，一般都有一个端口碰撞客户端和一个端口碰撞服务端，这里的客户端和服务端分别指的是发送和监视数据包的软件组件，客户端负责生成碰撞序列，服务端负责被动收集序列、重新配置包过滤器以允许连接到受保护的服务。

典型的端口碰撞场景是端口碰撞服务端配置一个包过滤器来阻止所有到服务的访问，如ssh，除非端口碰撞客户端发送一个特定的端口碰撞序列，例如：服务端需要客户端按顺序发送TCP SYN包到下面的端口：
23400
1001
2003
65501

如果服务端监视这个保护序列，包过滤器重新配置允许从发送它的ip地址发起的ssh连接，利用包过滤器提供的连接跟踪机制（如在Netfilter中的conntrack系统），一个ssh会话在初始化规则后超时移除保护服务器后仍能保持连接，端口碰撞序列可以被加密，在http://www.portknocking.org/有很多应用列表，下面用图来表达在工作中的端口碰撞，图1：

图1工作中的端口碰撞

端口碰撞限制

端口碰撞为限制对服务的访问提供了一些实实在在的好处，但是也隐藏着一些局限，首先，加密保护序列是非常重要的，这就意味着这几字节的信息必须被传输，对于对称加密系统，加密的数据至少与数据块大小一样（对于Rijndael对称加密是128 比特），对于非对称加密，加密的数据实际上将会更大。

例如，原始的ElGamal算法使用GnuPG加密数据时明文大小将变成双倍大小，即使GnuPG也利用压缩技术（相对明文的原始大小有时能减少密文的大小），典型的大尺寸的GnuPG密钥大小暗示密文消息最小尺寸也将好几百字节。

这对端口碰撞来说有重要的含义，在一个保护序列中的每个数据包仅能发送2字节信息，因为在TCP和UDP头的端口字段只有16比特宽，（假设在包头部的其他字段也不用于传输数据，但是，即使其他字段用于传输数据，仍然不能使用包载重量引起更多数据传输），因此，对于一个密文块，一个加密的序列必须包括至少B/(2*8)个数据包，这里的B是以比特为单位的块大小，当考虑一般速度和目前的网络可靠性后这还不算太坏，但是真正的问题是无次序的传递。

解密混乱的数据引起更多的混乱数据，因为在端口碰撞客户端和服务端之间的连接还没有一个意见，服务端对混乱数据的重新排序还无能为力。

数据包可能通过不同的路由器进行传输，它们中一些可能比较慢，因此，客户端必须凭借人为的机制尝试减少混乱传送的趋势：时间。通过在一个保护序列每个数据包中引入一个时间延迟，假定大约半秒，数据包抵达服务器的时候，数据包顺序通常能被维持，对于一个128比特大小的块，对应的端口碰撞序列是128/(2*8)=8个包，计算半秒的延迟在内，需要4秒传输这个序列，对于一个更大的消息，如那些用非对称加密的密文，数据传输速率就不够实用了。

介绍另外一个端口碰撞方案限制传输数据，它要保护一个重放攻击实际上很困难，任何一个都能能监视从客户端发送到服务端的保护序列，如果序列是通过NAT设备发送的这就是一个非常严重的问题，源ip允许通过在服务端的包过滤器扩展NAT地址，例如：如果端口碰撞客户端在一个RFC1918子网上，如10.10.1.0/24，端口碰撞服务器在一个远程仅能通过互联网访问的网络上，服务端必须允许访问NAT ip地址，任何在同一个子网上的客户端都具有同等级的访问权限，只要建立一个接受来自NAT地址的连接规则。

为解决重放问题已经对传统的端口碰撞技术做了许多改变，如使用S/Key样式哈希函数迭代和简单地修改加密密钥产生一个时效因子，但是，这些方法需要一些处于端口碰撞客户端和服务端的状态被维持，当涉及有多个用户后就不好进行维持了。

传统的端口碰撞局限性是它极容易由于第三方恶意程序破坏掉保护序列，仅需要通过欺骗一个传统从客户端发出的数据包放入碰撞序列，攻击者能在包上简单地设置与客户端一样的源地址和端口号，这个额外的数据包将破坏掉保护序列，因此服务端将不允许合法的客户端进行任何访问，尽管实际上做这种事情的人相对较少，主要问题是这样的攻击非常容易执行，所有需要的就是一个数据包，甚至攻击者不需要原始数据包路径。

最后，保护序列很容易被任何入侵检测系统（IDS）通过端口扫描检测到，入侵检测系统可以监视客户端和服务端之间的通讯，对加密保护序列特别有效，它倾向于比简单共享序列更长，对于一个IDS，端口碰撞看起来象一系列在相对较短的时间周期内从单个ip地址对多个端口的探测，这是对端口扫描最合适的定义了。