身为中小企业的网络管理员主要工作就是负责企业内部网络及各个服务器的安全，因此必然离不开各式各样的网络及单机病毒。当然对于单机病毒来说一个强有力的杀毒软件加上最终的重装系统是百分之百可以解决的。

　　然而一旦病毒和内网联系起来的话，网络管理员将面临棘手的查杀难题。最近笔者所在单位就爆发了一次局部的网络病毒，排查与解决问题的过程是曲折和复杂的，在这里笔者不愿独享写出来和各位IT168的网管读者探讨与研究。

　　        一，网络环境简介：

　　笔者负责区级教育网络的维护工作，全部教育城域网均使用由我们提供的服务，包括办公网邮件系统服务以及信息网站互动平台等。所有服务器都在10.82.0.*/255.255.254.0这个网段，结合入侵检测系统和防毒进行进行防护，而其他各个教育机构都通过电信的光纤连接到核心层的网络设备上，每个教育机构独立一个诸如10.82.*.*的内部网段。

　　二，故障起因——服务器部分服务失效：

　　最近有一个部门的员工打电话告诉我们说这几天一直无法正常访问办公网邮件系统服务器10.82.0.3以及信息网站互动平台10.82.0.1，而访问其他诸如搜狐，新浪等外部网站都没有问题。开始笔者以为是该员工的计算机自身存在问题，让其恢复了系统后问题也得到了解决。然而随着时间的推进笔者又接收到来自该分支机构的多个不同科室的电话，反映的情况都是一样的即无法正常访问办公网邮件系统服务器10.82.0.3以及信息网站互动平台10.82.0.1。与此同时笔者用自己的机器访问这两台服务器上的应用服务时没有任何问题，也没有接到其他分支机构的故障电话，而且本人咨询了具体情况后发现并不是该分支机构下的所有机器都无法访问这两个服务器上的应用，出现问题的只是其中的十几台，其他几十台没有任何问题。

　　三，排查故障——筛选目标：

　　为了更好的了解和解决网络问题，笔者亲自到该分支机构去检测。检测发现当访问10.82.0.3邮件办公系统时可以出现正常的访问登录界面，不过在输入用户名和密码时要嘛“登录”按钮不能用，要嘛干脆登录进入后直接出现一行名为“office.nsf/pgnavigator?openpage>http/1.1 200 ok content-length:4742 content-type:text/html”报错的提示，而且和往常登录界面不同的是在办公主页下方出现了一行“input”的小字。之后笔者更换了浏览器为火狐以及腾讯的TT浏览器故障依旧，看来并不是本机IE浏览器插件的问题。而且笔者还得到了一个新的消息，那就是前几天更更恢复完系统解决问题的那个员工计算机又出现了同样的症状，无法顺利访问这两台服务器。

　　通过检测的种种现象来看，首先服务器自身的问题可以排除，毕竟其他分支机构以及笔者都可以顺利访问，而且该机构下的某些机器也可以顺利登录信息平台和邮件系统。另外当把系统恢复到以前或者重新安装后问题也可以解决，这说明故障确实出现在本机。排除了服务器，网络设备后笔者将关注的目标放到了本机上。

　　四，高级检测——确定目标：

　　平时这个分支机构的计算机都是由笔者和几个同伴一起负责维护，按照常理来说安全防范级别应该比较高，系统自动更新补丁都随时安装，杀毒软件也使用的是卡巴斯基，那么为什么还会在本机出现故障呢？笔者再次检测发现出问题的几台计算机的卡巴斯基并没有升级到最新病毒库，于是手工升级，并在安全模式下全面查杀本地硬盘各个分区，确保无毒后再次访问办公系统，结果令人遗憾的是故障依旧。不过每当访问这两个服务器应用服务时卡巴斯基都给出了发现危机的提示——malcious http object <http://ck1.in/n.js>:access denied。这说明在访问服务器时页面要求自动跳转到http://ck1.in/n.js这个地址，而该地址被卡巴斯基过滤禁止访问了。笔者测试了所有出问题的机器都在访问服务器时卡巴斯基给出警报提示。

　　由于之前已经确定了服务器自身没有问题，所以排除了服务器上存在木马或被篡改添加恶意脚本的可能，因此我们确定了目标，主要问题是病毒带来的，该病毒被卡巴斯基命名为trojan program trojan-downloader.js.agent.lg，是一种木马病毒。笔者在故障机上直接访问http://ck1.in/n.js这个地址出现了该地址被杀毒软件屏蔽的提示，看来该地址是万恶之源。

　　五，解决问题——Sniffer出山找源头

　　虽然确定了本次网络故障是由病毒引起，但是笔者一直有一个疑惑，那就是各个机器的安全级别都很高，平时都是由我们专业人员负责维护，自动打各种漏洞补丁的，那么为什么还会有这么多的计算机感染了该木马病毒呢？另外我们也针对这些故障机器进行了查杀病毒操作，卡巴斯基并没有找到对应的染毒文件。种种迹象都表明病毒未必都在这些故障机器的系统中。

　　这时有一个念头出现在笔者的脑海中，记得以前曾经应对和解决过ARP欺骗病毒，只要网络中有一台机器感染了ARP病毒，那么几乎这个网段的所有机器都无法上网或者访问网络时断时续。那么这次的木马trojan program trojan-downloader.js.agent.lg病毒的感染与攻击机理是否相同呢？为了证实此想法笔者拿出了看家工具——sniffer来扫描整个网段，看看是否有机器在发送或接收可疑数据包。

　　（1）扫描网络：

　　安装Sniffer针对出问题的网段进行扫描，笔者发现MAC地址为000BDBC2F6C5的机器频繁发送广播数据包，数量比较大。

　　将MAC地址切换到IP信息后笔者发现这台可疑机器的IP地址为10.82.4.89，另外从扫描的图表中我们看到了10.82.4.89这台计算机不光频繁发送广播包，还发送了基于239.255.255.250地址的组播包，这在我们平时各种服务和应用中更是少见，这点增加了他的可疑性。

　　为了确定笔者的想法本人通过sniffer只针对该一台机器进行扫描，并且在扫描的同时通过网络来访问之前出现问题的两台服务器应用，结果发现只要笔者在浏览器中输入地址访问办公邮件系统或信息平台，回车后10.82.4.89这台机器就马上发送数据到239.255.255.250地址，进行组播数据传输。看来这台机器是罪魁祸首的可能性已经超过百分之八十。

　　小提示：

　　通过主机扫描笔者发现该机器名为dellesp，地址是10.82.4.89，MAC信息是000BDBC2F6C5。可惜该分支机构DELL机器有几十台，由于平时没有按照科室的序号对计算机命令，所以无法从dellesp信息来定位故障来源。这点需要引起重视，应该在以后的维护中将各个员工机按照一定的顺序命令和归纳。

　　（2）过滤可疑机：

　　由于无法通过计算机名来定位与排查，所以笔者只能够在交换机和路由器上对地址是10.82.4.89，MAC信息是000BDBC2F6C5机器进行封杀了，如果禁止该机器访问网络后故障解决就可以断定他是木马的来源了。

　　笔者登录到交换设备的管理界面，通过sh mac address命令来查看连接到该交换设备上的所有网络设备对应的MAC地址。

　　接下来交换机界面会显示出所有设备的MAC地址以及存在类型还有该MAC设备连接交换机的端口，在这些信息中笔者看到了MAC地址为000bdbc2f6c5这台机器对应的交换机端口为GI0/2。于是笔者进入到该接口通过shutdown命令关闭来阻止该机器对网络的访问。

　　（3）恢复正常：

　　当我们顺利将000bdbc2f6c5这台机器过滤后网络马上恢复了正常，所有原本出现问题的计算机访问办公系统和信息平台服务都没有问题，访问时卡巴斯基杀毒软件也没有再有任何警报产生。之后笔者也接到了000bdbc2f6c5这台机器的主人打来电话说上不了网了，原来是办公室的一台笔记本电脑，将其杀毒后才用no shut命令解除了端口过滤。

　　小提示：

　　当然如果要封锁的端口连接有多台员工计算机的话，我们就不能够通过简单的shut端口命令来过滤问题机了，毕竟其他机器也会出现无法上网的问题。这时我们可以使用基于MAC地址的ACL访问控制列表来解决，由于篇幅的关系这里就不详细介绍了，感兴趣的读者可以自行搜索研究。

　　六，总结：

　　之前笔者一直认为木马病毒和蠕虫病毒不同并不会引起全网多台机器无法访问网络，然而经过本次故障的排查和解决让笔者不得不信服现在病毒的强大，对木马类病毒更加刮目相看，原来他们不光可以盗取帐号等个人隐私，还可以对网络其他机器造成恶劣影响。希望这种情况能够引起各位IT168网管读者的重视，让我们可以更好更快的解决企业内部网络故障，彻底战胜病毒。