redwolf在路上 - 网络技术

什么是PKI(公钥基础设施)

redwolf@redwolf.com.cn (redwolf) — Mon, 04 May 2009 13:03:00 +0800

为解决Internet的安全问题,世界各国对其进行了多年的研究,初步形成了一套完整的Internet安全解决方案,即目前被广泛采用的PKI技术(Public Key Infrastructure z公钥基础设施),PKI(公钥基础设施)技术采用证书管理公钥,通过第三方的可信任机构z认证中心CA(Certificate Authority),把用户的公钥和用户的其它标识信息(如名称、e-mail、身份证号等)捆绑在一起,在Internet网上验证用户的身份。目前,通用的办法是采用建立在PKI基础之上的数字证书,通过把要传输的数字信息进行加密和签名,保证信息传输的机密性、真实性、完整性和不可否认性,从而保证信息的安全传输。

所谓PKI就是一个用公钥概念和技术实施和提供安全服务的具有普适性的安全基础设施。但PKI的定义在不断地延伸和扩展。PKI涉及到多个实体之间的协作过程,如CA、RA、证书库、密钥恢复服务器和终端用户。国外的PKI应用已经开始,开发PKI的厂商也很多。许多厂家如Baltimore、Entrust等推出了可以应用的PKI产品,有些公司如VerySign等已经开始提供PKI服务。网络许多应用已经在使用PKI技术以保证网络的认证、不可否认、加解密和密钥管理等。尽管如此,总的说来PKI技术仍在发展中。PKI系统仅仅还是在做示范工程。我们认为PKI技术将成为所有应用的计算基础结构的核心部件,包括那些越出传统网络界限的应用。提供

1)PKI基础

PKI基础设施采用证书管理公钥,通过第三方的可信任机构:CA认证中心,把用户的公钥和用户的其它标识信息捆绑在一起,在Internet网上验证用户的身份。PKI基础设施把公钥密码和对称密码结合起来,在Internet网上实现密钥的自动管理,保证网上数据的安全传输。

从广义上讲,所有提供公钥加密和数字签名服务的系统,都可叫做PKI系统,PKI的主要目的是通过自动管理密钥和证书,可以为用户建立起一个安全的网络运行环境,使用户可以在多种应用环境下方便地使用加密和数字签名技术,从而保证网上数据的机密性、完整性、有效性。数据的机密性是指数据在传输过程中,不能被非授权者偷看；数据的完整性是指数据在传输过程中不能被非法篡改；数据的有效性是指数据不能被否认。一个有效的PKI系统必须是安全的和透明的,用户在获得加密和数字签名服务时,不需要详细地了解PKI是怎样管理证书和密钥的,一个典型、完整、有效的PKI应用系统至少应具有以下部分:

(1)公钥密码证书管理；

(2)黑名单的发布和管理;

(3)密钥的备份和恢复;

(4)自动更新密钥;

(5)自动管理历史密钥;

（6）支持交叉认证。

由于PKI基础设施是目前比较成熟、完善的Internet网络安全解决方案,国外的一些大的网络安全公司纷纷推出一系列的基于PKI的网络安全产品,如美国的VeriSign,IBM,加拿大的Entrust、SUN等安全产品供应商为用户提供了一系列的客户端和服务器端的安全产品,为电子商务的发展以及政府办公网、EDI等提供了安全保证。简言之,PKI (Public Key Infrastructure)公钥基础设施就是提供公钥加密和数字签名服务的系统,目的是为了管理密钥和证书,保证网上数字信息传输的机密性、真实性、完整性和不可否认性。

2)单钥密码算法(加密) 信息

单钥密码算法,又称对称密码算法:是指加密密钥和解密密钥为同一密钥的密码算法。因此,信息的发送者和信息的接收者在进行信息的传输与处理时,必须共同持有该密码(称为对称密码）。在对称密钥密码算法中,加密运算与解密运算使用同样的密钥。通常,使用的加密算法比较简便高效,密钥简短,破译极其困难;由于系统的保密性主要取决于密钥的安全性,所以,在公开的计算机网络上安全地传送和保管密钥是一个严峻的问题。最典型的是DES (Data Encryption Standard)算法。

3)双钥密码算法(加密、签名〉

双钥密码算法,又称公钥密码算法:是指加密密钥和解密密钥为两个不同密钥的密码算法。公钥密码算法不同于单钥密码算法,它使用了一对密钥:一个用于加密信息,另一个则用于解密信息,通信双方无需事先交换密钥就可进行保密。

4)PKI组成

PKI是一种新的安全技术,它由公开密钥密码技术、数字证书、证书发放机构(CA)和关于公开密钥的安全策略等基本成分共同组成的。PKI是利用公钥技术实现电子商务安全的一种体系,是一种基础设施,网络通讯、网上交易是利用它来保证安全的。从某种意义上讲,PKI包含了安全认证系统,即安全认证系统一CA/RA系统是PKI不可缺的组成部分。

PKI(Public Key Infrastructure)公钥基础设施是提供公钥加密和数字签名服务的系统或平台,目的是为了管理密钥和证书。一个机构通过采用PKI框架管理密钥和证书可以建立一个安全的网络环境。PKI主要包括四个部分:

(1)X.509格式的证书(X.509V3)和证书废止列表CRL(X.509 V2)；

(2)CA/RA操作协议；

(3)CA管理协议；

信息

(4)CA政策制定。

信息来自

一个典型、完整、有效的PKI应用系统至少应具有以下部分: 信息来自

(1)CA认证中心CA是PKI的核心,CA负责管理PKI结构下的所有用户(包括各种应用程序)的证书,把用户的公钥和用户的其它信息捆绑在一起,在网上验证用户的身份,CA还要负责用户证书的黑名单登记和黑名单发布,下面有CA的详细描述。

(2)X.500目录服务器X.500目录服务器用于发布用户的证书和黑名单信息,用户可通过标准的LDAP协议查询自己或其他人的证书和下载黑名单信息。

(3)具有高强度密码算法(SSL)的安全WWW服务器出口到中国的WWW服务器,如微软的IIS、Netscape的WWW服务
(图5.3) 信息

参加电子商务的各方必须有一个可以被验证的标识,这就是数字证书。数字证书是各实体（持卡人/个人、商户/企业、网关/银行等)在网上信息交流及商务交易活动中的身份证明。该数字证书具有惟一性。它将实体的公开密钥同实体本身联系在一起,为实现这一目的,必须使数字证书符合X509国际标准,同时数字证书的来源必须是可靠的。这就意味着应有一个网上各方都信任的机构,专门负责数字证书的发放和管理,确保网上信息的安全,这个机构就是CA认证机构。各级CA认证机构的存在组成了整个电子商务的信任链。如果CA机构不安全或发放的数字证书不具有权威性、公正性和可信赖性,电子商务就根本无从谈起。数字证书认证中心(Certificate Authority ,CA)是整个网上电子交易安全的关键环节。它主要负责产生、分配并管理所有参与网上交易的实体所需的身份认证数字证书。每一份数字证书都与上一级的数字签名证书相关联,最终通过安全链追溯到一个已知的并被广泛认为是安全、权威、足以信赖的机构:根认证中心(根CA)。

电子交易的各方都必须拥有合法的身份,即由数字证书认证中心机构(CA)签发的数字证书,在交易的各个环节,交易的各方都需检验对方数字证书的有效性,从而解决了用户信任问题。CA涉及到电子交易中各交易方的身份信息、严格的加密技术和认证程序。基于其牢固的安全机制,CA应用可扩大到一切有安全要求的网上数据传输服务

。数字证书认证解决了网上交易和结算中的安全问题,其中包括建立电子商务各主体之间的信任关系,即建立安全认证体系(CA)选择安全标准(如SET、SSL)采用高强度的加、解密技术。其中安全认证体系的建立是关键,它决定了网上交易和结算能否安全进行,因此,数字证书认证中心机构的建立对电子商务的开展具有非常重要的意义。

认证中心(CA),是电子商务体系中的核心环节,是电子交易中信赖的基础。它通过自身的注册审核体系,检查核实进行证书申请的用户身份和各项相关信息,使网上交易的用户属性客观真实性与证书的真实性一致。认证中心作为权威的、可信赖的、公正的第三方机构,专门负责发放并管理所有参与网上交易的实体所需的数字证书。

B.CA/RA简介

提供

开放网络上的电子商务要求为信息安全提供有效的、可靠的保护机制。这些机制必须提供机密性、身份验证特性(使交易的每一方都可以确认其它各方的身份）、不可否认性(交易的各方不可否认它们的参与)。这就需要依靠一个可靠的第三方机构验证,而认证中心(CA：Certification Authority)专门提供这种服务。

提供

证书机制是目前被广泛采用的一种安全机制,使用证书机制的前提是建立CA (Certification Authority：认证中心)以及配套的RA (Registration Authority z注册审批机构)系统。

CA中心,又称为数字证书认证中心,作为电子商务交易中受信任的第三方,专门解决公钥体系中公钥的合法性问题。CA中心为每个使用公开密钥的用户发放一个数字证书,数字证书的作用是证明证书中列出的用户名称与证书中列出的公开密钥相对应。CA中心的数字签名使得攻击者不能伪造和篡改数字证书。

在数字证书认证的过程中,证书认证中心(CA)作为权威的、公正的、可信赖的第三方,其作用是至关重要的。认证中心就是一个负责发放和管理数字证书的权威机构。同样CA允许管理员撤销发放的数字证书,在证书废止列表(CRL)中添加新项并周期性地发布这一数字签名的CRL。

信息来自

RA (Registration Authority),数字证书注册审批机构。RA系统是CA的证书发放、管理的延伸。它负责证书申请者的信息录人、审核以及证书发放等工作;同时,对发放的证书完成相应的管理功能。发放的数字证书可以存放于IC卡、硬盘或软盘等介质中。RA系统是整个CA中心得以正常运营不可缺少的一部分。

C.认证中心的功能

概括地说,认证中心(CA)的功能有:证书发放、证书更新、证书撤销和证书验证。CA的核心功能就是发放和管理数字证书,具体描述如下:①接收验证最终用户数字证书的申请；②确定是否接受最终用户数字证书的申请：证书的审批；③向申请者颁发、拒绝颁发数字证书:证书的发放；④接收、处理最终用户的数字证书更新请求:证书的更新；⑤接收最终用户数字证书的查询、撤销；⑥产生和发布证书废止列表(CRLh⑦数字证书的归档；⑧密钥归档；⑨历史数据归档。提供

认证中心为了实现其功能,主要由以下三部分组成：

(1)注册服务器:通过Web Server建立的站点,可为客户提供每日24小时的服务。因此客户可在自己方便的时候在网上提出证书申请和填写相应的证书申请表,免去了排队等候等烦恼。

(2)证书申请受理和审核机构：负责证书的申请和审核。它的主要功能是接受客户证书申请并进行审核。

(3)认证中心服务器:是数字证书生成、发放的运行实体,同时提供发放证书的管理、证书废止列表(CRL)的生成和处理等服务。

6)PKI相关标准信息来自

PKI包括很多协议标准,图5.4表明应用程序与PKI之间的关系以及相应的标准。PKI标准使得多个PKI可以交互,并且使多个应用程序面对的是单一的,固定的接口。

Internet连接被禁用的解决方法二

redwolf@redwolf.com.cn (redwolf) — Tue, 25 Mar 2008 09:03:37 +0800

Internet连接被禁用的解决方法,昨天新买的电脑做好系统后怎么都上不了网,但在CMD下又能PING通网关和网站,但就上不了网,网络连接里显示Internet连接被禁用,怎么启用都启用不了,在网上找了下大多数都是说在里禁用一下UPN服务之类的,我照做后是不显示Internet连接了,但还是一样打不开网页,把DNS和所有能出现这样现象的全找了一遍还是没发现原因,重做一次系统后照旧,后来想一下会不会是网线或接口有问题,试着把网线和网络插口换了下,OK!搞定,呵呵```本来以为是网线和插口的问题,后来二天还是这样反复定时上不了网.经过二天的排查，认为是聚生网管的问题，把聚生网管卸载，装在另一台服务器上就OK了，现在还没出现过定时上不了网的情况了。

[转]Windows Server Update Services 2.0更新及使用教程1

redwolf@redwolf.com.cn (redwolf) — Wed, 20 Feb 2008 14:37:06 +0800

大部分对计算机比较熟悉的朋友都知道，通常安装好Windows 操作系统后要做的第一件事就是上Windows Update网站去给Windows 安装补丁程序，否则各种漏洞对系统就是一个很大的威胁。不过遗憾的是很多人还没有这样的意识，疏忽了给系统打补丁。这也间接造成了病毒的横行，例如去年的“蠕虫王”和前几天的“冲击波”，这两个病毒都是利用了微软软件的漏洞编写和传播的，遗憾的是在这些病毒广泛流传之前，相应软件的补丁程序早就已经由微软发布出来并提供了免费下载，只要用户能经常性地访问Windows Update网站打补丁，就不会感染这些病毒，可是很多人都疏忽了这一点。好在经过这两次教训，更多的人知道“打补丁”的重要性，可是问题又来了。

微软的升级服务器都架设在国外，有时候由于网络的原因造成了国内用户连接服务器的速度非常慢，这些时候光下载补丁就要一个多小时的时间，效率非常低。另一方面，对于有上百台电脑的企业，每台电脑都连接到微软的服务器去下载上百兆字节的补丁程序，这对企业的网络带宽也是一个不小的负担，况且由于大家都到微软的服务器下载补丁，管理员就无法对补丁程序的内容进行控制，如果某个补丁正好跟企业内部广泛使用的某个软件有冲突的话，还可能造成更大的麻烦。现在，问题解决了，那就是使用微软的SUS（Software Update Service，软件更新服务）服务。

而SUS的后续版本Windows Server Update Services（下文统一简称为WSUS）又将带来什么新功能呢?

我们来进入文章的第一部分强大的更新服务器WSUS

虽然美国微软已经把软件名更名为Windows Server Update Services 2.0（WSUS）但是微软中国还叫Software Update Services 2.0（SUS）其实是一个软件。

我们来看下微软中国的关于Software Update Services 2.0的说明吧

简介
即将发布的 Software Update Services (SUS) 2.0 致力于帮助用户对基于 Microsoft® Windows® 2000 和 Windows Server™ 2003 的服务器以及运行 Microsoft® Windows® 2000 Professional 或 Windows® XP Professional 的台式机快速部署最新的重要更新和安全更新。

通过使用计划发布的 SUS 2.0，信息技术 (IT) 管理员可以完全控制管理通过 Windows Update 发布给网络中的计算机的更新的分发。

SUS 2.0 解决方案提供包括下列组件的管理体系结构：

• Windows Update - 包括所有基于产品和更新类型的可用 Microsoft 更新的 Microsoft 网站。

• 服务器组件 - Microsoft 软件更新服务，称为 SUS 2.0 服务器，用于安装在公司防火墙内运行 Windows 2000 Server 或 Windows Server 2003 家族操作系统的计算机上。服务器组件提供通过基于 Web 的工具管理和分发更新的管理功能，管理员可以访问公司网络中的任何 Windows 计算机。

• 客户端组件 - 自动更新（Automatic Updates），即客户端组件，在接收 Microsoft 产品更新的计算机上运行。本组件可以将服务器和客户端计算机直接连接至 Windows Update 或连接至接收更新的运行 SUS 2.0 的服务器上。自动更新组件计划纳入 Windows 2000 Service Pack 4 (SP4) 和更高版本、Windows XP 和更高版本以及 Windows Server 2003 中。

SUS 2.0 中计划包含的功能
SUS 2.0 构建在 SUS 1.0 的功能之上，目前计划提供下列功能：

• 扩展对包括 Office、SQL Server、Exchange 和硬件驱动程序在内的 Microsoft 产品的支持

• 扩展对附加更新类别的支持

• 提供使用 Windows 客户端或服务器计算机支持的任何语言的计算机部署更新的能力

• 自动排列优先级和下载重要更新

• 通过后台智能传输服务 (BITS) 技术提高带宽效率

• 提供对特定计算机组进行更新的能力

• 提供管理员选择和决定自动下载特定类型更新的计划的能力

• 改进了报告能力，使管理员能够监视更新部署状态和服务器的正常运转

• 扩展了通过应用程序编程接口 (API) 和脚本管理客户端和服务器组件的能力

• SQL Server 引擎用作 SUS 2.0 数据知识库

• 方便地从 SUS 1.0 迁移到 SUS 2.0

要求
计划的 SUS 2.0 要求如下：

服务器
• Windows 2000 Server SP4 或更高版本或 Windows Server 2003

• Microsoft Internet Information Services (IIS) 5.0 或更高版本、Microsoft Internet Explorer 6.0

客户端
• Windows 2000 Service Pack 3 (SP3) 或更高版本、Windows XP 和 Windows Server 2003

功能一览
SUS 2.0 目前计划提供下列功能。

客户端功能
自动更新使 Windows 能够自动下载和安装 Microsoft 产品的更新。下表中列出的是计划的客户端组件的主要功能。

SUS 2.0 计划的客户端功能

功能说明
内置安全
内容：
SUS 2.0 客户端将只信任由 Microsoft 签名的特定内容，因此，不可能篡改内容。
客户端-服务器关系：SUS 2.0 客户端要求 SUS 2.0 服务器进行自身身份验证来建立通信，并使用安全协议加密会话期间交换的数据。
计算机隐私：SUS 客户端不发送任何个人标识信息给 Microsoft。搜集的数据绝对是一般信息并只用来改进服务。

自动检测、下载和安装适用更新
自动更新可以确定如果计算机缺少更新则可以自动启动下载和安装。
在托管环境中，客户端可以直接从 Windows Update 或从 SUS 2.0 服务器获得更新。
在托管环境中，管理员可以配置客户端检查 SUS 2.0 服务器新更新的频率。

用户可用的计划和通知选项
用户可用的计划和通知选项可以通过组策略进行配置。
具有管理权限的用户可以指定在自动下载、安装或设置安装计划前是否通知用户。此外，用户可以检索以前拒绝的更新或隐藏的更新。

有效的后台下载更新
自动更新计划使用 BITS（一种创新的带宽限制技术）,已内置入 Windows 2000 SP3 和更高版本的操作系统中，用于将更新下载至计算机。
BITS 技术提供下载期间的增量数据压缩 - 只从 SUS 2.0 服务器或 Windows Update 下载文件中发生更改的部分，这样可以通过自动更新有效分发 Service Pack。

安装更新时不中断用户
设置为该选项时，自动更新能够在无需重启或中断服务的情况下，一找到更新就立即安装，而不会等到计划的自动安装时间。而且，自动更新将把需要计算机重启的更新合并到一次重启中。
自动更新还去除用户与最终用户许可协议 (EULA) 交互的要求。在 SUS 环境中，EULA 将由管理员代表客户端在 SUS 2.0 服务器上接受。

强大的、可扩展的管理员管理能力
在 Active Directory® 目录服务环境中，计划为管理员提供通过使用组策略配置自动更新行为的可能性。在其他情况下，计划为管理员提供通过使用登录脚本或类似机制使用注册表项远程配置自动更新的能力。
此外，管理员可以使用脚本通过基于组件对象模型 (COM) 的 API 管理客户端。计划可使用软件开发工具包 (SDK)。

客户端计算机的自我更新
在管理员托管方案中，客户端计算机可以将其自动更新组件更新为新版本，而无需管理员重新配置计算机。

改进的更新适用规则
SUS 2.0 客户端具有仅下载和安装真正对计算机适用的特定更新的能力。而管理员不用猜测更新安装在何处，SUS 2.0 客户端与 SUS 2.0 服务器协同来评估将哪一个更新应用至特定系统。例如，客户在 Windows XP 计算机上安装适合于 Windows 2000 的更新时不会有风险。

服务器端功能
SUS 2.0 服务器管理工具计划提供一套强大的管理功能。下表中列出了服务器组件的功能。

SUS 2.0 计划的服务器端功能

功能说明
内置安全
SUS 2.0 管理工具页限于 SUS 2.0 服务器上的本地管理员。同步将通过更新服务器验证所有下载的数字签名。如果签名不是来自于 Microsoft，包将被删除。此进程使用的协议保证 SUS 2.0 服务器与 Windows Update 站点通信的安全性和可靠性。

更多内容
SUS 2.0 支持随时间推移更新所有的 Microsoft 产品。

新数据模型
SUS 2.0 组件旨在通过新数据模型处理更新，在该模型中更新之间可以存在复杂的关系（例如，更新之间的取代和依赖）。

更新管理体系结构和横向扩展支持
SUS 2.0 计划为管理员提供创建由 SUS 2.0 服务器层次结构组成的更新管理体系结构的能力。例如，SUS 2.0 服务器可部署为匿名服务器、从属副本主机或负载平衡群集。因此，SUS 2.0 横向扩展为可处理任意多个客户端。
此外，计划让管理员可以灵活选择配置计算机是直接从 Windows Update 还是从内部分发更新的 Intranet SUS 2.0 服务器获得更新。管理员还可以根据网络配置使用两种设置的组合。

预先部署检查和审批
通过在一个特定的目标组中向所有计算机发送预先部署请求，计划使管理员可以评估需要更新的计算机数目以及部署更新将影响网络的程度。预先部署检查使得管理员能够在实际部署安装更新前执行更新影响分析。

目标
目标计划使管理员能够创建同等级的计算机的目标组并从一个 SUS 2.0 服务器为那些组指定特定更新。此外，SUS 2.0 将支持下列功能：客户端和服务器端目标、支持 Active Directory 环境的基于注册表的策略以及非 Active Directory 环境的服务器端列表。

管理员定义的下载行为
除了 BITS 技术将促进的有效后台下载外，计划的 BITS 技术使得服务器能够同步基于管理员定义的更新首选项和计划。管理员能够在更新下载时指定时间段（包括部署的仅下载作为更新的选项）和出现下载时使用的网络带宽值。

基于截止时间的安装（或卸载）
计划让管理员能够强制安装更新的截止时间。在这种情况下用户不能在指定截止时间后延期安装更新。

卸载
如果更新支持卸载，当部署更新后确定更新不适合产品环境时管理员可以启动卸载更新。

报告
计划使管理员能够通过 SUS 2.0 报告功能监视更新活动和服务器的正常运转。为监视和管理更新活动，SUS 2.0 提供基于客户端发送的事件，包括每次更新、每台计算机和每个目标组的更新部署状态的标准报告。此外，如果管理员要创建客户报告，则能够访问 SUS 2.0 数据库中的只读视图。

通过 API 扩展管理
管理员可以使用脚本通过基于 .NET 的 API 管理 SUS 2.0 服务器。开发人员可以创建通过 SUS 2.0 API 与 SUS 2.0 集成的管理应用程序。可以使用 SDK。

导入和导出能力
管理员可以使用导入和导出功能在两个 SUS 2.0 服务器之间下载和传输更新。在这种情况下，导入和导出功能将使在没有物理 Internet 访问或与其他网络的 Internet 连接的断开的网络（受保护的网络）中的更新管理体系结构更易于管理，例如智能社区。

备份和还原服务器数据库
管理员可以很容易从 Microsoft® SQL Server™ 2000 Service Pack 2 (SP2) 或更高版本以及 Microsoft Data Engine (MSDE) 2000 数据库备份和还原 SUS 2.0 服务器的更新内容、部署操作事件和设置。

灵活的服务器配置选项
对于远程管理，服务器配置选项计划包括使用安全套接字层 (SSL) 或超文本传输协议 (HTTP) 与 SUS 2.0 服务器连接并支持除默认端口 80 以外其他端口用于客户端和服务器通信。如果 SUS 2.0 服务器通过代理服务器与 Internet 相连，管理员还可以配置代理服务器设置。

SUS 1.0 服务器的迁移工具
迁移工具使得 SUS 1.0 客户能够无缝地将以前 SUS 1.0 服务器上的管理设置迁移到 SUS 2.0 服务器。

SUS 2.0 和更新管理进程
本节说明 Microsoft 推荐的更新管理进程方法，还为管理员提供如何使用计划的 SUS 2.0 功能确保进程的四个阶段中的每一阶段都能成功的示例。注意：许多功能可以在一个以上的阶段中使用。有关计划的 SUS 2.0 管理功能的详细信息，请参阅本文档前面部分的“服务器端功能”。

1. 评估
管理员在评估阶段的目标是了解什么因素可能对产品环境构成威胁并了解准备产品环境以支持例行和紧急更新管理的方法。通过第一步，评估阶段实质是个持续进行的进程。

例如，管理员将评估有多少服务器和客户端需要更新，它们各自的存储和网络带宽需求以及部署一般更新的可以接受的时间。管理员还要确定要更新什么平台、产品和语言。基于这些因素，他们能够确定最有效的拓扑以横向扩展其 SUS 2.0 组件。SUS 2.0 旨在提供很多选项设置 SUS 2.0 组件，包括在 SUS 2.0 服务器上本地存储更新内容或根据需要从 Windows 下载内容。管理员还可以配置自动更新以在计算机上自动下载和安装缺少的更新。SUS 2.0 提供选项管理 Active Directory 和非 Active Directory 环境中的客户端。

SUS 2.0 计划提供标准合并报告，管理员可以在持续进行的基础上运行。这些报告提供与 SUS 2.0 服务器联系的计算机列表，然后是这些计算机的操作系统、语言和服务包级的列表。报告还将识别计算机安装或丢失了哪些更新并确定服务器的正常运行。

2. 识别
管理员在识别阶段的目标是以简便的方式发现新更新，确定更新是否与产品环境有关以及确定更新优先级。

SUS 2.0 管理工具旨在允许管理员创建订阅。管理员使用订阅可以确定按照产品和分类哪些更新与 Windows Update （或上游 SUS 2.0 服务器）同步；例如订阅可以只包含 Windows XP 重要更新和 Office XP 安全更新的下载请求。管理员可以为每个订阅设置同步计划。例如，管理员可以创建一个需要每天下载的重要更新的订阅，再创建另一个每周下载的可选更新的订阅。

要确定更新是否与产品环境相关，计划使管理员能够查看更新的属性。管理员还可以运行预先部署检查更新，旨在帮助管理员在产品环境中安装更新前评估需要更新的计算机数量以及部署更新给网络带来的影响。

3. 评估和计划
评估和计划阶段管理员的目标是在一个类似产品环境的环境（与产品环境分离）中测试更新，查看重要业务系统和应用程序是否兼容，确定将更新部署到产品中的必要任务，计划更新发布，构建发布以及进行接受发布的测试。

在测试环境中评估更新时，管理员可以运行在实际部署中使用的许多 SUS 2.0 功能。这些功能包括创建订阅，设置自动同步 SUS 2.0 服务器的计划，创建计算机目标组以及确定要下载和安装到这些组的更新，运行预先部署检查和安排自动更新安装计划。测试期间和测试完成后，管理员可以使用 SUS 2.0 提供的标准报告监视测试更新安装的成功进行。

4. 部署
部署阶段的管理员目标是测试、审批和计划更新安装并在部署完成后检查进程。

要考察产品环境以在部署前确保可以处理更新，SUS 2.0 计划让管理员检查更新属性并使用预先部署检查在安装更新前确定影响。要建立更新应用至产品的顺序，管理员可以使用 SUS 2.0 基于网络和人力资源创建最有效的上游和下游以及独立和副本 SUS 2.0 服务器配置。此外，管理员可以通过使用组策略或者通过 API 扩展管理服务器或客户端，配置客户端如何与 SUS 2.0 服务器或 Windows Update 通信。

通过 SUS 2.0 管理工具，管理员可以指定计算机的目标组并确定要部署到这些组的更新。如果在更新部署到产品环境后，证明更新不合适，计划使管理员可以启动更新安装（如有必要，在截止日期前启动）或启动卸载。管理员还可以使用报告确定计算机或目标组的更新部署的成功。

进程完成后
管理员按序完成每个阶段后，返回评估阶段，继续清查现有的计算资产、评估可能存在的安全威胁和漏洞，确定更新信息的优先来源以及评估现有软件分发体系结构和操作有效性。

SUS 2.0 管理更新
SUS 2.0 目前计划启用下列方案。

SUS 2.0 服务器的计划方案
Microsoft 正在计划为 SUS 2.0 服务器启用下列方案：

• 将多个不同更新部署到具有良好控制级的计算机组
使用 SUS 2.0 管理工具，管理员可以创建一个或多个计算机目标组，然后确定将一个或多个更新安装到这些组中的计算机上。管理员还可以设置截止时间（日期和时间），在该日期之前选定更新将安装到指定目标组。
在 Active Directory 环境中，管理员可以根据当前计划使用组策略将客户端计算机分配到使用 SUS 2.0 管理工具创建的目标组。新的组策略使客户端计算机能够使用客户端目标。当这些计算机连接到 SUS 2.0 服务器时，可以与自身所属的组通信，在这种情况下服务器自动将其添加到组。

• 基于管理员首选项从 Microsoft 无缝并有效下载更新
使用 SUS 2.0 管理工具管理员可以创建订阅，并在其中指定从 Microsoft 下载哪些更新以及指定更新下载的计划。订阅运行时，包含订阅的 SUS 2.0 服务器会用 Windows Update 中可用的匹配类别中的更新同步订阅中指定的更新。在订阅中指定更新时，管理员可以选择平台、产品、语言和更新类别。例如，订阅可以包括只下载英文版的 Windows XP 的重要更新和英文版的 Office XP 的安全更新的下载请求。

• 确定公司网络中更新的适用性
SUS 2.0 管理工具目前计划为管理员提供执行更新影响分析（或预先部署检查）的能力，可在产品环境中部署更新前用于所有计算机或特定计算机组。在确定一组更新的适用性时，管理员可以使用更新状态报告监视审核更新的进程。

• 检查一组计算机中的部署状态
SUS 2.0 管理工具计划为管理员提供生成更新状态报告的能力，报告中显示执行某一操作（或所有操作）的所有更新（例如，安装或卸载）以及操作发生的日期。此外，管理员还可以生成该报告以显示所有计算机的更新或特定目标组的更新。

• 启动更新卸载（如有必要）
如果部署更新后管理员确定更新不适合产品环境，可以卸载更新（如果该更新支持卸载）。对于卸载，管理员可以设置截止日期，超过该日期更新将自动卸载。要知道更新是否支持卸载，管理员可以通过管理工具接口检查更新的详细信息。

• 通过脚本扩展管理 SUS 2.0 组件
计划使管理员可以通过 API 管理服务器端和客户端 SUS 2.0 组件。计划使服务器 API 基于 .NET，而客户端 API 基于 COM。计划使 SDK 对两种组件均可用。

自动更新的计划方案
SUS 2.0 目前计划启用下列自动更新方案：

• 自动更新的一次单击配置体验
通过在控制面板中的自动更新页中的一次单击，拥有管理权限的用户可以指定是否要在下载或安装更新前接收来自自动更新的通知。其他选项（包括设置自动安装更新的时间）在这种情况下在自动更新页中进行配置一样容易。

• 自动获得重要更新和其他 Microsoft 更新的最新信息
计划使用户不必搜索重要更新和信息 - 自动更新会直接传递给用户的计算机。当用户在线并使用 Internet 连接从 Windows Update 网站搜索所需下载更新时，自动更新可以识别出。

计划的部署方案
SUS 2.0 具有足够的灵活性，可以满足多种组织（从拨号连接的小型业务客户到有跨多个站点分布的成千上万用户的大型业务客户）更新管理的需要。根据组织规模、位置和连接系统结构，管理员可以确定最有效的方式横向扩展 SUS 2.0 服务器（可以为一个或多个服务器）。

以下列出的是在小型、中型和未连接的网络中部署 SUS 2.0 组件的通用计划方案。

单个 SUS 2.0 服务器（小型或简单网络）
在小型或简单网络方案中，根据计划发布，管理员可以在企业防火墙内设置运行 SUS 2.0 的服务器，这样可以直接从外部的公共 Windows Update 站点同步内容，并将更新分发到客户端计算机，如下图所示。

单个 SUS 2.0 服务器

多个 SUS 2.0 服务器（中型或更复杂网络）
以下是两个计划的通用方案，用于在中型或更复杂网络中部署 SUS 2.0 组件。

多个独立的 SUS 2.0 服务器
在此计划方案中，管理员可以部署多个配置好的服务器，这样每个服务器可以单独管理，并且每个服务器可以将其内容与 Windows Update 同步，如下图所示。

多个独立的 SUS 2.0 服务器

此方案中的部署方法适用于将不同的局域网 (LAN) 或广域网 (WAN) 的网段作为独立实体（如分支机构办公室）进行管理的情况。也适用于当一个运行 SUS 2.0 的服务器配置为仅对运行某一定操作系统（如 Windows 2000）的客户端部署更新而另一个服务器配置为仅对运行其他操作系统（如 Windows XP）的客户端部署更新的情况。在这些情况下，两个服务器无须同步内容。

多个内部同步 SUS 2.0 服务器
计划使管理员可以部署多个运行 SUS 2.0 的服务器，其中这些服务器在组织的 Intranet 内同步所有内容。在这种情况下，一个服务器设置为父服务器或上游服务器，然后其他服务器将同步其上的来源。附加运行 SUS 2.0 的服务器 - 子服务器或下游服务器，从上游服务器同步内容的服务器。子服务器可以执行手动或自动同步，同步包括更新以及批准更新的列表，或只有更新而无列表。如果适用，可以在地理上分散的网络中定位服务器，以提供对所有客户端的最佳连接。

如第二幅图中所示，管理员可以设计部署多个内部同步服务器，而对 Internet 开放其中一个（第一幅图的扩展版本）或通过向外扩展设计将其 Intranet 完全与 Internet 隔离，如下图所示。

多个内部同步 SUS 2.0 服务器

断开连接的 SUS 2.0 服务器（安全性高的网络，无 Internet 连接）
如果网络的、基于 Windows 的计算机没有连接到 Internet，在此计划方案中，管理员可以设置运行 SUS 2.0 的内部服务器，如下图所示。在此示例中，创建了一个与 Internet 相连但与 Intranet 隔离的服务器。当在此服务器上完成下载、测试和审批后，管理员在 Intranet 内向运行 SUS 2.0 的服务器以及向分发点手动发送媒体。下图以最简形式说明此模型，可以将其扩展到任意规模的部署。

断开连接的 SUS 2.0 服务器（没有连接到 Internet 的 Intranet）

后续步骤
有关 SUS 1.0 的信息，请参阅Microsoft 网站上的 Software Update Services，其网址为 http://go.microsoft.com/fwlink/?LinkId=22631（英文）。虽然 SUS 2.0 极大地扩展了 SUS 1.0 的功能集，但是您现在可以执行下列操作：

该版本新增加的功能主要有：
支持对更多微软产品进行更新，根据目前评估版的估计，除了Windows，还有Office、Exchange、SQL等产品被支持。
可以根据更新所应用的产品以及类型自动下载更新程序。

支持更多语言。

通过2.0版的后台智能传输服务（Background Intelligent Transfer Service，BITS）最大限度利用网络带宽。

可以将更新程序应用给目标计算机或者目标计算机组。

在安装之前就可以判断关键更新以及安全更新程序是否适用于某台计算机。

更灵活的部署选项。

更详细的报告。

灵活的数据库选项。

数据合并以及导出/导入功能。

通过公开的API对现有功能进行扩展。

首页右上角有几个大图标，分别可以打开不同功能的页面，接下来就分别看看。

更新
这里显示了服务器已经下载回来的所有补丁程序（安装文件，或仅目录），并且根据不同的类别和应用范围进行了分类。在页面最左侧是更新链接以及筛选面板，对于每个我们经过测试没问题的更新程序，只要选中程序，然后点击这里的“更改批准”按钮就可以将该补丁程序发布出去，而对于那些不需要的补丁程序，则可以在点击选中之后点击“拒绝更新”按钮。

左面的筛选列表主要是为了确定用户要同步的信息，更新程序列表中，最左侧的图标表示了每个更新程序的不同重要性，而将鼠标指针悬停在该图标上方稍等片刻之后这类图标的含义就会显示出来，而第二列类似文件柜的图标则显示了每个更新的下载情况，如果该图标是灰色的，表明更新还没有被下载，如果是淡蓝色并带有绿色箭头则表示更新正在被下载，深蓝色则表明下载已经完成。“标题”一列显示了每个更新程序的名称；“分类”一列则显示了更新程序所属的类别；“已释放”一列显示了该程序被微软发布的时间，注意，这里显示的是微软发布该程序的时间，而不是你下载到WSUS服务器上，或者批准发布的时间；最后一列“批准”则显示了该程序当前的状态。侧面板的下半部分详细显示了上半部分被选中的更新的详细信息，从介绍到应用的语言以及重要程度都有提及，该面板上还有两个其他选项卡，在这些选项卡中可以了解更多详细信息，例如被选中的补丁程序已经应用到了哪些计算机，哪些计算机需要但是还没有安装，甚至哪些在安装的时候失败了，都可以从中看到。

报告
报告页面上提供的链接则可以对服务器的状态以及补丁的下载和安装情况生成详细的报告，让管理员做到心中有数。

计算机
这是WSUS的一个新功能，我们可以根据实际情况（例如运行不同操作系统或不同的用途）将所有计算机分别归类为不同的组，这样在部属更新的时候就可以为不同的组部署不同的更新

选项
WSUS的主要设置都是在这里进行的，在安装好WSUS之后，首先建议你在这里根据实际需要对选项进行调整。

同步选项
首先是同步计划，我们可以根据自己的网络情况设置不同的计划，例如可以让服务器每天凌晨的网络使用低峰里倒微软的服务器去同步，当然，你也可以选择自己手工同步。
接着是“自动批准选项”。“更新”选项下我们可以在很对不同类别的更新程序采取不同的批准方式，首先选中“使用下列规则自动批准更新进行检测”，然后选中下方的“使用下列规则自动批准更新进行安装”，距离来说，如果我们需要带WSUS检测到有新的关键更新或安全更新之后就自动批准、下载，并发布出去，那么可以这样设置；点击“批准进行安装”类别下的“添加/删除分类”按钮，打开图15所示的对话框，然后在这里选中“安全更新程序”以及“关键更新程序”，点击确定。接着点击“添加/删除计算机组”按钮，然后确保所有计算机组都被选中。

最后是计算机选项在这里可以指定如何将计算机指定给组。如果您使用 Windows Server Update Services 来指定，那么新计算机将被自动放到“未指定的计算机”组中。

下面我开始说明一些Windows Server Update Services的使用方法
先决条件

SUS有自己的服务器端和客户端。

对于服务器端，有如下的要求：

硬件：700MHz主频以上的CPU，512MB以上内存，6GB以上的硬盘空间

软件：Windows 2000 Server SP2 以上的操作系统，Windows Server 2003，IIS 5以上版本，IE 5.5以上版本

可见SUS对硬件的要求比较高，不过这里有一点是要说明的，微软推荐的这种硬件配置可以同时为15000台计算机提供升级服务，因此如果你的网络没有这么大规模，硬件的条件可以适当放宽。另一方面，对于6GB的硬盘空间，这是用来保存所有语种的补丁文件的，如果你的网络中只有简体中文版或者英文版操作系统的计算机，那你可以通过设置而不下载其他语种的补丁文件，以节约硬盘空间。

对于客户端，同样有一些要求：

首先，SUS服务只能为Windows 2000 SP2/XP/2003提供升级服务，这就意味着Windows NT和Windows 9x以及Windows 2000 SP1都无法通过这个服务升级。

对于Windows 2000 SP2和Windows XP，首先还需要安装一个SUS的客户端程序；对于Windows 2000 SP3及以上版本，Windows XP SP1 及以上版本和Windows Server 2003，都不需要安装客户端，直接就可以在组策略中进行设置。

工作原理

对于服务器端，可以理解为微软升级服务器的一个本地镜像。服务器端可以自动或者手动跟微软的升级服务器同步，下载所有的补丁程序，然后发布在企业内部的网络中。

客户端则跟通常情况没有太大差别，只是通过组策略的设置把默认的微软服务器改为企业内部的升级服务器的路径，就可以自动下载和安装。

而如果你的网络环境有特别需要，你还可以架设多个SUS服务器，客户端可以选择任意一个服务器下载补丁。对于服务器，你还可以设置其它的SUS服务器都跟同一个主SUS保持同步，而不是各自去跟微软的服务器同步，这样进一步减少了网络流量。

应用范围

SUS只能提供Windows操作系统的关键更新和Service Pack，驱动程序和其他更新都是不包括在内的。而微软的其他产品，例如Office、Exchange等的升级也不包括。

服务器端的配置

在本文中，我们会练习在一台Windows Server 2003 Standard独立服务器上安装并配置SUS服务。

首先要下载服务器端的安装文件，然后直接执行安装，其中一切选项都可以按照默认设置进行。需要注意的是，由于安全方面的原因，SUS服务器的系统盘和保存SUS补丁文件的硬盘分区都必须是NTFS文件系统。另外，如果你是在Windows 2000 Server操作系统上安装SUS，安装程序还会同时为你安装IIS Lockdown Tool，这是一个提高IIS安全性的软件。

服务器端软件安装好后就可以开始设置了，设置SUS服务器有两种方法：本地设置和远程设置，设置需要你有Administrators组的权限。

对于本地设置，只要在控制面板的管理工具中双击“Microsoft Software Update Services”即可。

而远程管理则需要在远端计算机上打开IE浏览器（5.5以上版本），然后在地址栏输入“http://服务器名或IP/susadmin” 然后回车，接着输入相应的用户名和密码登录。

首先先让我们看看他是如何安装的

进入管理界面后首先要进行同步配置首先选择要更新的软件版本

然后选择分类

然后就可以进行更新操作了
之后需要配置客户端计算机
该操作可以配置一台计算机，也可以同时配置多台计算机，具体操作方法是：将这些计算机包括在组策略对象 (GPO) 中，然后针对该对象执行下述过程。Microsoft 建议您新建一个仅包含 WSUS 设置的 GPO，然后将此 WSUS GPO 链接到适用于您的环境的 Active Directory 容器。在简单环境中，您可能将单个 WSUS GPO 链接到域。在较为复杂的环境中，您可能将多个 WSUS GPO 链接到多个组织单位 (OU)，从而可以对不同类型的计算机应用不同的 WSUS 策略设置。
设置客户端计算机包括以下四个过程：

加载 WSUS 管理模板。
将计算机指向 WSUS 服务器。
配置自动更新的行为。
设置计算机和 WSUS 服务器之间的连接频率。
加载 WSUS 管理模板
在组策略对象编辑器中，右键单击任一管理模板节点。
单击“添加/删除模板”。
单击“添加”。
在“策略模板”中，单击“wuau.adm”，然后单击“打开”。
在“添加/删除模板”中，单击“关闭”。
将计算机指向 WSUS 服务器
在组策略对象编辑器中，依次展开“计算机配置”、“管理模板”、“Windows 组件”，然后单击“Windows Update”。
在详细信息窗格中，单击“指定 Intranet Microsoft 更新服务位置”。
同时在“为检测更新设置 Intranet 更新服务”和“设置 Intranet 统计服务器”中键入同一 WSUS 服务器的 HTTP URL。例如，在上述两个文本框中键入 http://服务器名，其中服务器名是 WSUS 服务器的名称。
单击“确定”，然后配置自动更新的行为。
注意

每台客户端计算机只能设置为一次与一台 WSUS 服务器进行通信。如果以后更改上述设置，并指定一台不同的 WSUS 服务器，客户端计算机便会停止与先前指定的 WSUS 服务器的连接。但是，该客户端计算机将仍然保留在先前 WSUS 服务器上指定的计算机列表和计算机组中。此外，先前的 WSUS 服务器将报告该客户端计算机上一次与其进行连接的时间（该时间必须是精确的时间 - 应该在该客户端计算机停止与该服务器进行连接之前）。要使客户端计算机不再出现在先前指定的 WSUS 服务器上，必须将该计算机从 WSUS 服务器中删除。有关执行此任务的步骤，请参阅从 WSUS 服务器中删除计算机。
配置自动更新的行为
在组策略对象编辑器中，依次展开“计算机配置”、“管理模板”、“Windows 组件”，然后单击“Windows Update”。
在详细信息窗格中，单击“配置自动更新”。
选择下列选项之一：
提醒下载并提醒安装。该选项会在下载和安装更新之前对已登录的管理用户进行提醒。
自动下载并提醒安装。该选项会自动开始下载更新，然后在安装更新之前对已登录的管理用户进行提醒。
自动下载并计划安装。该选项会自动下载并安装更新。如果将自动更新配置为执行计划安装，那么还必须设置执行计划安装的日期和时间。
允许本地管理员选择设置。该选项允许本地管理员使用控制面板中的“自动更新”来自行选择配置选项。例如，他们可以选择自己的计划安装时间。不允许本地管理员禁用自动更新。只有当自动更新完成自我更新以便与 WSUS 兼容之后，才会显示“允许本地管理员选择设置”选项。
设置计算机和 WSUS 服务器之间的连接频率
在组策略对象编辑器中，依次展开“计算机配置”、“管理模板”、“Windows 组件”，然后单击“Windows Update”。
在组策略对象编辑器的详细信息窗格中，单击“自动更新检测频率”，然后设置该选项。
连接间隔的确切时间实际上等于此处指定的小时数减去指定小时数的百分之零到百分之二十。例如，如果使用该策略指定的连接频率为 20 小时，那么所有应用该策略的客户端都会每隔 16 小时到 20 小时检查一次更新。如果将状态设置为“启用”，Windows 将按照指定的间隔检查是否具有可用的更新。如果将状态设置为“禁用”或“未配置”，Windows 将按照 22 小时的默认间隔检查是否具有可用的更新。

注意

如果希望 WSUS 服务器接收更新，则必须还将它视为一台客户端计算机。这样便可以针对 WSUS 服务器执行上述过程；例如，在本主题所述的过程中，您需要将服务器包括在域 GPO 中。
WSUS 客户端计算机要求自动更新与 WSUS 兼容。在多数情况下，您无需考虑此事项。当客户端计算机首次与 WSUS 服务器连接时，自动更新便会进行自我更新（假如您已经执行了默认服务器安装 - WSUS 已安装在“默认网站”上）。但是，如果您运行的是没有附带任何 Service Pack 的 Windows XP 版本，自动更新便无法自动进行自我更新。如果您在网络中运行该版本的 Windows XP，则请参阅部署 Microsoft Windows Server Update Services（文档可能为英文）(http://www.microsoft.com/)，了解有关详细信息。
管理员定义的配置选项（无论是在 Active Directory 环境中借助适用于基于域的 GPO 的组策略进行设置，还是在非 Active Directory 环境中通过配置注册表或本地 GPO 进行设置）始终优先于用户定义的选项。使用管理策略配置自动更新时，便会在客户端计算机上禁用自动更新用户界面。
有关在 Active Directory 和非 Active Directory 网络环境中设置和配置客户端计算机的选项的详细信息，请参阅部署 Microsoft Windows Server Update Services（文档可能为英文）。(http://www.microsoft.com/)

然后要使用安全套接字层(SSL)
要设置 SSL，必须在 WSUS 服务器上安装证书，然后将客户端计算机（和下游 WSUS 服务器，如果有的话）配置为信任服务器证书。
客户端的配置

客户端我们分两种情况说明，那就是域环境和工作组环境。首先看看工作组环境。

注意：以下内容涉及到活动目录以及组策略，而Windows XP Home Edition即没有组策略也无法加入域，因此不在我们这里的讨论范围。

工作组环境下需要对每台客户端计算机分别设置，如果网络中有较多的计算机这样显然很麻烦，好在通常计算机数量多的情况下管理员都会使用活动目录的方式管理，因此这个问题并不严重，我们继续看下去。

对于Windows 2000 SP2和Windows XP，我们要先安装SUS客户端

安装后，在客户端的运行中输入“gpedit.msc”打开组策略编辑器，并依次展开“计算机配置”-“管理模板”，然后在“管理模板”上点击鼠标右键，选择“添加/删除模版”，然后在图六的界面上点击“添加”按钮，并找到%windir%\inf目录下的wuau.adm文件，双击添加。接着继续打开“Windows组件”-“Windows Update”（这一项只有在安装了客户端软件并添加后才会出现），在窗口右侧就会显示出两条可用的策略。其中“配置自动更新”可以让你设置进行更新的时间和处理方法，“指定企业内部互联网…”则用来指定服务器的位置，你可以以“http://服务器名称”或者“http://服务器IP”的方式输入。而接下来你要做的就是分别在网络中的每台计算机上进行同样的设置。

处理好这些后就可以了，以后每到预先设置的时间，程序就会自动连接到指定的升级服务器检查更新，如果有更新，则会按照预先的设置，或者自动下载并询问安装，或者提示用户。需要注意，SUS对于客户端没有可访问的页面，所有的升级只能在后台自动进行。

对于Windows XP SP1和Windows 2000 SP3 还有Windows Server 2003，这些操作系统已经安装了客户端，因此直接在组策略中按照上面的方法设置即可。

如果你的网络规模比较大，应用了活动目录，那么管理起来会更加方便。

在域控制器上的运行中输入“dsa.msc”并回车，打开Active Directory用户和计算机设置窗口，在要创建策略的OU或者域上点击鼠标右键，选择“属性”，然后在属性窗口中打开“组策略”选项卡，并点击“新建”按钮，给新建的策略命名（例如叫做SUS，图七）。选中新建的组策略，点击“编辑”按钮，接着会弹出一个组策略设置窗口，这跟我们平常运行gpedit.msc打开的窗口很类似，不过这里可以为整个域中的所有计算机设置组策略。

在这个窗口中依次展开“计算机配置”-“管理模板”-“Windows 组件”-“Windows Update”，然后通过设置这里的策略就可以给所有登入域的计算机设置SUS客户端的工作参数。有一点是需要注意的，如果客户端的操作系统是Windows 2000 SP2、Windows XP，那么首先仍然需要安装SUS客户端软件。

整个客户端的设置工作就是这样了。相信经过设置，以后管理员的维护工作将会更加轻松，而网络中的计算机也会更加安全！

shangrh 发表于 >2005-6-9 10:15:25 [全文] [评论] [引用] [推荐] [档案] [推给好友]

2005-6-9

Windows Server Update Services 2.0更新及使用教程

大部分对计算机比较熟悉的朋友都知道，通常安装好Windows 操作系统后要做的第一件事就是上Windows Update网站去给Windows 安装补丁程序，否则各种漏洞对系统就是一个很大的威胁。不过遗憾的是很多人还没有这样的意识，疏忽了给系统打补丁。这也间接造成了病毒的横行，例如去年的“蠕虫王”和前几天的“冲击波”，这两个病毒都是利用了微软软件的漏洞编写和传播的，遗憾的是在这些病毒广泛流传之前，相应软件的补丁程序早就已经由微软发布出来并提供了免费下载，只要用户能经常性地访问Windows Update网站打补丁，就不会感染这些病毒，可是很多人都疏忽了这一点。好在经过这两次教训，更多的人知道“打补丁”的重要性，可是问题又来了。

微软的升级服务器都架设在国外，有时候由于网络的原因造成了国内用户连接服务器的速度非常慢，这些时候光下载补丁就要一个多小时的时间，效率非常低。另一方面，对于有上百台电脑的企业，每台电脑都连接到微软的服务器去下载上百兆字节的补丁程序，这对企业的网络带宽也是一个不小的负担，况且由于大家都到微软的服务器下载补丁，管理员就无法对补丁程序的内容进行控制，如果某个补丁正好跟企业内部广泛使用的某个软件有冲突的话，还可能造成更大的麻烦。现在，问题解决了，那就是使用微软的SUS（Software Update Service，软件更新服务）服务。

而SUS的后续版本Windows Server Update Services（下文统一简称为WSUS）又将带来什么新功能呢?

我们来进入文章的第一部分强大的更新服务器WSUS

虽然美国微软已经把软件名更名为Windows Server Update Services 2.0（WSUS）但是微软中国还叫Software Update Services 2.0（SUS）其实是一个软件。

我们来看下微软中国的关于Software Update Services 2.0的说明吧

简介
即将发布的 Software Update Services (SUS) 2.0 致力于帮助用户对基于 Microsoft® Windows® 2000 和 Windows Server™ 2003 的服务器以及运行 Microsoft® Windows® 2000 Professional 或 Windows® XP Professional 的台式机快速部署最新的重要更新和安全更新。

通过使用计划发布的 SUS 2.0，信息技术 (IT) 管理员可以完全控制管理通过 Windows Update 发布给网络中的计算机的更新的分发。

SUS 2.0 解决方案提供包括下列组件的管理体系结构：

• Windows Update - 包括所有基于产品和更新类型的可用 Microsoft 更新的 Microsoft 网站。

• 服务器组件 - Microsoft 软件更新服务，称为 SUS 2.0 服务器，用于安装在公司防火墙内运行 Windows 2000 Server 或 Windows Server 2003 家族操作系统的计算机上。服务器组件提供通过基于 Web 的工具管理和分发更新的管理功能，管理员可以访问公司网络中的任何 Windows 计算机。

• 客户端组件 - 自动更新（Automatic Updates），即客户端组件，在接收 Microsoft 产品更新的计算机上运行。本组件可以将服务器和客户端计算机直接连接至 Windows Update 或连接至接收更新的运行 SUS 2.0 的服务器上。自动更新组件计划纳入 Windows 2000 Service Pack 4 (SP4) 和更高版本、Windows XP 和更高版本以及 Windows Server 2003 中。

SUS 2.0 中计划包含的功能
SUS 2.0 构建在 SUS 1.0 的功能之上，目前计划提供下列功能：

• 扩展对包括 Office、SQL Server、Exchange 和硬件驱动程序在内的 Microsoft 产品的支持

• 扩展对附加更新类别的支持

• 提供使用 Windows 客户端或服务器计算机支持的任何语言的计算机部署更新的能力

• 自动排列优先级和下载重要更新

• 通过后台智能传输服务 (BITS) 技术提高带宽效率

• 提供对特定计算机组进行更新的能力

• 提供管理员选择和决定自动下载特定类型更新的计划的能力

• 改进了报告能力，使管理员能够监视更新部署状态和服务器的正常运转

• 扩展了通过应用程序编程接口 (API) 和脚本管理客户端和服务器组件的能力

• SQL Server 引擎用作 SUS 2.0 数据知识库

• 方便地从 SUS 1.0 迁移到 SUS 2.0

要求
计划的 SUS 2.0 要求如下：

服务器
• Windows 2000 Server SP4 或更高版本或 Windows Server 2003

• Microsoft Internet Information Services (IIS) 5.0 或更高版本、Microsoft Internet Explorer 6.0

客户端
• Windows 2000 Service Pack 3 (SP3) 或更高版本、Windows XP 和 Windows Server 2003

功能一览
SUS 2.0 目前计划提供下列功能。

客户端功能
自动更新使 Windows 能够自动下载和安装 Microsoft 产品的更新。下表中列出的是计划的客户端组件的主要功能。

SUS 2.0 计划的客户端功能

功能说明
内置安全
内容：
SUS 2.0 客户端将只信任由 Microsoft 签名的特定内容，因此，不可能篡改内容。
客户端-服务器关系：SUS 2.0 客户端要求 SUS 2.0 服务器进行自身身份验证来建立通信，并使用安全协议加密会话期间交换的数据。
计算机隐私：SUS 客户端不发送任何个人标识信息给 Microsoft。搜集的数据绝对是一般信息并只用来改进服务。

自动检测、下载和安装适用更新
自动更新可以确定如果计算机缺少更新则可以自动启动下载和安装。
在托管环境中，客户端可以直接从 Windows Update 或从 SUS 2.0 服务器获得更新。
在托管环境中，管理员可以配置客户端检查 SUS 2.0 服务器新更新的频率。

用户可用的计划和通知选项
用户可用的计划和通知选项可以通过组策略进行配置。
具有管理权限的用户可以指定在自动下载、安装或设置安装计划前是否通知用户。此外，用户可以检索以前拒绝的更新或隐藏的更新。

有效的后台下载更新
自动更新计划使用 BITS（一种创新的带宽限制技术）,已内置入 Windows 2000 SP3 和更高版本的操作系统中，用于将更新下载至计算机。
BITS 技术提供下载期间的增量数据压缩 - 只从 SUS 2.0 服务器或 Windows Update 下载文件中发生更改的部分，这样可以通过自动更新有效分发 Service Pack。

安装更新时不中断用户
设置为该选项时，自动更新能够在无需重启或中断服务的情况下，一找到更新就立即安装，而不会等到计划的自动安装时间。而且，自动更新将把需要计算机重启的更新合并到一次重启中。
自动更新还去除用户与最终用户许可协议 (EULA) 交互的要求。在 SUS 环境中，EULA 将由管理员代表客户端在 SUS 2.0 服务器上接受。

强大的、可扩展的管理员管理能力
在 Active Directory® 目录服务环境中，计划为管理员提供通过使用组策略配置自动更新行为的可能性。在其他情况下，计划为管理员提供通过使用登录脚本或类似机制使用注册表项远程配置自动更新的能力。
此外，管理员可以使用脚本通过基于组件对象模型 (COM) 的 API 管理客户端。计划可使用软件开发工具包 (SDK)。

客户端计算机的自我更新
在管理员托管方案中，客户端计算机可以将其自动更新组件更新为新版本，而无需管理员重新配置计算机。

改进的更新适用规则
SUS 2.0 客户端具有仅下载和安装真正对计算机适用的特定更新的能力。而管理员不用猜测更新安装在何处，SUS 2.0 客户端与 SUS 2.0 服务器协同来评估将哪一个更新应用至特定系统。例如，客户在 Windows XP 计算机上安装适合于 Windows 2000 的更新时不会有风险。

服务器端功能
SUS 2.0 服务器管理工具计划提供一套强大的管理功能。下表中列出了服务器组件的功能。

SUS 2.0 计划的服务器端功能

功能说明
内置安全
SUS 2.0 管理工具页限于 SUS 2.0 服务器上的本地管理员。同步将通过更新服务器验证所有下载的数字签名。如果签名不是来自于 Microsoft，包将被删除。此进程使用的协议保证 SUS 2.0 服务器与 Windows Update 站点通信的安全性和可靠性。

更多内容
SUS 2.0 支持随时间推移更新所有的 Microsoft 产品。

新数据模型
SUS 2.0 组件旨在通过新数据模型处理更新，在该模型中更新之间可以存在复杂的关系（例如，更新之间的取代和依赖）。

更新管理体系结构和横向扩展支持
SUS 2.0 计划为管理员提供创建由 SUS 2.0 服务器层次结构组成的更新管理体系结构的能力。例如，SUS 2.0 服务器可部署为匿名服务器、从属副本主机或负载平衡群集。因此，SUS 2.0 横向扩展为可处理任意多个客户端。
此外，计划让管理员可以灵活选择配置计算机是直接从 Windows Update 还是从内部分发更新的 Intranet SUS 2.0 服务器获得更新。管理员还可以根据网络配置使用两种设置的组合。

预先部署检查和审批
通过在一个特定的目标组中向所有计算机发送预先部署请求，计划使管理员可以评估需要更新的计算机数目以及部署更新将影响网络的程度。预先部署检查使得管理员能够在实际部署安装更新前执行更新影响分析。

目标
目标计划使管理员能够创建同等级的计算机的目标组并从一个 SUS 2.0 服务器为那些组指定特定更新。此外，SUS 2.0 将支持下列功能：客户端和服务器端目标、支持 Active Directory 环境的基于注册表的策略以及非 Active Directory 环境的服务器端列表。

管理员定义的下载行为
除了 BITS 技术将促进的有效后台下载外，计划的 BITS 技术使得服务器能够同步基于管理员定义的更新首选项和计划。管理员能够在更新下载时指定时间段（包括部署的仅下载作为更新的选项）和出现下载时使用的网络带宽值。

基于截止时间的安装（或卸载）
计划让管理员能够强制安装更新的截止时间。在这种情况下用户不能在指定截止时间后延期安装更新。

卸载
如果更新支持卸载，当部署更新后确定更新不适合产品环境时管理员可以启动卸载更新。

报告
计划使管理员能够通过 SUS 2.0 报告功能监视更新活动和服务器的正常运转。为监视和管理更新活动，SUS 2.0 提供基于客户端发送的事件，包括每次更新、每台计算机和每个目标组的更新部署状态的标准报告。此外，如果管理员要创建客户报告，则能够访问 SUS 2.0 数据库中的只读视图。

通过 API 扩展管理
管理员可以使用脚本通过基于 .NET 的 API 管理 SUS 2.0 服务器。开发人员可以创建通过 SUS 2.0 API 与 SUS 2.0 集成的管理应用程序。可以使用 SDK。

导入和导出能力
管理员可以使用导入和导出功能在两个 SUS 2.0 服务器之间下载和传输更新。在这种情况下，导入和导出功能将使在没有物理 Internet 访问或与其他网络的 Internet 连接的断开的网络（受保护的网络）中的更新管理体系结构更易于管理，例如智能社区。

备份和还原服务器数据库
管理员可以很容易从 Microsoft® SQL Server™ 2000 Service Pack 2 (SP2) 或更高版本以及 Microsoft Data Engine (MSDE) 2000 数据库备份和还原 SUS 2.0 服务器的更新内容、部署操作事件和设置。

灵活的服务器配置选项
对于远程管理，服务器配置选项计划包括使用安全套接字层 (SSL) 或超文本传输协议 (HTTP) 与 SUS 2.0 服务器连接并支持除默认端口 80 以外其他端口用于客户端和服务器通信。如果 SUS 2.0 服务器通过代理服务器与 Internet 相连，管理员还可以配置代理服务器设置。

SUS 1.0 服务器的迁移工具
迁移工具使得 SUS 1.0 客户能够无缝地将以前 SUS 1.0 服务器上的管理设置迁移到 SUS 2.0 服务器。

SUS 2.0 和更新管理进程
本节说明 Microsoft 推荐的更新管理进程方法，还为管理员提供如何使用计划的 SUS 2.0 功能确保进程的四个阶段中的每一阶段都能成功的示例。注意：许多功能可以在一个以上的阶段中使用。有关计划的 SUS 2.0 管理功能的详细信息，请参阅本文档前面部分的“服务器端功能”。

1. 评估
管理员在评估阶段的目标是了解什么因素可能对产品环境构成威胁并了解准备产品环境以支持例行和紧急更新管理的方法。通过第一步，评估阶段实质是个持续进行的进程。

例如，管理员将评估有多少服务器和客户端需要更新，它们各自的存储和网络带宽需求以及部署一般更新的可以接受的时间。管理员还要确定要更新什么平台、产品和语言。基于这些因素，他们能够确定最有效的拓扑以横向扩展其 SUS 2.0 组件。SUS 2.0 旨在提供很多选项设置 SUS 2.0 组件，包括在 SUS 2.0 服务器上本地存储更新内容或根据需要从 Windows 下载内容。管理员还可以配置自动更新以在计算机上自动下载和安装缺少的更新。SUS 2.0 提供选项管理 Active Directory 和非 Active Directory 环境中的客户端。

SUS 2.0 计划提供标准合并报告，管理员可以在持续进行的基础上运行。这些报告提供与 SUS 2.0 服务器联系的计算机列表，然后是这些计算机的操作系统、语言和服务包级的列表。报告还将识别计算机安装或丢失了哪些更新并确定服务器的正常运行。

2. 识别
管理员在识别阶段的目标是以简便的方式发现新更新，确定更新是否与产品环境有关以及确定更新优先级。

SUS 2.0 管理工具旨在允许管理员创建订阅。管理员使用订阅可以确定按照产品和分类哪些更新与 Windows Update （或上游 SUS 2.0 服务器）同步；例如订阅可以只包含 Windows XP 重要更新和 Office XP 安全更新的下载请求。管理员可以为每个订阅设置同步计划。例如，管理员可以创建一个需要每天下载的重要更新的订阅，再创建另一个每周下载的可选更新的订阅。

要确定更新是否与产品环境相关，计划使管理员能够查看更新的属性。管理员还可以运行预先部署检查更新，旨在帮助管理员在产品环境中安装更新前评估需要更新的计算机数量以及部署更新给网络带来的影响。

3. 评估和计划
评估和计划阶段管理员的目标是在一个类似产品环境的环境（与产品环境分离）中测试更新，查看重要业务系统和应用程序是否兼容，确定将更新部署到产品中的必要任务，计划更新发布，构建发布以及进行接受发布的测试。

在测试环境中评估更新时，管理员可以运行在实际部署中使用的许多 SUS 2.0 功能。这些功能包括创建订阅，设置自动同步 SUS 2.0 服务器的计划，创建计算机目标组以及确定要下载和安装到这些组的更新，运行预先部署检查和安排自动更新安装计划。测试期间和测试完成后，管理员可以使用 SUS 2.0 提供的标准报告监视测试更新安装的成功进行。

4. 部署
部署阶段的管理员目标是测试、审批和计划更新安装并在部署完成后检查进程。

要考察产品环境以在部署前确保可以处理更新，SUS 2.0 计划让管理员检查更新属性并使用预先部署检查在安装更新前确定影响。要建立更新应用至产品的顺序，管理员可以使用 SUS 2.0 基于网络和人力资源创建最有效的上游和下游以及独立和副本 SUS 2.0 服务器配置。此外，管理员可以通过使用组策略或者通过 API 扩展管理服务器或客户端，配置客户端如何与 SUS 2.0 服务器或 Windows Update 通信。

通过 SUS 2.0 管理工具，管理员可以指定计算机的目标组并确定要部署到这些组的更新。如果在更新部署到产品环境后，证明更新不合适，计划使管理员可以启动更新安装（如有必要，在截止日期前启动）或启动卸载。管理员还可以使用报告确定计算机或目标组的更新部署的成功。

进程完成后
管理员按序完成每个阶段后，返回评估阶段，继续清查现有的计算资产、评估可能存在的安全威胁和漏洞，确定更新信息的优先来源以及评估现有软件分发体系结构和操作有效性。

SUS 2.0 管理更新
SUS 2.0 目前计划启用下列方案。

SUS 2.0 服务器的计划方案
Microsoft 正在计划为 SUS 2.0 服务器启用下列方案：

• 将多个不同更新部署到具有良好控制级的计算机组
使用 SUS 2.0 管理工具，管理员可以创建一个或多个计算机目标组，然后确定将一个或多个更新安装到这些组中的计算机上。管理员还可以设置截止时间（日期和时间），在该日期之前选定更新将安装到指定目标组。
在 Active Directory 环境中，管理员可以根据当前计划使用组策略将客户端计算机分配到使用 SUS 2.0 管理工具创建的目标组。新的组策略使客户端计算机能够使用客户端目标。当这些计算机连接到 SUS 2.0 服务器时，可以与自身所属的组通信，在这种情况下服务器自动将其添加到组。

• 基于管理员首选项从 Microsoft 无缝并有效下载更新
使用 SUS 2.0 管理工具管理员可以创建订阅，并在其中指定从 Microsoft 下载哪些更新以及指定更新下载的计划。订阅运行时，包含订阅的 SUS 2.0 服务器会用 Windows Update 中可用的匹配类别中的更新同步订阅中指定的更新。在订阅中指定更新时，管理员可以选择平台、产品、语言和更新类别。例如，订阅可以包括只下载英文版的 Windows XP 的重要更新和英文版的 Office XP 的安全更新的下载请求。

• 确定公司网络中更新的适用性
SUS 2.0 管理工具目前计划为管理员提供执行更新影响分析（或预先部署检查）的能力，可在产品环境中部署更新前用于所有计算机或特定计算机组。在确定一组更新的适用性时，管理员可以使用更新状态报告监视审核更新的进程。

• 检查一组计算机中的部署状态
SUS 2.0 管理工具计划为管理员提供生成更新状态报告的能力，报告中显示执行某一操作（或所有操作）的所有更新（例如，安装或卸载）以及操作发生的日期。此外，管理员还可以生成该报告以显示所有计算机的更新或特定目标组的更新。

• 启动更新卸载（如有必要）
如果部署更新后管理员确定更新不适合产品环境，可以卸载更新（如果该更新支持卸载）。对于卸载，管理员可以设置截止日期，超过该日期更新将自动卸载。要知道更新是否支持卸载，管理员可以通过管理工具接口检查更新的详细信息。

• 通过脚本扩展管理 SUS 2.0 组件
计划使管理员可以通过 API 管理服务器端和客户端 SUS 2.0 组件。计划使服务器 API 基于 .NET，而客户端 API 基于 COM。计划使 SDK 对两种组件均可用。

自动更新的计划方案
SUS 2.0 目前计划启用下列自动更新方案：

• 自动更新的一次单击配置体验
通过在控制面板中的自动更新页中的一次单击，拥有管理权限的用户可以指定是否要在下载或安装更新前接收来自自动更新的通知。其他选项（包括设置自动安装更新的时间）在这种情况下在自动更新页中进行配置一样容易。

• 自动获得重要更新和其他 Microsoft 更新的最新信息
计划使用户不必搜索重要更新和信息 - 自动更新会直接传递给用户的计算机。当用户在线并使用 Internet 连接从 Windows Update 网站搜索所需下载更新时，自动更新可以识别出。

计划的部署方案
SUS 2.0 具有足够的灵活性，可以满足多种组织（从拨号连接的小型业务客户到有跨多个站点分布的成千上万用户的大型业务客户）更新管理的需要。根据组织规模、位置和连接系统结构，管理员可以确定最有效的方式横向扩展 SUS 2.0 服务器（可以为一个或多个服务器）。

以下列出的是在小型、中型和未连接的网络中部署 SUS 2.0 组件的通用计划方案。

单个 SUS 2.0 服务器（小型或简单网络）
在小型或简单网络方案中，根据计划发布，管理员可以在企业防火墙内设置运行 SUS 2.0 的服务器，这样可以直接从外部的公共 Windows Update 站点同步内容，并将更新分发到客户端计算机，如下图所示。

单个 SUS 2.0 服务器

多个 SUS 2.0 服务器（中型或更复杂网络）
以下是两个计划的通用方案，用于在中型或更复杂网络中部署 SUS 2.0 组件。

多个独立的 SUS 2.0 服务器
在此计划方案中，管理员可以部署多个配置好的服务器，这样每个服务器可以单独管理，并且每个服务器可以将其内容与 Windows Update 同步，如下图所示。

多个独立的 SUS 2.0 服务器

此方案中的部署方法适用于将不同的局域网 (LAN) 或广域网 (WAN) 的网段作为独立实体（如分支机构办公室）进行管理的情况。也适用于当一个运行 SUS 2.0 的服务器配置为仅对运行某一定操作系统（如 Windows 2000）的客户端部署更新而另一个服务器配置为仅对运行其他操作系统（如 Windows XP）的客户端部署更新的情况。在这些情况下，两个服务器无须同步内容。

多个内部同步 SUS 2.0 服务器
计划使管理员可以部署多个运行 SUS 2.0 的服务器，其中这些服务器在组织的 Intranet 内同步所有内容。在这种情况下，一个服务器设置为父服务器或上游服务器，然后其他服务器将同步其上的来源。附加运行 SUS 2.0 的服务器 - 子服务器或下游服务器，从上游服务器同步内容的服务器。子服务器可以执行手动或自动同步，同步包括更新以及批准更新的列表，或只有更新而无列表。如果适用，可以在地理上分散的网络中定位服务器，以提供对所有客户端的最佳连接。

如第二幅图中所示，管理员可以设计部署多个内部同步服务器，而对 Internet 开放其中一个（第一幅图的扩展版本）或通过向外扩展设计将其 Intranet 完全与 Internet 隔离，如下图所示。

多个内部同步 SUS 2.0 服务器

断开连接的 SUS 2.0 服务器（安全性高的网络，无 Internet 连接）
如果网络的、基于 Windows 的计算机没有连接到 Internet，在此计划方案中，管理员可以设置运行 SUS 2.0 的内部服务器，如下图所示。在此示例中，创建了一个与 Internet 相连但与 Intranet 隔离的服务器。当在此服务器上完成下载、测试和审批后，管理员在 Intranet 内向运行 SUS 2.0 的服务器以及向分发点手动发送媒体。下图以最简形式说明此模型，可以将其扩展到任意规模的部署。

断开连接的 SUS 2.0 服务器（没有连接到 Internet 的 Intranet）

后续步骤
有关 SUS 1.0 的信息，请参阅Microsoft 网站上的 Software Update Services，其网址为 http://go.microsoft.com/fwlink/?LinkId=22631（英文）。虽然 SUS 2.0 极大地扩展了 SUS 1.0 的功能集，但是您现在可以执行下列操作：

该版本新增加的功能主要有：
支持对更多微软产品进行更新，根据目前评估版的估计，除了Windows，还有Office、Exchange、SQL等产品被支持。
可以根据更新所应用的产品以及类型自动下载更新程序。

支持更多语言。

通过2.0版的后台智能传输服务（Background Intelligent Transfer Service，BITS）最大限度利用网络带宽。

可以将更新程序应用给目标计算机或者目标计算机组。

在安装之前就可以判断关键更新以及安全更新程序是否适用于某台计算机。

更灵活的部署选项。

更详细的报告。

灵活的数据库选项。

数据合并以及导出/导入功能。

通过公开的API对现有功能进行扩展。

首页右上角有几个大图标，分别可以打开不同功能的页面，接下来就分别看看。

更新
这里显示了服务器已经下载回来的所有补丁程序（安装文件，或仅目录），并且根据不同的类别和应用范围进行了分类。在页面最左侧是更新链接以及筛选面板，对于每个我们经过测试没问题的更新程序，只要选中程序，然后点击这里的“更改批准”按钮就可以将该补丁程序发布出去，而对于那些不需要的补丁程序，则可以在点击选中之后点击“拒绝更新”按钮。

左面的筛选列表主要是为了确定用户要同步的信息，更新程序列表中，最左侧的图标表示了每个更新程序的不同重要性，而将鼠标指针悬停在该图标上方稍等片刻之后这类图标的含义就会显示出来，而第二列类似文件柜的图标则显示了每个更新的下载情况，如果该图标是灰色的，表明更新还没有被下载，如果是淡蓝色并带有绿色箭头则表示更新正在被下载，深蓝色则表明下载已经完成。“标题”一列显示了每个更新程序的名称；“分类”一列则显示了更新程序所属的类别；“已释放”一列显示了该程序被微软发布的时间，注意，这里显示的是微软发布该程序的时间，而不是你下载到WSUS服务器上，或者批准发布的时间；最后一列“批准”则显示了该程序当前的状态。侧面板的下半部分详细显示了上半部分被选中的更新的详细信息，从介绍到应用的语言以及重要程度都有提及，该面板上还有两个其他选项卡，在这些选项卡中可以了解更多详细信息，例如被选中的补丁程序已经应用到了哪些计算机，哪些计算机需要但是还没有安装，甚至哪些在安装的时候失败了，都可以从中看到。

报告
报告页面上提供的链接则可以对服务器的状态以及补丁的下载和安装情况生成详细的报告，让管理员做到心中有数。

计算机
这是WSUS的一个新功能，我们可以根据实际情况（例如运行不同操作系统或不同的用途）将所有计算机分别归类为不同的组，这样在部属更新的时候就可以为不同的组部署不同的更新

选项
WSUS的主要设置都是在这里进行的，在安装好WSUS之后，首先建议你在这里根据实际需要对选项进行调整。

同步选项
首先是同步计划，我们可以根据自己的网络情况设置不同的计划，例如可以让服务器每天凌晨的网络使用低峰里倒微软的服务器去同步，当然，你也可以选择自己手工同步。
接着是“自动批准选项”。“更新”选项下我们可以在很对不同类别的更新程序采取不同的批准方式，首先选中“使用下列规则自动批准更新进行检测”，然后选中下方的“使用下列规则自动批准更新进行安装”，距离来说，如果我们需要带WSUS检测到有新的关键更新或安全更新之后就自动批准、下载，并发布出去，那么可以这样设置；点击“批准进行安装”类别下的“添加/删除分类”按钮，打开图15所示的对话框，然后在这里选中“安全更新程序”以及“关键更新程序”，点击确定。接着点击“添加/删除计算机组”按钮，然后确保所有计算机组都被选中。

最后是计算机选项在这里可以指定如何将计算机指定给组。如果您使用 Windows Server Update Services 来指定，那么新计算机将被自动放到“未指定的计算机”组中。

下面我开始说明一些Windows Server Update Services的使用方法
先决条件

SUS有自己的服务器端和客户端。

对于服务器端，有如下的要求：

硬件：700MHz主频以上的CPU，512MB以上内存，6GB以上的硬盘空间

软件：Windows 2000 Server SP2 以上的操作系统，Windows Server 2003，IIS 5以上版本，IE 5.5以上版本

可见SUS对硬件的要求比较高，不过这里有一点是要说明的，微软推荐的这种硬件配置可以同时为15000台计算机提供升级服务，因此如果你的网络没有这么大规模，硬件的条件可以适当放宽。另一方面，对于6GB的硬盘空间，这是用来保存所有语种的补丁文件的，如果你的网络中只有简体中文版或者英文版操作系统的计算机，那你可以通过设置而不下载其他语种的补丁文件，以节约硬盘空间。

对于客户端，同样有一些要求：

首先，SUS服务只能为Windows 2000 SP2/XP/2003提供升级服务，这就意味着Windows NT和Windows 9x以及Windows 2000 SP1都无法通过这个服务升级。

对于Windows 2000 SP2和Windows XP，首先还需要安装一个SUS的客户端程序；对于Windows 2000 SP3及以上版本，Windows XP SP1 及以上版本和Windows Server 2003，都不需要安装客户端，直接就可以在组策略中进行设置。

工作原理

对于服务器端，可以理解为微软升级服务器的一个本地镜像。服务器端可以自动或者手动跟微软的升级服务器同步，下载所有的补丁程序，然后发布在企业内部的网络中。

客户端则跟通常情况没有太大差别，只是通过组策略的设置把默认的微软服务器改为企业内部的升级服务器的路径，就可以自动下载和安装。

而如果你的网络环境有特别需要，你还可以架设多个SUS服务器，客户端可以选择任意一个服务器下载补丁。对于服务器，你还可以设置其它的SUS服务器都跟同一个主SUS保持同步，而不是各自去跟微软的服务器同步，这样进一步减少了网络流量。

应用范围

SUS只能提供Windows操作系统的关键更新和Service Pack，驱动程序和其他更新都是不包括在内的。而微软的其他产品，例如Office、Exchange等的升级也不包括。

服务器端的配置

在本文中，我们会练习在一台Windows Server 2003 Standard独立服务器上安装并配置SUS服务。

首先要下载服务器端的安装文件，然后直接执行安装，其中一切选项都可以按照默认设置进行。需要注意的是，由于安全方面的原因，SUS服务器的系统盘和保存SUS补丁文件的硬盘分区都必须是NTFS文件系统。另外，如果你是在Windows 2000 Server操作系统上安装SUS，安装程序还会同时为你安装IIS Lockdown Tool，这是一个提高IIS安全性的软件。

服务器端软件安装好后就可以开始设置了，设置SUS服务器有两种方法：本地设置和远程设置，设置需要你有Administrators组的权限。

对于本地设置，只要在控制面板的管理工具中双击“Microsoft Software Update Services”即可。

而远程管理则需要在远端计算机上打开IE浏览器（5.5以上版本），然后在地址栏输入“http://服务器名或IP/susadmin” 然后回车，接着输入相应的用户名和密码登录。

首先先让我们看看他是如何安装的

进入管理界面后首先要进行同步配置首先选择要更新的软件版本

然后选择分类

然后就可以进行更新操作了
之后需要配置客户端计算机
该操作可以配置一台计算机，也可以同时配置多台计算机，具体操作方法是：将这些计算机包括在组策略对象 (GPO) 中，然后针对该对象执行下述过程。Microsoft 建议您新建一个仅包含 WSUS 设置的 GPO，然后将此 WSUS GPO 链接到适用于您的环境的 Active Directory 容器。在简单环境中，您可能将单个 WSUS GPO 链接到域。在较为复杂的环境中，您可能将多个 WSUS GPO 链接到多个组织单位 (OU)，从而可以对不同类型的计算机应用不同的 WSUS 策略设置。
设置客户端计算机包括以下四个过程：

加载 WSUS 管理模板。
将计算机指向 WSUS 服务器。
配置自动更新的行为。
设置计算机和 WSUS 服务器之间的连接频率。
加载 WSUS 管理模板
在组策略对象编辑器中，右键单击任一管理模板节点。
单击“添加/删除模板”。
单击“添加”。
在“策略模板”中，单击“wuau.adm”，然后单击“打开”。
在“添加/删除模板”中，单击“关闭”。
将计算机指向 WSUS 服务器
在组策略对象编辑器中，依次展开“计算机配置”、“管理模板”、“Windows 组件”，然后单击“Windows Update”。
在详细信息窗格中，单击“指定 Intranet Microsoft 更新服务位置”。
同时在“为检测更新设置 Intranet 更新服务”和“设置 Intranet 统计服务器”中键入同一 WSUS 服务器的 HTTP URL。例如，在上述两个文本框中键入 http://服务器名，其中服务器名是 WSUS 服务器的名称。
单击“确定”，然后配置自动更新的行为。
注意

每台客户端计算机只能设置为一次与一台 WSUS 服务器进行通信。如果以后更改上述设置，并指定一台不同的 WSUS 服务器，客户端计算机便会停止与先前指定的 WSUS 服务器的连接。但是，该客户端计算机将仍然保留在先前 WSUS 服务器上指定的计算机列表和计算机组中。此外，先前的 WSUS 服务器将报告该客户端计算机上一次与其进行连接的时间（该时间必须是精确的时间 - 应该在该客户端计算机停止与该服务器进行连接之前）。要使客户端计算机不再出现在先前指定的 WSUS 服务器上，必须将该计算机从 WSUS 服务器中删除。有关执行此任务的步骤，请参阅从 WSUS 服务器中删除计算机。
配置自动更新的行为
在组策略对象编辑器中，依次展开“计算机配置”、“管理模板”、“Windows 组件”，然后单击“Windows Update”。
在详细信息窗格中，单击“配置自动更新”。
选择下列选项之一：
提醒下载并提醒安装。该选项会在下载和安装更新之前对已登录的管理用户进行提醒。
自动下载并提醒安装。该选项会自动开始下载更新，然后在安装更新之前对已登录的管理用户进行提醒。
自动下载并计划安装。该选项会自动下载并安装更新。如果将自动更新配置为执行计划安装，那么还必须设置执行计划安装的日期和时间。
允许本地管理员选择设置。该选项允许本地管理员使用控制面板中的“自动更新”来自行选择配置选项。例如，他们可以选择自己的计划安装时间。不允许本地管理员禁用自动更新。只有当自动更新完成自我更新以便与 WSUS 兼容之后，才会显示“允许本地管理员选择设置”选项。
设置计算机和 WSUS 服务器之间的连接频率
在组策略对象编辑器中，依次展开“计算机配置”、“管理模板”、“Windows 组件”，然后单击“Windows Update”。
在组策略对象编辑器的详细信息窗格中，单击“自动更新检测频率”，然后设置该选项。
连接间隔的确切时间实际上等于此处指定的小时数减去指定小时数的百分之零到百分之二十。例如，如果使用该策略指定的连接频率为 20 小时，那么所有应用该策略的客户端都会每隔 16 小时到 20 小时检查一次更新。如果将状态设置为“启用”，Windows 将按照指定的间隔检查是否具有可用的更新。如果将状态设置为“禁用”或“未配置”，Windows 将按照 22 小时的默认间隔检查是否具有可用的更新。

注意

如果希望 WSUS 服务器接收更新，则必须还将它视为一台客户端计算机。这样便可以针对 WSUS 服务器执行上述过程；例如，在本主题所述的过程中，您需要将服务器包括在域 GPO 中。
WSUS 客户端计算机要求自动更新与 WSUS 兼容。在多数情况下，您无需考虑此事项。当客户端计算机首次与 WSUS 服务器连接时，自动更新便会进行自我更新（假如您已经执行了默认服务器安装 - WSUS 已安装在“默认网站”上）。但是，如果您运行的是没有附带任何 Service Pack 的 Windows XP 版本，自动更新便无法自动进行自我更新。如果您在网络中运行该版本的 Windows XP，则请参阅部署 Microsoft Windows Server Update Services（文档可能为英文）(http://www.microsoft.com/)，了解有关详细信息。
管理员定义的配置选项（无论是在 Active Directory 环境中借助适用于基于域的 GPO 的组策略进行设置，还是在非 Active Directory 环境中通过配置注册表或本地 GPO 进行设置）始终优先于用户定义的选项。使用管理策略配置自动更新时，便会在客户端计算机上禁用自动更新用户界面。
有关在 Active Directory 和非 Active Directory 网络环境中设置和配置客户端计算机的选项的详细信息，请参阅部署 Microsoft Windows Server Update Services（文档可能为英文）。(http://www.microsoft.com/)

然后要使用安全套接字层(SSL)
要设置 SSL，必须在 WSUS 服务器上安装证书，然后将客户端计算机（和下游 WSUS 服务器，如果有的话）配置为信任服务器证书。
客户端的配置

客户端我们分两种情况说明，那就是域环境和工作组环境。首先看看工作组环境。

注意：以下内容涉及到活动目录以及组策略，而Windows XP Home Edition即没有组策略也无法加入域，因此不在我们这里的讨论范围。

工作组环境下需要对每台客户端计算机分别设置，如果网络中有较多的计算机这样显然很麻烦，好在通常计算机数量多的情况下管理员都会使用活动目录的方式管理，因此这个问题并不严重，我们继续看下去。

对于Windows 2000 SP2和Windows XP，我们要先安装SUS客户端

安装后，在客户端的运行中输入“gpedit.msc”打开组策略编辑器，并依次展开“计算机配置”-“管理模板”，然后在“管理模板”上点击鼠标右键，选择“添加/删除模版”，然后在图六的界面上点击“添加”按钮，并找到%windir%\inf目录下的wuau.adm文件，双击添加。接着继续打开“Windows组件”-“Windows Update”（这一项只有在安装了客户端软件并添加后才会出现），在窗口右侧就会显示出两条可用的策略。其中“配置自动更新”可以让你设置进行更新的时间和处理方法，“指定企业内部互联网…”则用来指定服务器的位置，你可以以“http://服务器名称”或者“http://服务器IP”的方式输入。而接下来你要做的就是分别在网络中的每台计算机上进行同样的设置。

处理好这些后就可以了，以后每到预先设置的时间，程序就会自动连接到指定的升级服务器检查更新，如果有更新，则会按照预先的设置，或者自动下载并询问安装，或者提示用户。需要注意，SUS对于客户端没有可访问的页面，所有的升级只能在后台自动进行。

对于Windows XP SP1和Windows 2000 SP3 还有Windows Server 2003，这些操作系统已经安装了客户端，因此直接在组策略中按照上面的方法设置即可。

如果你的网络规模比较大，应用了活动目录，那么管理起来会更加方便。

在域控制器上的运行中输入“dsa.msc”并回车，打开Active Directory用户和计算机设置窗口，在要创建策略的OU或者域上点击鼠标右键，选择“属性”，然后在属性窗口中打开“组策略”选项卡，并点击“新建”按钮，给新建的策略命名（例如叫做SUS，图七）。选中新建的组策略，点击“编辑”按钮，接着会弹出一个组策略设置窗口，这跟我们平常运行gpedit.msc打开的窗口很类似，不过这里可以为整个域中的所有计算机设置组策略。

在这个窗口中依次展开“计算机配置”-“管理模板”-“Windows 组件”-“Windows Update”，然后通过设置这里的策略就可以给所有登入域的计算机设置SUS客户端的工作参数。有一点是需要注意的，如果客户端的操作系统是Windows 2000 SP2、Windows XP，那么首先仍然需要安装SUS客户端软件。

整个客户端的设置工作就是这样了。相信经过设置，以后管理员的维护工作将会更加轻松，而网络中的计算机也会更加安全！

看雪论坛脱壳基础知识入门（2006年版）

redwolf@redwolf.com.cn (redwolf) — Tue, 24 Oct 2006 16:10:57 +0800

转载自:看雪论坛

第一课 PE格式

   要想学脱壳，第一步就得掌握PE格式，PE是Portable Executable File Format（可移植的执行体）简写，它是目前Windows平台上的主流可执行文件格式。

Microsoft Visual C++提供的WINNT.H里有PE数据结构的完整定义。
推荐文档：
  ah007翻译的“PE文件格式”1.9版
  qduwg翻译的PE文件格式
  Iczelion's 的PE文件格式
  PE结构各字段偏移参考
  微软官方提供的PE文档(Revision 8.0 - May 16, 2006)

   学习PE格式的方法是自己先准备一个十六进制工具，如HexWorkshop，WinHex，用这些工具打开一个EXE文件对照着学。强烈推荐你用
Stud_PE v.2.2.0.5这款工具辅助学习PE格式。PE格式学习的重点是在输入表（Import Table）这块。
Stud_PE工具界面：

PE结构图：

第二课 SEH技术

   结构化异常处理（Structured Exception Handling，SEH）是Windows操作系统处理程序错误或异常的技术。SEH是Windows操作系统的一种系统机制，与特定的程序设计语言无关。
   外壳程序里大量地使用了SEH，如果不了解SEH，将会使你跟踪十分困难。

  SEH in ASM 研究(一)by hume
  SEH in ASM 研究(二)by hume
  Structured Exception Handling
  加密与解密二版菜鸟学习笔记(2) - SEH 结构化异常处理 by ytcswb

由于 Ollydbg   对SEH处理异常灵活，因此脱壳用Ollydbg会大大提高效率。

附CONTEXT结构环境：

代码:
typedef struct _CONTEXT {
/*000*/ DWORD       ContextFlags;
/*004*/ DWORD       Dr0;
/*008*/ DWORD       Dr1;
/*00C*/ DWORD       Dr2;
/*010*/ DWORD       Dr3;
/*014*/ DWORD       Dr6;
/*018*/ DWORD       Dr7;
/*01C*/ FLOATING_SAVE_AREA FloatSave;
/*08C*/ DWORD       SegGs;
/*090*/ DWORD       SegFs;
/*094*/ DWORD       SegEs;
/*098*/ DWORD       SegDs;
/*09C*/ DWORD       Edi;
/*0A0*/ DWORD       Esi;
/*0A4*/ DWORD       Ebx;
/*0A8*/ DWORD       Edx;
/*0AC*/ DWORD       Ecx;
/*0B0*/ DWORD       Eax;
/*0B4*/ DWORD       Ebp;
/*0B8*/ DWORD       Eip;
/*0BC*/ DWORD       SegCs;
/*0C0*/ DWORD       EFlags;
/*0C4*/ DWORD       Esp;
/*0C8*/ DWORD       SegSs;
/*0CC*/     BYTE    ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];
/*2CC*/ } CONTEXT;

第三课认识壳

1. 什么是壳？

   在一些计算机软件里也有一段专门负责保护软件不被非法修改或反编译的程序。它们一般都是先于程序运行，拿到控制权，然后完成它们保护软件的任务。由于这段程序和自然界的壳在功能上有很多相同的地方，基于命名的规则，就把这样的程序称为“壳”了。

推荐文档：
  一切从“壳”开始

描述壳的示意图：

2. 壳的加载过程

    这里谈的加壳工具不是WinZIP、WinRAR等数据压缩工具，而是谈压缩可执行文件EXE或DLL的工具。加壳过的EXE文件是可执行文件，它可以同正常的EXE文件一样执行。用户执行的实际上是外壳程序，这个外壳程序负责把用户原来的程序在内存中解压缩，并把控制权交还给解开后的真正程序，这一切工作都是在内存中运行的，整个过程对用户是透明的。
   壳和病毒在某些方面比较类似，都需要比原程序代码更早的获得控制权。壳修改了原程序的执行文件的组织结构，从而能够比原程序的代码提前获得控制权，并且不会影响原程序的正常运行。
   这里简单说说一般壳的装载过程。（参考了Ljtt以前写过的一篇文章）
   1）获取壳自己所需要使用的API地址
   如果用PE编辑工具查看加壳后的文件，会发现未加壳的文件和加壳后的文件的输入表不一样，加壳后的输入表一般所引入的DLL和API函数很少，甚至只有Kernel32.dll以及GetProcAddress这个API函数。
   壳实际上还需要其他的API函数来完成它的工作，为了隐藏这些API，它一般只在壳的代码中用显式链接方式动态加载这些API函数:3个脱壳相关的重要函数介绍
   2）解密原程序的各个区块(Section)的数据
   壳出于保护原程序代码和数据的目的，一般都会加密原程序文件的各个区块。在程序执行时外壳将会对这些区块数据解密，以让程序能正常运行。壳一般按区块加密的，那么在解密时也按区块解密，并且把解密的区块数据按照区块的定义放在合适的内存位置。
   如果加壳时用到了压缩技术，那么在解密之前还有一道工序，当然是解压缩。这也是一些壳的特色之一，比如说原来的程序文件未加壳时1～2M大小，加壳后反而只有几百K。
   3）重定位
   文件执行时将被映像到指定内存地址中，这个初始内存地址称为基地址（ImageBase）。当然这只是程序文件中声明的，程序运行时能够保证系统一定满足其要求吗？
   对于EXE的程序文件来说，Windows系统会尽量满足。例如某EXE文件的基地址为0x400000，而运行时Windows系统提供给程序的基地址也同样是0x400000。在这种情况下就不需要进行地址“重定位”了。由于不需要对EXE文件进行“重定位”，所以加壳软件把原程序文件中用于保存重定位信息的区块干脆也删除了，这样使得加壳后的文件更加小巧。有些工具提供“Wipe Reloc”的功能，其实就是这个作用。
   不过对于DLL的动态链接库文件来说，Windows系统没有办法保证每一次DLL运行时提供相同的基地址。这样“重定位”就很重要了，此时壳中也需要提供进行“重定位”的代码，否则原程序中的代码是无法正常运行起来的。从这点来说，加壳的DLL比加壳的EXE更难修正。
   4）HOOK-API
   程序文件中的输入表的作用是让Windows系统在程序运行时提供API的实际地址给程序使用。在程序的第一行代码执行之前，Windows系统就完成了这个工作。
   壳一般都修改了原程序文件的输入表，然后自己模仿Windows系统的工作来填充输入表中相关的数据。在填充过程中，外壳就可填充HOOK-API的代码的地址，这样就可间接地获得程序的控制权。
   5）跳转到程序原入口点（OEP）
    从这个时候起壳就把控制权交还给原程序了，一般的壳在这里会有明显的一个“分界线”。但现在的猛壳己没这界限了，壳里有肉，肉里有壳。

3. 压缩引擎

    各类加壳软件，其压缩算法一般不是自己实现的，大多是调用其他的压缩引擎。目前压缩引擎种类比较多，不同的压缩引擎有不同特点，如一些对图像压缩效果好，一些对数据压缩效果好。而加壳软件选择压缩引擎有一个特点，在保证压缩比的条件下，压缩速度慢些关系不是太大，但解压速度一定要快，这样加了壳的EXE文件运行起来速度才不会受太大的影响。例如下面几个压缩引擎就能满足这要求：

1. aPLib压缩引擎 http://www.ibsensoftware.com/，这个库对于低于64K的文件压缩效果较好，速度较快。
2. JCALG1压缩引擎，相对于aPlib，JCALG1对于大文件效果好些。
3. LZMA压缩引擎 http://www.7-zip.org/zh-cn/sdk.html，LZMA 是 7-Zip 程序中 7z 格式的默认压缩算法，压缩率很高。

第四课常见压缩壳与加密壳

    加壳软件按照其加壳目的和作用，可分为两类：一是压缩（Packers），二是保护（Protectors）。压缩这类壳主要目的是减小程序体积，如ASPacK、UPX和PECompact等。另一类是保护程序，用上了各种反跟踪技术保护程序不被调试、脱壳等，其加壳后的体积大小不是其考虑的主要因素，如ASProtect、Armadillo、EXECryptor等。随着加壳技术的发展，这两类软件之间的界线越来越模糊，很多加壳软件除具有较强的压缩性能，同时也有了较强的保护性能。

1. ASPacK
主页：http://www.aspack.com/
   ASPack是款Win32可执行文件压缩软件，可压缩Windows 32位可执行文件（.exe）以及库文件（.dll、.ocx），文件压缩比率高达40%～70%。

2. UPX
主页：http://upx.sourceforge.net/
   UPX是一个以命令行方式操作的可执行文件经典免费压缩程序，压缩算法自己实现，速度极快，压缩比极高。（开源）

3. PECompact
主页：http://www.bitsum.com/
   PECompact同样也是一款能压缩可执行文件的工具（支持EXE、DLL、SCR、OCX等文件）。相比同类软件，PECompact提供了多种压缩项目的选择，用户可以根据需要确定哪些内部资源需要压缩处理。同时，该软件还提供了加解密的插件接口功能。

4. ASProtect
主页：http://www.aspack.com/
   ASProtect是一款非常强大的Windows 32位保护工具，这4、5年来，其一直在更新进步。其开发者是俄国人Alexey Solodovnikov。它拥有压缩、加密、反跟踪代码、反-反汇编代码、CRC校验和花指令等保护措施。它使用Blowfish、Twofish、TEA等强劲的加密算法，还用RSA1024作为注册密钥生成器。它还通过API钩子（API hooks，包括Import hooks（GPA hook）和Export hooks）与加壳的程序进行通信。甚至用到了多态变形引擎（Polymorphic Engine）。反Apihook代码（Anti-Apihook Code）和BPE32的多态变形引擎（BPE32的Polymorphic Engine）。并且ASProtect为软件开发人员提供SDK，实现加密程序内外结合。

更多与壳有关的描述参考：
    纵横间谁能相抗—论壳与加壳技术 作者:forgot

常见加密壳官方站点

ASProtect           http://www.aspack.com/
ACProtect           http://www.ultraprotect.com/
Armadillo           http://www.siliconrealms.com
EXECryptor          http://www.strongbit.com/
Obsidium            http://www.obsidium.de/
PESpin              http://pespin.w.interia.pl/
VMProtect           http://www.polytech.ural.ru/
Xtreme-Protector    http://www.oreans.com/xprotector/
Themida/WinLicense  http://www.oreans.com

本站的工具栏目：    http://www.pediy.com/tools/packers.htm
第五课文件类型分析

   拿到一个壳，第一步就是用相关工具分析一下是什么壳，然后就可心中有数地跟踪分析。文件分析工具有PEID，FileInfo等。

1.PEiD

   PEiD的GUI界面操作非常方便直观。它的原理是利用查特征串搜索来完成识别工作的。各种开发语言都有固定的启动代码部分，利用这点就可识别出是何种语言编编译的。同样，不同的壳也有其特征码，利用这点就可识别是被何种壳所加密。PEiD提供了一个扩展接口文件userdb.txt ，用户可以自定义一些特征码，这样就可识别出新的文件类型。
   有些外壳程序为了欺骗PEiD等文件识别软件，会伪造启动代码部分，例如将入口代码改成与Visual C++ 6.0所编程程序入口处类似代码，即可达到欺骗目的。所以，文件识别工具所给出的结果只是个参考，文件是否被加壳处理过，还得跟踪分析程序代码才可得知。 可参考这个文档了解如何伪装：让侦测工具把壳识别为VC++7.0的源代码   。目前Hying的壳PE-Armor伪装能力是最强的：

   PEiD分析不出类型的文件就报告是“Nothing found *”，如出现这情况一般都是未知壳或新版的壳。

下面PEiD识别出这个软件是用Asprotect 1.2x加的壳。

2.FileInfo

   FileInfo（简称Fi）另一款不错的文件检测工具。Fi运行时是DOS界面，在DOS窗口中运行程序相当不便，建议采用下面的技巧：
1.用鼠标将文件拖到Fi主文件上。
2.将Fi快捷方放进Windows的SendTo文件夹里.以后要分析某文件，只需右击“发送到”功能就可打开Fi。
   FileInfo升级慢，其识别库不能自定义。而PEiD升级比较频繁，用户也可自定义特征码，因此PEiD用的比较普遍。

   有时，FileInfo和PEID会报“PE Win GUI”，Win GUI就是Windows图形用户界面程序统称，表明程序可能没加壳。但不排除也有加壳的可能性，下图是一个ExeCryptor 2.2x的壳，FileInfo报“*PE Win GUI *section* ??”，其不能识别出来。识别信息中带了个问号，表明FI对给出的结果不是太肯定。

第六课寻找OEP

   一般的压缩壳，如Aspack等都有专用的脱壳机  。而加密壳（如ASProtect,Armadillo）一般很少有脱壳机，必须手工脱壳。手工脱壳一般情况是分三步：一是查找程序的真正入口点（OEP）；二是抓取内存映像文件；三是输入表重建。（当然现在的加密壳复杂些，要考虑更多的东西）
   OEP是Original Entry Point缩写，即程序加壳前的真正的入口点。
   外壳初始化的现场环境（各寄存器值）与原程序的现场环境是相同的。加壳程序初始化时保存各寄存器的值，外壳执行完毕，会恢复各寄存器内容。其代码形式一般如下：

    PUSHFD         ; 将标志寄存器入栈保存
    PUSHAD         ; push eax, ecx, edx, ebx, esp, ebp, esi, edi
    ……           ; 外壳代码部分
    POPAD          ; pop edi, esi, ebp, esp, ebx, edx, ecx, eax
    POPFD          ; 恢复标志寄存器
    JMP OEP        ;
OEP: ……          ; 解压后的程序原代码

   为了讲述方便，本节用UPX加壳的Win98记事本来演示。首先用PEid查看加壳前的记事本：

   PEid显示Notepad.exe程序是用Microsoft Visual C++ 6.0编译的，接下来用UPX来加壳，方法是开个DOS窗口，用命令upx notepad.exe。如下图所示：

   这时再用PEid查看加壳的文件，PEid会给出如下信息：UPX 0.89.6 - 1.02 / 1.05 - 1.24 -> Markus & Laszlo

   UPX的壳可以用UPX.exe自身来脱，命令是：upx -d 文件名。一些变种的UPX壳用UPX.EXE自身脱不了，这时可以试试UPX ShellEx 这款工具。

本节实例下载：notepad.upx.rar

   脱壳前建议用PE工具LordPE打开目标文件查看一下区块，以尽可能地多了解一些信息，对脱壳有帮助，如下图：

1.根据跨段指令寻找OEP

   推荐用Ollydbg来调试脱壳，比SoftICE和TRW2000方便多了。运行Ollydbg，点击菜单“选项/调试设置”，将第一次暂停设在WinMain函数上。再用Ollydbg打开实例notepad.upx.exe就可中断在外壳的入口点处了：

上图相关代码如下：
0040E8C0 >  60              pushad     //一开始Ollydbg就会中断这行，这个就是外壳的入口点,注意这个pushad指令

    绝大多数加壳程序在被加密的程序中加上一个或多个段，所以依据跨段的转移指令（JMP）就可找到真正的入口点，此时就会有POPAD/POPFD指令出现。UPX 用了一次跨段的转移指令（JMP），在跳到OEP处会看到虚拟地址的值有一个突变，此时就能确定OEP了。
    UPX壳比较简单，大家不必要跟踪去找这个跨段的转移指令，中断WinMain后，只需要在Ollydbg里往下翻屏，就会发现这个跨段转移指令：

上图相关代码如下：
0040EA0E    61              popad            //注意这里的popad指令，和开始的pushad对应
0040EA0F  - E9 B826FFFF     jmp     004010CC  //这里跳到OEP,将光标移到这，按F4执行到这行

   这一句0040EA0F   jmp  004010CC 就是跳到OEP的指令，执行到这，UPX外壳己将程序解压完毕，并模拟Windows加载器的将原始程序加载到内存，004010CC 就是映射到内存目标程序的入口点，此时就可抓取内存映像文件了。

2.根据堆栈平衡原理找OEP

   这个堆栈平衡原理其找OEP原理这篇文档描述的比较详细：寻找真正的入口（OEP）--广义ESP定律 作者:Lenus
操作方法：多数壳在运行到OEP的时候ESP=0012FFC4，这就是说程序的第一句是对0012FFC0进行写入操作，只要在0012FFC0下硬件写入断点（命令行里键入HW 12FFC0），我们就能停在OEP的第二句处。

   用OllyDBG重新加载实例程序notepad.upx.exe，在命令行下硬件写断点：

   按F9执行程序，就会中断在OEP第二行：

此时如果将光标向上移，会发现第一句代码变乱了：
004010C7    000D 0A000055  add     [5500000A], cl
004010CD    8BEC           mov     ebp, esp

这是因为Ollydbg将数据当汇编代码来分析了，你可以按 Ctrl＋ALT＋向上光标键将当前显示的代码向上滚动一个字节就可看到正确的汇编代码了：

004010CC    55              push    ebp
004010CD    8BEC            mov     ebp, esp   //中断在这行
004010CF    83EC 44         sub     esp, 44
004010D2    56              push    esi
004010D3    FF15 E4634000   call    [4063E4]                         ; kernel32.GetCommandLineA

中断后，别忘点击菜单“调试/硬件断点/”打开硬件断点面板，将刚才的硬件断点删除。

小知识： 硬件断点的原理 作者:Lenus

3.根据编译语言特点找OEP

   各类语言编译的文件入口点都有一些规律，可以这利用这点来寻找入口点。
1）Delphi程序
执行程序，用LordPE（或Prodump）选dump(full)脱壳，存为dump.exe。接着用Hex Workshop打开dump.exe，搜索文本“runtime”，搜到后，向前查找离“runtime”最近的十六进制数字“55 8B EC”，数字所在的地址就是程序的OEP。
2）Visual C程序
可以利用Visual C启动部分的几个函数GetCommandLineA(W)、GetVersion、GetModuleHandleA(W)、GetStartupInfoA(W) 等来定位程序的OEP。

   常见的各类编译语言的入口汇编代码都要熟悉，因为一些加密强壳会偷OEP处的代码到壳里，一般情况各编译语言入口代码都相同，到时只需要直接引用相关程序的入口代码，这给我们恢复代码带来方便。

4.用内存断点找OEP

Author：Lenus
From:   www.popbase.net & www.pediy.com
E-mail：Lenus_M@163.com
--------------------------------------------------
1.前言
   发现论坛中很多兄弟在询问：什么是二次内存断点，三次内存断点。还有很多人对内存断点的原理不是很明白。其实只要懂得壳是如何解压代码的，那么就完全可以按自己的喜欢来下断。

   本文要解决的问题是：
   1.什么是内存断点？
   2.如何在寻找OEP时使用内存断点。
   3.内存断点的局限性。

2.内存断点寻找OEP的原理
  i.首先，在OD中内存断点，硬件断点和普通断点（F2下断）是有本质区别的。硬件断点等效与SoftICE命令bpm，他的中断要用到DR0-DR7的调试寄存器，也就是说OD通过这些DR0-DR7的调试寄存器来判断是否断下。
    普通断点（F2下断）等效于bpx，他是在所执行的的代码的当前地址的一个字节修改为CC（int3）。当程序运行到int3的时候就会产生一个异常，而这个异常将交给OD处理，把这个异常的regEIP-1以后就正好停在了需要的中断的地方（这个根据系统不同会不一样），同时OD在把上面的int3修改回原来的代码。
  而内存断点基本上使用的是对代码使用的保护属性来实现中断。

  内存断点分为：内存访问断点，内存写入断点。
  我们知道，在程序运行的时候会有3种基本的状态产生：读取，写入，执行。

004AE242     A1 00104000       mov eax,dword ptr ds:[004AE24C]            //004AE24C处的内存读取
004AE247     A3 00104000       mov dword ptr ds:[004AE24C],eax            //004AE24C处的内存写入
004AE24C     83C0 01           add eax,1                                  //004AE24C处的内存执行

  那么我们应该如何中断在上面的几行呢？
  1.当我们对004AE24C下内存访问断点的时候，可以中断在004AE242也可以中断在004AE247。
  2.当我们对004AE24C下内存写入断点的时候，只能中断在004AE247。
  3.当我们对004AE24C下内存访问断点的时候，能中断在004AE24C。

  到这里你可能不明白了，为什么内存访问断点能中断在004AE247这一句对004AE24C的写入，而且还能中断在004AE24C的执行呢？

  其实很简单，我们只要仔细体会一下“内存访问”这四个字的含义遍可以知道，当我们对004AE24C进行读取的时候需要“访问”他吧，当我对004AE24C进行写入的时候也需要“访问”他吧！！当然我们要执行内存地址004AE24C的代码的时候也是还是要“访问”他的！

  所以我们不难得出下面的结论：
  1.内存写入中断的地方，一定是也可以用内存访问中断。
  2.内存执行的地方，也可以用内存访问中断。
  如果这时你认为，那么内存写入岂不是没用了。呵呵~那我要告诉你当然不是，如果你想快速的准确的定位到004AE247这一行的时候，那么他就大有作用了！

  总结一下：内存断点不修改改原代码，不会像普通断点那样因为修改代码被程序校验而导致中断失败；对于区段的访问只是区域大了一点，其原理和上面分析的三行代码是一样的。

  ii.如何使用内存断点来寻找OEP呢？
  要回答这个问题首先要回答这一个问题：壳是如何解压代码的？

  正如我们知道的，壳如果要把原来加密或压缩的代码运行起来就必须要解压和解密原来的代码。而这一个过程我们难道不能将他看做是对代码段（code段）的写入吗？好了，解压完毕了。我们要从壳代码的区段JMP到原来的代码段的时候，难道不正是对代码段（code段）的执行吗？
  理清了上面的关系就好办了，那么如果载入OD后，我们直接对code段下内存访问断点的时候，一定会中断在壳对code段的写入的代码的上面，就像上面的004AE247的这一行。而如果当他把code段的代码全部解压解密完毕了以后，JMP到OEP的时候，我们是不是还可以停在OEP的代码上面呢？而且每按下F9都会中断，因为这时code段在执行中哦！

  相信很多人到这里已经明白了，为什么在教程中到达了某一个时候，某一行的时候。牛人们就叫我们对code段下内存访问断点了吧。
  而如果你还要继续问我为什么一定要到那个地方才可以下断呢？我难道不可以一开始就下断吗？
  正入我上面所说的，如果你在前面下断很可能壳对code段还没解压完毕呢，这时如果你不停的按F9，你将会看到OD的下方不断的在提示你“对401000写入中断” “对401002写入中断”“对401004写入中断”.......如果你不介意按F9到他把正个code段写完的话，我除了同情你的“F9”以外，没什么其他的意见！

  那么我们就没有别更快一点的办法了吗？
  有的！那就是我们呼之欲出的两次内存断点办法。
  怎么理解两次内存断点呢？

  让我来做一个假设吧，假设我是一个壳的作者。一个EXE文件的有code段，data段，rsrc段.....依次排列在你的内存空间中，那么我会怎么解码呢？呵呵~我比较笨一点，我会先将code段解码，然后再将data段解压，接着是rsrc段......那么聪明的你不难发现，只要你在data断或者rsrc段下内存访问断点，那么中断的时候code段就已经解压完毕了。这时我们再对code段下内存反问断点，不就可以到达OEP了吗？

  这里注意上面虽然下了两次内存访问断点，但是本质是不一样的，目的也是不一样的。

  1.对data段下内存访问断点而中断是因为内存写入中断，目的是断在对对data段的解压时，这时壳要对data段写数据，但是code段已经解压完毕。
  2.对code段下内存访问断点而中断是因为内存执行中断，目的当然就是寻找OEP了。

  总结一下：如果我们知道壳在什么地方对code段解压完毕我们就可以使用内存断点，找到OEP。如果不知道，那么我们就依靠2次内存断点去找，如果还不行就用多次内存断点。总之明白了原理在多次的内存断点其实都一样。从这个过程中我们了解的是壳在对区段解码的顺序！

  iii.实战

  说了这么多，我想大家都越越欲试了吧。
  好吧，来弄一个猛壳怎么样：
注：本节实例有些难度，不适合新手练习，新手可以跳过这个实例的学习，等找到合适的实例会补充上来的

本节实例下载：unpackme.rar

  这个壳是一个hying的旧版，我们用他来实验一下我们内存断点法。

  OD载入以后来到这里

0040D000 u>  56                    push esi              //这里
0040D001     52                    push edx
0040D002     51                    push ecx
0040D003     53                    push ebx
0040D004     55                    push ebp
0040D005     E8 15010000           call unpackme.0040D11F

  根据跟过一次的经验我们将先设置，除int3异常以外忽略其他异常，SHIFT+F9

003725B1    64:8925 0000000>       mov     fs:[0], esp
003725B8    CC                     int3
003725B9     90                    nop                    //到这里
003725BA     8BCD                  mov ecx,ebp

  然后再设置除“除零”异常外，忽略其他异常。SHIFT+F9

00372660     F7F3                  div ebx                //到这里
00372662     90                    nop

  下面是很多的单步异常，太麻烦我们不管他，现在开始用内存断点的方法（记得将所有异常忽略）。

对code段下内存访问断点，希望他已经解压完毕。方法是按ALT＋M键打开内存窗口，在.code段按F2设断：

SHIFT+F9执行：

0040D19D     A4                    movs byte ptr es:[edi],byte ptr ds:[esi]         //还没解完呢
0040D19E     B3 02                 mov bl,2

对data段下内存“写入”断点，试试看他是不是要写data段。

00372712     F3:A4                 rep movs byte ptr es:[edi],byte ptr ds:[esi]      //断到这里
00372714     5E                    pop esi

下面再对code段下内存访问断点。F9

00372855     8907                  mov dword ptr ds:[edi],eax                         ; SHELL32.DragFinish  //这里是对IAT加密

的地方了！！！
00372857     5A                    pop edx
00372858     0FB642 FF             movzx eax,byte ptr ds:[edx-1]
0037285C     03D0                  add edx,eax
0037285E     42                    inc edx
0037285F     83C7 04               add edi,4
00372862     59                    pop ecx
00372863   ^ E2 A9                 loopd short 0037280E
00372865   ^ E9 63FFFFFF           jmp 003727CD
0037286A     8BB5 93060000         mov esi,dword ptr ss:[ebp+693]                      //到这里下断F2

现在如果再对data下访问断点已经是没用了。这时应该格外的小心。

我们现在就想既然这一段是对code解码的，那么我们就绕过他吧！

到0037286A下断F2，然后清除内存断点！！！！

F9以后停在这里，继续对code下内存访问断点。

看看左下角还在解码，哎~真是麻烦！

003728E1    /EB 1D                 jmp short 00372900
003728E3    |25 FFFFFF7F           and eax,7FFFFFFF
003728E8    |0385 83060000         add eax,dword ptr ss:[ebp+683]
003728EE    |2B85 8F060000         sub eax,dword ptr ss:[ebp+68F]
003728F4    |8BDE                  mov ebx,esi
003728F6    |2BD8                  sub ebx,eax
003728F8    |8958 FC               mov dword ptr ds:[eax-4],ebx                     //停在这里
003728FB    |83C7 08               add edi,8
003728FE   ^|EB DB                 jmp short 003728DB
00372900    \64:FF35 30000000      push dword ptr fs:[30]                          //清除内存断点以后到这里下断，F9

又是一段解码的代码，再次使用上面的办法手动跳出去。

现在继续对code段下内存访问断点！！F9以后到达这里。

004010CC     FFD7                  call edi                                           ; unpackme.004010CE   //OEP哦
004010CE     58                    pop eax
004010CF     83EC 44               sub esp,44
004010D2     56                    push esi
004010D3     90                    nop
004010D4     E8 B518F7FF           call 0037298E
004010D9     8BF0                  mov esi,eax

呵呵~虽然不是我们熟悉的OEP，但是地址是没错了，况且根据我们的步骤，我可以很肯定的说这是code段的第一次“执行”中断！

所以这就是OEP了。

总结一下：当我们在寻找OEP的时候，要多次对code下断“赌”一“赌”他解压完毕，如果不是就对别的段试试~如果程序跑飞了，那就没办法了，重来呗~其实说起来要赌的是：当data段，idata段，rsrc段摆在你的面前，你会好好“珍惜”那个段，不过还好上天还会给我们从来一次的机会（ctrl+F2 ^_^），那么我们会对那个不会跑飞的段说3个字----“先断你”如果非要在上面加一个次数，我希望是“一次内存断点就好了”

  vi.下面来讨论一下内存断点的局限性问题。
  是不是什么壳都可以用内存中断啊？
  不是每个都可以的，一些像UPX和ASPACK就不行。
  为什么？
  呵呵~follew me！
  情况1.
  我们来看看UPX的壳

首先，他的壳代码在UPX1段。

这里是他要跳到OEP的地方

0040ED4F    /77 11             ja short NOTEPAD_.0040ED62
0040ED51    |01C3              add ebx,eax
0040ED53    |8B03              mov eax,dword ptr ds:[ebx]
0040ED55    |86C4              xchg ah,al
0040ED57    |C1C0 10           rol eax,10                           //在解码
0040ED5A    |86C4              xchg ah,al
0040ED5C    |01F0              add eax,esi
0040ED5E    |8903              mov dword ptr ds:[ebx],eax
0040ED60   ^|EB E2             jmp short NOTEPAD_.0040ED44
0040ED62    \24 0F             and al,0F
0040ED64     C1E0 10           shl eax,10
0040ED67     66:8B07           mov ax,word ptr ds:[edi]
0040ED6A     83C7 02           add edi,2
0040ED6D   ^ EB E2             jmp short NOTEPAD_.0040ED51        //回跳解码
0040ED6F     61                popad
0040ED70   - E9 5723FFFF       jmp NOTEPAD_.004010CC             //跳到OEP

我们看到他在对code段解压完毕的时候马上就JMP到OEP去了，那么我们根本就来不及使用内存断点的办法。

你可能说，我可以在

0040ED6F     61                popad //这一句下段然后使用啊

呵呵~~当然可以，不过你把花在下内存断点的时间，多按下几次F8不更好？！

也就是说当一个壳如果他在JMP 到OEP前的一行代码仍在都在对code段解压，那么我们就不能再使用这种办法了！

或者说我们没必要使用内存断点更贴切一点！

  情况2.
  对于一些在OEP处有stolen code的代码
  我们来看看一个OEP

0049E2F4 u>  55                push ebp                               //OEP
0049E2F5     8BEC              mov ebp,esp
0049E2F7     83C4 F4           add esp,-0C
0049E2FA     B8 BCE04900       mov eax,unpack.0049E0BC
0049E2FF     E8 048CF6FF       call unpack.00406F08                   //这里调用子程序
0049E304     A1 B8FE4900       mov eax,dword ptr ds:[49FEB8]
0049E309     50                push eax
0049E30A     6A 00             push 0
0049E30C     68 1F000F00       push 0F001F
0049E311     E8 E68EF6FF       call   //API
0049E316     A3 60194A00       mov dword ptr ds:[4A1960],eax
0049E31B     833D 60194A00 00  cmp dword ptr ds:[4A1960],0

这个软件在被PESPIN加壳了以后这些全被偷掉了！

也就是说，壳在模拟OEP代码的时候必然会执行

0049E2FF     E8 048CF6FF       call unpack.00406F08  //这一步

而这个地方是call向code段的。如果我们使用内存访问断点，那么就停在这个子程序的地方

00406F08     50                push eax                                        //会停在这里
00406F09     6A 00             push 0
00406F0B     E8 F8FEFFFF       call
00406F10     BA 04F14900       mov edx,unpack.0049F104
00406F15     52                push edx

这里既不是处理stolen code的地方，也不是FOEP的地方。这就会对我们的判断产生误导。

当然你可以alt+F9返回到壳处理stolen的地方，然后用内存断点，或者按几下F8到达FOEP处，但试问如果你拿到一个未知的壳的时候又怎么知道应该这么处理呢？

还有其他一些情况留给大家总结吧！

在下的砖已抛出，各位的玉不久矣。

--------------------------------------------------
3.总结
      好了说了很多，大家应该对内存断点的办法有了全面的了解，如果了解了内存断点的原理就不难明白他的使用方法，不难明白为什么有写壳不能使用内存断点的办法，其实任何的一种办法都需要经验的积累。相信如果大家在回答开篇的3个问题，已经不难了。
      大家可以结合原理再好好的体会一下《手动脱壳进阶第八篇Skvp1.32》这篇文章。

第七课 Dump内存映像

    外壳程序解压还原后就会跳到OEP处执行，此时内存映像文件是己解压的程序。这时就可抓取内存映像文件了（该过程称为Dump）。当然不一定非要在程序原入口点抓取，只要能保证内存映像文件是己还原的就行了。
    有关Dump技术的原理大家可以参考：浅谈脱壳中的Dump技术  作者:Lenus

    继续上一个实例notepad.upx.exe，到OEP后就可以Dump取内存映像文件：
004010CC    55             push    ebp
004010CD    8BEC           mov     ebp, esp
004010CF    83EC 44        sub     esp, 44

   运行LordPE.EXE，点击Options，默认选项如下：

   默认选上“Full dump:paste header from disk”，PE头的信息直接从磁盘文件获得。设置好后，在LordPE的进程窗口选择notepad.upx.exe，点击右键，执行“dump full”菜单命令。如图：

   将内存抓取的文件另存为dumped.exe，此时程序还不能运行，接下来就是重建输入表。

第八课重建输入表

   在脱壳中输入表处理是很关键的一个环节，因此要求脱壳者对PE格式中的输入表概念非常清楚。在磁盘文件中，PE文件的输入表结构如下图所示：

                         图8.1 磁盘文件中的输入表

   PE文件运行时，Windows系统加载器首先搜索OriginalFirstThunk，如果存在，装载程序迭代搜索数组中的每个指针，找到每个IMAGE_IMPORT_BY_NAME结构所指向的输入函数的地址，然后用函数入口地址来替代由FirstThunk指向的 IMAGE_THUNK_DATA 数组里的元素值（即用真实的函数地址填充到IAT里）。因当PE文件装载内存后准备执行时，上图己转换成这种情况了：

                         图8.2 PE文件装载内存后的输入表

   此时输入表中其它部分就不重要了，程序依靠IAT提供的函数地址就可正常运行（图8.2 红圈部分）。如果程序加壳了，那壳自己模仿Windows装载器的工作来填充IAT中相关的数据，此时内存中就一张IAT表，输入表的其他部分是不存的（当然不是绝对的，也有不少壳，如Aspack等，内存中会出现完整的输入表结构），如图8.3所示。


             图8.3 外壳加载程序后的内部IAT

   输入表重建就是根据图8.3这张IAT恢复整个输入表的结构（即图8.1这个结构），ImpREC这款工具就是这个功能。
   一些压缩壳，填充IAT过程中没做什么手脚，用ImpREC工具可以直接重建输入表。而一些加密壳为了防止输入表被还原，就在IAT加密上大作文章，此时壳填充IAT里的不是实际的API地址，而是填充壳中用来HOOK-API的外壳代码的地址。这样壳中的代码一旦完成了加载工作，在进入原程序的代码之后，仍然能够间接地获得程序的控制权。因为程序总是需要与系统打交道，与系统交道的途径是API，而API的地址已经替换成了壳的HOOK-API的地址，那程序每一次与系统打交道，都会让壳的代码获得一次控制权，这样壳可以进行反跟踪继续保护软件，同时也可完成某些特殊的任务。所以重建输入表的关键是获得没加密的IAT ，一般的做法是跟踪加壳程序对IAT处理过程，修改相关指令，不让外壳加密IAT。

   UPX、ASPack等加壳保护的壳没加密IAT，而ASProtect、tElock等加密保护的壳都对IAT进行了加密处理。这篇先来简单的，即UPX壳。用OD打开上面的notepad.upx.exe实例，运行到OEP。（实际跟踪过程中，不一定要到OEP，只要外壳处理完IAT就可）然后如下操作：

1) 运行ImportREC，在下拉列表框中选择notepad.upx.exe进程，如图：

2) 上面己得知notepad.upx.exe的OEP地址是4010CC，则在左下角OEP处填入OEP的RVA值，这里填上10CC。点击“IAT AutoSearch”按钮，让其自动检测IAT偏移和大小，如出现下图表示ImportREC自己找到IAT的地址与大小了，即IAT地址：000062E0，大小248。

如果ImportREC没找到IAT偏移，则必须手工填入IAT偏移和大小（IAT偏移手动获得以后再讲述）。

3) 点击“Get Import”按钮，让其分析IAT结构得到基本信息，如下图所示：

4)如发现某个DLL显示"valid :NO" ，按"Show Invalids"按钮将分析所有的无效信息，在Imported Function Found栏中点击鼠标右键，选择"Trace Level1 (Disasm)"，再按"Show Invalids"按钮。如果成功，可以看到所有的DLL都为"valid:YES"字样；
5)再次刷新"Show Invalids"按钮查看结果，如仍有无效的地址，继续手动用右键的Level 2或3修复；
6)如还是出错，可以利用"Invalidate function(s)"、"Delete thunk(s)"、编辑Import表（双击函数）等功能手动修复。
7)开始修复已脱壳的程序。选择Add new section (缺省是选上的) 来为Dump出来的文件加一个Section(虽然文件比较大，但避免了许多不必要的麻烦) 。
8)单击"Fix Dump"按钮，并选择刚在前面己Dump出来的文件。如修复的文件名是"Dump.exe"，它将创建一个"Dump_.exe"，此外OEP也被修正。

    经过这些步骤，这个UPX壳己成功脱掉。此时再用PEID查一下脱壳后的程序dumped_.exe，会显示是“Microsoft Visual C++ 6.0 SPx Method 1”，如下图所示：

再用LordPE查看脱壳后的输入表：

从上图可以看出，输入表己正确修复，此时脱壳后的文件己能成功运行了。
第九课手动确定IAT的地址与大小

    在第八课中讲到，点击ImportREC的“IAT AutoSearch”按钮，一般情况下ImportREC可以自动识别出IAT地址与大小。但如果不能自动识别，就必须手动确定IAT地址与大小，然后将IAT的RVA与Size填进ImportREC，点击“Get Import”按钮就可得到输入表。
    还是用上一节实例演示，用OD打开notepad.upx.exe，来到OEP处：

    随便找一个API函数调用语句，如：
004010D3    FF15 E4634000   call    [4063E4]          ; kernel32.GetCommandLineA

   其中地址4063E4就是IAT中的一部分，在数据窗口下命令：D 4063E4，显示如下：

  上图每一组数据都是指向一个API函数，如 8D 2C 81 7C 就是地址：7C812C8D，在OD里按Ctrl＋G，输入7C812C8D跳到这个地址就会发现是kernel32.GetCommandLineA函数：

   IAT是一块连续排列的数据，因此在数据窗口向上翻屏，直到出现00数据，寻找IAT起始地址：

然后向下翻屏，寻找IAT结束地址：

为了直观些，你也可以这样让数据窗口直接显示这些API函数，以确定IAT是否正确，在数据窗口点击鼠标右键：

调整显示格式后的数据窗口：

这样就直观了，IAT中每组数据指向一个API函数，各DLL之间是以000000分开的。

因此IAT范围：0x4062E4～0x406524 ，大小为0x406524-0x4062E4=0x240

如果IAT加密了，此时IAT中的地址不是指向系统DLL中的API函数了，可能指向外壳。这就十分有必要找到外壳处理IAT的代码了，前面己说过，外壳加载时，会模拟Windows加载器，向IAT里填充当前操作系统API函数的实际地址。所以，在IAT里设个内存写断点，就可中断到这段代码处。
重新加载notepad.upx.exe，在IAT某个地址下内存写断点，这里选择0x4062E4这个地址设内存写断点，先在数据窗口下命令：D 4062E4

然后选择一个地址，点击鼠标右键，下“内存写断点”。

此时只要有数据写入4062E4地址处，OD就会中断，按F9运行OD，会中断这里：

0040E96D    > /8A02          mov     al, [edx]
0040E96F    . |42            inc     edx
0040E970    . |8807          mov     [edi], al
0040E972    . |47            inc     edi
0040E973    . |49            dec     ecx
0040E974    .^\75 F7         jnz     short 0040E96D

这段还不是处理IAT，按F9继续执行程序，会中断这里：

0040E9E9    > /8A07          mov     al, [edi]
0040E9EB    . |47            inc     edi
0040E9EC    . |08C0          or      al, al
0040E9EE    .^|74 DC         je      short 0040E9CC
0040E9F0    . |89F9          mov     ecx, edi
0040E9F2    . |57            push    edi                        // 函数名字符串
0040E9F3    . |48            dec     eax
0040E9F4    .  F2:AE         repne   scas byte ptr es:[edi]
0040E9F6    . |55            push    ebp                        // DLL模块句柄
0040E9F7    .  FF96 A4EC0000 call    [esi+ECA4]                 ;  kernel32.GetProcAddress
0040E9FD    . |09C0          or      eax, eax
0040E9FF    . |74 07         je      short 0040EA08
0040EA01    . |8903          mov     [ebx], eax                // EBX指向IAT,将取得的API地址填充进IAT
0040EA03    . |83C3 04       add     ebx, 4                    // 指向下一个地址
0040EA06    .^\EB E1         jmp     short 0040E9E9
0040EA08    >  FF96 A8EC0000 call    [esi+ECA8]

上面这段就是UPX外壳填充IAT的全过程，感兴趣的，动态跟踪一下就明白了。这里用GetProcAddress函数获得函数地址：

FARPROC GetProcAddress(
  HMODULE hModule,    // DLL模块句柄
  LPCSTR lpProcName   // 函数名
);

为了方便大家学习脱猛壳技术，根据我自己的经验，将一些比较不错的文章列出：

────────────────────────────────────────────────────────────────────
Armadillo壳

试玩armadillo3.50a一点心得  （基础知识）

Armadillo COPYMEMEII之DUMP的一个LOADPE小插件  （利用插件Dump取COPYMEMEII保护的程序）
Armadillo 3.6主程序脱壳   （Dump取COPYMEMEII保护的程序另一方法）

Patch 修复 Armadillo 的IAT乱序（处理IAT乱序）

Armadillo中code splicing的几种处理方法（手工修复Code Splicing）
Armadillo客户版Code Splicing+Import （利用ArmInline工具修复Code Splicing）

浅谈Armadillo V.3.75 与 V.3.78的保护  （Nanomites原理概念，即CC保护）
Blaze Media Pro5.05脱壳＋基本修复CC(int3)＋破解  （修复CC）
Armadillo V4.40主程序脱壳  （目前处理CC很好的一个方法）

带key脱壳：
http://bbs.pediy.com/showthread.php?threadid=23174

────────────────────────────────────────────────────────────────────
ASProtect 2.x SKE壳

Asprotect2.XX IAT fixer v2.2S  (VolX脚本，功能相当强大，相当一个ASProtect脱壳机了)

nspack3.5主程序脱壳分析(Aspr SKE 2.X)   (输入表)
Asprotect SKE 2.2 的Advanced Import protection保护技术  (输入表)

莱鸟脱Aspr2.11 SKE+修复stolen   (Dump法对付stolen OEP)

ASProtect.SKE.2.11 stolen code解密  (ASProtect 2.11的stolen与SDK修复技术 )
ASProtect_SKE_2.3Beta_Build0319 stolen code分析 (ASProtect 2.22/2.23的stolen与SDK修复技术 )

────────────────────────────────────────────────────────────────────
Obsidium壳

Obsidium外壳学习手记
 Obsidium1.2.5.0主程序脱壳记录点滴  （SDK修复部分）

────────────────────────────────────────────────────────────────────
SVKP 壳

────────────────────────────────────────────────────────────────────
PESpin 壳

────────────────────────────────────────────────────────────────────
EXECryptor壳

────────────────────────────────────────────────────────────────────
常见脱壳问题收集

引用:
Q：OD载入Aspr的壳就弹出检查到调试器，请卸载对话框，确定后马上退出，根本不给人调试的机会，这样的壳怎么脱？
A:原因应该是导入表有dll也是aspr的壳，OD载入停在系统断点就可，然后IsDebugPresent就OK了（shoooo回答）

引用:
Q：何为脱壳的软件重新加ASPR壳？
A: Directory Table中
   Reserved: 00000000   010000000

   那个1清0（堀北真希回答）

引用:
Q：如何清除themida给系统留下的补丁？运行了一个themida加的软件。结果themida修改了SSDT,以后每次启动系统，驱动都自动加载了
A:
sc stop oreans32
sc delete oreans32
（peaceclub回答）

引用: 1.什么叫 stolen code?如何判断有没stolen code?

    stolen code = 被偷走的代码

     跟到原程序代码段发现代码不完整就是被偷走了,看经验

2.什么叫SDK 如何判断SDK?

     software development kit，提供一个接口给使用者，与壳发生交互作用增加强度。可以看软件说明。

3.什么叫暗庄,如何判断有无暗庄?

      检测到自己被脱壳但是不明说，暗地里搞破坏。


4.脱aspr壳的时候在什么情况下需要补区段?

       代码被抽走的时候

寻找真正的入口（OEP）--广义ESP定律

redwolf@redwolf.com.cn (redwolf) — Tue, 24 Oct 2006 15:59:28 +0800

寻找真正的入口（OEP）--广义ESP定律

作者：Lenus
FROM: poptown.gamewan.com/bbs
E-MAIL：Lenus_M@163.com

1.前言

  在论坛上看到很多朋友，不知道什么是ESP定律，ESP的适用范围是什么，ESP定律的原理是什么，如何使用ESP定律？看到了我在

http://poptown.gamewan.com/dispbbs.asp?boardID=5&ID=54&page=1

调查结果发现,大家对ESP定律很感兴趣，当然因为实在是太好用了，现在我就来告诉大家什么是ESP定律，它的原理是什么！！

BTW：在看完了手动脱壳入门十八篇了以后，再看这篇文章也许会对你更有帮助！

在下面地址下载：

http://soft.winzheng.com/SoftView/SoftView_23125.htm

2.准备知识

  在我们开始讨论ESP定律之前，我先给你讲解一下一些简单的汇编知识。
  1.call
  这个命令是访问子程序的一个汇编基本指令。也许你说，这个我早就知道了！别急请继续看完。
  call真正的意义是什么呢？我们可以这样来理解：1.向堆栈中压入下一行程序的地址；2.JMP到call的子程序地址处。例如：

00401029    .  E8 DA240A00    call 004A3508
0040102E    .  5A             pop edx
在执行了00401029以后，程序会将0040102E压入堆栈，然后JMP到004A3508地址处！

  2.RET
  与call对应的就是RET了。对于RET我们可以这样来理解：1.将当前的ESP中指向的地址出栈；2.JMP到这个地址。

  这个就完成了一次调用子程序的过程。在这里关键的地方是：如果我们要返回父程序，则当我们在堆栈中进行堆栈的操作的时候，一定要保证在RET这条指令之前，ESP指向的是我们压入栈中的地址。这也就是著名的“堆栈平衡”原理！

3.狭义ESP定律

  ESP定律的原理就是“堆栈平衡”原理。

  让我们来到程序的入口处看看吧！

  1.这个是加了UPX壳的入口时各个寄存器的值！
EAX 00000000
ECX 0012FFB0
EDX 7FFE0304
EBX 7FFDF000
ESP 0012FFC4
EBP 0012FFF0
ESI 77F51778 ntdll.77F51778
EDI 77F517E6 ntdll.77F517E6
EIP 0040EC90 note-upx.
C 0  ES 0023 32bit 0(FFFFFFFF)
P 1  CS 001B 32bit 0(FFFFFFFF)
A 0  SS 0023 32bit 0(FFFFFFFF)
Z 0  DS 0023 32bit 0(FFFFFFFF)
S 1  FS 0038 32bit 7FFDE000(FFF)
T 0  GS 0000 NULL
D 0
O 0  LastErr ERROR_MOD_NOT_FOUND (0000007E)

  2.这个是UPX壳JMP到OEP后的寄存器的值！
EAX 00000000
ECX 0012FFB0
EDX 7FFE0304
EBX 7FFDF000
ESP 0012FFC4
EBP 0012FFF0
ESI 77F51778 ntdll.77F51778
EDI 77F517E6 ntdll.77F517E6
EIP 004010CC note-upx.004010CC
C 0  ES 0023 32bit 0(FFFFFFFF)
P 1  CS 001B 32bit 0(FFFFFFFF)
A 0  SS 0023 32bit 0(FFFFFFFF)
Z 1  DS 0023 32bit 0(FFFFFFFF)
S 0  FS 0038 32bit 7FFDE000(FFF)
T 0  GS 0000 NULL
D 0
O 0  LastErr ERROR_MOD_NOT_FOUND (0000007E)

呵呵~是不是除了EIP不同以外，其他都一模一样啊！

为什么会这样呢？
我们来看看UPX的壳的第一行：

0040EC90 n>  60               pushad      //****注意这里*****
0040EC91     BE 15B04000      mov esi,note-upx.0040B015

PUSHAD就是把所有寄存器压栈！我们在到壳的最后看看：

0040EE0F     61               popad      //****注意这里*****
0040EE10   - E9 B722FFFF      jmp note-upx.004010CC   //JMP到OEP

POP就是将所有寄存器出栈！

而当我们PUSHAD的时候，ESP将寄存器压入了0012FFC0--0012FFA4的堆栈中！如下：

0012FFA4   77F517E6  返回到 ntdll.77F517E6 来自 ntdll.77F78C4E           //EDI
0012FFA8   77F51778  返回到 ntdll.77F51778 来自 ntdll.77F517B5          //ESI
0012FFAC   0012FFF0                                                    //EBP
0012FFB0   0012FFC4                                                   //ESP
0012FFB4   7FFDF000                                                  //EBX
0012FFB8   7FFE0304                                                 //EDX
0012FFBC   0012FFB0                                                //ECX
0012FFC0   00000000                                               //EAX

所以这个时候，在教程上面就告诉我们对ESP的0012FFA4下硬件访问断点。也就是说当程序要访问这些堆栈，从而恢复原来寄存器的值，准备跳向苦苦寻觅的OEP的时候，OD帮助我们中断下来。

于是我们停在0040EE10这一行！

总结：我们可以把壳假设为一个子程序，当壳把代码解压前和解压后，他必须要做的是遵循堆栈平衡的原理，让ESP执行到OEP的时候，使ESP=0012FFC4。

4.广义ESP定律

  很多人看完了教程就会问：ESP定律是不是就是0012FFA4，ESP定律的适用范围是不是只能是压缩壳！

  我的回答是：NO！

  看完了上面你就知道你如果用0012FFA8也是可以的，ESP定律不仅用于压缩壳他也可以用于加密壳！！！

  首先，告诉你一条经验也是事实---当PE文件运行开始的时候，也就是进入壳的第一行代码的时候。寄存器的值总是上面的那些值，不信你自己去试试！而当到达OEP后，绝大多的程序都第一句都是压栈！（除了BC编写的程序，BC一般是在下面几句压栈）

  现在，根据上面的ESP原理，我们知道多数壳在运行到OEP的时候ESP=0012FFC4。这就是说程序的第一句是对0012FFC0进行写入操作！

  最后我们得到了广义的ESP定律，对只要在0012FFC0下，硬件写入断点，我们就能停在OEP的第二句处！！

下面我们来举个例子,就脱壳进阶第一篇吧！

  载入OD后，来到这里：

0040D042 N>  B8 00D04000      mov eax,Notepad.0040D000 //停在这里
0040D047     68 4C584000      push Notepad.0040584C
0040D04C     64:FF35 00000000 push dword ptr fs:[0]    //第一次硬件中断，F9
0040D053     64:8925 00000000 mov dword ptr fs:[0],esp
0040D05A     66:9C            pushfw
0040D05C     60               pushad
0040D05D     50               push eax

直接对0012FFC0下硬件写入断点，F9运行。（注意硬件中断）

在0040D04C第一次硬件中断，F9继续！

0040D135     A4               movs byte ptr es:[edi],byte ptr ds:[esi] //访问异常，不管他 shift+F9继续
0040D136     33C9             xor ecx,ecx
0040D138     83FB 00          cmp ebx,0
0040D13B   ^ 7E A4            jle short Notepad.0040D0E1

第二次硬件中断。

004058B5       64             db 64                                 //断在这里
004058B6       89             db 89
004058B7       1D             db 1D
004058B8       00             db 00
004058B9       00             db 00

这里也不是，F9继续！

004010CC   /.  55             push ebp
004010CD   |.  8BEC           mov ebp,esp  //断在这里，哈哈，到了！（如果发现有花指令，用ctrl+A分析一下就能显示出来）
004010CF   |.  83EC 44        sub esp,44
004010D2   |.  56             push esi

   快吧！还不过瘾，在来一个例子。

   脱壳进阶第二篇

   如果按上面的方法断不下来，程序直接运行了！没什么，我们在用另一种方法！

   载入后停在这里，用插件把OD隐藏！

0040DBD6 N>^\E9 25E4FFFF      jmp Note_tEl.0040C000                  //停在这里
0040DBDB     0000             add byte ptr ds:[eax],al
0040DBDD     0038             add byte ptr ds:[eax],bh
0040DBDF     A4               movs byte ptr es:[edi],byte ptr ds:[esi]
0040DBE0     54               push esp

   F9运行，然后用SHIFT+F9跳过异常来到这里：

0040D817   ^\73 DC            jnb short Note_tEl.0040D7F5       //到这里
0040D819     CD20 64678F06    vxdcall 68F6764
0040D81F     0000             add byte ptr ds:[eax],al
0040D821     58               pop eax

   在这里对0012FFC0下硬件写入断点！（命令行里键入HW 12FFC0）SHIFT+F9跳过异常，就来到OEP的第二行处：（用CTRL+A分析一下）

004010CC   /.  55             push ebp
004010CD   |.  8BEC           mov ebp,esp                       //断在这里
004010CF   |.  83EC 44        sub esp,44
004010D2   |.  56             push esi
004010D3   |.  FF15 E4634000  call dword ptr ds:[4063E4]
004010D9   |.  8BF0           mov esi,eax
004010DB   |.  8A00           mov al,byte ptr ds:[eax]
004010DD   |.  3C 22          cmp al,22

   就这样我们轻松搞定了两个加密壳的找OEP问题！

5.总结

  现在我们可以轻松的回答一些问题了。

  1.ESP定律的原理是什么？

  堆栈平衡原理。

  2.ESP定律的适用范围是什么？

  几乎全部的压缩壳，部分加密壳。只要是在JMP到OEP后，ESP=0012FFC4的壳，理论上我们都可以使用。但是在何时下断点避开校验，何时下断OD才能断下来，这还需要多多总结和多多积累。欢迎你将你的经验和我们分享。

  3.是不是只能下断12FFA4的访问断点？

  当然不是，那只是ESP定律的一个体现，我们运用的是ESP定律的原理，而不应该是他的具体数值，不能说12FFA4，或者12FFC0就是ESP定律，他们只是ESP定律的一个应用罢了！

  4.对于STOLEN CODE我们怎么办？

  哈哈，这正是寻找STOLEN CODE最好的办法！当我们断下时，正好断在了壳处理STOLEN CODE的地方，在F8一会就到OEP了！

6.后话


  以上的方法原理都是我自己总结，自己的经验，如果有什么不对的地方，有什么没解释清楚的地方。还请海涵！但是如果觉得我很厉害，那就大可不必，因为ESP定律也是别人教我的，不是我第一个提出来的！我只是个比你们早飞一点的菜鸟罢了^-^

  看了上面的文字希望能对你在寻找OEP的时候有帮助，但是别忘了一句话：菜鸟认为找OEP很难，高手认为修复才是最难！好了，下一篇应该写IAT的修复原理了！让我们共同努力吧！

打造可随意安装的完美XP镜像

redwolf@redwolf.com.cn (redwolf) — Mon, 31 Jul 2006 09:20:59 +0800

以往，我们用Ghost制作的Win98/Me操作系统镜像文件，可以在其他电脑上通行无阻地克隆，从而大大节省在多台电脑中重复安装操作系统的时间，这对办公室和网吧装机特别有用。但WinXP和Windows Server 2003会识别电脑硬件设备，一旦硬件发生大的改变(例如：更换主板或CPU)，它们的镜像文件就无法克隆到其他电脑中正常使用。
　　
　　其实，有一种方法可使WinXP的Ghost镜像文件适用于任何一台电脑，下面，笔者就以WinXP为例示范如何操作，Windows Server 2003操作方法也一样。
　　
　　实现原理：对操作系统进行重新封装，即回到初始安装状态前，然后再做成Ghost镜像。
　　
　　●建议：
　　
　　缩减WinXP容量
　　
　　首先减少电脑中WinXP的容量，主要目的是缩小系统体积，将镜像文件尽量压缩到650MB至700MB之间，以便进行光盘刻录。
　　
　　而要大幅缩小WinXP的容量，有三种操作可以进行。
　　
　　第一是先在“控制面板”→“电源选项”中关闭休眠功能，系统会自动删除C盘根目录下的hiberfil.sys文件，节省的硬盘空间大致与虚拟内存容量相当。
　　
　　第二是用SFC命令删除C:WindwosSystem32dll cache文件夹内的文件，具体做法是：点“开始”→“运行”，输入“sfc.exe /purgecache”(不要引号，注意sfc.exe与/之间有空格)，这样能节省约300MB容量。
　　
　　第三就是在所有的驱动器中禁用系统还原。
　　
　　按上述步骤，可将WinXP的总容量压缩在1.2GB以下。
　　
　　注：上述工作完成后需重新启动才能有效。
　　
　　●注意：
　　
　　卸载和修改硬件驱动程序
　　
　　首先声明最好使用PS2接口的鼠标和键盘，以防止在删除“通用串行总线控制器”时发生USB鼠标和USB键盘没有响应的情况。
　　
　　打开“设备管理器”，然后依次卸载“网络界面卡”、“通用串行总线控制器”、“声音”、“视频和游戏控制器”、“监视器”、“显示卡”。具体做法是：在某种硬件名称上单击鼠标右键，选择“卸载”就行了, 另外还应调整“IDE ATA/ATAPI控制器”为“标准双通道PCI IDE控制器”。注意如果系统要求重新启动，应选“否”，切勿启动！
　　
　　显示器的分辨率必须调整到800×600 @60Hz的标准，防止分辨率过高造成其他机器的显示器黑屏。
　　
　　至此，一个“干净”的WinXP系统已经准备好，接下来，我们可以对它进行重新封装。
　　
　　重新封装WinXP
　　
　　在WinXP安装光盘中提供了系统重新封装工具，路径是“光碟目录：SUPPORTTOOLSDEPLOY.CAB”，如果没有安装光盘可从微软的网站上下载该工具包。然后在C盘根目录下建立一个名为C:Sysprep的文件夹，将WinXP重新封装的工具包DEPLOY.CAB解压到将该目录。
　　
　　提醒：WinXP原版、SP1、SP2的封装工具包各不相同，需选择使用。
　　
　　1．双击Setupmpr.exe文件，进入Windows安装管理器后，点“下一步”按钮。
　　
　　2．选择“创建新文件”，点“下一步”按钮。
　　
　　3．在应答文件的用途对话框中选择第二项“Sysprep安装”，点“下一步”按钮。
　　
　　4．然后在“选择此应答文件安装的平台”对话框中选当前运行的操作系统，点“下一步”按钮。
　　
　　5．在“您想安全自动安装吗”对话框中选择“是，完全自动安装”，再点击“下一步”按钮。
　　
　　6．以下进入Windows安装管理的各个设置页面。首先在“自定义软件”页面中，输入用户名称和单位，点“下一步”按钮。
　　
　　7．在接下来出现的“显示设置”页面中，将颜色、屏幕区域、刷新频率都选为“使用Windows默认值”，并单击“下一步”按钮。
　　
　　8．在“时区”页面中，选择“北京时间”，单击“下一步”按钮。
　　
　　9．在“提供产品密钥”页面中输入WinXP的安装序列号。
　　
　　10．接着在“计算机名”页面输入你的电脑名称，单击“下一步”按钮。
　　
　　11．在“系统管理员密码”页面可选择输入或不输入密码。笔者建议大家不要输入密码，在安装好系统后再修改更为方便。
　　
　　在接下来的“网络组件”、“工作组或域”、“电话服务”页面都使用默认值。再点“下一步”按钮。
　　
　　12．在“区域”页面选择“中文（中国）”，单击“下一步”按钮。
　　
　　13．在紧接着出现的“语言”页面选择“中文（简体）”，再点“下一步”按钮。
　　
　　14．在“安装打印机”页面直接点“下一步”跳过安装。
　　
　　15．出现“运行一次”页面，单击“下一步”。
　　
　　16．出现“附加命令”页面，单击“下一步”。
　　
　　17．最后，在“OEM复写器字串”页面中点“完成”按钮，并在随后出现的应答文件存放位置对话框中点“确定”（必须按窗口右上角的关闭钮才可关闭），这样，终于完成WinXP自动安装应答文件的建立工作。这个应答文件名为sysprep.inf，它存放在C:sysprep文件夹内，按窗口上的关闭按钮可结束。
　　
　　18．接下来，正式进行WinXP操作系统的封装工作。用鼠标双击C:sysprepsysprep.exe文件，在警告窗口中点“确定”按钮。
　　
　　19．进入封装前的“系统准备窗口”对话框。在“标记”复选框中共有四个选择。其中第一项为检测非即插即用设备（PnP）；第二项是使用最小化安装（MiniSetup）；第三项（NoSIDGen）和第四项（已提前激活）都是XP以上操作系统专用的。我们应勾选后二至四项，再单击界面上方的“重新封装（Reseal）”按钮（至于“工厂（Factory）”和“审核（Audit）”一定不要随便点击，因为只要点击它，电脑就会按“关机模式”下的设置生效，到时后悔也来不及了），跟着电脑会自动关机，重新封装任务完成。最后利用软盘或光盘启动系统到DOS环境，再用Ghost软件制作高压缩比的镜像文件，以保证WinXP能够备份到一张700MB容量的CD-R刻录光盘中。
　　
　　到此，一张完全与硬件无关的WinXP镜像文件就制作完成了

逆向思维--魔兽世界封包分析

redwolf@redwolf.com.cn (redwolf) — Mon, 29 May 2006 15:29:46 +0800

本文作者：sodme
本文出处：http://blog.csdn.net/sodme
声明：本文可以不经作者同意任意转载，但任何对本文的引用都须注明作者、出处及此声明信息。谢谢！！

　　特别声明：
　　本人非常欣赏暴雪及他们的游戏，之所以写这个文章，是想让大家了解一些网络封包分析方面的常见方法以及学习暴雪游戏在网络处理方面的经验，偶认为作为一个网络编程者，熟练掌握封包分析的工具和方法应该是其基本功之一。本文所列的所有封包分析内容，全部是采用普通黑箱方式即可得来的，并未涉及对魔兽世界可执行程序的逆向工程。同时，除此文涉及的内容外，本人拒绝向任何人透露更详细的关于魔兽世界封包方面的更多内容，有兴趣者请自己进行相关的试验，本人在此文中也将尽量避免公开敏感的封包内容及相关加解密算法。谨以此文献给忠爱的暴雪！

　　一、登录模块流程及封包分析

　　我们先看登录流程。从封包流程来看，魔兽的登录流程是这样的：

　　1.由Client向登录/账号服务器(Login Server)发送用户名及密码等信息。此数据包的最后部分是用户名(明文表示，未加密)，在用户名的前一个字节表示的是用户名的长度。登录/账号服务器向Client返回登录成功及后续连接到游戏服务器服务器所必备的信息等。这中间的两个来往数据包，我还没有看出具体有什么作用。在这个交互过程中，由登录/账号服务器向Client发送所有的游戏服务器列表，服务器列表数据包的内容包括：ip, port, 服务器上所拥有的角色个数等信息，因服务器列表内容过多，被客户端分为两次接收完毕。

　　2.Client收到Login Server的服务器列表后，根据最近访问的服务器标识(这个信息应该是包含在那个服务器列表数据包中)，连接到最近游戏的那个游戏服务器(Game Server)。连接成功后，Game Server首先向Client发送一个8字节的数据包，据以往的常识判断，这个数据包的内容很可能是以后客户端与服务器通信的加密密钥。

　　3.Client向Game Server再次发送自己的账号信息。Game Server与Client经过两个数据包的交互后，向Client发送角色数据包，此包中包括了玩家在该Game Server所创建的所有角色信息，当然这个信息只是部分的，并不是该角色的所有信息。

　　4.在此后的通信过程中，Client每隔30秒向Game Server发送一个保持连接的包，该包长度为10字节，包的最后四字节是一个递增数字，前面6字节暂时未看出规律。

　　5.只要Client没有点击某个角色进入最终的Game Server，则Client要始终与Login Server保持连接。当Client点击角色进入Game Server时，Client才与Login Server断开连接。在以后的游戏过程中，Client始终与且仅与该Game Server进行数据通信。

　　通过对登录流程中的数据包初步分析，可以得出以下几个结论：
　　1.Client向Login Server发的第一个数据包，用户名部分是采用明文的，且该数据包的内容，每次登录都一样，并没有因时间的不同而发生改变。由此可以推算：针对于此数据包中的密码加密算法是固定不变的，换句话说，密码的加密算法是比较容易通过逆向工程被找到的。偶认为，针对于此处，服务器也应该先向客户端发送一个加密密钥，以后的通信可以用该密钥作为安全验证的依据。但暴雪没有这样作，最大的可能是为了提高服务器的效率，在登录服务器上，如果每个客户端一旦连接成功，登录服务器都得向客户端广播一个数据包的话，可能这个量还是比较大的，这可能延长了玩家的登录等待时间，所以他们没有在这块作。

　　2.Client在登录Login Server的地址，每次Login Server的登录地址都可能是不一样的。偶没有在客户端目录里找到这些地址，只在客户端目录里找到了四个大区的四个域名，我猜想，魔兽世界是用的DNS解析的简单方法来实现Login Server的简单动态均衡的。不知道这个猜想是否正确。

　　3.“根据玩家最近在玩的哪个游戏，由客户端和服务器自动为玩家选择进入这个游戏服务器”，这一项设定充分体现了暴雪一贯的风格：为玩家着想，最大限度地提高游戏的舒适度。再次对暴雪的态度予以肯定！

　　4.一旦玩家进入了游戏世界，客户端与服务器的通信端口会一直保持不变。即：魔兽世界的游戏世界服务器群设计结构采用的是带网关的服务器集群。

　　5.偶觉得在整个的登录流程中，让我产生最大疑问的就是Login Server与Client的连接保持逻辑。当Client与Game Server连接了之后，Client并未与Login Server断开，是一直保持连接的。后来，经进一步的抓包分析，Client之所以要与Login Server保持这样的连接，是为了当Client重新选择服务器时，不至于重新连接Login Server。当Client点击了"选择服务器"按纽后，Login Server会每隔5秒向Client发一个当前所有的服务器列表数据包。要知道，这个服务器列表数据包的内容可是非常大的，如果有玩家就打开了这个窗口不关闭，Login Server向这种情况的所有玩家每5秒钟就发一个服务器列表数据包，这个广播量可是很大的哦(2k左右，这可是一个用户是2k哦)。偶认为这里的逻辑设计是相当不合理的。Login Server如果为了给客户端提供一个最新的全局服务器列表，可以保持连接，但也没必要每隔5秒就向客户端发一个服务器列表，最多只在客户端在某个服务器上创建了不同的角色后再更新这个列表也是可以的，但只用更新这个列表中的变化内容即可，不用发全部的完整包，这样，在通信量上就小了很多。据说，魔兽刚开始的时候，产生DOWN机的原因就是登录模块没有处理好，偶不知道现在的这个情况是不是已经经过改良的了。但偶还是认为每隔5秒就向客户端发送一个2K的包，这一点是不可以被接受的。

　　以上只是针对于魔兽世界登录流程的简单分析，没有多少技术含量，拿出来跟大家相互讨论讨论，看看有没有可以借鉴的地方，后面还会有其它部分的封包分析。欢迎继续关注偶的Blog: http://blog.csdn.net/sodme。

　　偶在文章前面部分说过，作为一个网络编程人员，熟练使用截包软件和掌握基本的封包分析方法是其基本能力之一，发此文的目的一个原因也是希望向正在作网络编程的兄弟介绍一下相关工具的使用和常见的分析方法。下面补充一下关于封包分析的基本方法和相关工具：

　　1.你需要一个截包工具，偶推荐：commview，小巧但功能强大，支持自定义的封包分析插件以DLL形式装载，也就是说只要你愿意，你可以写个DLL对某类特殊形式的包进行显示、记录、解密等特别处理。

　　2.如何查看真正的封包数据。在commview里，会详细列出自网卡级别以上的各层封包数据，包括Ethernet层，IP层和TCP层。而我们作封包分析时，只需要关注TCP层。但TCP层里也有很多内容，对于我们的分析需求来说，我们需要关注的是其Data字段（在协议目录里可以看到"data length标识，点击即可查看data段"）的内容。

　　3.TCP的几个状态对于我们分析所起的作用。在TCP层，有个FLAGS字段，这个字段有以下几个标识：SYN, FIN, ACK, PSH, RST, URG.其中，对于我们日常的分析有用的就是前面的五个字段。它们的含义是：SYN表示建立连接，FIN表示关闭连接，ACK表示响应，PSH表示有DATA数据传输，RST表示连接重置。其中，ACK是可能与SYN，FIN等同时使用的，比如SYN和ACK可能同时为1，它表示的就是建立连接之后的响应，如果只是单个的一个SYN，它表示的只是建立连接。TCP的几次握手就是通过这样的ACK表现出来的。但SYN与FIN是不会同时为1的，因为前者表示的是建立连接，而后者表示的是断开连接。RST一般是在FIN之后才会出现为1的情况，表示的是连接重置。一般地，当出现FIN包或RST包时，我们便认为客户端与服务器端断开了连接；而当出现SYN和SYN＋ACK包时，我们认为客户端与服务器建立了一个连接。PSH为1的情况，一般只出现在DATA内容不为0的包中，也就是说PSH为1表示的是有真正的TCP数据包内容被传递。TCP的连接建立和连接关闭，都是通过请求－响应的模式完成的。

封包分析的手段，说简单也挺简单的，那就是：比较！要不断地从不同的思维角度对封包进行对比分析，要充分发挥你的想象力不断地截取自己需要的包进行比较。不仅要作横向（同类）的比较，还要作纵向（不同类）的比较。即时对于同一个包，也要不断地反复研究。

　　初涉封包分析的新手，一般会不知道封包分析究竟该从何入手。基于经验，本文将告诉你一般会从哪些类型的包入手进行分析以及应该怎样对封包进行初步的分析。需要指出的是：封包分析是一件非常有趣但同时也非常考验耐心的事，通常，半天的封包分析下来，会让你眼前全是诸如“B0 EF 58 02 10 72....”之类的网络数据，而且附带有头疼、头晕症状，所以，没有充分的心理准备，还请不要轻易尝试。呵呵。

　　从事封包分析的基本前提是：应该了解和熟悉TCP协议，并知道数据包“粘合”是怎么一回事。当然，我们平常截获到的包，从数量上来看，只有一小部分是属于“粘合”的情况。但如果不了解它，将可能会对你的分析思路产生误导和困惑。关于“粘包”的更详细解释，请参考我的另外一篇文章“拼包函数及网络封包的异常处理(含代码) (http://blog.csdn.net/sodme/archive/2005/07/10/419233.aspx)”。

　　上一篇有关魔兽世界封包分析的文章（http://blog.csdn.net/sodme/archive/2005/06/18/397371.aspx）中，我根据客户端与服务器端连接及断开事件的处理流程以及登录过程中的一些数据包分析了魔兽的架构和登录逻辑。这篇文章中，我将结合聊天数据包的分析，来阐述魔兽世界封包的大体结构。

　　首先解释一下我们的目标：封包的大体结构。封包的大体结构包含哪些内容呢？一般情况下，封包的大体结构至少包括两方面的信息：
　　1、一个封包是如何表示它的长度的？封包长度是由哪个字段表示的？（或者说：如何表示封包的开始和结束的）
　　2、各种不同的封包类型是通过哪个字段表示的？

　　是不是所有游戏的封包都必然会有表示“长度”信息的“字段”呢？答案是否定的。有的游戏确实没有采用这种方式，它们的作法设定特殊的包开始和包结束标志。但是，从应用的角度来看，偶推荐使用“长度”这样的方法，因为不管在网络底层的处理效率以及上层应用的处理便捷性来说，使用“长度”字段标识一个完整的逻辑包都是比较好的办法。在确定了封包的大体结构后，我们才方便分析具体类型包（比如聊天、行走等）的详细结构。

　　作数据包分析，在单纯采用黑箱分析的阶段，我们选取的数据包，须要是具有这种性质的，即：在数据包发送前客户端未进行加密等处理时，这个数据包中的部分内容，我们是已经知道的。这样的包，就可以作为封包分析的突破口。这样看来，我们拿“聊天封包”作为第一个分析对象也就不难理解了，因为我们说的话，打上去的字，我们自己是知道的，但是我们说的话经过客户端的处理后，发到网络上的可能就是已经加了密的或者加了校验码的。站在黑箱分析的角度，我们能作的，就是不断截取各种“聊天包”进行对比、判断和总结。

　　OK，打开你的commview。让我们从“聊天封包”开始。

　　分析“聊天包”的前提，是我们能够正常判断哪种类型的数据包是属于聊天的，不要误把行走或其它的数据包当作了聊天数据包。为了减小分析难度，建议新手到游戏中人少或周围没有玩家的地方进行封包分析。这样一来没人打扰，二来你的网络通信量会相对小得多，比较容易进行一些封包判定。

　　第一步，我们需要确定客户端与服务器通信所用的端口，然后在commview的rules->ports中设定服务器端口，截获与该端口通信的所有数据包。服务器端口的确定方法：不要使用其它网络通信工具，打开commview，进游戏，截包，观察其通信端口。进行封包分析时，特别是初期的封包分析时，你的网络通信应该尽可能是单一的，即：除了游戏，其它的通信软件尽可能不要开。但当你确定了服务器的IP和端口后，就可以照常使用其它网络软件了。

　　第二步，如前面述，在游戏中找个人少或没人的地方，开始“自言自语”，呵呵。说话的内容，建议以字母和数字为宜，不要说中文。因为中文是双字节的，而字母和数字是单字节的，对于单字节的信息内容，截包软件会以单字节的文本信息显示，但对于双字节的汉字而言，截包软件在对其进行显示时由于换行等原因会造成部分中文显示有乱码，不容易直接看出中文内容。如果执意要说中文，偶也不拦你，给你推荐一个工具：String Demander(下载地址：http://www.cnxhacker.com/Download/show/395.html)，这个软件，可以查询中文所对应的编码。

　　第三步，设定好commview的rules并使之生效，开始截包。

　　观察通过以上的过程所截的包，可以发现，魔兽世界的聊天封包的说话内容是明文的！这一点，用不着大惊小怪，呵呵。聊天封包本身并不会对游戏的关键逻辑造成损害，所以，即使让其明文显示也不足为奇。但是，我们还是不太相信自己的眼睛，于是再截若干个包，发现包中的说话内容确实是明文的！但是，包的其它字段却是我们一时看不懂的“密文”。

　　看来，下面的事情就是对这些包里的“密文”进行研究了。一般情况下，这种“密文”的加密方法，通过封包分析是分析不出来的，但，我们仍然可以通过封包分析来推论一些与“密文”生成算法有关的问题。我们可以作以下的对比分析：
　　1、连续三次输入“a”，并分别观察及保存封包数据；
　　2、连续三次输入“aa”，并分别观察及保存封包数据；
　　3、连续三次输入“aaa”，并分别观察及保存封包数据。

　　输入的封包用例，我们选择了字母"a"，它的ASCII码是61。输入的规律是：每种情况连续输入三次，然后逐次增加a字母的个数。于是，我们发现这样一个有趣的现象：
　　1、包中有关说话的内容是明文的；
　　2、即使针对于同样的说话内容，比如“a”，客户端所发出去的包也是不一样的；
　　3、当一次说话的字母个数增加1时，封包的总体长度也随之增加1；
　　4、除每个封包的前面6个字节以及说话的字节外，其余的封包内容每次都一样；
　　5、每个聊天封包的结尾字节都是0。

　　于是，我们可以试着得出如下结论：
　　1、包是没有压缩的，它所使用的加密算法应该是按字节进行的，并没有改变封包的长度使之看上去使用统一的长度；
　　2、包是以0结尾的（尽管我们不知道它是以什么表示开头的，呵呵）；
　　3、封包加密算法中所使用的密钥是可变的，即针对于相同的数据包内容由于加密的密钥不同，所以产生的密文也不同。由于客户端的数据传到服务器端后，服务器端还要对数据进行解密。所以，客户端的加密算法与服务器端的解密算法应该共用了前6字节中的某些内容，以此作为解密算法的密钥。如果这6字节中没有包含有关封包加、解密所需要的同步数据，那客户端和服务器之间应该会通过其它的方式同步这样的数据。不过，偶倾向于前者，即：这6字节中应该含有加、解密所需要的密钥信息。

　　回头看我们上面观察到的有趣现象，针对于第2点，反过来想，这应该也是最起码的功能了。就是说，即使客户端作出的是同样的动作，在客户端发出的包中，包的内容也是不一样的。这样，外挂就不能靠单纯的重复发相同的包而达到其目的了。

　　分析来分析去，我们还是没能确定魔兽封包的大体结构。其实，到现在，我觉得我此文的目的已经达到了，即向大家展示封包分析的思维角度和思维方式。至于具体结果，偶觉得倒真的不重要的了。可以肯定地告诉大家的是，魔兽的封包结构偶大致已经掌握了。偶仅在此公布我的分析结果：
　　1、魔兽的封包长度字段是每个封包的前两字节，它的表示方式是：前两字节的数值＋2。之所以加这个2，是因为封包长度字段本身占用了两个字节的长度。
　　2、魔兽的封包类型偶推断是第三和第四字节，其中普通聊天的类型标识是“95 00”。

　　请不要来信向我询问任何有关魔兽封包破解的内容，偶能说的都已经在文章里说了，偶之所以写这个系列的文章不是想破解魔兽，而是想以这样优秀的一款游戏作为案例来向大家展示它在封包设计方面值得我们学习和讨论的地方，同时向更多的朋友普及有关封包分析的常识、工具以及思维方式，仅此而已。

　　ps:由于每次封包分析的内容都很多，所以，一有了点结论后，要及时记录和总结，并与之前取得的总结进行对比，及时更新相关的记录文档。

计算机群集技术概述

redwolf@redwolf.com.cn (redwolf) — Sun, 30 Apr 2006 11:31:43 +0800

　　随着计算机技术的发展和越来越广泛的应用，越来越多的依赖于计算机技术的应用系统走进了我们的工作和生活。在给我们带来方便和效率的同时，也使得各行各业对于计算机技术的依赖程度越来越高。尽管随着计算机技术以日新月异的速度发展，单台计算机的性能和可靠性越来越好，但还是有许多现实的要求是单台计算机难以达到的。看看下面的例子：

　　• 某银行需要一台服务器来储存财务数据。他要求这台计算机即使是在机房坍塌的情况下也能够被各个业务网点访问。
　　• 某科研单位需要用一台超级计算机来模拟气象变化。他们需要有相当于200GHz奔腾4处理器的浮点运算能力。
　　• 某网络公司刚刚起步。他们想要一台现在5万人民币以下，但以后可以逐步升级到具有巨型计算机能力的服务器来运行数据库。

　　在这些情况下，往往需要将多台计算机组织起来进行协同工作来模拟一台功能更强大解决问题。这种技术称为集群技术。目前应用最为广泛的集群计算技术可以分为三大类：高可用性集群技术、高性能计算集群技术和高可扩展性集群技术。下面我们将对这三种集群技术进行一下简单的介绍。
高可用性集群技术

　　高可用性集群，英文原文为High Availability Cluster, 简称HA Cluster，是指以减少服务中断（宕机）时间为目的的服务器集群技术。

　　随着全球经济的增长，世界各地各种各样的组织对IT系统的依赖都在不断增加，电子贸易使得商务一周七天24小时不间断的进行成为了可能。新的强大的应用程序使得商业和社会机构对日常操作的计算机化要求达到了空前的程度，趋势非常明显，我们无时无刻不依赖于稳定的计算机系统。

　　这种需求极速的增长，使得对系统可用性的要求变得非常重要，许多公司和组织的业务在很大程度上都依赖于计算机系统，任何的宕机都会造成严重的损失，关键IT系统的故障可能很快造成整个商业运作的瘫痪，每一分钟的宕机都意味着收入、生产和利润的损失，甚至于市场地位的削弱。

Industry Business Operation                   Average Cost per Hour of Downtime
Financial Brokerage operations                   $6.5 million
Financial Credit card/sales authorization $2.6 million
Media Pay-per-view television                   $1.1 million
Retail Home Shopping (TV)                   $113.0 thousand
Retail Home catalog sales                   $90.0 thousand
Transportation Airline reservation $89.5 thousand

　　根据1998年Garter Group的统计我们可以看出，我们需要可以不间断使用的计算机系统，并且这种对高可用性系统和技术的需求还会不断的增长。

　　可用性是指一个系统保持在线并且可供访问，有很多因素会造成系统宕机，包括为了维护而有计划的宕机以及意外故障等，高可用性方案的目标就是使宕机时间以及故障恢复时间最小化，可以容忍的宕机时间明确的说明方案的全面性、复杂性和成本

Percent Available downtime/Year Classification
99. 5                   3.7 days                  Conventional
99. 9                   8.8 hours                 Available
99. 99                       52.6 minutes     Highly Available
99. 999                     5.3 minutes         Fault Resilient
99. 9999                   32 seconds         Fault Tolerant

　　为了提高整个系统的可用性，除了提高计算机各个部件的可靠性以外，一般情况下都会采用集群的方案。
所谓集群，就是共同为客户机提供网络资源的一组计算机系统。而其中的每一台提供服务的计算机，我们称之为节点。当一个节点不可用或者不能处理客户的请求时，该请求将会转到另外的可用节点来处理，而这些对于客户端来说，它根本不必关心这些要使用的资源的具体位置，集群系统会自动完成。
集群中节点可以以不同的方式来运行，这要看它们是如何设置的。在一个理想的两个节点的集群中，两个服务器都同时处于活动状态，也就是在两个节点上同时运行应用程序，当一个节点出现故障时，运行在出故障的节点上的应用程序就会转移到另外的没有出现故障的服务器上，这样一来，由于两个节点的工作现在由一个服务器来承担，自然会影响服务器的性能。
针对这种情况的解决方案是，在正常操作时，另一个节点处于备用状态，只有当活动的节点出现故障时该备用节点才会接管工作，但这并不是一个很经济的方案，因为你不得不买两个服务器来做一个服务器的工作。虽然当出现故障时不会对性能产生任何影响，但是在正常运行时的性能价格比并不太好。
从上面的工作方式出发，我们可以把集群分为下面几种（特别是两节点的集群）

　　主/主 (Active/active)

　　这是最常用的集群模型，它提供了高可用性，并且在只有一个节点在线时提供可以接受的性能，该模型允许最大程度的利用硬件资源。每个节点都通过网络对客户机提供资源，每个节点的容量被定义好，使得性能达到最优，并且每个节点都可以在故障转移时临时接管另一个节点的工作。所有的服务在故障转移后仍保持可用，但是性能通常都会下降。
主/从(Active/passive)

　　为了提供最大的可用性，以及对性能最小的影响，Active/passive模型需要一个在正常工作时处于备用状态，主节点处理客户机的请求，而备用节点处于空闲状态，当主节点出现故障时，备用节点会接管主节点的工作，继续为客户机提供服务，并且不会有任何性能上影响。
混合型(Hybrid)

　　混合是上面两种模型的结合，只针对关键应用进行故障转移，这样可以对这些应用实现可用性的同时让非关键的应用在正常运作时也可以在服务器上运行。当出现故障时，出现故障的服务器上的不太关键的应用就不可用了，但是那些关键应用会转移到另一个可用的节点上，从而达到性能和容错两方面的平衡。
高性能计算集群技术

　　高性能计算集群，英文原文为High Performance Computing Cluster, 简称HPC Cluster，是指以提高科学计算能力为目的计算机集群技术。 HPC Cluster是一种并行计算（Parallel Processing）集群的实现方法。并行计算是指将一个应用程序分割成多块可以并行执行的部分并指定到多个处理器上执行的方法。目前的很多计算机系统可以支持SMP（对称多处理器）架构并通过进程调度机制进行并行处理，但是SMP技术的可扩展性是十分有限的，比如在目前的Intel架构上最多只可以扩展到8颗CPU。为了满足哪些"计算能力饥渴"的科学计算任务，并行计算集群的方法被引入到计算机界。著名的"深蓝"计算机就是并行计算集群的一种实现。

　　由于在某些廉价而通用的计算平台（如Intel+Linux）上运行并行计算集群可以提供极佳的性能价格比，所以近年来这种解决方案越来越受到用户的青睐。比如壳牌石油（Shell）所使用的由IBM xSeries服务器组成的1024节点的Linux HPC Cluster是目前世界上计算能力最强的计算机之一。

　　HPC Cluster向用户提供一个单一计算机的界面。前置计算机负责与用户交互，并在接受用户提交的计算任务后通过调度器（Scheduler）程序将任务分配给各个计算节点执行；运行结束后通过前置计算机将结果返回给用户。程序运行过程中的进程间通信（IPC）通过专用网络进行。

　　HPC Cluster中使用的服务器通常可以分为用户节点、管理节点、存贮节点和计算节点四种。它们的角色分别是：

　　用户节点：
　　提供用户界面的计算机。它从用户那里接受任务，运行调度器（在本地或独立的"控制节点"上）将任务分派到其它计算机，并将运算结果返回给用户。

　　管理节点：
　　提供管理功能的计算机。它应该能够使管理员从这一计算机对集群中的任意一台计算机进行监视和操作，并处理集群中所有计算机的日志和报警信息。

　　存贮节点：
　　提供存贮共享的计算机。为了使任务可以并行执行，每台执行任务的计算机必须能够访问同样的数据。存贮节点通过网络共享（NFS）或其它方式来确保数据访问的同步。

　　计算节点：
　　真正执行计算任务的计算机。集群中的大部分计算机都是这种类型。一个HPC Cluster中通常同时使用三个网络，它们分别是IPC网络，管理网络和存贮访问网络。根据具体的使用需求和选择的节点特性，这些网络可以使用多种介质和协议。

　　IPC网络：
　　用于并行任务执行时的进程间通信的专用网络，通常要求延迟小，带宽大。

　　管理网络：
　　用来收集集群信息、监视集群计算机和执行维护任务的网络。

　　存贮访问网络：
　　用来访问公用存贮的专用网络。
　　在实现一个HPC Cluster时，通常需要考虑以下问题：
　　• 应用程序是计算能力饥渴型（CPU+内存）还是IO（磁盘/网络）饥渴型？
--HPC Cluster只适合解决计算能力饥渴型的问题
　　• 应用程序是否可以"并行化"？
--HPC Cluster对于可以并行化的应用程序最为有效
　　• 怎样才能提高"计算密度"？
--所谓的"计算密度"是指在单位空间中所能提供的计算能力（所能摆放的计算机台数）。没有很好的计划和组织，一台1000+节点的超级计算机就可能成为一场超级麻烦。更高的计算密度不仅意味着更小的体积，也以为着更加简便的管理和更少的投资。1U的机架式服务器应当是首选。然后应该考虑的是：哪种服务器需要更少的电缆？哪种计算机用作计算节点可以省去额外的控制部件（如连接键盘、鼠标的控制台切换器）？哪种计算节点可以提供更高的计算效能？
　　• 如何安装和管理所有的计算机？
--计算机的可管理性在HPC Cluster的实现中至关重要。在同时面对数十甚至成百上千的计算机的情况下，管理员能否简单快速地执行维护工作常常成为影响集群发挥效用的关键因素。
在集群计算的需求确定之后，选择各种组件构成Cluster的实现方案常常十分困难，而且经常由于组件之间难以协同工作而导致Cluster的实现失败，或者最终构造了一个难以使用又难以管理的Cluster。针对这种情况，应该优先考虑选择一体化的HPC产品。这些产品通常会在厂商的工厂中进行组装和测试，然后按机架的方式交付客户使用。比如在目前的IBM所提供的1300 HPC Cluster，它基于Intel架构的硬件平台和Linux操作系统，使用与"深蓝"计算机上同样的集群计算技术，在计算密度、集群管理等方面都比较出色。

高可扩展性集群技术

　　高可扩展性集群技术
　　高可扩展性集群技术就是带均衡策略（算法）的服务器群集。负载均衡群集在多节点之间按照一定的策略（算法）分发网络或计算处理负载。负载均衡建立在现有网络结构之上，它提供了一种廉价有效的方法来扩展服务器带宽，增加吞吐量，提高数据处理能力，同时又可以避免单点故障。

　　一般的框架结构如下图（以Web访问为例，其它应用类似）。后台的多个Web服务器上面有相同的Web内容，Internet客户端的访问请求首先进入一台服务器，由它根据负载均衡策略（算法）合理地分配给某个Web服务器。每个Web服务器有相同的内容做起来不难，所以选择负载均衡策略（算法）是个关键问题。下面会专门介绍均衡算法。

　　负载均衡的作用就像轮流值日制度，把任务分给大家来完成，以免让一个人过度劳累。但是与轮流值日制度不同的是，负载均衡是一种动态均衡，它通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把任务理分配出去。对于不同的应用环境（如电子商务网站，它的计算负荷大；再如网络数据库应用，读写频繁，服务器的存储子系统系统面临很大压力；再如视频服务应用，数据传输量大，网络接口负担重压。），使用的均衡策略(算法)是不同的。所以均衡策略（算法）也就有了多种多样的形式，广义上的负载均衡既可以设置专门的网关、负载均衡器，也可以通过一些专用软件与协议来实现。在OSI七层协议模型中的第二（数据链路层）、第三（网络层）、第四（传输层）、第七层（应用层）都有相应的负载均衡策略（算法），在数据链路层上实现负载均衡的原理是根据数据包的目的MAC地址选择不同的路径；在网络层上可利用基于IP地址的分配方式将数据流疏通到多个节点；而传输层和应用层的交换（Switch），本身便是一种基于访问流量的控制方式，能够实现负载均衡。
　　到目前为止，针对网络负载均衡的产品主要有两大类：一是硬件；二是软件。硬件产品比软件产品运行得快但是价格较高。著名的产品有：3Com的智能网卡和DynamicAccess技术结合起来，不用在交换机上做任何设置，就可以完成分担任务；Cisco路由器通过对动态环路、旁路技术等功能的提供实践着负载均衡；Win2000中，专门集成了针对服务器群集的负载均衡软件；IBM的Web专用服务器和Network Dispatcher软件；Lotus的ICM；还有许多厂商都支持的链路聚集、高层交换......实现方法还在不断地花样翻新，充实着"负载均衡"的内容。
　　目前，基于均衡算法主要有三种：轮循(Round-Robin)、最小连接数（Least Connections First），和快速响应优先（Faster Response Precedence）。轮循算法，就是将来自网络的请求依次分配给集群中的服务器进行处理。最小连接数算法，就是为集群中的每台服务器设置一个记数器，记录每个服务器当前的连接数，负载均衡系统总是选择当前连接数最少的服务器分配任务。这要比"轮循算法"好很多，因为在有些场合中，简单的轮循不能判断哪个服务器的负载更低，也许新的工作又被分配给了一个已经很忙的服务器了。快速响应优先算法，是根据群集中的服务器状态（CPU、内存等主要处理部分）来分配任务。这一点很难做到，事实上到目前为止，采用这个算法的负载均衡系统还很少。尤其对于硬件负载均衡设备来说，只能在TCP/IP协议方面做工作，几乎不可能深入到服务器的处理系统中进行监测。但是它是未来发展的方向。
　　采用负载均衡群集的场合很多，本文将以Web/Ftp服务器群集这个典型的应用为例进行介绍。互联网的出现使信息访问产生了质的飞跃，但随之而来的是Web流量的激增（高并发访问），由于涉及的信息量十分庞大，用户访问的频率也高，许多基于Web的大型公共信息系统(如电子图书馆、BBS、搜索引擎和远程教育等)需要在实时性和吞吐量方面都具有较高性能的Web服务器支持。一些热门的Web站点由于负荷过重而变得反应迟缓。如何提高Web服务器的性能和效率成为一个亟待解决的问题。
　　实际上，服务器的处理能力和I/O已经成为提供Web服务的瓶颈。如果客户的增多导致通信量超出了服务器能承受的范围，那么其结果必然是服务质量下降。显然，单台服务器有限的性能不可能解决这个问题，一台普通服务器的处理能力只能达到每秒几万个到几十万个请求，无法在一秒钟内处理上百万个甚至更多的请求。显然，采用高性能的主机系统（小型机乃至大型计算机）是可行的。但是，除了其价格价格昂贵外，这种高速、高性能的主机系统，很多情况下也不能解决同时处理几万个并发。因为，高速主机系统只是对于复杂单一任务和有限的并发处理显得高性能，而Internet中的Web服务器绝大多数处理是"简单任务"、高强度并发处理，因此，即便有大资金投入采用高性能、高价格的主机系统，也不能满足Web应用的需要。这就是利用Web服务器群集实现负载均衡的最初基本设计思想。
　　Web服务器群集的概念最早由伊利诺斯州大学（UIUC：University of Illinois at Urbana-Champaign）的超级计算应用中心（NCSA：National Center of Supercomputing Applications)提出并实现了一个原型系统"NCSA Scalable Web Server Cluster"，它通过连接一组计算机对客户同时提供服务，实现分布负载，降低对用户请求的响应时间，并扩展Web服务器的应用。后来Berkeley的NOW小组、NSC和科罗拉多大学的Harvest小组、Cisco及IBM公司等也加入此行列，很快推出相应产品。如NCSA使用几台工作站构成可扩展并行Web服务器群，提供使用其浏览器软件Mosaic、服务器软件httpd的用户查询帮助信息和下载软件的服务器系统，采用轮循算法选择群集中某台计算机为当前访问请求服务；加州大学SWEB系统采用DNS转发技术实现服务器IP地址重定向（Yahoo 采用的就是这种方法）；Inktomi公司利用NOW构造并行的HotBot检索引擎，因而系统具有成本低和扩展能力强的特点；此外，IBM公司也提出类似的可扩展并行Web服务器群集系统的设计方案。这些系统的成功表明Web 服务器群集是改善Web服务的一种有效解决方案，并且正在成为主流技术。
　　在Web负载均衡群集的设计中，网络拓扑被设计为对称结构。在对称结构中每台服务器都具备等价的地位，都可以单独对外提供服务。通过负载算法，分配设备将外部发送来的请求均匀分配到对称结构中的每台服务器上，接收到连接请求的服务器都独立回应客户的请求。如下图所示。

　　这种Web服务器群集有如下特点：
　　1. 高性能：一个Web服务器群集系统由多台Web服务器组成，对外部而言，整个群集就如同一台高性能Web服务器，系统只有一个对外的网络地址（主机名或IP地址），所有的HTTP请求都发到这个地址上。系统中有专门的机制能够将这些请求按照一定原则分发到群集中的各台服务器上，让它们各自分担一部分工作。
　　2. 可扩展性它是采用同样的方法或技术高效率地支持较大规模系统的能力。Web服务器群集系统的组成结构和工作原理决定了它能够比较容易地达到较好的可扩展性，因为扩大系统规模非常容易，只要在网络中增加新的Web服务器计算机即可。
　　3. 高可用性 Web服务器群集系统将会在各种商业应用领域中占有举足轻重的地位。商用系统最重视系统的可靠性和容错性，二者合在一起称为系统的可用性。常用的系统可用性指标有系统平均无故障时间、期望不间断工作时间及年平均故障率等。由于Web服务器群集系统中各台Web服务器之间相对独立，采用一些不太复杂的技术就能使Web服务器群集系统达到很高的可用性。一些商用产品中已经部分实现了这种技术。
此外，Web服务器群集系统还具有价格便宜、能够保护原有投资等特点。
　　目前比较成熟的产品主要有Cisco的LocalDirector、IBM的Network Dispatcher、HydraWEB的HydraWEB Dispatcher和RND的Web Server Director等等。这些产品的应用非常广泛，如Yahoo、Net Center和MSN都是用几百到几千台计算机组成Web 服务器群集来对外提供服务，它们使用了上述产品。

高可用集群技术

　　高可用集群技术
　　下面针对高可用性集群，介绍一下它的工作原理。
　　在微软的MSCS（Microsoft Cluster Server）术语中，所有的应用程序、数据文件、磁盘、网络IP地址等都被称为资源，一些资源可以组成一个资源组，一个资源组存在于一个节点上，但同时只能在一个节点上，它是MSCS可以进行故障切换（FailOver）的最小单元。
　　在MSCS中，所有的资源都处于资源监视器的监视之下，资源监视器通过资源动态链接库文件与资源进行通信，这些资源动态链接库会侦测对应资源的状态，并通知资源监视器，之后，监视器再把信息提供给集群服务（Cluster Service），缺省情况下，集群服务会启动一个资源监视器来监视节点中的全部资源。
MSCS用依赖性来定义不同资源彼此之间的关系，MSCS会根据资源间的相互依赖关系来决定把这些资源变为在线或者是离线的顺序。举一个WEB服务器文件共享的例子，文件共享的资源需要硬盘驱动器来存储数据，把这些有关系的资源一起放在MSCS组中，要实现共享，就必须先把硬盘准备好。同时，为了完成文件共享，我们还需要准备好网络名称以及IP地址。

　　从上图可以看出，文件共享资源依赖于硬盘资源，网络名称资源依赖于IP地址资源，而对应的WEB服务刚依赖于文件共享和网络名称。
　　资源的存在可以分为五种状态
　　1、Offline，资源不能被别的资源或者客户机使用
　　2、Offline Pending，资源正处于Offline的过程中
　　3、Online，资源处于可用的状态
　　4、Online Pending，资源正处于Online的过程中
　　5、Failed，资源出现了MSCS无法解决的问题
　　前面已经提到，MSCS可以从一个节点故障切换到另一个节点的最小单元是资源组。被定义好的相关的资源放在同一个组中，并建立对应的依赖关系。以下图为例，如果节点A中的资源组1要移到节点B上的话，资源组1中的资源（资源A，资源B，资源C）也必须从节点A移到节点B才行。

　　在MSCS的资源中，有一个非常重要的资源，Quorum，它是一个可以被两个节点访问的物理硬盘，用来保存集群的信息。这些信息是用来维护集群的完整性以及使节点保持同步，特别是当节点不能与另一个节点通信的时候。Quorum盘在某一时刻只能被一个节点所拥有，并用来决定由哪个节点来拥有集群的所有资源。Quorum必须位于共享的磁盘子系统中，一般都是使用外接的磁盘柜。一般情况下，不建议把应用
程序和数据保存到包含Quorum的硬盘上。
故障切换（Failover）是指把出现故障的节点上的资源重新定位到另一个可用的节点上。负责监视资源的资源监视器一旦发现资源出现故障，它就会通知集群服务，集群服务会根据事前定义好的策略触发对应的事件。虽然发现的是个别资源的故障，但是，集群还是会把整个资源组进行故障切换。

　　故障切换会在三种不同的情况下发生：人工（一般是因为管理员的请求），自动，或者在特定的时间（由集群管理软件设定）。自动故障切换又包含了三个阶段：1、故障发现。2、资源重新定位。3、重新启动应用程序（一般是故障切换过程中最耗费时间的）。当达到资源组的故障切换阀值时，自动的故障切换才会发生，阀值是可以设定的，一般由管理员来设定。
故障恢复（Failback）是一种故障切换的特例，是指发生故障切换之后，把部分或者全部资源组移回它们首选的节点的过程。首选的节点，就是指集群中指定的运行资源组的道选的节点，如果是多个节点的高可用性方案，就会有多个首选的节点。当首选的节点出现故障后，对应的资源组就切换到另外的可用节点上，当出现故障的节点恢复正常后，资源组可以自动的切换回首选节点。如果没有定义首选节点，资源组就不会自动切换回来。
　　要检查资源是不是可用，资源监视器会向对应的动态链接库发送状态信息的请求，一般会有两种级别的检查，LooksAlive和IsAlive。LooksAlive级别的检查相对比较简单，每隔一段时间（相对比较短的时间，缺省是5秒），资源监视器会进行一次LooksAlive级别的检查，如果资源没有响应，监视器会向集群服务报告。IsAlive级别的检查是非常完整的检查，它会彻底检查资源是不是工作正常，IsAlive检查的时间间隔比LooksAlive要长，缺省是1分钟。
结合上面提到的各个要素，高可用性就是通过下面的过程来实现的：
　　首先，资源监视器根据设定的时间间隔对资源进行LookAlive和IsAlive两种级别的检查，一旦发现某一个资源不可用，就会试图重新启动该资源。根据阀值的设定，如果在某一时间段内，资源不可用的情况达到了设定的阀值时，就会发生故障切换。经过故障切换的过程，对应的资源组在另外一个节点上重新启动了，继续为客户机提供服务，对客户来说，工作没有影响，这就完成了一次故障切换。当出现故障的节点恢复正常以后，如果事先对该资源组设定了首选节点，就会把该资源组移回该首选节点。
高性能计算技术
　　HPC: 并行计算工作原理
　　要实现并行计算，您需要：
　　1. 支持并行运算的硬件架构；
　　2. 支持并行计算的应用程序；
　　3. 使应用能够并行执行的软件工具，如编译器，API等等。
下面我们就这三个方面分别介绍它们的分类和作用。
一、并行计算硬件架构
　　1、计算方式的分类
　　在这里我们使用历史"悠久"的Flynn分类法将计算方式分为以下四种：
　　• SISD（单指令流单数据流）：传统的计算机只有一块CPU，因此准许一条指令流顺序执行。目前许多大型主机有一块以上的CPU，但各CPU执行的指令流互不相关，因此它们仍被看作是SISD机器，不过是很多运行在不同数据空间上的SISD的组合。很多HP，DEC和SUN的工作站属于这种类型。并行计算机不应采用这种计算方式。
　　• SIMD（单指令流多数据流）：单个指令流对于多个数据流进行操作。这种方式可以形象化为多台计算机在中央调度处理器的协调下处理各自的数据。从逻辑上看，此时指令全部来自于中央调度器，尽管它们可以执行在不同的硬件设备（CPU）上。
　　• MISD（多指令流单数据流）：多个指令流共同操作同一条数据流。到目前为止尚未发明这样的系统。
　　• MIMD（多指令流多数据流）：这种系统并行的在不同数据上执行不同的指令流，这种类型与上面提到的多处理器SISD系统的本质区别在于不同处理器处理的数据是彼此相关的，它们实际上是在并行执行同一工作的不同部分。因此MIMD系统可以将一个主任务分解为众多子任务并行执行以缩短工作时间。这是目前大部分协同计算系统所采用的计算方式。
　　2、并行计算的相关架构
　　为了使计算机系统能够实现并行处理，一系列的计算机架构相关的技术被开发出来。下面我们介绍一下其中的几种主要技术。
　　■ 处理器阵列（Array Processors）:

　　使用多个处理器组成阵列，在运行时由中央处理器广播指令流，各个其它处理器（又称处理元，processing element）执行指令流来处理本地内存中的数据。这种处理技术是被广泛采用的分布式内存技术的基础。

　　■ 共享内存（Shared Memory）：

　　处理器（PE）通过某种连接机制连接到一块巨大的共享内存上，使得任何处理器都能够访问任何一段内存。这种技术的优点是在并行环境中可以简化操作系统、编译器和应用程序的设计，缺点是当处理器数目增加时性能会迅速下降而成本会迅速上升。著名的Cray T90超级计算机使用的就是这种技术，目前很多的RISC工作站也使用这种技术。这种技术在很多新的并行计算实现上也被部分借鉴。

　　■ 分布式内存（Distributed Memory）：

　　每个处理器（PE）只访问自己的本地内存，处理器之间通过某种连接机制进行通讯，从而进行协同工作，成为一台并行计算机。这种技术的优点是可以很容易地组合很多标准计算机硬件成为一台超级计算机，与其它技术相比具有很高的性能价格比和可扩展性。缺点是应用程序中必须包含明确的信息传递调用以利用并行架构，而且编译器、调试器、并行化工具和性能监测工具的设计也会非常复杂。使用这种技术时，连接机制的选择至关重要。带宽和时延会直接影响整个系统的性能。这种技术在新兴的Linux HPC中广为采用。

　　■ 虚拟共享内存（Virtual Shared memory）：

　　这种技术将分布式内存虚拟为统一的内存空间，从而获得分布式内存和共享内存技术的所有优点。但是由于过多的内存访问调度，在目前的技术水平上性能非常差。目前的实际应用中不会采取这种技术。

二、并行应用程序技术

　　应用程序决定了计算过程中的指令流和数据流，所以应用程序能否并行化是能否利用并行计算机的硬件架构的关键所在。以下是一些对并行应用程序常用技术的简单介绍。

　　■ 数据和功能并行化：

　　这时将计算任务分配到多个处理器上执行的最基本方法。数据并行化是指将需要处理的数据划分到不同的处理器上，然后所有处理器执行相同的指令流来处理各自的数据。设想一下一个求1000个数的正弦函数的程序，如果您有1000个处理器，您可以为每个处理器分配一个计算正弦函数的任务，然后让1000个处理器同时开始执行。这是一种SIMD的实现技术。功能并行化是指将应用程序中的不同功能分配到不同的处理器/内存上去完成，是一种MIMD的实现方法。

　　■ 循环级并行化：

　　对于大多数科学计算任务而言，大部分的时间花费在循环计算之中。在共享内存架构的系统中，"并行编译器"可以检测到循环中互无关联的计算步骤并将它们分配给不同的处理器去执行。

　　■ 数组语句（Array Syntax）：

　　SIMD的另一种实现方法。在程序设计语言中包含对数组成员进行一次性赋值和计算的语句。在并行系统上，并行编译器会自动对这些赋值和计算进行并行化处理。

　　■ 信息传递（Message passing）：

　　在分布式内存架构上，每个处理器只能访问自己的内存。当处理器之间需要进行数据交换时，信息传递是目前最为广泛使用的技术。从程序员的角度来看，这种技术就是一系列发送与接收调用的组合。当应用程序变得比较庞大而复杂时，这种技术的使用会变得非常复杂和容易出错，比如一个处理器等待的消息永远无法收到等等。但是一旦程序设计成功，这种技术在分布式内存系统和共享内存系统上都能够获得很好的性能。

　　三、常用的并行计算工具软件

　　并行计算工具软件是指那些帮助程序设计人员更好或更简单地利用并行架构的工具。下面我们介绍最常用的几种。

　　■ 编译器（Compiler）：

　　编译器在并行计算中的作用分为两个层面，一是像在串行系统上一样生成优化的代码序列，二是将可以并行执行的部分进行并行化处理。尽管编写出能够把传统的、串行结构的应用程序编译为完美的并行代码的编译器是几乎不可能的任务，但计算机科学家们的不懈努力正在使编写并行程序越来越容易。目前很多的编译器可以借助程序员写在程序中的简单编译指导生成高质量的并行代码，如数组语句的处理等。在目前的多数共享内存架构的系统上，编译器已经可以进行循环级的并行化。

　　■ 调试器（Debugger）:

　　调试器可以说是程序设计的必备工具。在并行计算系统中，特别是分布式内存架构的系统中，一个调试器通常面临以下的挑战：必须能够反映出信息传递的过程和状态；在查看变量时，必须能够查看每个处理器上的同名变量的状态；由于在科学计算中大数组的广泛应用，必须能够以直观的方式表示出数组成员的值，等等等等。

　　■ 性能监测/分析工具：

　　由于并行计算所带来的程序并行执行的复杂性和不可预见性，您会需要一个功能强大的性能监测/分析工具来帮助您完成分析并行化程度、信息传递特性以及判定系统瓶颈等工作，以便使并行系统投入产能应用时能够有最好的性能状态。

　　■ 并行化工具/API：

　　并行化工具是指将串行源代码转化为并行源代码的工具，通常只需要程序员在程序中插入简单的宏，就可以完成向并行源代码的转化。并行API主要是指实现了完整信息传递功能的软件包，使得程序员指需要进行简单的调用就可以实现信息传递，而无须自己实现其中的每一个细节。

　　综上所述，一个成功的并行计算系统的核心是硬件架构、应用程序和辅助软件。目前广为应用的硬件架构是共享内存和分布式内存，前者可以简化程序设计但成本高，可扩展性差；后者成本低，扩展性好但会导致程序设计复杂化。应用程序在设计上会因为硬件架构的不同而有所不同，其中信息传递技术虽然设计复杂但在两种硬件架构上都能够获得高性能。恰当的辅助工具不仅使程序设计更为简单，而且实际上，在大规模的应用系统中，没有这些工具几乎不可能实现稳定的、高性能的并行计算。

　　Linux HPC Cluster

　　HPC（高性能计算）虽然已经有很多年的历史了，但是其普及程度一直不是很高。主要原因不外乎以下几点：

　　价格昂贵。相对较小的生产规模使得相关的部件成本极高，价格常常使用户望而却步。

　　不容易扩展。由于没有使用市面上通用的模块，HPC系统的扩展要么不容易在技术上实现，要么成本难以令用户接受。

　　对使用环境要求苛刻。过去，一套大的HPC系统可能需要像篮球场那么大的机房去安装，可以想见配套的建筑、电源、布线和散热措施的准备会有多么复杂和昂贵。

　　近年来，随着计算机技术的进步，一种新的HPC系统正迅速崛起，这就是使用运行Linux操作系统的Intel平台的计算机来构建HPC Cluster。这是一种分布式内存的HPC架构，针对上面提出的三个问题，它能够提供如下的好处：

　　由于使用Linux操作系统和通用的Intel平台，集群中的各个节点（计算机）的价格将会相对低廉；

　　由于使用通用的硬件平台和标准的网络组件，集群的扩展容易实现而且价格低廉；

　　不难看出，Linux HPC最大的优点是廉价！这一特点使得更多的"计算饥渴"的用户可以选择使用HPC系统。作为HPC技术最先进的公司，几年前IBM就已经帮助包括壳牌石油在内的许多客户建立了1000节点以上的Linux HPC系统，这些系统至今仍然在全世界最快速的计算机系统中占据着一席之地。

　　一个好的Linux HPC系统完全不会在任何方面逊色于其它的分布式内存HPC系统，但问题是想要构建一个好的Linux HPC系统事实上是很难的。请考虑以下这些问题：

　　您想要一个廉价的Linux HPC系统。您应该购买什么样的计算机来构成这个系统才能避免在实施和使用中的问题？

　　您有64台Intel平台的计算机来运行Linux系统。为了把它们组建成为一个HPC系统，您还需要购买哪些硬件设备？

　　为了放置这些硬件设备，您需要多少个标准机架和什么样的机房来安装？

　　为了将新的HPC系统整合到您的网络环境中，您需要多少个额外的IP地址？您应该怎样分配它们？

　　为了将新的HPC系统整合到您的网络环境中，您需要多少根网线？如果数目很多的话，您如何保证在安装的时候不会弄错？

　　您打算怎么为这些计算机安装系统？如果系统崩溃了，您又如何保证在最短的时间里让它们恢复运作？

　　您的应用程序打算使用什么并行API开发？

　　您打算使用什么样的程序调度机制和哪一个调度器？

　　您如何做到像管理一台计算机一样管理这个HPC Cluster？
　　负载平衡技术

LoadBalance（负载均衡）群集

　　负载均衡群集系统使应用程序处理负载或网络流量负载可以在计算机群集中尽可能平均地分摊处理。这样的系统非常适合于运行同一组应用程序的大量用户。每个节点都可以处理一部分负载，并且可以在节点之间动态分配负载，以实现平衡。对于网络流量也如此。通常，网络服务器应用程序接受了太多的入网流量，以致无法迅速处理，这就需要将流量发送给在其它节点上运行的网络服务器应用。还可以根据每个节点上不同的可用资源或网络的特殊环境来进行优化。在网站，电子邮件提供商，VOD（Video On Demand）方面有广泛的应用。

　　以下将介绍负载均衡群集。

　　什么是负载均衡群集？-- 解释（定义，一般的框架结构，策略，哪些产品，技术区别，发展）

　　负载均衡群集就是带均衡策略（算法）的服务器群集。负载均衡群集在多节点之间按照一定的策略（算法）分发网络或计算处理负载。负载均衡建立在现有网络结构之上，它提供了一种廉价有效的方法来扩展服务器带宽，增加吞吐量，提高数据处理能力，同时又可以避免单点故障。

　　一般的框架结构如下图（以Web访问为例，其它应用类似）。后台的多个Web服务器上面有相同的Web内容，Internet客户端的访问请求首先进入一台服务器，由它根据负载均衡策略（算法）合理地分配给某个Web服务器。每个Web服务器有相同的内容做起来不难，所以选择负载均衡策略（算法）是个关键问题。下面会专门介绍均衡算法。

　　负载均衡的作用就像轮流值日制度，把任务分给大家来完成，以免让一个人过度劳累。但是与轮流值日制度不同的是，负载均衡是一种动态均衡，它通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把任务理分配出去。对于不同的应用环境（如电子商务网站，它的计算负荷大；再如网络数据库应用，读写频繁，服务器的存储子系统系统面临很大压力；再如视频服务应用，数据传输量大，网络接口负担重压。），使用的均衡策略(算法)是不同的。所以均衡策略（算法）也就有了多种多样的形式，广义上的负载均衡既可以设置专门的网关、负载均衡器，也可以通过一些专用软件与协议来实现。在OSI七层协议模型中的第二（数据链路层）、第三（网络层）、第四（传输层）、第七层（应用层）都有相应的负载均衡策略（算法），在数据链路层上实现负载均衡的原理是根据数据包的目的MAC地址选择不同的路径；在网络层上可利用基于IP地址的分配方式将数据流疏通到多个节点；而传输层和应用层的交换（Switch），本身便是一种基于访问流量的控制方式，能够实现负载均衡。

　　到目前为止，针对网络负载均衡的产品主要有两大类：一是硬件；二是软件。硬件产品比软件产品运行得快但是价格较高。著名的产品有：3Com的智能网卡和DynamicAccess技术结合起来，不用在交换机上做任何设置，就可以完成分担任务；Cisco路由器通过对动态环路、旁路技术等功能的提供实践着负载均衡；Win2000中，专门集成了针对服务器群集的负载均衡软件；IBM的Web专用服务器和Network Dispatcher软件；Lotus的ICM；还有许多厂商都支持的链路聚集、高层交换......实现方法还在不断地花样翻新，充实着"负载均衡"的内容。

　　负载均衡系统的几种负载均衡算法（负载均衡策）

　　目前，基于均衡算法主要有三种：轮循（Round-Robin）、最小连接数（Least Connections First），和快速响应优先（Faster Response Precedence）。轮循算法，就是将来自网络的请求依次分配给集群中的服务器进行处理。最小连接数算法，就是为集群中的每台服务器设置一个记数器，记录每个服务器当前的连接数，负载均衡系统总是选择当前连接数最少的服务器分配任务。这要比"轮循算法"好很多，因为在有些场合中，简单的轮循不能判断哪个服务器的负载更低，也许新的工作又被分配给了一个已经很忙的服务器了。快速响应优先算法，是根据群集中的服务器状态（CPU、内存等主要处理部分）来分配任务。这一点很难做到，事实上到目前为止，采用这个算法的负载均衡系统还很少。尤其对于硬件负载均衡设备来说，只能在TCP/IP协议方面做工作，几乎不可能深入到服务器的处理系统中进行监测。但是它是未来发展的方向。

　　综上所述，负载均衡群集的使用是非常广泛的，它的核心内容是运用越来越科学的负载分配算法开发出软件或硬件，来实现负载的更加合理地分配。

　　怎么用？——举例说明，并包含需求分析

　　采用负载均衡群集的场合很多，本文将以Web/Ftp服务器群集这个典型的应用为例进行介绍。互联网的出现使信息访问产生了质的飞跃，但随之而来的是Web流量的激增（高并发访问），由于涉及的信息量十分庞大，用户访问的频率也高，许多基于Web的大型公共信息系统(如电子图书馆、BBS、搜索引擎和远程教育等)需要在实时性和吞吐量方面都具有较高性能的Web服务器支持。一些热门的Web站点由于负荷过重而变得反应迟缓。如何提高Web服务器的性能和效率成为一个亟待解决的问题。

　　实际上，服务器的处理能力和I/O已经成为提供Web服务的瓶颈。如果客户的增多导致通信量超出了服务器能承受的范围，那么其结果必然是宕机。显然，单台服务器有限的性能不可能解决这个问题，一台普通服务器的处理能力只能达到每秒几万个到几十万个请求，无法在一秒钟内处理上百万个甚至更多的请求。显然，采用高性能的主机系统（小型机乃至大型计算机）是可行的。但是，除了其价格价格昂贵外，这种高速、高性能的主机系统，很多情况下也不能解决同时处理几万个并发。因为，高速主机系统只是对于复杂单一任务和有限的并发处理显得高性能，而Internet中的Web服务器绝大多数处理是"简单任务"、高强度并发处理，因此，即便有大资金投入采用高性能、高价格的主机系统，也不能满足Web应用的需要。这就是利用Web服务器群集实现负载均衡的最初基本设计思想。

　　早期的服务器群集通常以主从方式（Active-Passive）备份。令服务运营商头疼的问题是：关键性服务器一般档次较高，花了两台服务器的钱却只能得到一台服务器的性能。随着LSANT（Load Sharing Network Address Transfer）技术的推出，这个问题得到了解决。多台服务器的IP地址被翻译成一个虚拟IP地址（VIP：Virtual IP），使得每台服务器均时时处于工作状态。若能将10台这样的服务器组成一个系统，并通过软件技术将所有请求平均分配给所有服务器，那么这个系统就完全拥有每秒钟处理几百万个甚至更多请求的能力。这样原来需要用小型机来完成的工作现由多台PC服务器就可以完成，这种弹性解决方案对投资保护的作用是相当明显的——既避免了小型机刚性升级所带来的巨大设备投资，又避免了人员培训的重复投资。同时，服务运营商可以依据业务的需要随时调整服务器的数量。至此形成了Web服务器群集的理论。

　　Web服务器群集的概念最早由伊利诺斯州大学（UIUC：University of Illinois at Urbana-Champaign）的超级计算应用中心（NCSA：National Center of Supercomputing Applications)提出并实现了一个原型系统"NCSA Scalable Web Server Cluster"，它通过连接一组计算机对客户同时提供服务，实现分布负载，降低对用户请求的响应时间，并扩展Web服务器的应用。后来Berkeley的NOW小组、NSC和科罗拉多大学的Harvest小组、Cisco及IBM公司等也加入此行列，很快推出相应产品。如NCSA使用几台工作站构成可扩展并行Web服务器群，提供使用其浏览器软件Mosaic、服务器软件httpd的用户查询帮助信息和下载软件的服务器系统，采用轮循算法选择群集中某台计算机为当前访问请求服务；加州大学SWEB系统采用DNS转发技术实现服务器IP地址重定向（Yahoo 采用的就是这种方法）；Inktomi公司利用NOW构造并行的HotBot检索引擎，因而系统具有成本低和扩展能力强的特点；此外，IBM公司也提出类似的可扩展并行Web服务器群集系统的设计方案。这些系统的成功表明Web 服务器群集是改善Web服务的一种有效解决方案，并且正在成为主流技术。

　　在Web负载均衡群集的设计中，网络拓扑被设计为对称结构。在对称结构中每台服务器都具备等价的地位，都可以单独对外提供服务。通过负载算法，分配设备将外部发送来的请求均匀分配到对称结构中的每台服务器上，接收到连接请求的服务器都独立回应客户的请求。如下图所示。

　　Web服务器群集有如下特点：

　　高性能：一个Web服务器群集系统由多台Web服务器组成，对外部而言，整个群集就如同一台高性能Web服务器，系统只有一个对外的网络地址（主机名或IP地址），所有的HTTP请求都发到这个地址上。系统中有专门的机制能够将这些请求按照一定原则分发到群集中的各台服务器上，让它们各自分担一部分工作。

　　可扩展性它是采用同样的方法或技术高效率地支持较大规模系统的能力。Web服务器群集系统的组成结构和工作原理决定了它能够比较容易地达到较好的可扩展性，因为扩大系统规模非常容易，只要在网络中增加新的Web服务器计算机即可。

　　高可用性 Web服务器群集系统将会在各种商业应用领域中占有举足轻重的地位。商用系统最重视系统的可靠性和容错性，二者合在一起称为系统的可用性。常用的系统可用性指标有系统平均无故障时间、期望不间断工作时间及年平均故障率等。由于Web服务器群集系统中各台Web服务器之间相对独立，采用一些不太复杂的技术就能使Web服务器群集系统达到很高的可用性。一些商用产品中已经部分实现了这种技术。

　　此外，Web服务器群集系统还具有价格便宜、能够保护原有投资等特点。

　　目前比较成熟的产品主要有Cisco的LocalDirector、IBM的Network Dispatcher、HydraWEB的HydraWEB Dispatcher和RND的Web Server Director等等。这些产品的应用非常广泛，如Yahoo、Net Center和MSN都是用几百到几千台计算机组成Web 服务器群集来对外提供服务，它们使用了上述产品。

　　以下是对2个Web服务器群集产品的分析：

　　Scalable Web Server Cluster UIUC的NCSA Scalable Web Server Cluster是世界上第一个Web服务器群集系统。1994年，NCSA为了缓解其Web站点面临的大量用户访问的压力，把4台Sun工作站用FDDI连接起来组成一个群集，代替原有单台Sun工作站的Web服务器，对外提供Web服务。NCSA把这个系统称为Scalable Web Server Cluster，它几乎具备了现代Web服务器群集系统所具有的一切特征：用高速局域网连接多台Web服务器，通过并行处理提高系统的吞吐能力；整个系统只有一个网络地址; 通过一台动态DNS服务器实现请求分配，该DNS服务器对DNS请求采用轮循算法依次返回群集中各台Web服务器的IP地址，引导Client将HTTP请求发送到群集中不同的Web服务器上，以实现群集的负载均衡; 采用AFS（UNIX支持的分布式文件系统）将多台服务器上的文件系统组合成一个逻辑上单一的分布式文件系统，用来存储站点内容，使请求不论被分配到哪台Web服务器上都能得到完全相同的应答服务；系统在其中一台Web服务器发生故障时仍能正常工作，并支持在线增加或减少Web服务器的数量等（其结构如下图所示）。

　　Scalable Web Server Cluster是一个实验性的Web服务器群集系统，现代Web服务器群集系统和产品的大部分概念和方法均来源于它。
LocalDirector Cisco的LocalDirector是一种用来实现请求分配的设备，通过它可以组成Web服务器群集系统。LocalDirector有2个网络接口，一个用于连接Internet，另一个用于连接局域网中的Web服务器群集，如下图所示。

　　LocalDirector采用IP NAT（Network Address Transfer）技术，整个系统对外只有一个IP地址，通过IP地址变换将HTTP请求分配到群集中不同的Web服务器。群集中的各台Web服务器上存储的页面信息要求完全一致。LocalDirector在请求分配时实现了2种不同的负载均衡算法：最小连接数和快速响应优先，用户在配置LocalDirector时可以选择使用其中一种。此外，LocalDirector还支持动态改变群集规模的大小，即在不停机的情况下增加或减少服务器。

　　LocalDirector具有很强的吞吐能力，自身延迟也小，因而能够支持较大规模的系统，并且可以通过级联进一步扩大系统的规模（如下图所示）。像IBM的Network Dispatcher、HydraWEB的HydraWEB Dispatcher和RND的Web Server Director等在结构和功能上与LocalDirector类似。值得一提的是，这些产品的价格基本上与一台普通的工作站相当，比大多数高性能计算机要低许多。

　　总结：
　　负载均衡群集的应用提高了Web服务器、FTP服务器，邮件服务器和其它关键应用服务器的可用性和可伸缩性。单一计算机只能提供有限级别的服务器可靠性和可伸缩性。但是，通过将两个或两个以上高级服务器的主机连成群集，网络负载均衡就能够提供关键任务服务器所需的高可靠性和高性能。

Cisco注册及证书问题

redwolf@redwolf.com.cn (redwolf) — Tue, 28 Mar 2006 11:27:42 +0800

Tips:去考试中心注册考试时，推荐使用126的信箱http://mail.126.com

Tips:请不要在论坛中公布您的Cisco认证跟踪系统密码，以免造成不必要的损失。

Tips:关于通过考试后Cisco发的确认信，这个信没什么用，没收到也没关系，收到了也不用深究，看一下删除就可以。请不要去追求这些无关紧要的小事了:p(假如是考试中心代收证书，一般考生不会收到这些邮件)

Tips:凡是由考场代收证书的考生，请自己直接联系考场协商注册和收证书等问题，Cisco ID和密码也请直接询问考场工作人员，不必回帖询问了。

Tips:通过考试后，一般20天以内会发出证书，请耐心等待。收到证书一般需要4-8周时间(该时间从证书发出开始计时)，省会城市快的话可能2周就能收到(从发出证书开始计算)，请少安毋躁，耐心等待就可以。

Tips:假如不能访问Cisco认证跟踪系统的站点，请稍后再试，或者检查您自己的网络设置。

Tips:Last name是考生的姓，比如名字是钱伯斯，那么Last name是Qian(写qian或者QIAN也可以)，First name是BoSi(写bosi或者BOSI也可以)

Tips:通过考试后的成绩单一般是1张，个别情况可能是多张，这个不影响证书发送。

Tips:发现名字错了，请直接联系考试中心解决。假如是考试中心原因导致的错误，可以叫考试中心负责改名字，或者叫他们免费安排重新考试)。假如是自己原因导致名字错误，自认倒霉吧，花钱买点经验，或者请考试中心给你改名字(需要提交报告到上级机构)

Tips:协议的签署，晚几天也没关系(一般几天内不签署，会自动被签署，这可能和考场有一定关系)，只是可能导致证书晚到几天。

考试后2个月没收到证书怎么办？
1:联系你考试时的考试中心，询问是否他们代收了。假如是代收，问是否到了；假如没有代收，看是否自己注册并从Cisco发出了。
2:假如证书状态不正常，导致没有从Cisco发出，参考下面的证书状态问题的文章处理
3:假如证书状态正常，也从Cisco发出了，但是没有收到，那么可能是邮局给弄丢了，或者邮局投递后，被你填写的收信人弄丢了(比如小区收发室的收发人员)。这时可以参考下面的文章向Cisco购买纸质证书或者购买电子证书(需要用信用卡向Cisco支付15美元)。

让别人验证你通过了Cisco考试的方法

关于通过考试后Cisco发来的邮件

在VUE查询考试已经通过的方法(查Cisco ID很方便)

如何在Prometric查看是否通过了考试

如何更改我在Cisco的名字？(需要提供国内相关部门出具的身份证明)

为什么我没有收到证书？(请耐心等待4-8个周的时间)

什么是Cisco ID Number？

几个ID的区别：Cisco ID, Testing ID, Candidate ID, Registration ID and Validation ID

提问时最好请附上JPG图片说明，需要登录跟踪系统查看的，请提供Cisco ID和密码。(请不要在论坛公开您的密码)

鉴于不少问题的解决方法不能三言两语描述出来，因此需要了解注册问题的，请您直接提供下列资料：
假如是在VUE考试的，请提供：Registration ID和Validation ID，还有您的姓(生僻字请提供汉语拼音的读音)。
假如是在Prometric考试的，请提供：Candidate ID和Registration ID，还有您的姓(生僻字请提供汉语拼音的读音)。

这些ID都在您的CCNA成绩单上能找到，请仔细看一下。假如考试后没有拿到成绩单或者您将成绩单丢失了，请直接联系您考试时的考试中心。

CCNA证书样本，点击看大图

此主题相关图片如下：

CCNA卡样本，点击看大图

此主题相关图片如下：

验证你通过了Cisco考试的方法

1.使用您的Cisco ID和密码登录下面的地址(想必大家都很熟悉了)
https://www.certmanager.net/cisco/login.aspx?ReturnUrl=%2fCisco%2fDefault.aspx

登录后点击上面的“Validation and Logos”
选择其中的“Certification Validation”

520)this.width=520;" src="http://www.gotoie.com/leadbbs/images/fileType/jpg.gif" onload="javascript:if(this.width>520)this.width=520;" align=absMiddle border=0>此主题相关图片
520)this.width=520;" style="CURSOR: hand" onclick=javascript:window.open(this.src); src="http://www.gotoie.com/leadbbs/images/upload/2004/08/11/165034.jpg" width=520 onload="javascript:if(this.width>520)this.width=520;" align=absMiddle border=0>

2.
520)this.width=520;" src="http://www.gotoie.com/leadbbs/images/fileType/jpg.gif" onload="javascript:if(this.width>520)this.width=520;" align=absMiddle border=0>此主题相关图片
520)this.width=520;" style="CURSOR: hand" onclick=javascript:window.open(this.src); src="http://www.gotoie.com/leadbbs/images/upload/2004/08/11/165114.jpg" width=520 onload="javascript:if(this.width>520)this.width=520;" align=absMiddle border=0>

3.对方会收到这样的邮件
520)this.width=520;" src="http://www.gotoie.com/leadbbs/images/fileType/jpg.gif" onload="javascript:if(this.width>520)this.width=520;" align=absMiddle border=0>此主题相关图片
520)this.width=520;" style="CURSOR: hand" onclick=javascript:window.open(this.src); src="http://www.gotoie.com/leadbbs/images/upload/2004/08/11/165149.jpg" width=520 onload="javascript:if(this.width>520)this.width=520;" align=absMiddle border=0>

4.访问邮件中提供的地址，并输入邮件中提供的ID
520)this.width=520;" src="http://www.gotoie.com/leadbbs/images/fileType/jpg.gif" onload="javascript:if(this.width>520)this.width=520;" align=absMiddle border=0>此主题相关图片
520)this.width=520;" style="CURSOR: hand" onclick=javascript:window.open(this.src); src="http://www.gotoie.com/leadbbs/images/upload/2004/08/11/165300.jpg" onload="javascript:if(this.width>520)this.width=520;" align=absMiddle border=0>

5.就可以看到您通过考试了。
520)this.width=520;" src="http://www.gotoie.com/leadbbs/images/fileType/jpg.gif" onload="javascript:if(this.width>520)this.width=520;" align=absMiddle border=0>此主题相关图片
520)this.width=520;" style="CURSOR: hand" onclick=javascript:window.open(this.src); src="http://www.gotoie.com/leadbbs/images/upload/2004/08/11/165334.jpg" onload="javascript:if(this.width>520)this.width=520;" align=absMiddle border=0>

NA考试中子网计算的通吃方法

redwolf@redwolf.com.cn (redwolf) — Wed, 22 Mar 2006 17:50:45 +0800

NA考题中经常会有要算某个IP地址是否在某一个子网中，或者诸如此类的问题。其实解决方法很简单，根本用不着去求助什么子网计算器。
这里以一个C类网络（192.168.0.0)为例，详细说明此方法：
大家知道C类地址的标准掩码为24位，即255.255.255.0，使用这样的掩码，该子网中将会有256-2即254个主机地址。（192.168.0.1-192.168.0.254）
接下来就是一个借位的问题，比如说掩码变为了255.255.255.192或者其他的，子网数目，每个子网中的主机地址又是怎么样的呢？
考虑掩码255.255.255.0 其最后八位应该是00000000，如果该串中第一位变了1，即10000000，则对应于十进制数128；前两位都变成了1，即11000000，对应的十进制数就为192，以此类推
上面的情况可以被认为是标准掩码向主机位借位，255.255.255.128表示借了一位，255.255.255.192表示借了两位，以此类推。
如果在标准掩码的基础上向主机位借位为N，未被借出的位（即掩码中为0的位）为M，则由此产生的子网数将为2的N次方减2（过去的一些标准规定第一个和最后一个子网不能使用，所以要减去2）。每个子网中可用的主机数为2的M次方减2（除去网络地址和广播地址）。
那么具体来讲，每个子网的界限如何定呢？
请大家研究以下一个实例：
如果在网络192.168.0.0中使用子网掩码255.255.255.192，情况会是怎样的？
最简便的方法，就是用256减去由借位得来的掩码中的数值（此处为192），就可以得到每个子网的网络号增量。此处为256-192=64
所以，以下的地址都为网络号：
192.168.0.0
192.168.0.64
192.168.0.128
192.168.0.192
一共划出来了四个网络，第一个和最后一个按旧标准规定不能分配，所以可用的网络为
192.168.0.64（包含可用主机地址192.168.0.65------192.168.0.126，一定要注意这是 192.168.0.127是这个子网的广播地址！！）。
另一个可用子网为192.168.0.128（包含可用主机地址192.168.0.129-------192.168.0.190，同理，这个子网的广播地址为192.168.0.191！！）。
注意上面的例子，我们在C类标准掩码255.255.255.0的基础上向主机位借了两位。按照前面的公式，N=2 ; M=8-2=6
所以可用的子网数为2的2次方减2等于2
每个子网可用主机数为2的6次方减2等于62。
关键一点：大家千万不要认为只有IP地址中包含了0的才会是网络地址，同样也不要认为包含了255的就一定会是广播地址，要具体问题具体分析。
上面的方法对A B类地址同样有效。注意是相对标准掩码（A类为255.0.0.0 B类为255.255.0.0）借位。