[故事之二十七]PC机网卡故障，攻击服务器，速度下降

E网十族

[症状]今天是五一节假期的最后一天，某大型铁路枢纽站来电，报告其售票系统出现很大问题，最先是枢纽所在局本地的售票系统报告售票速度比平时慢几倍，车站售票厅前已经排起了长队，乘客意见很大。其它市内预售处也受到影响，出票速度也很慢。随后，是各联网局均有报告网络的票务查询速度慢，邻近局报告更频繁一些。维护人员认为是中心票务服务器有问题，随即决定系统暂停业务并将备份服务器很快启动投入系统运行，非但未能见效，反而速度更加缓慢。急招该系统的工程集成商立刻处理系统问题，观察中心票务服务器CPU资源利用率达到了97％，基本上是满负荷运行，其它服务器和工作站等网上设备均为发现问题。短时间断开预售点和其它路局的连接路由，故障现象依旧。系统集成商随即将票务中心机房内的其它网络设备如交换机、集线器、网关等全部更换，启动系统故障依旧。故障累计已经近7小时，路局承受的压力越来越大，已经开始准备紧急启动本地人工售票预案。
[诊断过程]网络医院接报后立即赶往票务中心计算机网络的机房，网管人员告知在节日期间已经出现过类似的现象，只是持续的时间不很长(有时会持续2小时左右)，速度虽有变慢，但基本上不影响出票速度。经过与网关人员和系统集成商的工程技术人员简单交流后，分析故障原因可能有五，一是票务结算软件问题；二是病毒或内部人员尤其是网络管理人员误操作或更改设置，比如删除不应该删除的文件，私自在系统上运行了冲突软件或破坏性软件；三是系统平台故障，比如NT平台受到干扰后出现硬损伤(指不能恢复的改变，必须重新安装系统才能正常运行)；四是网络设备问题，五是其它网络问题。由于已经更换过票务服务器和交换机等网络设备，所以先暂不考虑第一、四种可能性；为了节省故障诊断时间，暂不考虑第二、三种可能性(如对系统进行一次详细检查和协议测试或重新安装一次NT平台并做好相应的设置、数据恢复等需要较长时间)，而首先就第五种可能性对网络进行测试。查看其它服务器CPU资源利用率，都在25％以下。
查看网络拓扑结构图，将网络测试仪F683随即接入网络中的一台工作组交换机，观察整个网络的工作情况。先查看网络设备的工作情况，显示交换机、路由器等本身均正常。核心交换机与票务服务器的连接端口为第二插槽第7端口，设置为100Mbps，流量实测为84％，偏高。查看整个网段的MAC对话矩阵，也显示票务服务器的访问流量很高，进一步查看IP对话矩阵，与MAC矩阵基本一致，比其它对话矩阵中的成员高出500倍以上。追查访问的数据来源，发现一台内部账务处理PC机与票务服务器之间的对话流量很高。从MAC矩阵上观察其流量很高，从IP矩阵上观察流量稍低于MAC流量。为了提高处理速度，票务服务器按设计是直接与核心交换机相连的，而账务处理用的PC机通过桌面交换机—工作组交换机—核心交换机后与票务服务器相连。询问票务处理PC机的操作人员，答曰节前该机工作就不正常，速度慢。曾向网络维护人员报告过故障，但因邻近节日，维护工作量大，维护人员计划待节日以后再处理账务PC机的问题。
将账务PC关机，系统故障立即消失，整个系统恢复正常，一片欢呼。为了确认该PC机具体的故障位置，将其移动到局办公网上接入网络，重新设置后工作正常！！！
为了慎重起见，网管人员还是决定启用一台新机器代替账务PC接入网络，同时观察网络的工作状态。发现网络完全恢复正常，故障排除。
用网络测试仪测试办公网，流量为2％，很低，无错误数据包。将集线器串入账务PC与交换机的连接通道，用网络测试仪和协议分析仪接入观察。从F683网络测试仪上观察，显示网络流量为79％！！错误37％(其中90％为长帧，其余为短帧)，网络测试仪指示流量来源于账务PC，数据包中有约36％左右指向了一个未知的IP地址，其它数据包虽然指向该地址但来源地址比较混乱且无规律可循，协议分析仪上解析的地址经网管人员确认后证实36％的指向地址是票务服务器的IP地址，其它来源地址也是原票务网中地址范围内的地址。如果该PC机携带能模仿IP地址的病毒程序，则原系统有可能还会发生类似故障，所以我们先将账务工作站PC的网卡更换，更换后该机表现正常(说明病毒在捣乱的可能性很小)，不再发送非法帧。将故障网卡重新安装驱动程序，故障现象依旧，集线器上测试的错误仍是长帧和短帧，再次表明网卡本身故障的可能性最大，病毒感染的可能性很小。
[诊断评点]现在可以让我们来事后模拟叙述一下整个网络故障的进程。以便读者了解故障的进程和原因。
票务网络中的一台不起眼的工作站的网卡发生了故障。最初的故障发生于节日前，故障现象是发送错误帧。由于工作站与桌面交换机相连，而该桌面交换机是存储转发型性交换机，所以发送的错误帧被交换机过滤掉了。所以这些错误帧只能对本工作站造成影响，对网络不构成威胁。随着网卡的进一步物理性损坏，网卡变得不能清除发送过的IP地址，并将目标地址“定格”在访问联系最多的票务服务器，开始发送不受限制的数据包。这些数据包不断请求票务服务器处理重复查询计算同一张票的出票业务。由于其不受发送速度的限制(即该网卡不管网络流量是否超高，都会不加理会地向网络发送流量)，网络中的交换机随即将大量的垃圾包送往票务服务器，占用大量网络带宽资源，同时迫使票务服务器消耗大量资源处理这些垃圾包，使得其它正常的网络访问受阻。还由于这些数据包的可操作性很差，服务器会进一步耗用额外的资源来处理这些数据。
在上一篇故事中我们曾提到过，网卡故障后有两类基本的表现，一类是安静型，即不再进行正常的网络通信并且不再向网络发送任何数据，这是比较友好的“醉汉”。对网络基本上没有破坏性。另一类是“狂躁型”，发生故障后向网络发送不受限制的数据包。这些数据包可能是正常格式的，也可能是非正常格式的(即错误数据包)。两种格式的数据包都可能对网络性能造成严重影响甚至破坏。错误格式的数据包一般不能通过存储转发型的交换机，所以本故障的网络监测看不到错误数据包，只能看到正常格式的故障数据包。当接入集线器后才可以观察到错误数据包。
[诊断建议]该网络由于系统成员数量少，在建网规划时没有配备网管系统和测试工具。所以故障早期没有任何超流量报警信号提示，这对于网络故障的迅速定位和排除是不利的。现存的许多网络在维护工作中都基本上采取事后维护的方法，即出了问题才去查找和处理，这对于可靠性要求高的网络是非常危险的。因为我们不能侥幸地“期盼”不管是网络设备，还是网上设备，他们出了问题以后都表现为“安静型”。只有坚持定期地对网络进行监测才是避免重大网络事故的有力措施。其实在本例中，如果每日坚持用3分钟时间监测一下网络，就完全可以在故障的早期排除之，避免后期重大事故的发生。
[后记]我们担心的“病毒”至今没有出现。