大家对windows操作系统一定不陌生，但你是否注意到系统中“svchost.exe”这个文件呢？细心的朋友会发现windows中存在多个 “svchost”进程（通过“ctrl+alt+del”键打开任务管理器，这里的“进程”标签中就可看到了），为什么会这样呢？下面就来揭开它神秘的面纱。

发现

　　在基于nt内核的windows操作系统家族中，不同版本的windows系统，存在不同数量的“svchost”进程，用户使用“任务管理器”可查看其进程数目。一般来说，win2000有两个svchost进程，winxp中则有四个或四个以上的svchost进程（以后看到系统中有多个这种进程，千万别立即判定系统有病毒了哟），而win2003 server中则更多。这些svchost进程提供很多系统服务，如：rpcss服务（remote procedure call）、dmserver服务（logical disk manager）、dhcp服务（dhcp client）等。

　　如果要了解每个svchost进程到底提供了多少系统服务，可以在win2000的命令提示符窗口中输入“tlist -s”命令来查看，该命令是win2000 support tools提供的。在winxp则使用“tasklist /svc”命令。

svchost中可以包含多个服务

深入

　　windows系统进程分为独立进程和共享进程两种，“svchost.exe”文件存在于“%systemroot% system32”目录下，它属于共享进程。随着windows系统服务不断增多，为了节省系统资源，微软把很多服务做成共享方式，交由 svchost.exe进程来启动。但svchost进程只作为服务宿主，并不能实现任何服务功能，即它只能提供条件让其他服务在这里被启动，而它自己却不能给用户提供任何服务。那这些服务是如何实现的呢？

　　原来这些系统服务是以动态链接库（dll）形式实现的，它们把可执行程序指向 svchost，由svchost调用相应服务的动态链接库来启动服务。那svchost又怎么知道某个系统服务该调用哪个动态链接库呢？这是通过系统服务在注册表中设置的参数来实现。下面就以rpcss（remote procedure call）服务为例，进行讲解。

　　从启动参数中可见服务是靠svchost来启动的。

实例

　　以windows xp为例，点击“开始”/“运行”，输入“services.msc”命令，弹出服务对话框，然后打开“remote procedure call”属性对话框，可以看到rpcss服务的可执行文件的路径为“c:\windows\system32\svchost -k rpcss”，这说明rpcss服务是依靠svchost调用“rpcss”参数来实现的，而参数的内容则是存放在系统注册表中的。

　　在运行对话框中输入“regedit.exe”后回车，打开注册表编辑器，找到[hkey_local_machine systemcurrentcontrolsetservicesrpcss]项，找到类型为“reg_expand_sz”的键“magepath”，其键值为“%systemroot%system32svchost -k rpcss”（这就是在服务窗口中看到的服务启动命令），另外在“parameters”子项中有个名为“servicedll”的键，其值为“% systemroot%system32rpcss.dll”，其中“rpcss.dll”就是rpcss服务要使用的动态链接库文件。这样 svchost进程通过读取“rpcss”服务注册表信息，就能启动该服务了。

解惑

　　因为svchost进程启动各种服务，所以病毒、木马也想尽办法来利用它，企图利用它的特性来迷惑用户，达到感染、入侵、破坏的目的（如冲击波变种病毒“w32.welchia.worm”）。但windows系统存在多个svchost进程是很正常的，在受感染的机器中到底哪个是病毒进程呢？这里仅举一例来说明。

　　假设windows xp系统被“w32.welchia.worm”感染了。正常的svchost文件存在于“c:\windows\system32”目录下，如果发现该文件出现在其他目录下就要小心了。“w32.welchia.worm”病毒存在于“c:\windows\system32wins”目录中，因此使用进程管理器查看svchost进程的执行文件路径就很容易发现系统是否感染了病毒。windows系统自带的任务管理器不能够查看进程的路径，可以使用第三方进程管理软件，如“windows优化大师”进程管理器，通过这些工具就可很容易地查看到所有的svchost进程的执行文件路径，一旦发现其执行路径为不平常的位置就应该马上进行检测和处理。

　　由于篇幅的关系，不能对svchost全部功能进行详细介绍，这是一个windows中的一个特殊进程，有兴趣的可参考有关技术资料进一步去了解它。

    大家都知道，TCP与UDP不同，它是基于连接的，也就是说：为了在服务端和客户端之间传送TCP数据，必须先建立一个虚拟电路，也就是TCP连接，建立TCP连接的标准过程是这样的：

　　首先，请求端（客户端）发送一个包含SYN标志的TCP报文，SYN即同步（Synchronize），同步报文会指明客户端使用的端口以及TCP连接的初始序号；

　　第二步，服务器在收到客户端的SYN报文后，将返回一个SYN+ACK的报文，表示客户端的请求被接受，同时TCP序号被加一，ACK即确认（Acknowledgement）。

　　第三步，客户端也返回一个确认报文ACK给服务器端，同样TCP序列号被加一，到此一个TCP连接完成。

    以上的连接过程在TCP协议中被称为三次握手（Three-way Handshake）。

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

　　从防御角度来说，有几种简单的解决方法：

　　第一种是缩短SYN Timeout时间，由于SYN Flood攻击的效果取决于服务器上保持的SYN半连接数，这个值=SYN攻击的频度 x  SYN Timeout，所以通过缩短从接收到SYN报文到确定这个报文无效并丢弃改连接的时间，例如设置为20秒以下（过低的SYN Timeout设置可能会影响客户的正常访问），可以成倍的降低服务器的负荷。

　　第二种方法是设置SYN Cookie，就是给每一个请求连接的IP地址分配一个Cookie，如果短时间内连续受到某个IP的重复SYN报文，就认定是受到了攻击，以后从这个IP地址来的包会被丢弃。

　　可是上述的两种方法只能对付比较原始的SYN Flood攻击，缩短SYN Timeout时间仅在对方攻击频度不高的情况下生效，SYN Cookie更依赖于对方使用真实的IP地址，如果攻击者以数万/秒的速度发送SYN报文，同时利用SOCK_RAW随机改写IP报文中的源地址，以上的方法将毫无用武之地。

　　攻击的过程是这样的：Woodlly Attacker向一个具有大量主机和因特网连接的网络的广播地址发送一个欺骗性Ping分组（echo 请求），这个目标网络被称为反弹站点，而欺骗性Ping分组的源地址就是Woolly希望攻击的系统。

　　这种攻击的前提是，路由器接收到这个发送给IP广播地址（如206.121.73.255）的分组后，会认为这就是广播分组，并且把以太网广播地址FF:FF:FF:FF:FF:FF:映射过来。这样路由器人因特网上接收到该分组，会对本地网段中的所有主机进行广播。

　　读者肯定能够想到下面会发生什么情况。网段中的所有主机都会向欺骗性分组的IP地址发送echo响应信息。如果这是一个很大的以太网段，可以会有500个以上的主机对收到的echo请求进行回复。

　　由于多数系统都会尽快地处理ICMP传输信息，Woodlly Attacker把分组的源地址设置为目标系统，因些目标系统都很快就会被大量的echo信息吞没，这样轻而易举地就能够阻止该系统处理其它任何网络传输，从而引起拒绝为正常系统服务。

　　这种攻击不仅影响目标系统，还影响目标公司的因特网连接。如果反弹站点具有T3连接（45Mbps），而目标系统所在的公司使用的是租用线路（56Kbps），则所有进出该公司的通讯都会停止下来。

　　那么如何防止这种类型的攻击？用户可以分别在源站点、反弹站点和目标站点三个方面采取步骤，以限制Smurf攻击的影响。[page]　　解决办法：

　　阻塞Smurf攻击的源头

　　Smurf攻击依靠攻击者的力量使用欺骗性源地址发送echo请求。用户可以使用路由路的访问保证内部网络中发出的所有传输信息都具有合法的源地址，以防止这种攻击。这样可以使欺骗性分组无法找到反弹站点。

　　阻塞Smurf的反弹站点

　　用户可以有两种选择以阻塞Smurf攻击的反弹站点。第一种方法可以简单地阻塞所有入站echo请求，这们可以防止这些分组到达自己的网络。

　　如果不能阻塞所有入站echo请求，用户就需要罅自己的路由器把网络广播地址映射成为LAN广播地址。制止了这个映射过程，自己的系统就不会再收到这些echo请求。

　　如果使用Cisco路由路，制止网络广播映射成为LAN广播的方法是在LAN接口的配置模式中输入命令：
no ip directed-broadcast

　　注意：必须在所有路由器的所有LAN接口都使用该命令。只在某些外围路由器上使用上述命令不会起作用。

　　防止Smurf攻击目标站点

　　除非用户的ISP愿意提供帮助，否则用户自己很难防止Smurf对自己的WAN接连线路造成的影响。虽然用户可以在自己的网络设备中阻塞这种传输，但对于防止Smurf吞噬所有的WAN带宽已经太晚了。

　　但至少用户可以把Smurf的影响限制在外围设备上。通过使用动态分组过滤技术，或者使用防火墙，用户可以阻止这些分组进入自己的网络。防火墙的状态表很清楚这些攻击会话不是本地网络中发出的（状态表记录中没有最初的echo请求记录），因些它会象对待其它欺骗性攻击行为那样把这样信息丢弃。

数字时间戳（digital time-stamp）
　　在各种政务和商务文件中，时间是十分重要的信息。在书面合同中，文件签署的日期和签名一样均是十分重要的防止文件被伪造和篡改的关键性内容。
　　在电子文件中，同样需对文件的日期和时间信息采取安全措施，而数字时间戳服务（DTS：digital time-stamp service）就能提供电子文件发表时间的安全保护。
　　数字时间戳服务（DTS）是网上安全服务项目，由专门的机构提供。时间戳(time-stamp)是一个经加密后形成的凭证文档，它包括三个部分：
① 需加时间戳的文件的摘要 (digest)；
② DTS收到文件的日期和时间；
③ DTS的数字签名。
　　时间戳产生的过程为：用户首先将需要加时间戳的文件用HASH编码加密形成摘要，然后将该摘要发送到DTS，DTS在加入了收到文件摘要的日期和时间信息后再对该文件加密（数字签名），然后送回用户。由 Bellcore 创造的DTS采用如下的过程：加密时将摘要信息归并到二叉树的数据结构；再将二叉树的根值发表在报纸上，这样更有效地为文件发表时间提供了佐证。注意，书面签署文件的时间是由签署人自己写上的，而数字时间戳则不然，它是由认证单位DTS来加的，以DTS收到文件的时间为依据。因此，时间戳也可作为科学家的科学发明文献的时间认证。

时间认证中心 (TCA Time Certification Authority)
　　在电子交易中，无论是数字时间戳服务（DTS）还是数字证书 (Digital ID)的发放，都
不是靠交易的双方自己能完成的，而需要有一个具有权威性和公正性的第三方来完成。认证中心(CA)就是承担网上安全电子交易认证服务、能签发数字证书、并能确认用户身份的服务机构。认证中心通常是企业性的服务机构，主要任务是受理数字证书的申请、签发及对数字证书的管理。认证中心依据认证操作规定 (CPS：Certification Practice Statement)来实施服务操作。

我国数字时间认证中心
国家授时中心（NTSC）作为我国标准时间产生、保持和传递的中心，具有数字时间认证的技术条件和权威性。国家授时中心正在积极建立我国的数字时间认证中心，以满足日益发展的电子政务和电子商务的迫切需求。预计该中心将在2001年建成并投入使用。