<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

依据本人日前提交的《ISA服务异常诊断思路与步骤》中描述的诊断思路，今天连同客户方工程师对ISA故障进行了再次调试。时间为10点至18点。

今天计划如下调试工作：

1. 继续进行数据包分析、采用更加专业的网络分析工具及数据包分析软件、检测在ISA通信过程中是否存在异常信源、特殊结构数据包、攻击携带的淹没数据报、重点对PSP软件采用的协议与信令进行元数据分析，考量以上内容中可能出现的对ISA服务失败的诱因。

2. 再次对之前诊断过程中存在疑虑的问题进行剖析、对Cache、DNS、防火墙系统策略与用户策略的一致性问题、ISA内核dump参数进行确认。

3. 确认SYN攻击是否是造成ISA服务失败的主要原因。

4. 以上步骤如不凑效、重新安装Windows、重新部署ISA并导入原有配置及策略。

实际调试进展

1. 今天上网用户为5用户、会话数为175个、经过对数据包抓包、分析

采用wireshark1.0.1软件进行数据包分析、在进行数据包分析过程中、系统再次失败，数据包分析中发现ISA通讯中存在大量的WinSocket请求、其中这些请求中AFD数据块大量重复产生、查看每个会话中数据报文内容、我们可以分析到存在以下问题：

l WinSocket请求较多、虽然Socket链接本身是正常的，但是问题出在，许多Socket连接在会话结束后，该连接占用的系统资源没有被正常释放掉、由于Socket连接会消耗操作系统的核心转储资源，如非分页文件池、windows核心态系统缓存、windows用户态系统缓存、上位内存区域等重要资源，因此此请求需要进一步分析连接请求的释放存在哪些异常。

l TCP半连接数非常多、这些半连接数在整个网络当中有相当一部分是由05016用户发出的，经过查看ISA日志、由迅雷进程引起。通过分析迅雷的原理、迅雷软件本身具备P2P性质、而且每个迅雷的版本采用的P2P方式都有不同、有的采用随机端口、有的采用高位端口、有的走UDP协议、有的走HTTP的80端口、因此对于迅雷不宜采用ISA策略的限制方式，而应该考虑限制迅雷进程的带宽与流量。

l 分析部分数据包、数据包内容中有异常数据，在一个数据会话中，我们可以看到

0000140000001D4669FF866BD7E17338.......Fi..k..s8
7E086870F25CA3CB7F56140000005000~.hp./...V....P.
00001000000030304530344342363332......00E04CB632
3030352E6578650F0000003232312E32005.exe....221.2
33392E3137302E31313600050C00000F39.170.116......
0000003232312E3233392E3137302E31...221.239.170.1
3136520000001000000030303044383716R.......000D87
354434454638303030300F000000473A5D4EF80000....G:
003232312E3233332E3231382E313738.221.233.218.178
00050C00000F0000003232312E323333.........221.233
2E3231382E3137385500000010000000.218.178U.......
3030443046383341373932463030303000D0F83A792F0000
73662E6578650F0000003231392E3132sf.exe....219.12
382E3230352E31333800050C00000F008.205.138.......
00003231392E3132382E3230352E3133..219.128.205.13
384E00000010000000303030433736308N.......000C760

存在多个数据转发源、进一步分析还是迅雷的问题，看来要防止如何将这种不断增长的源控制在一个正常的非分页文件池大小内才是关键。

2. 非分页文件池问题

非分页文件池是操作系统中内存管理的非常重要的一部分。其管理机制如下：

Windows2000/XP内存管理器位于Ntoskrnl.exe文件中，硬件抽象层中没有内存管理器的任何部分。

内存管理器是完全可重入的，支持多进程并发执行。

内存管理器组成部分：

1） 一组执行体系统服务程序：用于虚拟内存的分配、回收和管理。

2） 一个转换无效和访问错误陷阱处理程序：用于解决硬件检测到的内存管理异常，并代表进程将虚拟页面装入内存。

3） 运行在六个不同的核心态系统线程上下文中的几个关键组件：

——工作集管理器：优先级16，每秒钟被平衡集管理器（一个内核创建的系统线程）调用一次。

——进程/堆栈交换程序：优先级23，完成进程和内核线程堆栈的换入和换出操作。

——已修改页面写入器：优先级17，将修改链表上的脏页写回到适当的页文件。

——映射页面写入器：优先级17，将映射文件中脏页写回磁盘。

——废弃段线程：优先级18，负责系统高速缓存和页面文件的扩大和缩小。

——零页线程：优先级0，将空闲链表中的页面清零。

地址空间的布局：

Win32环境下，32位的地址空间转化为4GB的虚拟内存。默认情况下，将一半（2GB）分配给用户进程，另一半（2GB）分配给操作系统。

Windows2000/XPAdvancedServer版本和Windows2000/XPDataCenter版本支持一个引导选项（Boot.ini中通过/3GB标识激活），允许用户拥有3GB地址空间，留1GB给操作系统。

对于要访问整个3GB地址空间的进程，进程映像文件必须在映像头设置IMAGE-FILE-LARGE-ADDRESS-AWARE标识，否则系统将保留第3个GB的地址空间。可以通过指定链接标识/LARGEADDRESSAWARE来设置该标识。如果与此链接程序开关相链接，则可以使用3GB用户方式地址空间。

2GBWindows2000/XP用户地址空间分布

——NULL指针分配的分区：0x0～0xFFFF

——进程私有地址空间：0x10000～0x7FFEFFFF

——64KB拒绝访问区域：0x7FFF0000～0x7FFFFFFF，阻止线程跨过用户/系统边界传送缓冲区。

Windows2000/XP用户地址空间系统变量

——MmHighestUserAddress：描述最高用户地址（对于x862GB用户空间为0x7FFEFFFF）

——MmUserProbeAddress：描述最高用户地址＋1

性能计数器：Windows2000/XP中可利用性能计数器得到系统虚拟内存的使用信息，和单个进程地址空间的使用情况。

x86系统地址空间分布

——0x80000000~0x9FFFFFFF：引导系统（Ntoskrnl.exe和Hal.dll）和非分页缓冲池初始部分的系统代码。

——0xA0000000~0xA3FFFFFF：系统映射视图（如Win32k.sys）或者会话空间。

——0xA4000000~0xBFFFFFFF：附加系统页表项（PTE）或附加系统高速缓存。

——0xC0000000~0xC03FFFFF：进程页表和页目录，描述虚拟地址映射的结构。

——0xC0400000~0xC07FFFFF：超空间和进程工作集列表。

——0xC0800000~0xC0BFFFFF：未使用区域，不可访问。

——0xC0C00000~0xC0FFFFFF：系统工作集链表，描述系统工作集的工作集链表数据结构。

——0xC1000000~0xE0FFFFFF：系统高速缓存，用来映射在系统高速缓存中打开的文件的虚拟空间。

——0xE1000000~0xEAFFFFFF：分页缓冲池，可分页系统内存堆。

——0xEB000000~0xFFBDFFFF：系统页表项和非分页缓冲池。

——0xFFBE0000~0xFFFFFFFF：系统性故障转储信息和硬件抽象层（HAL）使用区域。

会话空间：用来映射一个用户的会话信息。

——进程创建时，会将会话空间映射到属于该进程会话的页面。

——会话是由进程和其他系统对象组成，每个会话有私有的GUI数据结构，以及Win32子系统进程（Csrss.exe）和登录进程（Winlogon.exe）的拷贝。

——会话管理器进程（Smss.exe）负责创建新的会话。

地址转换机制

用户应用程序以32位虚拟地址方式编址，每个虚拟地址与一个称作“页表项”（PTE）的结构有关，它包含了虚拟地址映射的物理地址。

1． 虚拟地址变换

x86系统利用二级页表结构实现虚拟地址向物理地址的变换。

x86系统中，32位虚拟地址分成三个部分：页目录索引（10bit）、页表索引（10bit）、字节索引（12bit）。

虚拟地址变换的基本步骤：

——内存管理的硬件设备定位当前进程的页目录；

——页目录索引指出页目录项在页目录中的位置，页目录项中的页框号描述了映射虚拟地址所需页表的位置；

——页表索引指出页表项在页表中的位置，页表项描述了虚拟页面在物理内存的位置；

——当页表项指向的页面有效时，字节索引指明物理页内所需数据的地址；若所指页面无效，则交由内存管理器的故障处理程序处理。

2． 页目录

每个进程都有一个单独的页目录，用来映射进程所有页表的位置，其物理地址被保存在核心进程（KPROCESS）块中。

进程切换时，操作系统设置一个专用的CPU寄存器来通知硬件设备新进程页目录所在地址。

页目录是由页目录项（PDE）组成，每个页目录项4字节。x86中，描述4GB虚拟地址空间需要1024张页表，因此页目录索引10位。

3． 进程页表与系统页表

进程页表是每个进程私有的，而系统页表被所有进程共享。

当进程创建时，系统空间的页目录项初始化为指向现存的系统页表，但各个进程的系统空间不完全相同。当系统页表更新时，内存管理器不会立刻更新所有进程页目录，而是当进程访问新的虚拟地址时才更新进程页目录。

性能监视器中的空闲系统页表项计数器表示了可用系统页表项的数目，也可在HKLM/SYSTEM/CurrentControlSet/Control/SessionManager/MemoryManagement/SystemPages中设置需要的页表项数量。

4． 页表项

有效的页表项有两个主要的域：

（1）包含数据的物理页面的页框号，或内存中某页面的物理地址的页框号；

（2）一些描述页的状态和保护限制的标志位。

——访问位：某页首次被读写时，置为“1”

——修改位：某页首次被写时，置为“1”

——写位：为0时，对应页只读，为1时，对应页可读写

——多处理器的x86系统中，有个附加的由软件实现的写位，用来表示某页已经被一个运行在多个处理器上的线程写入。

x86中（非PAE系统），映射4GB地址空间需要1024张页表，每个页表含1024个页表项，每个页表项4字节，因此页表索引为10bit。

5． 快表TLB

x86提供了关联存储器数组形式的高速缓存，称为快表。它是一个向量，其存储单元能被同时读取并与目标值比较。

快表中每个项的标志符部分保存了虚拟地址的一部分，数据部分保存了物理页号及对应页的保护类型和状态。

将常用的虚拟地址记录在快表项中，减少了对内存的访问，加快了虚拟地址到物理地址的变换。

如果一个虚拟地址不在快表中，它可能仍在内存中，需要对内存多次访问来找到它。当一个页表项由无效变为有效时，内存管理器会调用内核例程将新页表项装入快表，x86中，装入快表不需要软件干预。

用户空间内存分配方式

首先介绍两个与内存分配相关的数据结构（虚拟地址描述符和区域对象），然后介绍三种管理应用程序内存的方法。

1． 虚拟地址描述符

虚拟地址描述符（VAD）用来描述哪些虚拟地址已经在进程地址空间中被保留。对个进程，内存管理器都维持一棵虚拟地址描述信息树，用来描述进程地址空间状态。

当进程保留地址空间，或映射一个内存区域时，就创建一个VAD来保存分配请求所提供的信息。当线程首次访问一个地址时，需找到一个包含被访问地址的VAD，利用所得信息填充页表项。

2． 区域对象

区域对象在Win32中也称文件映射对象，表示可以被两个或多个进程共享的内存块，也可被映射到页文件或外存文件。

主要作用

——将可执行映像装入内存

——访问高速缓存文件中的数据

——将文件映射到进程地址空间，不必进行文件I/O

每个打开文件都有一个单独的区域对象指针结构，由三个32位指针组成：指向数据控制区域的指针、指向共享的高速缓存映射的指针、指向映像控制区域的指针。

CreatFileMapping函数可以创建区域对象；OpenFileMapping打开有名字的区域；可通过句柄继承或句柄复制访问区域对象；设备驱动程序可使用ZwOpenSection，ZwMapViewOfSection，ZwUnmapOfSection函数操纵区域对象。

3． 以页为单位的虚拟内存分配方式

适合于大型对象或结构数组

进程地址空间的页面有三种状态：空闲、被保留、被提交；保留和提交功能是通过Win32VirtualAlloc和VirtualAllocEx函数实现的。

应用程序可以同时进行保留和提交，也可以先保留地址空间，当需要时再向地址空间提交物理页面，这样可以减少内存的使用。

VirtualFree或VirtualFreeEx函数用来回收页面或释放地址空间。回收的内存仍然被保留，而释放的内存是空闲的。

4． 内存映射文件

适合于大型数据流文件以及多个进程之间的数据共享

内存映射文件用来保留一个地址区域，并将磁盘文件提交给该区域，用于3个目的

——加载和执行.exe和.dll文件，可节省应用程序启动所需时间

——访问磁盘数据文件，减少文件I/O

——实现多个进程间的数据共享

利用区域对象实现这些功能，因为区域对象可以链接到打开的磁盘文件（映射文件），或已提交的内存（提供共享内存）。

进程要访问非常大的区域对象，可以通过调用MapViewOfFile函数映射区域对象的一部分（区域视图），并指定映射范围。

5． 堆功能

内存堆的应用程序内存管理方法适合于大量的小型内存申请

堆是保留的地址空间中一个或多个页组成的区域，可由堆管理器进一步划分和分配

堆管理器用来分配和回收可变内存，其函数位于Ntdll.dll和Ntoskrnl.exe中。

进程启动时有一个缺省堆，通常为1MB，它在进程生命周期中不能被释放；而HeapCreat函数创建的私有堆可以用HeapDestroy来释放。

从缺省堆中分配内存时，先调用GetProcessHeap函数得到句柄，再调用HeapAlloc和HeapFree来分配和回收内存块。

系统内存分配

系统初始化时，创建了两种动态大小的内存缓冲池来分配系统内存，ExAllocatePool函数可从缓冲池中分配和回收内存：

——非分页缓冲池：由长驻物理内存的系统虚拟地址区域组成。

——分页缓冲池：系统空间中可以被分页和换出的虚拟内存区域。

两种非分页缓冲池：一般情况下使用；4页缓冲池在非分页缓冲池已漫且不允许分配失败时使用。

分页缓冲池：单处理器系统3个，多处理器系统5个

分页/非分页缓冲池初始大小依赖于系统物理内存大小，可设置HKLM/SYSTEM/CurrentControlSet/Control/SessionManager/MemoryManagement的NonpagedPoolSize和PagedPoolSize值改变缓冲池大小。

快速内存分配机制——后备链表：仅包含固定长度的块，因此不必查找适合分配大小的空闲内存。

若后备链表为空时，必须从分页或非分页缓冲池中进行分配。可使用ExInitializeNpagedLookasideList和ExInitializePagedLookasideList函数按照频繁分配的数据结构大小创建后备链表。

缺页处理

对无效页面的一次访问称为缺页错误，由内存管理故障处理程序解决。

1． 四个基本类型的无效页表项

页文件：所需页没有驻留在内存，而是驻留在页文件中，并引发页面调入操作。

请求零页：所需页是零页面，此时会给进程工作集添加一个由零初始化的页。

转换：所需页面在内存中的后备链表、修改链表或修改尚未写入链表。此时从链表中删除此页，并添加到工作集。

未知：页表项为0，或页表不存在。此时需检查VAD以确定虚拟地址是否被提交。

2． 一个特例——原型页表项

区域对象第一次被创建时，同时创建原型页表项，它用于实现页面共享。

当共享页面为有效时，进程页表项和原型页表项都指向包含数据的物理页。

当共享页面无效时，进程页表项指向原型页表项，而原型页表项描述被访问的页面的状态（活动/有效、转换、修改尚未写入、请求零页、页文件、映射文件6种）

3． 页面调入I/O

当必须向文件（页或映射文件）发出读操作来解决缺页问题时，将产生页面调入I/O。

页面调入I/O操作是同步的，线程会一直等待I/O完成。

当进行调页I/O时，进程中的其他线程仍可以同时处理缺页错误，因此在I/O结束时页面调度程序必须识别如下情况：冲突页错误、页面从虚拟地址空间中被删除、页面保护限制发生变化、原型页表项引发错误。

4． 冲突页错误

同一进程中的另一线程或另一进程也对正在被调入的页面产生缺页错误，称为冲突页错误。

页面调度程序检测到冲突页错误时，会对页框号数据库项中的特定事件发出等待操作。当I/O完成后，第一个获得页框号数据库锁的线程负责执行完成页面调入操作。

5． 页文件

虚拟存储器在磁盘上的部分称为页文件。内存＝物理内存＋页文件。

性能计数器可以检查被提交的进程私有内存使用情况，但无法确切知道一个进程提交的私有内存中有多少常驻内存，多少在页文件中。

Windows2000/XP最多支持16个页文件。

系统启动时，会话管理器进程读取页文件链表，并检查HKLM/SYSTEM/CurrentControlSet/Control/SessionManager/MemoryManagement/PagingFiles打开页文件，如果没有，则创建一个缺省的20MB页文件。系统运行期间不能删除打开的页文件。

系统进程为每个页文件都维持一个打开的句柄，Ntdll.dll中的NtCreatePagingfile系统服务程序可增加一个新页文件。

工作集

工作集即在物理内存中保持的虚拟页面的子集，分进程工作集和系统工作集。

1． 页面调度策略

取页策略：内存管理器利用请求式页面调度算法及簇方式将页面装入内存。当缺页中断时，将出错页面和它附近的一些页面装入内存，这样可减少读取外存的次数。

置页策略：当线程收到页错误时，内存管理器要使用“置页策略”来确定在物理内存中放置虚拟页面的最佳位置。

如果当页错误发生时物理内存已满，“置页策略”要决定哪一个虚拟页面必须从内存中删去来为新的页面腾出空间。多处理器系统中，采用局部先进先出（FIFO）策略，而单处理器系统中，采用最近最久未使用（LRU）替换策略。

2． 工作集管理

系统初始时，所有进程缺省的工作集最大最小值相同。有“增大调度优先级”权限的进程可用SetProcessWorkingSet函数来更改缺省值，但不能超过内核变量MmMaximumWorkingSetSize中的最大值。

当物理内存变得很低时，工作集管理器自动修剪工作集，以增加可用空闲内存数量。

有一系列内核控制变量描述工作集扩展和修剪，但这些值是确定的，不能被注册值调整。

3． 平衡集管理器和交换程序

系统初始化时创建平衡集管理器，用来对工作集进行调整。工作集管理器也是运行在平衡集管理器线程环境下的一个例程。

平衡集管理器等待两个事件对象

——1秒周期计时器到期后产生事件，并经历以下4步

平衡集管理器每被唤醒4次就唤醒交换程序；检查后备链表，必要时调整其深度；寻找处于CPU饥饿状态而需提高其优先级的线程；调用工作集管理器。

——内部工作集管理器事件，即工作集需要调整时

交换程序：即KeSwapProcessOrStack例程，用来寻找一段时间内一直处于等待状态的线程，将其内核堆栈转移以收回物理内存。

4． 系统工作集

系统工作集用来管理操作系统中可分页的代码和数据，其中可驻留5种页面：系统高速缓存页面；分页缓冲池；Ntoskrnl.exe中可分页的代码和数据；设备驱动程序中可分页的代码和数据；系统映射视图。

系统工作集最大最小值是在系统初始化时计算的，基于物理内存数量和系统是professional或server。

物理内存管理

页框号数据库用来描述物理内存中各页面的状态，有效页表项指向页框号数据库中的项，页框号数据库项又指回此页表。原型页框号指回原型页表项。

页面可处于活动、过渡、后备、修改、修改不写入、空闲、零初始化和损坏不可用8种状态，除活动和过渡之外，其余6种组成了链表。

1． 动态页链表

当需要一个零初始化的页面时，首先访问零页链表，若为空，则从空闲链表中选取一页并零初始化，若也为空，则从后备链表中选取一页并零初始化。

——零页链表是由零页线程（优先级为0）从空闲链表中移过来的，当空闲链表中有8个或8个以上页时激活零页线程。

当不需要零初始化页面时，首先访问空闲链表，若为空，则访问后备链表。

当进程放弃一个页面时，如果页面未修改过，则加入后备链表；如果修改过，则加入修改链表。

进程撤销时，将所有私有页面加入空闲链表。对页文件支持的区域最后一次访问结束时，页面加入空闲链表。

当修改页链表太大，或零初始化和后备链表的大小低于最小值时，唤醒“修改页面写回器”线程，将页面写回外存，并将页面移入后备链表。

2． 修改页面写回器

由两个系统线程组成，优先级都为17

——MiModifiedPageWriter：将修改页写回页文件

——MiMappedPageWriter：将修改页写入映射文件

触发修改页面写回器的事件

——修改页面数量大于内核变量MmModifiedPageMaximum指定值

——可利用页数量小于内核变量MmMinimumFreePages指定值

——MiMappedPagesTooOldEvent事件：该事件在预定的数秒后（缺省为300秒，可用注册值修改）产生，将映射页面写入外存

若页面写入外存时正在被另一线程共享，则I/O完成后不会将此页移入后备链表。

3． 页框号数据结构

页框号数据库项是定长的，不同页框号类型，包含的域也不同（参见图4－28）

几个基本的域

——页表项地址：指向此页页表项的虚拟地址

——访问计数：对此页的访问数量

——类型：该页框号表示的页面状态（8种）

——标识：包含修改状态、原型页表项、奇偶校验错误、正在读取或写入等信息。

——初始页表项的内容

——页表项的页框号：指向该页面页表项的页表页的物理页号

其他内存相关机制

1． 锁内存

可以通过两种方式将页面锁在内存中

——设备驱动程序调用核心态函数MmProbeAndLockPages，MmLockPagableCodeSection,mLockPagableDataSection,LockPagableSectionByHandle。解锁之前锁定的页面一直在内存中。

——Win32应用程序调用VirtualLock函数锁住工作集中页面，但不能防止调页。

2． 分配粒度

系统按照分配粒度定义的整型边界对齐每个保留的进程地址空间区域，系统分配粒度值可通过GetSystemInfo函数找到，目前为64KB。

保留地址空间时，保证区域大小是系统页大小倍数。

3． 内存保护机制

4种基本方式

——所有系统范围内核心态组件使用的数据结构和缓冲池只能在核心态下访问，用户线程不能访问。

——每个进程有独立私有的地址空间，其他进程的线程不能访问。（与其他进程共享页面或另一进程具有对进程对象的虚拟内存读写权限时除外）

——除虚拟到物理地址转换的隐含保护外，还提供一些硬件内存保护措施。

——利用共享内存区域对象的存取控制表（ACL）将对共享内存的访问限制在适当权限的进程中。

4． 写时复制

当进程映射区域对象的写时复制视图时，内存管理器直到页面修改时才进行复制，而不是在映射视图的同时，这样可以节约物理内存。

5． 地址窗口扩充

地址窗口扩充（AWE）函数集可使进程能够访问更多的物理内存，步骤如下：

——分配要使用的物理内存：AllocateUserPhysicalPages函数（需锁内存页面的权限）

——创建一个虚拟地址空间作为窗口用来映射分配好的物理内存：VirtualAlloc函数和MEM_PHYSICAL标识

——将内存映射到窗口：MapUserPhysicalPages或MapUserPhysicalPagesScatter函数

AWE函数分配和映射内存的限制

——页面不能在进程间共享

——同一物理页面不能映射到同一进程的多个虚拟地址上

——页保护可读/写

6． 物理地址扩展

物理地址扩展（PAE）的内存映射模式允许访问64GB物理内存。

物理地址扩展模式下，虚拟地址划分为4个域：页目录指针索引（2bit）、页目录索引（9bit）、页表索引（9bit）、页内字节偏移（12bit）。

物理地址扩展模式之所以能对更大范围的内存编址，是因为页目录项和页表项都由32位扩展到了64位。

我们了解了原理后，通过修改windows的内存管理配置可以有效调节非分页文件池的问题。修改方法由于不同的操作系统版本、应用系统、硬件配置（CPU、内存）等不一致、因此此问题不具备操作方法的可复制性，需单独对待。了解原理最重要。建议参考微软windows开发实验室的核心团队出版的书籍：《深入解析windows操作系统》。

截至到2008年9月22日，经过调试后的ISA01已经稳定运行了一个星期，没有出过服务失败问题，至此、ISA问题已经解决。

经验与总结：

总结

由于ISA系统封装了windows的TCP/IP协议栈、因此，ISA故障会由多个方面引起、网络、操作系统、策略、配置、参数、ISA后台数据库。所以在进行ISA诊断的时候需要2个必备条件、而这2个必备条件不具备导致了先前许多公司与技术工程师束手无策。

n 经历ISA服务失败的前后、保留现场进行线索收集

n 具备对网络、交换机、windows操作系统、IT基础服务（DNS、AD、路由）、ISA策略、SQLServer数据库、网络安全与攻击防御、编程水平（WindowsSDK、DDK、T-SQL、C++）的全面掌握。

u 熟悉网络、交换机、路由器；这里对应到网络性能诊断、需要熟悉网络协议、网络服务工具、设备调试。对网络造成的ISA故障进行排除。

u 熟悉windows操作系统原理；重点掌握windows内存管理、对winsocket封装熟悉、否则无法发现此ISA系统的罪魁非分页文件池错误进行鉴别，更加无法修正了。

u 熟悉IT基础服务（DNS、AD、router)；这里对应到对DNS服务、AD服务正常运行，排除由此带来的ISA问题的嫌疑。

u ISA策略与配置；解决ISA问题、当然要熟悉ISA，ISA原理本身就是网络安全范畴、ISA方面的技能就是安装、配置、策略了，因此这是必备技能。

u SQLServer数据库；由于ISA内置的SQLSERVER数据库的精简版MSDE，MSDE本身也有内存、系统缓存等问题需要进行检查与排除、所以务必要可以掌握OSQL的命令行使用。

u 网络安全与攻击防御；诊断中发现有SYN攻击、如何去减少、一定要对网络安全基础知识有了解、否则也就无法去了解怎么配置改善SYN攻击。

u 编程水平：

l WindowsSDK：许多命令行工具都存在于WindowsResourceKitTools、WindowsSupportTools、SDK中、而且在上述SYN攻击代码中使用了VC++编程的代码大量调用了SDK中提供的API

l WindowsDDK：查看非分页文件池大小务必使用DebuggingToolsforWindows(x86)、WinDbg，DDK本身是windows的内核驱动编程工具，因此要熟悉DDK命令、C++语言

l T-SQL：MSDE作为ISA后台数据库使用、在我上次提交的21280错误的排错方法中，使用SQL语言调整MSDE的性能中使用到。

l C++；SDK/DDK中使用的API都以C++方式提供、而且在我的参考文献《深入解析windows操作系统》中描述的内存管理原理也是用C++语言来描述的，因为原理复杂、所以采用程序原语表述更加容易理解。

系统的诊断是多维度的，不能ISA出了状况就只关注ISA，IT系统是一个有机的系统整体、需要多维度的检查、这样的思路与结论才是准确的。

需要依靠多种诊断工具和软件、但是不能完全依赖软件报出的结果。尽量采用微软原厂的工具来诊断。

原理的分析是最关键的，了解了原理才知道使用什么工具、寻找什么文献帮助、寻求哪方面的技术支持。

建议

v 建立完善的ISA监控预警机制、逐步把服务质量与ISA性能管理结合在一起。

v 使用迅雷、电驴等P2P用户的情况严重、这些软件无法使用策略等手段来禁止、所以需要进行技术手段与管理手段结合的方式来进行：技术手段建议可以在ISA前端部署一套网络流量/上网行为管理系统、配合终端的桌面管理系统，有效进行IT基础环境的专责管理。管理手段建议可以和流程、人员、稽考结合在ITIL整体来体现、这样一切结果都是流程化、统一化、避免了主观评判与管理因素。

v 购买正版ISA、获取微软原厂服务支持。虽然技术支持可以寻求武汉本地公司和个人来解决、但是知识库没有在客户方得到沉淀和积累、这样对于每个类似此次问题无法从项目中得到知识库建设的增长、自身IT人员技术水平也难以得到提升、更谈不上有效的绩效水平管理。

v ITIL管理不是口头的，需要有每个子系统都与之接洽的大局观与思路、从流程、人员、知识库、服务监督、服务响应、考核等方面来建设。我可以安排客户参观ITIL与运维做的比较好的成功案例客户供借鉴参考，如神龙、武钢、华中电网、东风有限等。