ISA服务异常诊断思路与步骤

 

诊断总体思路是采用排除法。深入了解ISA拒绝服务发生的前前后后、从操作系统、ISA配置、策略与规则、后台MSDE、入侵与攻击、局域网诊断、内存分配几个层面入手、将有可能涉及到ISA服务异常的可能性逐个进行排查、最后找到可能的线索及对应的解决方法。

我们的步骤如下，以下内容均在服务异常情况严重的ISA01服务器上进行操作，请领导与各位专家逐个审校并纠正、论证诊断思路是否正确可行、提出修改意见。

一、操作系统

a) 操作系统版本与补丁

i. Windows 2003 EE SP1

1. 不是Windows R2版本,排除造成ISA2006兼容性故障。

2. 该兼容性故障描述：该现象原因是网络适配器硬件所计算出来的TCP哈希值与Windows 2003 R2版本所计算出来的TCP哈希值不一致、导致数据包无法正确识别

3. 如果是Windows 2003 R2版本，我们可以通过修改注册表来解决此问题：将注册表中HKLMSYSTEM/CurrentControlSet/Services/Tcpip/Parameters/ EnableRSS的值设为0，并在设备管理器硬件高级属性中关闭接收端调节功能。

ii. 查看补丁情况是否有ISA2006SP1中缺少或建议打上的补丁，命令行执行systeminfo |find "KB"即可查看。

1. 无遗漏的windows补丁程序

2. 查阅ISA2006SP1所需补丁请链接至微软支持中心网站

http://support.microsoft.com/kb/943462

iii. 操作系统上是否安装有其他应用软件，该软件是否会对ISA造成影响。

1. ISA01服务器没有部署其他应用。

2. ISA01服务器查看管理工具中的组件服务，没有发现异常COM组件。

iv. 注册表与组策略

1. 查看ISA可能有影响的注册表内容

2. HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters中的EnableRSS值以禁用接收端缩放。

3. HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters中的EnableTCPA禁用 offloading 支持

4. 详细情况请查阅微软支持中心http://support.microsoft.com/kb/936594/zh-cn

b) 系统基础服务

i. DNS

1. 检查DNS服务配置无误

2. 当9月9日晚22：20分、异常情况重现时、经检测ISA服务假死后、ISA01 ping DNS：正常；ISA01 ping 163.com：正常；ISA01 ping 内网机器ip正常；但是内网nslookup只能解析本地DNS、不能解析外网DNS、即DNS请求出不去。

3. 因为DNS对内正常、对外失败、由于DNS请求出去必须要经过ISA，可以判断ISA此时已经拒绝了内网DNS请求、而经测ISA01ping内外网没有问题

4. DNS没有问题。

ii. AD

1. AD本身与ISA服务没有联系，这里主要看AD有没有异常

2. 经查没有异常

iii. TCP/IP

1. 异常发生的时候、ISA01机器访问http://www.163.com正常、内网http方式访问失败

2. 使用其他非IE浏览器、如FireFox访问，访问失败

3. 改变MTU，故障依旧

4. 改变网卡的执行顺序，故障依旧

5. 停止ISA firewall服务、故障依旧、内网ping ISA01不通、远程桌面连接失败。

6. 无法确认TCP是否有问题、需借助网络诊断，见第六项。

iv. 路由

1. ISA提供服务时，查路由，看路由表中的记录，没有异常。

2. ISA服务失败时，路由表与先前ISA正常服务相同

3. 路由没有问题

二、ISA配置与参数设置

a) 检查ISA配置参数

i. 检查内存分配

1. 由于 ISA Server 要处理大量需要系统非分页内存的并发连接，因此，内存限制因素是非分页池的大小，而这是由总的内存大小决定的。对于 Microsoft Windows Server2003操作系统，非分页池大小的最大值和最小值如下表所示。

物理内存 (MB)	128	256	512	1,024	2,048	4,096
最小非分页池大小	4	8	16	32	64	128
最大非分页池大小	50	100	200	256	256	256

2. 检查此项、没有问题。排除故障事件21280错误警报是由于内存导致的，继续查看是否有其他原因导致21280错误。此刻也无法断定21280错误就是导致ISA服务失败的根本原因。

ii. 缓存

1. 通过ISA性能查看器，检查以下性能计数器

2. 监视内存使用率并相应地更改内存缓存大小。信息性性能计数器包括：

3. /ISA Server Cache/Memory Cache Allocated Space (KB)

4. /ISA Server Cache/Memory URL Retrieve Rate (URL/sec)

5. /ISA Server Cache/Memory Usage Ratio Percent (%)

6. /ISA Server Cache/URLs in Cache

7. /Memory/Pages/sec

8. /Memory/Pool Nonpaged Bytes

9. /Memory/Pool Paged Bytes

10. /Process(WSPSRV)/Working Set

11. /TCP/Established Connections

12. 以上计数器没有发现有骤然高低的情况、即使在ISA服务失败后、以上计数器也没有发现有异常情况。

13. 直接禁用缓存、故障依旧

14. 排除是缓存设置的问题造成ISA服务失败。

iii. HTTP压缩

1. ISA Server 2006 提供了“超文本传输协议”(HTTP) 压缩功能。在配置了 HTTP 压缩之后，ISA Server 可对内容进行压缩，以节省有限的带宽。这在某些情况下很有用，例如，主办公机构的代理将 Internet 请求直接路由到 Internet，分支办公机构通过带宽有限的网络将它们的请求由主办公机构发送出去。该功能使用为人熟知的压缩算法 (GZip) 来压缩 HTTP 数据，压缩比会根据目标数据类型而有所不同（默认情况下，只对基于文本的数据进行压缩）。

2. 当 ISA Server 的 Web 筛选器检查传入的压缩内容时，会对压缩内容进行解压缩。在解压缩时，会将内容作为解压缩后的文本存储在缓存中。如果 ISA Server 接受了对缓存内容的请求，它会在发送数据前重新将其压缩，这会增加响应时间。

3. 此项配置在进行禁用web筛选前后、观察都没有明显的响应时间的差别、排除此项配置问题。

iv. Web 筛选器

1. 与应用程序筛选器类似，Web 筛选器也会对性能造成影响，具体取决于筛选器所执行的操作。ISA Server 整合了几种执行特定任务的 Web 筛选器。在这些筛选器中，最消耗 CPU 的是 HTTP 筛选器和链路转换筛选器。

2. HTTP 筛选器检查每个 Web 请求和响应，来确定它们是否符合常规的 HTTP 协议用法。该筛选器默认情况下是启用的，其默认配置提供了对 HTTP 报头及 URL 的大小限制。其他可用的功能包括按方法、扩展名、报头和 HTTP 负载签名来执行拦截。这些功能在选中的情况下对于性能没有影响，但签名拦截除外，该功能需要 10% 以上的 CPU 周期。推荐使用 HTTP 筛选器来保护 Web 流量。

3. 链路转换专门用于 Web 发布方案。它查看 HTML 响应正文，搜索绝对超链接，将其改为指向 ISA Server 计算机。默认情况下，链路转换扫描 HTTP 报头和响应正文，因此对于性能会有明显的影响。在启用了正文扫描时，它默认只扫描 HTML 内容，从而导致 CPU 使用率总体上增加 15%。

4. 禁用Web筛选器、故障依旧。排除是此项配置造成的问题。

v. 使用 /3GB Boot.ini 开关

1. 对于内存超过 2 GB 的大型系统，Windows Server 2003提供了 4GT RAM 优化功能。此功能将进程内存空间划分为 3 GB 用于应用程序内存、1 GB 用于系统内存。此功能使得进程可以在用户空间中利用超过 2 GB 的 RAM，并通过在 Boot.ini 文件中添加开关 /3GB 将其启用（有关详细信息，请参阅 Microsoft 知识库中的文章 Q171793 －“有关应用程序使用 4GT RAM 优化信息”）。

2. 此功能可能对 ISA Server 有好处，尤其是对于承载大型网站的反向缓存。不过，使用此功能会减少未分页池的最大大小（减小到 128 MB 而不是 256 MB），因而会减少最大并发 TCP 连接数。

3. 修改了ISA01的Boot.ini的/3GB参数、故障依旧，排除此原因。

三、策略与规则

a) ISA服务假死后、禁用所有策略、重启ISA服务，故障依旧。

b) 对17条用户策略进行逐一排查，重点检查每个策略的正确性、策略间是否有矛盾、不合理性。经查确认用户策略编写无误。

c) 通过参考ISA诊断手册、知道ISA2006系统策略与有的用户策略间存在造成ISA拒绝服务的可能。因此即使可以判断用户策略没有问题，也无法断定系统策略和用户策略间是否没有异常，需要进一步求证系统策略的配置组选项启用是否正确。

四、后台MSDE

a) ISA Server 提供了两种主要的方法来对防火墙活动进行日志记录：

i. MSDE 日志记录。此方法是用于防火墙和 Web 活动的默认日志记录方法。ISA Server 将日志记录直接写入 MSDE 数据库，允许对所记录的数据进行联机高级查询。

ii. 文件日志记录。通过此方法，ISA Server 按顺序将日志记录写入文本文件。

iii. 比较两种方法可以看出，MSDE 具有更多功能，但它也使用更多系统资源。具体来说，如果从 MSDE 日志记录切换到文件日志记录，可以预测处理器使用率总体上会提高 10% 到 20%。

iv. MSDE 日志记录还会消耗更多的磁盘存储资源。对于每兆数据，MSDE 日志记录大约要访问磁盘两次。而文件日志记录，访问两次可以处理 10 MB 的数据。提高 ISA Server 性能的一种方法是从 MSDE 切换到文件日志记录。仅在由于处理器或磁盘访问满负荷而导致性能问题的情况下，才推荐使用此方法。

v. ISA Server 2006 Enterprise Edition 还提供了远程 SQL 日志记录功能，该功能可以将所有记录保存到一个集中管理的 SQL 数据库中。远程 SQL 日志记录所消耗的 CPU 资源介于 MSDE 和文件日志记录之间，它几乎不使用任何磁盘 I/O 操作。不过，远程 SQL 日志记录也会带来其他必须考虑的容量要求，因为所有的日志记录都要写入到中央远程数据库。

b) 对于MSDE来说，我建议定期压缩SQL的事务日志、还有webproxylog和firewalllog这2个table定期清理。在ISA01上编写运行以下SQL语句：

i. Webproxylog删除（只保留7天的存档）

1. 将webproxylog中需要保留的资料放在一个临时表webproxylog1中

select* into webproxylog1  from webproxylog where  cast(convert( char(10),logtime,120) as datetime)>=cast(convert(char(10),getdate()-7,120) as datetime);

2. 删除旧的webproxylog表

drop table webproxylog;

3. 将webproxylog1重命名为webproxylog

exec sp_rename webproxylog1,'webproxylog';

4. 创建webproxylog的索引

CREATE CLUSTERED INDEX [IX_WebProxyLog_DateTime] ON    [WebProxyLog]([logTime]) ON [PRIMARY];

ii. FirewallLog 清除

1. 执行SQL命令

Truncate table FirewallLog

iii. DB清除

1. 执行SQL命令BACKUP LOG ISALOG  with no_log

2. 执行SQL命令DBCC  SHRINKDATABASE (ISALOG)

c) 此步骤完成后、ISA警报中关于日志满等警报已经消除、但ISA服务失败故障依旧。

d) 使用ISA性能查看器添加关于MSDE的性能计数器进行监视，发现MSDE所用的内存只有128M，负荷很高，联系到报21280错误：非分页文件池过低的警报，是否是此原因造成的ISA MSDE可用内存不足呢？因此决定调整DB使用内存的大小，该原理与Oracle调整SGA大小相似。

i. 以下为我解决此问题的所编写的程序脚本、源代码如下：

ii. 首先、我们查看MSDE中的MSSQL$MSFW 和MSFW 名称作为MSDE的实例名instance name。

iii. 使用SQL编辑器或文本编辑器编写位于c:/的程序名为checkmemory.sql的文件

USE master 

EXEC sp_configure 'show advanced options', 1 

RECONFIGURE WITH OVERRIDE 

USE master 

EXEC sp_configure 'max server memory (MB)' 

USE master 

EXEC sp_configure 'show advanced options', 0 

RECONFIGURE WITH OVERRIDE 

iv. 然后、我们在ISA端执行命令行：

osql -E -S servername/MSFW -i c:/checksqlmemory.sql 

v. 我们调整max memory size, 同样类似的SQL脚本如下：调整为3060M、整个系统的RAM为4096M、由于操作系统3G开关限制、无法使用全部3072M也就是3G、因此此处调整的max memory size为3060M。

USE master 

EXEC sp_configure 'show advanced options', 1 

RECONFIGURE WITH OVERRIDE 

USE master 

EXEC sp_configure 'max server memory (MB)', 3060 

RECONFIGURE WITH OVERRIDE 

USE master 

EXEC sp_configure 'show advanced options', 0 

RECONFIGURE WITH OVERRIDE

vi. 然后、我们将以上程序命名为c:/setservermemory.sql

vii. 最后在ISA端运行以下命令行

osql -E -S servername/MSFW -i c:/setchecksqlmemory.sql 

viii. 重新启动ISA服务以及MSDE

ix. 回到性能监视器、负荷马上降下来了，但晚上7点ISA故障依然出现，排除ISA MSDE的原因导致的ISA服务问题

x. 晚上10点20故障再次发生，这次ISA没有报21280错误警报了，以上操作似乎只解决了21280错误，却没有解决ISA服务失败的根本问题，可以判断：ISA拒绝服务与警报21280错误无关。

五、入侵与攻击

a) 首先对照微软给出的最佳经验，见下表来参看ISA相关配置项是否正确

b) 经过数次的ISA服务失败的情景观察，有一个现象：每次服务失败过程中都伴随着有不同程度的攻击产生，ISA警报也有记录、且这些警报与ISA日志中对应的情况一致：

i. 我们使用命令行在服务失败前与服务失败后分别执行，发现有明显的SYN攻击

1. SYN攻击通过创建大量的半公开TCP连接从而使服务器瘫痪。在这种情况下，外部地址通常是一个伪地址，并且有以增量方式增加的端口号。因此，根据SYN攻击的这一显著特性，可以从下面的netstat输出信息里把它识别出来。

2. c:/>netstat -n -p TCP

ii. 发现有异常的状态为SYN-RECEIVD的SYN攻击，IP为假冒IP，经与管理员查，无此IP。

iii. 查微软技术支持中心的微软新闻组中的专家建议：我们最近发现，在一个具有固定网络适配器的计算机上安装ISA Server 2006，可能会出现在被SYN攻击淹没中的连接不稳定现象。 这个问题和在某些情况下TCP/IP栈允许网卡自己计算TCP校验和有关，这个特性通常被称为任务分派。 显然地，在SYN攻击保护模式中，ISA没有正确的进行任务分派，结果校验和崩溃，然后不能建立新的TCP连接。不过只要你禁止任务分派就可以解决这个问题。 解决办法，修改注册表：在 HKEY_LOCAL_MACHINE/SYSTEM/ CurrentControlSet/ Services/ Tcpip/Parameters 下，建立一个DWORD值，名为 DisableTaskOffload ，然后设置为1 。

iv. 接着对照了ISA2006SP1中对于缓解攻击的配置建议

1. 每个源 IP 允许的并发TCP连接数量在恶意主机保持与 ISA 或 ISA 后面的受害计算机的无数TCP连接时，缓解TCP泛洪攻击，缺省值100，例外400

2. 每个源 IP 每分钟创建的 HTTP 请求数量，在恶意主机向受害网站发送无数的 HTTP 请求时，缓解 HTTP DoS 攻击 。缺省值600，例外6000

3. 每个源 IP 允许的并发非 TCP 连接数，在恶意主机向 ISA 后面的受害计算机发送无数的 UDP 或 ICMP 消息时，缓解非TCP泛洪攻击，缺省值100，例外400

4. 每个规则每分钟的非 TCP 会话数量，在许多傀儡主机参与攻击或用无数非 TCP 数据包堵塞网络时，缓解非 TCP DDoS 缺省值1000 

5. 在每个 IP 每分钟被拒绝的数据包超过限制时触发事件，向 ISA 管理员发出有关恶意IP的警报通知，缺省值100 

v. 经过以上配置后、SYN攻击有所缓解、但是故障依旧。

c) 这里是一个比较奇怪的现象

i. 服务失败伴随着SYN攻击的产生

ii. 此攻击没有在交换机、路由器上留下痕迹、经查交换机信息没有记录

iii. IP欺骗形式、难以定位到攻击源

iv. 就SYN攻击而言无法杜绝、只能缓解

1. 找到攻击源、但是无法避免该攻击源是否会再次被感染或成为新的攻击源

2. 重新进行IP规划、对于XXXX客户这样一个成熟IP规划、因为ISA的问题而要推倒规划重来、得不偿失。

3. 在ISA前端部署一台硬件防火墙抵御并缓解SYN攻击、无论SYN攻击是否是造成ISA服务失败的根本原因，这对XXXX客户的整个网络安全还是有积极意义的。

v. 需要证明SYN攻击是否是ISA服务失败的关键。由此证明结果可以排除SYN攻击嫌疑。

六、局域网诊断

a) 使用网络监视器抓包，没有什么重要信息，抓SYN攻击的假冒IP的包进行数据分析、找不到什么重要的线索

b) 考虑需要使用更加专业强大的网络监视器与抓包工具及数据分析工具，如Sniffer Pro。此为商业软件、手头没有License、未果。

c) 使用微软提供的ISA辅助工具查验：

i. DNSToolsPack

ii. CacheDirPack

iii. Fwengmonpack

iv. AdamSitesPack

v. Windows Server 2003 Resource Kit Tools中的poolmon.exe和memtriage.exe

vi. 数据已经提取、数据分析进行中、目前除了可以发现有攻击数据、内存占用等情况、有类似P2P软件的会话数量较多的情况、没有发现重要线索。

七、警报与事件查看

a) 警报与日志、事件查看器等信息报错主要集中在

i. 21280错误。非分页文件池太小

ii. 检测到攻击

iii. 日志满

b) ISA服务异常可以判断由于某个未知的原因导致的错误使ISA服务失败、警报信息中提供的内容不是ISA服务失败的关键。由于9月9日22：20发生的错误重现、可以看到经过MSDE的内存调整后、当时错误警告没有产生21280错误。由此可以证明21280错误不是ISA服务异常的关键、至于是“主谋”还是“帮凶”目前没有思路证明。

八、下一步

a) 继续严密观察DNS，使用网络监控器与DNSToolsPack观察

b) 使用Sniffer Pro对往来数据进行抓包分析，最好选择在晚上上网用户最少的时候进行，否则白天并发用户数大的情况下，会造成数据也多、分析时间变长。

c) 继续观察SYN攻击源、根据晚上上网用户最少的情况下进行客户端逐个确认攻击源在哪里，断网该攻击源后继续观察SYN情况是否已经解决，看ISA服务是否仍然失败，如果仍然失败，可以说明ISA故障与SYN攻击无关。

d) 抽一个不用网络的时间、建议中秋节把ISA01操作系统格式化重装、不用Ghost或TPM类似的快速系统恢复，重装ISA、导入原有策略。再看是否问题依旧。

e) 需要说明的是：由于没有定位到问题的关键原因，所以贸然做ISA群集没有意义！因为cluster是发现ISA01的ISA服务失败才可以切换到ISA02，由于ISA服务失败的表现形式是

i. ISA服务仍然在运行、ISA01可以正常访问内网、外网

ii. ISA服务没有失败，因此群集无法判断ISA需要故障切换，因此即便部署群集、ISA也不会切换服务到ISA02

iii. DNS及网络连接ping ISA01失败、这样相信ISA02与ISA01的网络也不能双向通过，因此只会造成ISA01可以访问ISA02,在没有人工重启ISA01之前，ISA02依然不能访问ISA01，所以，群集方案不适用！

原文链接： http://blog.csdn.net/jaminwm/article/details/2919783