概述:
=====
最近有一类新型的网络DoS攻击漏洞被人们发现, 这些属于同一组攻击类型的漏洞已被命名为＂Naptha＂. ＂Naptha＂实际上是TCP/IP堆栈以及网络应用程序在处理TCP连接状态实现上的弱点.
受影响系统:
===========
参见测试产品列表:
http://razor.bindview.com/publish/advisories/adv_list_NAPTHA.html
漏洞影响:
=========
通过创建大量的TCP连接并使它们保持在某些特定状态，某些应用程序甚至是操作系统自身会消耗大量的资源，直至出错或者崩溃。过去，以这种方式来攻击TCP连接并没有被广泛使用，因为这也会显著地消耗攻击者的系统资源。然而，＂Naptha＂的改进之处就在于它可以很容易的对目标进行攻击，而攻击者这一方只会有很少的一点资源耗费。
背景知识∶
=========
DoS （Denial of Service）
拒绝服务攻击是用来显著降低系统提供服务的质量或可用性的一种有目的行为。
DoS-RS（Resource Starvation）
资源耗尽是一种类型的拒绝服务攻击。这里我们要区分一下＂攻击＂与＂显著的安全问题＂的区别。如果攻击者拥有足够的网络资源，对于DoS-RS攻击来说，任何系统都是有弱点的。真正让DoS-RS成为安全问题的一种方法是要让被攻击目标耗费比攻击者多得多的系统资源。这种在资源耗费级别上的显著不同才说明这是一个安全漏洞。
DoS-RS-TCP_STATE
操作系统内核会为每一个TCP连接保存一条记录。大量的连接将要求更多的内存以及CPU处理时间。因此理论上来说，一台拥有大量的内存，快速的处理器，和性能优良的操作系统的主机上的用户，只须简单地使用一些标准程序例如TELNET(发起大量连接)就可以攻击那些配置较差的系统。然而，在发起攻击的系统上也会耗费大量的系统资源，因此这通常并不会被认为是一种严重的安全问题。
如果一个攻击程序直接使用一些网络API，例如Berkeley套接字来发动攻击，将更有效也更危险。但通常这仍然不足以对目标主机腹成严重的安全威胁。
细节描述∶
=========
＂Naptha＂是一个有效的＂DoS-RS-TCP_STATE＂攻击的例子。它不使用传统的网络API来设置TCP连接。不象真实的TCP/IP堆栈那样，它不保存任何连接状态的记录。它只根?发给它的报文中的某些标志来进行响应。按照这种方法，它可以与目标主机建立成千上丌的连接，而与目标主机相比，攻击者只使用了很少的资源。使用这种方法，它可以对目标主机上的某个特定服务或TCP/IP堆栈自身造成真正的威胁。
下面是很多Naptha攻击中的几个例子∶
- Novell＇s Netware 5.0 （安装了SP1）
在对524端口建立3000个打开的连接后，系统锁死。系统所有的64M内存全被使用， CPU占用率达到%100。在停止攻击后12小时，连接仍然没有超时，系统也没有释放内存。
- FreeBSD 4.0-REL
在对ssh端口建立495个连接后，系统开始变得不稳定。由于每个连接都会fork一个守护进程的子进程，使得文件句柄很快被耗尽；系统报告＂too many open files in system＂.在大约30分钟后，连接开始超时，系统再次变得不稳定。
?
- Windows 2000
Windows 2000好像不受影响
参见测试产品列表:
http://razor.bindview.com/publish/advisories/adv_list_NAPTHA.html
Naptha工作原理:
===============
这一节的目的是讲述Naptha攻击的基本结腹，以便研究者可以验证我们所说的∶这样的攻击是可能的而且应当被相当认真的对待。当然以前在这方面已经有人做过一些研究，但还没有人发布类似的工具，它能使目标主机处在任一TCP连接状态（例如＂ESTABLISHED＂和＂FIN-WAIT-1＂等等），并可以使用一种多组件体系（允许在不同的主机上发起攻击）Naptha攻击可以通过分布式的方式来实现，因此使其变得更为有效。
攻击的第一部分要从一个伪造IP地址的所有可能端口向目标主机发送一系列的SYN报文。如果考虑单个攻击的情况，这个程序在同一主机上的多份拷贝可以同时被用来攻击不同的主机，也可以使用多台主机攻击单一目标。这听起来像是一种SYN Flood攻击，实际上并不是这样的。
第二部分需要运行在刚才伪造IP所在的局域网中。程序首先确保路由器的ARP表中有这台＂幻影主机＂(就是伪造的IP地址)。接下来，它会在混杂模式下监听从目标主机发往＂幻影主机＂的报文。这个程序会使用合
的标志以及序列号来响应那些报文。例如，它监听SYN/ACK报文，然后发送ACK报文，它也可以在报文中设置FIN标志，以便让连接处于FIN-WAIT-1状态。为了让连接存活时间更长，它也会监听某些定期发送的数据报文或者＇keep alive＇(确保连接存活)的报文，然后发送ACK报文回复。单个攻击程序可以同时攻击多个目标主机。
使用＇幻影主机＇是为了让跟踪攻击来源更为困难。
为了实现在资源耗费上的不对等，这样的攻击程序必须不能在攻击主机的内核中设置任何的TCB(传输控制块)。这有助于保证攻击者的活动不会收到攻击主机系统内核限制的束缚。另外客户端程序进程的数目应当不会随着连接数目的增加而增加。Naptha通过完全避免使用系统的TCP/IP堆栈而是自己腹造raw socket报文来实现上述要求。事实上，在进行高速的Naptha攻击时，所受到的限制更多的是来自网络带宽而不是攻击主机的资源。
Naptha也支持对连接速率的限制。在某些情况下，连接可以被高速建立，目标主机上会被快速打开成千上丌的端口，在连接超时之前所有的资源就被耗尽了。而在另一种情况下，连接也可以以一种较慢的速率建立，以避免触发目标主机上（或防火墙）的SYN Flood保护机制。
为了完成有效的DoS,所要求建立连接的数目以及速率依赖于一些因素。不同的操作系统对连接数目，打开文件数目，进程使用内存等有不同的限制。不同端口上运行的应用程序也有自己的资源控制等级。有些应用程序为每一个连接开启一个新进程来处理。系统的CPU速度以及内存大小也影响它对Naptha攻击的抵抗能力。最后网络本身也会对攻击造成一定影响。
总之，Naptha攻击表明了资源耗尽攻击的严重性。针对这个问题，还没有一个显而易见的解决方法。下面的部分只是提供了一些改进的思路。
推荐做法:
=========
不幸的是，大部分的万商都受到Naptha攻击的影响。在一些万商提供补丁之前，除了通常的安全策略，我们能做的事情并不多。这里有我们推荐的一些做法∶
1. 如果你怀疑某个系统(特别是可公开访问的系统)容易变成Naptha攻击的牺牲品，请限制上面运行服务的数量。
2. 通过防火墙来限制对系统暴露在外的TCP端口的访问。在需要公开访问的系统，这可能是不现实的，但也应当尽可能的进行限制。
3. 确保所有的边界设备(例如路由器和防火墙)被正确的配置。你应当同时进行对内和对外的过滤。
4. 在Unix系统上，使用inetd或者 Dan Bernstein的tcpserver (http://cr.yp.to/ucspi-tcp.html)来限制开启守护进程的数目。这并不会防止特定守护进程的过载，然而这可以防止守护进程拖垮整个服务器。这也将允许服务器从攻击中恢复正常。在那些可以调节TCP超时以及keepalive参数的系统上，下列做法可以允许系统更快的恢复正常（假设Naptha攻击没有使系统崩溃）。例如，在Linux 2.2内核中设置下列TCP keepalive参数∶
# cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
# cat /proc/sys/net/ipv4/tcp_keepalive_probes
9
# cat /proc/sys/net/ipv4/tcp_max_ka_probes
5
# echo 30 /proc/sys/net/ipv4/tcp_keepalive_time
# echo 2 /proc/sys/net/ipv4/tcp_keepalive_probes
# echo 100 /proc/sys/net/ipv4/tcp_max_ka_probes
上面的例子中，keepalive 时间从2个小时变成30秒，keepalive探测的数目也从9调节成2。也可以将发送探测的最大数目从5改成100。这些数值都只是我们给出的一些建议值，在实际应用时几乎可以肯定的说应加以调整。
6. 用来演示这种攻击的程序只通过CERT提供给系统万商进行测试。程序代码不会公开发布。然而下列的信息可以作为＇指纹＇来使IDS系统可以检测我们的测试代码。请注意∶代码自身可以很容易得被修改以该改变此指纹，因此，这个指纹并不是一个检测Naptha攻击的可靠方法。
IP:
TOS = Low Delay
ID = 413
TCP:
FLAGS = SYN
SEQ ID = 6060842
WINDOW = 512
Snort (http://www.snort.org) 是一种免费的＂轻量级＂的IDS.下面是针对Naptha的Snort规则∶
alert tcp any any any any (flags:S; seq: 6060842; id: 413; msg: ＂ Naptha DoS Attack, see http://razor.bindview.com//publish/advisories/adv_NAPTHA.html＂;)
参考资料:
=========
CVE:
The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2000-1039 to this issue. This is a candidate for inclusion in the CVE list
