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

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

　　（1）扫描网络：

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

图4

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

图5

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

图6

　　小提示：

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

　　（2）过滤可疑机：

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

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

图7

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

图8

　　（3）恢复正常：

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

　　小提示：

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

　　六，总结：

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

上一页  [1] [2] 

（责任编辑：hahack）