原来偷跑云服务器流量的罪魁祸首是TA!

Author Avatar
EmptinessBoy 5月 24, 2020
  • 在其它设备中阅读本文章

(坑爹阿里云,偷跑血汗钱/dog

事情大概是这样的,每个月末都是我日常续费云服务器的日子。因为机子包年比较便宜,包年后只有带宽和CPU占用是按量付费,因此每个月一般只要往里面充值那么几块钱的流量费就差不多了。

但直到我昨天打开计费面板的时候,眼睁睁看到了我40G的流量包居然一周多一点的时间就被消耗殆尽了!!然后开始疯狂扣我的账户余额。

排查

看到这一幕的我显然是慌乱,照这样一个月跑下数百G的流量肯定不是问题。照这么来说,说不定哪一天我家的房子就归马云了(滑稽

赶紧打开服务器,使用 nload 看下当前的流量收发情况。

nloadtraffic.png

因为是一天前刚重启过云服务器,因此1.8GB的流量即一天产生的数据量(通过后台的统计报表可以看到,始终有进程以30多KB每秒的速率在上传数据。

分析进程

那么既然有异常流量的产生,那么就应该定位下,究竟是哪个进程导致了这些流量的产生。或许是某项服务,或许是不小心感染了木马。

统计进程流量这里使用的工具是:nethogs

NetHogs是一个开源的命令行工具(类似于Linux的top命令),用来按进程或程序实时统计网络带宽使用率。

NetHogs是一个小型的net top工具,不像大多数工具那样拖慢每个协议或者是每个子网的速度而是按照进程进行带宽分组。NetHogs不需要依赖载入某个特殊的内核模块。如果发生了网络阻塞你可以启动NetHogs立即看到哪个PID造成的这种状况。这样就很容易找出哪个程序跑飞了然后突然占用你的带宽。

安装方法:

yum install libpcap libpcap-devel install epel-release -y
yum install nethogs -y

安装完成后,输入 nethogs 命令就可以直接运行了

nethogs.png

一些交互式命令:

m : 修改单位
r : 按流量排序
s : 按发送流量排序
q : 退出命令提示符

通过上图观察,可以看出当前占用带宽最高的进程是 nginx。

那么也就基本排除了中木马或者其他乱七八糟的问题了。但是 nginx 作为 webserver 持续的匀速产生流量显然是不正常的。

抓包分析

按照正常的思路到这一步为止基本就需要调出 nginx 的日志。看看究竟哪些网站在产生流量。事实上我也这么做了,可是日志上并没有找到任何持续产生流量的网站。

那么事情就变得更加诡异了。只要是 nginx 产生的 http 或者 https 访问,都会留下日志。那么究竟是何种情况可以在不留下日志的情况下,让 nginx 持续产生上行流星呢?(已经排除 nginx rtmp 推流和 TCP 反向代理的可能

继续观察,这时 nethogs 为我显示出了更为详细的通信信息

nloadtraffic1.png

copy了目标对象的IP地址,网上查了下,属于机房的ip,随手往阿里云cdn工具中一查。尼玛!这居然是阿里云cdn的节点!!

aliyunshitcdn.png

那么问题就更蹊跷了,为何我服务器的 nginx 的443端口会和阿里云的 cdn 节点那么亲密,而且不留下任何 http 的日志呢?

为了捉住这背后的元凶,不得不对 nginx 进程进行抓包分析。

抓包使用的工具是 tcpdump。安装过程非常简单:

yum - y install tcpdump

install-tcpdump.png

tcpdump是一个用于截取网络分组,并输出分组内容的工具。凭借强大的功能和灵活的截取策略,使其成为类UNIX系统下用于网络分析和问题排查的首选工具

tcpdump 支持针对网络层、协议、主机、网络或端口的过滤,并提供and、or、not等逻辑语句来帮助你去掉无用的信息

基本参数方法:

抓包选项:
-c:指定要抓取的包数量。
-i interface:指定tcpdump需要监听的接口。默认会抓取第一个网络接口
-n:对地址以数字方式显式,否则显式为主机名,也就是说-n选项不做主机名解析。
-nn:除了-n的作用外,还把端口显示为数值,否则显示端口服务名。
-P:指定要抓取的包是流入还是流出的包。可以给定的值为"in"、"out"和"inout",默认为"inout"。
-s len:设置tcpdump的数据包抓取长度为len,如果不设置默认将会是65535字节。

安装完成了,试一波看看(

非常愉快的输入命令 tcpdump tcp port 443

tcpdump443.png

屏幕上瞬间输出了一大堆 tcp 的通信细节。具体到每个 ack - seq -fin。可是本宝宝看着满屏滚动的信息瞬间傻掉了好不好。(对不起,是我太菜。

本地分析

为了拯救像我那么笨的帅哥(dog,我决定想办法把抓包信息保存起来,下载回电脑慢慢分析。

想要把抓包信息存到文件的方法也很简单,只要在后面加上参数 -w 然后跟路径和文件名即可

tcpdump tcp port 443 -w ./target.cap

这波操作猛如虎,赶紧把生成的 cap 文件下载到电脑,使用 wireshark 进行数据分析。

zhuabaofenxi1.png

zhuabaofenxi2.png

通过分析可以看到,我那不听话的服务器和阿里云的 cdn 之间发生的 py 关系就是:

阿里云cdn节点始终不停的再向我服务器发送不带 host 的 https 连接(因为我的服务器对于空 host 会自动导向到 www.everdo.cn )。而一旦 https 握手请求建立完毕,就立刻断开当前连接,不再继续向往的服务器发送请求

就好比,阿里云 cdn 节点就像隔壁小王,是不是来家里勾引一波我家的 nginx,nginx 刚有反应,就又不理人家了。而这背后还要我这个主子来承担产生的大量流量费(你说坏不坏,哼😕

掌握了证据后,就赶紧联系来波阿里云客服,求证一波,这到底是咋回事。/dog

最终结果

在客服长达数小时的请您稍等后,终于定位到了,原来是我在使用 阿里云cdn 的时候,设置了一主一备的两个ip,这就会触发 cdn 调度系统进行健康检查。

又一波操作后,我把cdn后端的备用源站ip删除了。经过几小时的观察,果然一切正常了。

trafficfix.png

鉴于我早在一年多前就开始使用 阿里云cdn 了,一直是使用一主一备的设置,从来没有出现这类问题。只能怀疑是阿里云产品进行升级导致的问题,当然这一点客服当然是不会承认的啦。

就这样,被阿里云白嫖了两个月百元多的流量费(哭

This blog is under a CC BY-NC-ND 4.0 Unported License
本文链接:https://coding.emptinessboy.com/2020/05/%E5%8E%9F%E6%9D%A5%E5%81%B7%E8%B7%91%E4%BA%91%E6%9C%8D%E5%8A%A1%E5%99%A8%E6%B5%81%E9%87%8F%E7%9A%84%E7%BD%AA%E9%AD%81%E7%A5%B8%E9%A6%96%E6%98%AFTA%EF%BC%81/