查找ros小包攻击源

凌晨被客户电话吵醒, 报故障说大量的VPS延迟增大,丢包. 第一反应就是ROS被内网攻击了. 因为机房有防火墙,来自外部的攻击不会到达ROS.  为了避免内部攻击, 我也在ROS上做了诸多安全策略,  那么这次故障到底是什么情况呢?

打开管理后台,看到ROS CPU使用率 55%,  明显不正常,因为平时CPU使用不会超过30%, 由于ROS是软路由, 转发不是靠硬件电路, 主要是靠CPU. 所以CPU一直是ROS的性能瓶颈和薄弱环节.  但是这次看上行流量和下行流量都不高,在正常范围之内. 看来不是常规的发包. 常规的发包上行流量达到达到几百兆.

用winbox登陆ROS查看各个端口的流量信息:

可以看到每个端口的流量确实没有明显增大, 但是注意9口的数据包却比其他端口高出十几倍,达到每秒3万多个. 看来症结是9口下联的vps有异常. 9口下面有几十个vps, 具体是哪个在搞鬼, 还要做进一步判断: 抓包

选择 tools -> Packet Sniffer 打开抓包工具,设置为9口, 选择rx, rx是进入ros的数据包,然后点击apply应用, start开始,等2秒钟 stop , 然后点击  Packets 查看抓到的数据包

可以看到大量伪造源地址(Src. Address列),  源MAC为 00:50:56:AD:55:E9 的数据包在攻击目的地址为218.98.34.154的80端口,而且Size全部都是60, 是很小的数据包. 所以会在流量不明显增大的情况下极大的影响ROS转发性能. 当然这样的数据包也是出不去的, 我在ROS做了源地址限制. 不是下属网段的IP根本出不去.

剩下的就好办了, 根据源MAC揪出肇事的vps, 断网,网络马上恢复正常.  联系客户清理系统的事情就交给技术支持工程师了.  

这次问题是解决了,但是也导致了十几分钟的网络质量下降,  客户体验高于一切, 所以如何避免这样的故障才是关键的. ROS的API很好用,所以实现自动化处理也很简单:

1. 写个脚本实时监控每个端口的数据包流量, 设置一个阀值, 超过这个阀值的, 自动执行抓包分析, 根据抓到的数据包比例找出MAC, 再根据MAC找到对应的vps, 自动断网, 然后自动发报警邮件.

2. 用脚本每2秒抓包取样, 凡是有伪造IP的MAC, 不管数据包频率大小, 找出对应的vps, 断网, 因为伪造IP准没好事

提醒:

1.在处理发包问题的时候,不要尝试用IP来定位肇事者, 因为一般都是伪造源IP的. 根据MAC判断比较靠谱.

2.自动化处理的时候要注意伪造MAC的情况.避免误杀. 如果在VMware ESXI里面配置不允许伪造MAC, 则不需考虑这点.

3.在防火墙的filter rules 里面配置源地址限制, 根据这条规则的计数器来判断是不是有伪造源地址的发包, 可以配合查找肇事者.

chain=forward action=drop src-address=!x.x.x.x-x.x.x.x in-interface=lan

4. 如果针对每IP配置了queue, 还可以根据每IP的Upload和Upload packets来辅助判断 , 这在没有伪造IP情况下有效