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

《ISA服务异常诊断思路与步骤》 依据本人日前提交的《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 分析部分数据包、数据包内容中有异常数据，在一个数据会话中，我们可以看到 00 00 14 00 00 00 1D 46 69 FF 86 6B D7 E1 73 38 Fi..k..s8 7E 08 68 70 F2 5C A3 CB 7F 56 14 00 00 00 50 00 ~.hp.\...VP. 00 00 10 00 00 00 30 30 45 30 34 43 42 36 33 32 00E04CB632 30 30 35 2E 65 78 65 0F 00 00 00 32 32 31 2E 32 005.exe221.2 33 39 2E 31 37 30 2E 31 31 36 00 05 0C 00 00 0F 39.170.116 00 00 00 32 32 31 2E 32 33 39 2E 31 37 30 2E 31 ... 31 36 52 00 00 00 10 00 00 00 30 30 30 44 38 37 16R000D87 35 44 34 45 46 38 30 30 30 30 0F 00 00 00 47 3A 5D4EF80000G: 00 32 32 31 2E 32 33 33 2E 32 31 38 2E 31 37 38 .78 00 05 0C 00 00 0F 00 00 00 32 32 31 2E 32 33 33 221.233 2E 32 31 38 2E 31 37 38 55 00 00 00 10 00 00 00 .218.178U 30 30 44 30 46 38 33 41 37 39 32 46 30 30 30 30 00D0F83A792F0000 73 66 2E 65 78 65 0F 00 00 00 32 31 39 2E 31 32 sf.exe219.12 38 2E 32 30 35 2E 31 33 38 00 05 0C 00 00 0F 00 8.205.138 00 00 32 31 39 2E 31 32 38 2E 32 30 35 2E 31 33 ..3 38 4E 00 00 00 10 00 00 00 30 30 30 43 37 36 30 8N000C760 存在多个数据转发源、进一步分析还是迅雷的问题，看来要防止如何将这种不断增长的源控制在一个正常的非分页文件池大小内才是关键。 2. 非分页文件池问题 非分页文件池是操作系统中内存管理的非常重要的一部分。其管理机制如下： Win