由永恒之蓝病毒引发的运维安全思考——网络边界防御篇

由永恒之蓝病毒引发的运维安全思考

——网络边界防御篇

作者：高玉涵

时间：2019.02.05 0:48 农历新年初一

博客：blog.csdn.net/cg_i

前言

WannaCry已经用不着我来做广告，它早已被多家权威安全机构评为2017年度“最佳病毒”。时隔一年之后，勒索病毒虽层出不穷，不断升级，随着微软修复了漏洞，连上互联网的电脑，即可自动更新系统修复漏洞，也伴着Windows10的普及和众多安全机构的努力，病毒感染的机会已大大减少。

与之形成鲜明对比的是，大量使用WindowsXP、Windows7老旧系统，政府、企业等内网用户成了其攻击的主要目标。单位内网的特性，存在无法及时更新补丁、修补漏洞的问题，导致病毒能够轻易通过漏洞入侵系统。同时其内网相连，一旦其中一台电脑感染，可迅速传染给网内其他电脑。

我所处的内网环境，大量使用WindowsXP、Windows7系统，因为业务的特殊性，这些系统未安装任何防病毒程序，只是每次启动系统，C盘恢复到初次安装的状态（类式的特性还有很多，如禁用U盘、用户权限管理等，好在有这些特性，才没能使病毒攻击事态，得到进一步扩大）且都关闭了系统自身的防火墙（简直是黑客和病毒的梦想乐园）吐槽：机缘巧合的原因，2014年的全省第一版，系统定制标准，我有幸全程参与制定、编写及验证。标准其中项，就要求定制系统，启用防火墙且只有授权开放的端口放行（WannaCry利用135、137、138、139、445漏洞，攻击的端口就在标准禁行的行列）。时隔多年，再看当时制定的标准依然可行。可能源于风险认知或随着时间淡化，厂家在后期交付的定制系统，并未严格按照标准来执行，作为最终使用“标准”受益的甲方，也未严格按照标准来验收系统，在大家这种“不愿麻烦”的心理，就此埋下了隐患，因病毒攻击四起，一线救援电话频频，疲于应对的科技同事应该深有体会吧？

既然都已经不是新闻了，我有什么理由写一篇“马后炮”文章呢？虽然2017年WannaCry全球肆虐横行，但那一年，我所在的单位确未感丝毫。一来，平时工作中较为重视内网安全，业务系统终端，禁用U盘、办公电脑，统一部署防病毒、防火墙，U盘插入电脑、网络传输文件，强制查杀病毒策略等等。二来，那时我正参与新数据中心建设工作，忙得无暇顾及其它。期间，也未接到求援电话，所以未引起我过多的关注与重视。

今年春节前，频频接到各地系统“蓝屏”的求援电话，平均每天少则4~5起，多则10几起，多数重启下终端，又可正常办理业务，但过不了多久又会“蓝屏”，有些系统因此损坏，重启后无法进入系统。整个过程，就是我和WannaCry病毒之间的战斗，真得是一个人在战斗！

通过此次WannaCry病毒攻击事件，暴露出我工作中，平时自己忽略的地方（别人给我挖的坑，后面会讲到），处理过程中收获了宝贵的经验，记录下来，分享给大家，希望对你的工作有所帮助，能起到举一反三的效果。

考虑到维护网络安全，是多种手段互相配合、互相补充。单靠某一方法就能“一招制敌，万事无优”那是不可能的事。限于篇幅，这里也不想把讨论扩大。WannaCry病毒防御，计划以“网络边界防御”、“系统防御”两部份来讲述。如果内容让你感到无趣或啰嗦，先在此表示歉意。

案发现场

我们先来看看，遭受WannaCry病毒攻击后系统的症状。

（图1-1）

通过多位同事向我求助和发过来的图片来看，系统确定遭受WannaCry病毒攻击无疑。修补漏洞的方法这里不表，首要任务是，在网络上定位攻击的源头。

不在场证据，追查卡住了？

首先抓包。虽然找到了感染病毒的主机，但没有找感染源头。

（图1-2）

如图1-2所示。27、28、31号包，是中毒的114主机向115目标主机139端口发起三次握手。紧接着是114主机，发送CIFS协议包利用漏洞获取权限，向目标主机发起的攻击包。

到了这里算是“追到头了”。因当时条件限制，只能在未端设备上抓包，在它上面还有多个设备。同样，为不影响业务正常的办理，也只抓了10几分钟左右的包。在抓的包里也未发利用445端口攻击的包。

CIFS协议自身无路由特性，攻击主机只对本网段内的主机发起攻击。谁感染了它？源头来自上级、还是其它子网的主机，在此次抓的包里，并没有体现出来。其实我也是菜鸟，虽然尝试过很多方法，还是没有找到相关信息，这里成了悬案，只能寄望将来，经验的积累，能够找出，隐藏在这些数据包背后的秘密。

一首凉凉送给自己

虽暂时没有定位到攻击源头，但在排查过程中，发现网络简单到，缺少必要的安全控制策略，网络极易被攻击。

（图1-3）

如图1-2所示。192.168.1.0与201.18.8.0两个子网是直接能够互访。这可是生产网络，连最基本的网段隔离都没有。这种情况下，黑客或病毒可在网络任意位置，发起对全网的攻击，后期处理，定位攻击源也是非常麻烦的事情。当然，由此带来的安全隐患远不止于此。

 

应对WannaCry病毒，打造安全网络

首先，通过访问控制技术，在网络边界上，进行网段的隔离，要限制某些网段之间不互通，或有条件地互通，通过阻断445及其它关联端口（如135,137,139）的方式，预防本类攻击。

如图1-4所示。1.1.1.0与1.1.2.0不互通，但都能通11.1.0.0出口网络。同时，在所有网络上阻断445及其它关联端口。

因我使用的是迈普的路由器，策略以它为例给出，各家设备命令大同小异，可参考自家设备手册调整。

1. 网段隔离策略（各子网）。

ip access-list extended Limited

 10 permit ip any 11.1.0.0 0.0.255.255

 20 deny tcp any any eq 135

 30 deny tcp any any eq 137

 40 deny tcp any any eq 138

 50 deny tcp any any eq 139

 60 deny tcp any any eq 445 log

 70 deny udp any any eq 135

 80 deny udp any any eq 137

 90 deny udp any any eq 139

 100 deny udp any any eq 445

 exit

 

 

 

2. 有条件地互通策略（出口网络）。

ip access-list extended deny-wannacry

 10 deny tcp any any eq 135 log

 20 deny tcp any any eq 137 log

 30 deny tcp any any eq 138 log

 40 deny tcp any any eq 139 log

 50 deny tcp any any eq 445 log

 60 deny udp any any eq 135 log

 70 deny udp any any eq 137 log

 80 deny udp any any eq 139 log

 90 deny udp any any eq 445 log

 100 permit ip any any

 exit

最后必须配置允许所有，否则会引起所有业务中断。

3. 在对应端口上调用。

interface gigabitethernet0/1

 ip access-group Limited in

 exit

 

interface gigabitethernet0/2

 ip access-group Limited in

 exit

 

interface gigabitethernet0/3

 ip access-group deny-wannacry in

 exit

 

总结下来，通过这些措施实现了这样的效果：彻底杜绝了，网络各方向的WannaCry病毒攻击。即使子网内存在中毒主机，其攻击范围，也被限制在本地网络中，不仅避免了攻击事态进一步扩大，也为将来排查中毒主机，提供了方便。

 

书上错了吗？

 

细心的读者可能注意到了10 deny tcp any any eq 135 log未尾关键字“log”的语句。

当路由器为用户转发了数据之后，如果想查看路由器曾经为哪些用户转发过数据，在正常情况下，这是无法查证的。但是，可以通过接口配置ACL，并且强制ACL记录下曾经转发过的用户记录（log关键字），这样，就能从路由器得知哪些用户是发起过数据的，并且发送了多少数据，但是用户发出的数据内容，是无法记录的。

我使用的是MP7500E系列的路由器，官方文档给出的命令是，通过access-list logging启用ACL记录功能。原本想通过这个方法，来定位攻击源，但在我的设备上根本没有这个命令，又一次的陷入绝地。希望，正在观看此文的前辈高人指点迷津，不胜感激！