搜索
 找回密码
 加入

DDoS攻击原理

ctgwglzc 2007-3-10 00:28:06 1782
分布式拒绝服务攻击(DDoS)是目前黑客经常采用而难以防范的攻击手段。本文从概念开始详细介绍了这种攻击方式,着重描述了黑客是如何组织并发起的DDoS攻击,结合其中的Syn Flood实例,您可以对DDoS攻击有一个 更形象的了解。最后作者结合自己的经验与国内网络安全的现况探讨了一些防御DDoS的实际手段。
DDoS攻击概念
    
  DoS的攻击方式有很多种,最基本的DoS攻击就是利用合理的服务请求来占用过多的服务资源,从而使合法用户无法得到服务的响应。

  DDoS攻击手段是在传统的DoS攻击基础之上产生的一类攻击方式。单一的DoS攻击一般是采用一对一方式的,当攻击目标CPU速度低、内存小或者网络带宽小等等各项性能指标不高它的效果是明显的。随着计算机与网络技术的发展,计算机的处理能力迅速增长,内存大大增加,同时也出现了千兆级别的网络,这使得DoS攻击的困难程度加大了-目标对恶意攻击包的"消化能力"加强了不少,例如你的攻击软件每秒钟可以发送3,000个攻击包,但我的主机与网络带宽每秒钟可以处理10,000个攻击包,这样一来攻击就不会产生什么效果。
  这时侯分布式的拒绝服务攻击手段(DDoS)就应运而生了。你理解了DoS攻击的话,它的原理就很简单。如果说计算机与网络的处理能力加大了10倍,用一台攻击机来攻击不再能起作用的话,攻击者使用10台攻击机同时攻击呢?用100台呢?DDoS就是利用更多的傀儡机来发起进攻,以比从前更大的规模来进攻受害者。

  高速广泛连接的网络给大家带来了方便,也为DDoS攻击创造了极为有利的条件。在低速网络时代时,黑客占领攻击用的傀儡机时,总是会优先考虑离目标网络距离近的机器,因为经过路由器的跳数少,效果好。而现在电信骨干节点之间的连接都是以G为级别的,大城市之间更可以达到2.5G的连接,这使得攻击可以从更远的地方或者其他城市发起,攻击者的傀儡机位置可以在分布在更大的范围,选择起来更灵活了。
  被DDoS攻击时的现象

被攻击主机上有大量等待的TCP连接
网络中充斥着大量的无用的数据包,源地址为假
制造高流量无用数据,造成网络拥塞,使受害主机无法正常和外界通讯
利用受害主机提供的服务或传输协议上的缺陷,反复高速的发出特定的服务请求,使受害主机无法及时处理所有正常请求
严重时会造成系统死机
  攻击运行原理


如图一,一个比较完善的DDoS攻击体系分成四大部分,先来看一下最重要的第2和第3部分:它们分别用做控制和实际发起攻击。请注意控制机与攻击机的区别,对第4部分的受害者来说,DDoS的实际攻击包是从第3部分攻击傀儡机上发出的,第2部分的控制机只发布命令而不参与实际的攻击。对第2和第3部分计算机,黑客有控制权或者是部分的控制权,并把相应的DDoS程序上传到这些平台上,这些程序与正常的程序一样运行并等待来自黑客的指令,通常它还会利用各种手段隐藏自己不被别人发现。在平时,这些傀儡机器并没有什么异常,只是一旦黑客连接到它们进行控制,并发出指令的时候,攻击傀儡机就成为害人者去发起攻击了。
  有的朋友也许会问道:"为什么黑客不直接去控制攻击傀儡机,而要从控制傀儡机上转一下呢?"。这就是导致DDoS攻击难以追查的原因之一了。做为攻击者的角度来说,肯定不愿意被捉到(我在小时候向别人家的鸡窝扔石头的时候也晓得在第一时间逃掉,呵呵),而攻击者使用的傀儡机越多,他实际上提供给受害者的分析依据就越多。在占领一台机器后,高水平的攻击者会首先做两件事:1. 考虑如何留好后门(我以后还要回来的哦)!2. 如何清理日志。这就是擦掉脚印,不让自己做的事被别人查觉到。比较不敬业的黑客会不管三七二十一把日志全都删掉,但这样的话网管员发现日志都没了就会知道有人干了坏事了,顶多无法再从日志发现是谁干的而已。相反,真正的好手会挑有关自己的日志项目删掉,让人看不到异常的情况。这样可以长时间地利用傀儡机。

  但是在第3部分攻击傀儡机上清理日志实在是一项庞大的工程,即使在有很好的日志清理工具的帮助下,黑客也是对这个任务很头痛的。这就导致了有些攻击机弄得不是很干净,通过它上面的线索找到了控制它的上一级计算机,这上级的计算机如果是黑客自己的机器,那么他就会被揪出来了。但如果这是控制用的傀儡机的话,黑客自身还是安全的。控制傀儡机的数目相对很少,一般一台就可以控制几十台攻击机,清理一台计算机的日志对黑客来讲就轻松多了,这样从控制机再找到黑客的可能性也大大降低。
  黑客是如何组织一次DDoS攻击的?
    
  这里用"组织"这个词,是因为DDoS并不象入侵一台主机那样简单。一般来说,黑客进行DDoS攻击时会经过这样的步骤:

  1. 搜集了解目标的情况

  下列情况是黑客非常关心的情报:
被攻击目标主机数目、地址情况
目标主机的配置、性能
目标的带宽
  对于DDoS攻击者来说,攻击互联网上的某个站点,如http://www.WWWW.com,有一个重点就是确定到底有多少台主机在支持这个站点,一个大的网站可能有很多台主机利用负载均衡技术提供同一个网站的www服务。以yahoo为例,一般会有下列地址都是提供http://www.WWW.com服务的:
  66.218.71.87
  66.218.71.88
  66.218.71.89
  66.218.71.80
  66.218.71.81
  66.218.71.83
  66.218.71.84
  66.218.71.86

  如果要进行DDoS攻击的话,应该攻击哪一个地址呢?使66.218.71.87这台机器瘫掉,但其他的主机还是能向外提供www服务,所以想让别人访问不到http://www.WWW.com的话,要所有这些IP地址的机器都瘫掉才行。在实际的应用中,一个IP地址往往还代表着数台机器:网站维护者使用了四层或七层交换机来做负载均衡,把对一个IP地址的访问以特定的算法分配到下属的每个主机上去。这时对于DDoS攻击者来说情况就更复杂了,他面对的任务可能是让几十台主机的服务都不正常。

  所以说事先搜集情报对DDoS攻击者来说是非常重要的,这关系到使用多少台傀儡机才能达到效果的问题。简单地考虑一下,在相同的条件下,攻击同一站点的2台主机需要2台傀儡机的话,攻击5台主机可能就需要5台以上的傀儡机。有人说做攻击的傀儡机越多越好,不管你有多少台主机我都用尽量多的傀儡机来攻就是了,反正傀儡机超过了时候效果更好。

但在实际过程中,有很多黑客并不进行情报的搜集而直接进行DDoS的攻击,这时候攻击的盲目性就很大了,效果如何也要靠运气。其实做黑客也象网管员一样,是不能偷懒的。一件事做得好与坏,态度最重要,水平还在其次。

  2. 占领傀儡机

  黑客最感兴趣的是有下列情况的主机:

链路状态好的主机
性能好的主机
安全管理水平差的主机
  这一部分实际上是使用了另一大类的攻击手段:利用形攻击。这是和DDoS并列的攻击方式。简单地说,就是占领和控制被攻击的主机。取得最高的管理权限,或者至少得到一个有权限完成DDoS攻击任务的帐号。对于一个DDoS攻击者来说,准备好一定数量的傀儡机是一个必要的条件,下面说一下他是如何攻击并占领它们的。
  首先,黑客做的工作一般是扫描,随机地或者是有针对性地利用扫描器去发现互联网上那些有漏洞的机器,象程序的溢出漏洞、cgi、Unicode、ftp、数据库漏洞…(简直举不胜举啊),都是黑客希望看到的扫描结果。随后就是尝试入侵了,具体的手段就不在这里多说了,感兴趣的话网上有很多关于这些内容的文章。

  总之黑客现在占领了一台傀儡机了!然后他做什么呢?除了上面说过留后门擦脚印这些基本工作之外,他会把DDoS攻击用的程序上载过去,一般是利用ftp。在攻击机上,会有一个DDoS的发包程序,黑客就是利用它来向受害目标发送恶意攻击包的。
  3. 实际攻击

  经过前2个阶段的精心准备之后,黑客就开始瞄准目标准备发射了。前面的准备做得好的话,实际攻击过程反而是比较简单的。就象图示里的那样,黑客登录到做为控制台的傀儡机,向所有的攻击机发出命令:"预备~ ,瞄准~,开火!"。这时候埋伏在攻击机中的DDoS攻击程序就会响应控制台的命令,一起向受害主机以高速度发送大量的数据包,导致它死机或是无法响应正常的请求。黑客一般会以远远超出受害方处理能力的速度进行攻击,他们不会"怜香惜玉"。

  老到的攻击者一边攻击,还会用各种手段来监视攻击的效果,在需要的时候进行一些调整。简单些就是开个窗口不断地ping目标主机,在能接到回应的时候就再加大一些流量或是再命令更多的傀儡机来加入攻击。
  DDoS攻击实例 - SYN Flood攻击
    
  SYN-Flood是目前最流行的DDoS攻击手段,早先的DoS的手段在向分布式这一阶段发展的时候也经历了浪里淘沙的过程。SYN-Flood的攻击效果最好,应该是众黑客不约而同选择它的原因吧。那么我们一起来看看SYN-Flood的详细情况。

  Syn Flood原理 - 三次握手

  Syn Flood利用了TCP/IP协议的固有漏洞。面向连接的TCP三次握手是Syn Flood存在的基础。
TCP连接的三次握手


图二 TCP三次握手

  如图二,在第一步中,客户端向服务端提出连接请求。这时TCP SYN标志置位。客户端告诉服务端序列号区域合法,需要检查。客户端在TCP报头的序列号区中插入自己的ISN。服务端收到该TCP分段后,在第二步以自己的ISN回应(SYN标志置位),同时确认收到客户端的第一个TCP分段(ACK标志置位)。在第三步中,客户端确认收到服务端的ISN(ACK标志置位)。到此为止建立完整的TCP连接,开始全双工模式的数据传输过程。

Syn Flood攻击者不会完成三次握手


图三 Syn Flood恶意地不完成三次握手

  假设一个用户向服务器发送了SYN报文后突然死机或掉线,那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成),这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接,这段时间的长度我们称为SYN Timeout,一般来说这个时间是分钟的数量级(大约为30秒-2分钟);一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题,但如果有一个恶意的攻击者大量模拟这种情况,服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接,即使是简单的保存并遍历也会消耗非常多的CPU时间和内存,何况还要不断对这个列表中的IP进行SYN+ACK的重试。实际上如果服务器的TCP/IP栈不够强大,最后的结果往往是堆栈溢出崩溃---即使服务器端的系统足够强大,服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之小),此时从正常客户的角度看来,服务器失去响应,这种情况我们称做:服务器端受到了SYN Flood攻击(SYN洪水攻击)。  

下面是我在实验室中模拟的一次Syn Flood攻击的实际过程

  这一个局域网环境,只有一台攻击机(PIII667/128/mandrake),被攻击的是一台Solaris 8.0 (spark)的主机,网络设备是Cisco的百兆交换机。这是在攻击并未进行之前,在Solaris上进行snoop的记录,snoop与tcpdump等网络监听工具一样,也是一个很好的网络抓包与分析的工具。可以看到攻击之前,目标主机上接到的基本上都是一些普通的网络包。


     ? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes
     ? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes
     ? -> (multicast) ETHER Type=0000 (LLC/802.3), size = 52 bytes
     ? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes
192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]
192.168.0.210 -> 192.168.0.255 NBT Datagram Service Type=17 Source=ROOTDC[20]
192.168.0.247 -> 192.168.0.255 NBT Datagram Service Type=17 Source=TSC[0]
     ? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes
192.168.0.200 -> (broadcast) ARP C Who is 192.168.0.102, 192.168.0.102 ?
     ? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes
     ? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes
192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]
192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]
192.168.0.210 -> 192.168.0.255 NBT Datagram Service Type=17 Source=ROOTDC[20]
     ? -> (multicast) ETHER Type=0000 (LLC/802.3), size = 52 bytes
     ? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes
     ? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

…       


  接着,攻击机开始发包,DDoS开始了…,突然间sun主机上的snoop窗口开始飞速地翻屏,显示出接到数量巨大的Syn请求。这时的屏幕就好象是时速300公里的列车上的一扇车窗。这是在Syn Flood攻击时的snoop输出结果:
   …

127.0.0.178 -> lab183.lab.net AUTH C port=1352
127.0.0.178 -> lab183.lab.net TCP D=114 S=1352 Syn Seq=674711609 Len=0 Win=65535
127.0.0.178 -> lab183.lab.net TCP D=115 S=1352 Syn Seq=674711609 Len=0 Win=65535
127.0.0.178 -> lab183.lab.net UUCP-PATH C port=1352
127.0.0.178 -> lab183.lab.net TCP D=118 S=1352 Syn Seq=674711609 Len=0 Win=65535
127.0.0.178 -> lab183.lab.net NNTP C port=1352
127.0.0.178 -> lab183.lab.net TCP D=121 S=1352 Syn Seq=674711609 Len=0 Win=65535
127.0.0.178 -> lab183.lab.net TCP D=122 S=1352 Syn Seq=674711609 Len=0 Win=65535
127.0.0.178 -> lab183.lab.net TCP D=124 S=1352 Syn Seq=674711609 Len=0 Win=65535
127.0.0.178 -> lab183.lab.net TCP D=125 S=1352 Syn Seq=674711609 Len=0 Win=65535
127.0.0.178 -> lab183.lab.net TCP D=126 S=1352 Syn Seq=674711609 Len=0 Win=65535
127.0.0.178 -> lab183.lab.net TCP D=128 S=1352 Syn Seq=674711609 Len=0 Win=65535
127.0.0.178 -> lab183.lab.net TCP D=130 S=1352 Syn Seq=674711609 Len=0 Win=65535
127.0.0.178 -> lab183.lab.net TCP D=131 S=1352 Syn Seq=674711609 Len=0 Win=65535
127.0.0.178 -> lab183.lab.net TCP D=133 S=1352 Syn Seq=674711609 Len=0 Win=65535
127.0.0.178 -> lab183.lab.net TCP D=135 S=1352 Syn Seq=674711609 Len=0 Win=65535
… …       



这时候内容完全不同了,再也收不到刚才那些正常的网络包,只有DDoS包。大家注意一下,这里所有的Syn Flood攻击包的源地址都是伪造的,给追查工作带来很大困难。这时在被攻击主机上积累了多少Syn的半连接呢?我们用netstat来看一下:
  # netstat -an | grep SYN



192.168.0.183.9   127.0.0.79.1801     0   0 24656   0 SYN_RCVD
192.168.0.183.13   127.0.0.79.1801     0   0 24656   0 SYN_RCVD
192.168.0.183.19   127.0.0.79.1801     0   0 24656   0 SYN_RCVD
192.168.0.183.21   127.0.0.79.1801     0   0 24656   0 SYN_RCVD
192.168.0.183.22   127.0.0.79.1801     0   0 24656   0 SYN_RCVD
192.168.0.183.23   127.0.0.79.1801     0   0 24656   0 SYN_RCVD
192.168.0.183.25   127.0.0.79.1801     0   0 24656   0 SYN_RCVD
192.168.0.183.37   127.0.0.79.1801   0 0 24656 0 SYN_RCVD
192.168.0.183.53 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

…  



  其中SYN_RCVD表示当前未完成的TCP SYN队列,统计一下:

  # netstat -an | grep SYN | wc -l
  5273
  # netstat -an | grep SYN | wc -l
  5154
  # netstat -an | grep SYN | wc -l
  5267
  …..

  共有五千多个Syn的半连接存储在内存中。这时候被攻击机已经不能响应新的服务请求了,系统运行非常慢,也无法ping通。

  这是在攻击发起后仅仅70秒钟左右时的情况。

  DDoS的防范

  到目前为止,进行DDoS攻击的防御还是比较困难的。首先,这种攻击的特点是它利用了TCP/IP协议的漏洞,除非你不用TCP/IP,才有可能完全抵御住DDoS攻击。一位资深的安全专家给了个形象的比喻:DDoS就好象有1,000个人同时给你家里打电话,这时候你的朋友还打得进来吗?

  不过即使它难于防范,也不是说我们就应该逆来顺受,实际上防止DDoS并不是绝对不可行的事情。互联网的使用者是各种各样的,与DDoS做斗争,不同的角色有不同的任务。我们以下面几种角色为例:

企业网管理员
ISP、ICP管理员
骨干网络运营商

  企业网管理员

  网管员做为一个企业内部网的管理者,往往也是安全员、守护神。在他维护的网络中有一些服务器需要向外提供WWW服务,因而不可避免地成为DDoS的攻击目标,他该如何做呢?可以从主机与网络设备两个角度去考虑。

  主机上的设置

  几乎所有的主机平台都有抵御DoS的设置,总结一下,基本的有几种:

关闭不必要的服务
限制同时打开的Syn半连接数目
缩短Syn半连接的time out 时间
及时更新系统补丁
网络设备上的设置

  企业网的网络设备可以从防火墙与路由器上考虑。这两个设备是到外界的接口设备,在进行防DDoS设置的同时,要注意一下这是以多大的效率牺牲为代价的,对你来说是否值得。

  1.防火墙

禁止对主机的非开放服务的访问
限制同时打开的SYN最大连接数
限制特定IP地址的访问
启用防火墙的防DDoS的属性
严格限制对外开放的服务器的向外访问

  第五项主要是防止自己的服务器被当做工具去害人。

  2.路由器

以Cisco路由器为例


Cisco Express Forwarding(CEF)
使用 unicast reverse-path
访问控制列表(ACL)过滤
设置SYN数据包流量速率
升级版本过低的ISO
为路由器建立log server

  其中使用CEF和Unicast设置时要特别注意,使用不当会造成路由器工作效率严重下降,升级IOS也应谨慎。路由器是网络的核心设备,与大家分享一下进行设置修改时的小经验,就是先不保存。Cisco路由器有两份配置startup config和running config,修改的时候改变的是running config,可以让这个配置先跑一段时间(三五天的就随意啦),觉得可行后再保存配置到startup config;而如果不满意想恢复原来的配置,用copy start run就行了。

  ISP / ICP管理员

  ISP / ICP为很多中小型企业提供了各种规模的主机托管业务,所以在防DDoS时,除了与企业网管理员一样的手段外,还要特别注意自己管理范围内的客户托管主机不要成为傀儡机。客观上说,这些托管主机的安全性普遍是很差的,有的连基本的补丁都没有打就赤膊上阵了,成为黑客最喜欢的"肉鸡",因为不管这台机器黑客怎么用都不会有被发现的危险,它的安全管理太差了;还不必说托管的主机都是高性能、高带宽的-简直就是为DDoS定制的。而做为ISP的管理员,对托管主机是没有直接管理的权力的,只能通知让客户来处理。在实际情况时,有很多客户与自己的托管主机服务商配合得不是很好,造成ISP管理员明知自己负责的一台托管主机成为了傀儡机,却没有什么办法的局面。而托管业务又是买方市场,ISP还不敢得罪客户,怎么办?咱们管理员和客户搞好关系吧,没办法,谁让人家是上帝呢?呵呵,客户多配合一些,ISP的主机更安全一些,被别人告状的可能性也小一些。

  骨干网络运营商

  他们提供了互联网存在的物理基础。如果骨干网络运营商可以很好地合作的话,DDoS攻击可以很好地被预防。在2000年yahoo等知名网站被攻击后,美国的网络安全研究机构提出了骨干运营商联手来解决DDoS攻击的方案。其实方法很简单,就是每家运营商在自己的出口路由器上进行源IP地址的验证,如果在自己的路由表中没有到这个数据包源IP的路由,就丢掉这个包。这种方法可以阻止黑客利用伪造的源IP来进行DDoS攻击。不过同样,这样做会降低路由器的效率,这也是骨干运营商非常关注的问题,所以这种做法真正采用起来还很困难。

  对DDoS的原理与应付方法的研究一直在进行中,找到一个既有效又切实可行的方案不是一朝一夕的事情。但目前我们至少可以做到把自己的网络与主机维护好,首先让自己的主机不成为别人利用的对象去攻击别人;其次,在受到攻击的时候,要尽量地保存证据,以便事后追查,一个良好的网络和日志系统是必要的。无论DDoS的防御向何处发展,这都将是一个社会工程,需要IT界的同行们来一起关注,通力合作。

2 回复

ctgwglzc
2007-3-10 00:00:30
楼主
点击查看详情
一、 如果出现“Service Unavailable”的提示,刷新几下又可以访问。
    出现这种情况是由于您的网站超过了iis限制造成的,由于2003的操作系统在提示IIS过多时并非像2000系统提示“链接人数过多”,而是提示"Service Unavailable",出现这种情况是由于网站超过了系统资源限制造成的,主要是程序占用资源太多。比如同样是100人在线的论坛,雷傲论坛所占的资源就是PW论坛所占资源的10倍以上;另外,一些死循环程序,或者不优化的程序都会占用太多的系统资源,而系统资源明显是有限的。不过WINDOWS2003的操作系统,各网站之间是以独立进程运行的,不会相互影响。
如果一个网站的程序占资源太多或者发生太多的错误,系统日志就会提示:“应用程序池 'xxx' 被自动禁用,原因是为此应用程序池提供服务的进程中出现一系列错误,或者提示:应用程序池 'xxx' 超过了其作业限制设置。这时,访问这个网站就会提示:Service Unavailable。一般系统会在10秒左右恢复正常,多刷新几次就能正常访问了。 有关更多信息,请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持中心。这时,访问这个网站就会提示:Service Unavailable。一般系统会在30秒左右恢复正常,多刷新几次就能正常访问了。
另外,如果你的网站当前访问人数过多,超过了系统的iis连接数限制,也会出现Service Unavailable的提示(win2k主机下出现连接过多就会提示:连接过多,请稍后再试;而win2003的主机刚直接提示:Service Unavailable

二、没有限制IIS连接,还是遭遇Service Unavailable
  一般使用windows 2003 IIS 6的用户可能这个问题一直正常的系统,突然有一个网站打不开了
  提示: Service Unavailable 但这个网站并没有限制IIS连接数。然后马上影响到了别的网站,不到一会,其他的网站也全变成了 Service Unavailable
  这是什么原因呢?
  我们分析后可以知道,还是MS的老问题。ACCESS引擎当了。用服务器医生的文件医生修复,查看修复结果时会发现一些文件引起ACCESS引擎“灾难性故障”及“未将对象引用设置到对象的实例”的错误。 通过文件医生修复后,系统才会恢复正常。

三、浏览一个 Windows SharePoint Services Web 站点时,提示:Service Unavailable
   如果 Microsoft Internet 信息服务 (IIS) 6.0 中没有正确地配置用于虚拟服务器的应用程序池,就可能会发生此问题。此问题可能会在存在下列一种或多种情况时发生:a.应用程序池没有运行。 b.应用程序池帐户使用的密码不正确。c.应用程序池帐户不是服务器上的 IIS_WPG 和STS_WPG 这两个组的公共成员。
   解决方案
   要解决此问题,按照下列步骤操作: 1.验证是否已为虚拟服务器配置了应用程序池。默认的应用程序池是 MSSharePointPortalAppPool。
请按照下列步骤来确定虚拟服务器正在使用的应用程序池。
a. 单击“开始”,指向“管理工具”,然后单击“Internet 信息服务 (IIS) 管理器”。
b. 展开“ServerName”,展开“Web 站点”,右键单击虚拟服务器,然后单击“属性”。
c. 单击“主目录”选项卡。 为虚拟服务器配置的应用程序池列在“应用程序池”框中。
d. 单击“确定”。

2.验证应用程序池帐户使用的密码是否正确。IIS 不会自动轮询 Active Directory 目录服务中的密码更改。如果应用程序池帐户是一个域帐户,其密码已过期,则在为此帐户重新指定一个新密码后,您可能会收到本文“症状”部分所描述的错误信息。

按照下列步骤来验证应用程序池帐户所用的密码是否正确:
a. 在 Internet 信息服务 (IIS) 管理器中,展开“应用程序池”。
b. 右键单击为虚拟服务器配置的应用程序池(例如,右键单击MSSharePointPortalAppPool”),然后单击“属性”。
c. 单击“标识”选项卡。
d. 在“密码”框中,键入列在“用户名”框中的应用程序池帐户所用的密码,然后单击“确定”。
e. 在“确认密码”对话框中,再次键入密码,然后单击“确定”。

3.验证应用程序池帐户是服务器上的 IIS_WPG 组和 STS_WPG 组的成员。

根据您的具体情况选用下列方法之一。 a. 在成员服务器上安装了 SharePoint Portal Server 的情况下: 1.单击“开始”,指向“管理工具”,然后单击“计算机管理”。
2.展开“本地用户和组”,然后展开“用户”。
3.右键单击虚拟服务器的应用程序池使用的帐户,然后单击“属性”。
4.单击“成员属于”选项卡。

验证 IIS_WPG 和 STS_WPG 是否都出现在“成员属于”列表中。如果其中之一没有列出或者两者均未列出,请根据具体情况将 IIS_WPG 组、STS_WPG 组或者这两个组添加到列表中。

b. 在域控制器上安装了 SharePoint Portal Server 的情况下: 1.启动“Active Directory 用户和计算机”。
2.展开“用户”。
3.右键单击虚拟服务器的应用程序池使用的帐户,然后单击“属性”。
4.单击“成员属于”选项卡。

验证 IIS_WPG 和 STS_WPG 都出现在“成员属于”列表中。如果其中之一没有列出或者两者均未列出,请根据具体情况将 IIS_WPG 组、STS_WPG 组或者这两个组添加到列表中。


4.重新启动 IIS 以回收应用程序池: a. 在 Internet 信息服务 (IIS) 管理器中,右键单击“ServerName”,指向“所有任务”,然后单击“重新启动 IIS”。
b. 单击“在 ServerName 上重新启动 Internet 信息服务”,然后单击“确定
ctgwglzc
2007-3-10 00:28:06
楼主
You Receive a "Service Unavailable" Error Message When You Browse a Windows SharePoint Services Web Site

Service Unavailable
CAUSE
This issue may occur if the application pool for the virtual server is configured incorrectly in Microsoft Internet Information Services (IIS) 6.0. This issue may occur if one or more of the following conditions are true: • The application pool is not running.
• The application pool account uses an incorrect password.
• The application pool account is not a member of both the IIS_WPG group and the STS_WPG group on the server.

RESOLUTION
To resolve this problem, follow these steps: 1. Verify that the application pool is configured for the virtual server. The default application pool is MSSharePointPortalAppPool.

Follow these steps to determine the application pool that the virtual server is using: a.  Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
b.  Expand ServerName, expand Web Sites, right-click the virtual server, and then click Properties.
c.  Click the Home Directory tab.

The application pool that is configured for the virtual server is listed in the Application pool box.
d.  Click OK.

2. Verify that the password for the application pool account is correct. IIS does not automatically poll password changes in Active Directory directory service. If the application pool account is a domain account, and the password expires, you may receive the error message that is described in the "Symptoms" section of this article after a new password is specified for the account.

Follow these steps to verify that the password for the application pool account is correct: a.  In Internet Information Services (IIS) Manager, expand Application Pools.  
b.  Right-click the application pool that is configured for the virtual server (for example, right-click MSSharePointPortalAppPool), and then click Properties.  
c.  Click the Identity tab.  
d.  In the Password box, type the password of the application pool account that is listed in the User name box, and then click OK.
e.  In the Confirm Password dialog box, type the password again, and then click OK.  

3. Verify that the application pool account is a member of both the IIS_WPG group and the STS_WPG group on the server:

Use one of the following methods as appropriate to your situation:a.  If SharePoint Portal Server is installed on a member server: 1. Click Start, point to Administrative Tools, and then click Computer Management.
2. Expand Local Users and Groups, and then expand Users.
3. Right-click the account that is used by the application pool for the virtual server, and then click Properties.
4. Click the Member of tab.

Verify that both IIS_WPG and STS_WPG appear in the Member of list. If one or both groups are not listed, add the IIS_WPG group, the STS_WPG group, or both groups (as appropriate) to the list.

b.  If SharePoint Portal Server is installed on a domain controller: 1. Start Active Directory Users and Computers.
2. Expand Users.
3. Right-click the account that is used by the application pool for the virtual server, and then click Properties.
4. Click the Member of tab.

Verify that both IIS_WPG and STS_WPG appear in the Member of list. If one or both groups are not listed, add the IIS_WPG group, the STS_WPG group, or both groups (as appropriate) to the list.


4. Restart IIS to recycle the application pools: a.  In Internet Information Services (IIS) Manager, right-click ServerName, point to All Tasks, and then click Restart IIS.
b.  Click Restart Internet Information Services on ServerName, and then click OK.


MORE INFORMATION
For more information about Windows SharePoint Services, visit the following Microsoft Web site:
http://www.microsoft.com/Windows ... epoint/default.mspx (http://www.microsoft.com/windows ... point/default.mspx)
高级模式
游客