【松勤软件测试】昨天，松勤网被攻击，发现了一群bug，这个锅该谁来背-测试or开发 ？

昨天下午17：45左右，松勤网(www.songqinnet.com）系统管理员接到学员反馈，松勤网打不开，访问失败。管理员接到通知后火速赶现场（松勤网），情况如学员反馈一样，网站打不开，并且报：“系统内部代码错误”。

松勤网是软件测试在线学习的平台，每天有成百上千的访问量，众多软件测试爱好者都在上面学习视频、电子书。这下无法访问了，情况十分紧急，系统管理员火速展开了工作，如下：

1、松勤网部署在阿里云服务器上，管理员登录阿里云后台，直接切换到系统资源监控板块，但凡系统出现宕机，首先需要排查的就是系统硬件的问题，资源监控面板显示信息，如下图所示：

2、从上图可以看出，系统网络访问量在17:40-17:45，持续了5分钟左右的高峰，对应的系统CPU使用率在17:45分开始，持续了30分钟左右的峰值（100%使用率）。两组数据对比可以判断，CPU的忙碌和网络流量有直接的关联。

3、这个时候管理员脑海里面出现了2个疑问，第一，17：40开始，是什么业务导致了高网络流量；第二，CPU 使用率持续了30分钟的100%，是哪些程序使用了如此多的CPU资源。

4、以上两个问题，都需要登录到松勤网所在的Linux主机上去盘查。于是，管理员通过远程登录工具Putty，通过松勤网ip地址，linux系统的用户名和密码，远程登录到Linux系统（幸好，系统还可以勉强登录进去，但是速度很慢了）。登录linux系统后，管理员采用top命令，查看系统程序运行详细情况，如下图所示：

5、从上图可以看出，用户程序占用cpu达到84.1%（us），操作系统程序占用到15.4%（sy），系统空闲率为0（0.0 id），监控显示大量的 php-fpm进程，该进程属于www这个用户，www用户主管的恰恰就是网站的web服务器apache。

6、可以初步判定，是网络流量上来，触发了系统启动大量的php-fpm进程，进而引起系统cpu繁忙，那么问题是这些网络流量来自于哪里，是正常的访问还是恶意的攻击呢，难道系统没有防护吗，另外，到底是哪个业务流程触发了问题呢？

7、要解答上述问题，就需要系统日志的配合了，系统崩溃是由网络流量触发的，那么势必对系统产生访问量，用户访问的信息，记录在日志文件中，于是管理员运行以下命令：

cat www.songqinnet.com-access_log | awk ‘{print $1}’| sort | uniq -c | sort -rn | head -10

得到结果如下：

54584 157.x1.159.61
46811 120.2x9.34.119
26813 112.x7.99.39
17221 180.1x0.163.80
17064 117.1x0.150.7
15568 122.2x8.189.67

同时查到日志如下：
kernel: Out of memory: Kill process 29917 (php-fpm) score 30 or sacrifice child（内存满）

看内存消耗最多的前10个进程的命令：

ps auxw|head -1;ps auxw|sort -rn -k4|head -10

通过命令以下分析出大量的访问来自于120.2x9.34.119（x是出于隐私保护）：

cat www.songqinnet.com-access_log | grep “27/Dec/2018:17” | awk ‘{print $1}’| sort | uniq -c | sort -rn | head -10
40214 120.2x9.34.119

8、通过以上排查，管理员初步确认，网络大流量是来自于以上这个ip，于是按照经验“没有无缘无故的爱，也没有无缘无故的恨”，这个ip很可能是熟悉的人，于是通过系统匹配，定位出这个ip属于哪个用户，并且提取到该用户的手机号码，于是联系到这位来自于深圳的朋友并和她确认了，刚才的大流量确实来自于她那边的Jmeter。（小编要感谢这位朋友，因为你的大流量-5000TPS，把系统深层面的问题暴露出来了，不得不说你的电脑配置还是杠杠滴)。

9、到这里为止，触发本次系统崩溃的外部来源终于水落石出了。

10、可是是什么原因导致的呢 ？通过进一步排查发现系统存在的问题：

A.在最近一次系统升级中，开发哥哥升级防火墙规则后，竟然没有启动防火墙，直接导致操作系统层面没有任何网络流量防护。同时也发现之前的防火墙规则也非常简单，形同虚设。

于是管理员里面甩上一条命令，先解决燃眉之急：

iptables -I INPUT 5 -p tcp --syn --dport 443 -m connlimit --connlimit-above 10 -j REJECT（同一个ip地址，在443端口，链接超过10的链接拒绝）

B.开发哥哥完成了SQL代码调试后，端口3306竟然还可以通过外网访问到，这个是极其危险的，管理员里面关闭了这个访问。

C.在用户大流量访问的时候，系统进程php-fpm 出现多次致命的退出，导致了后台监管程序多次启动该进程，消耗了系统大量的内存。

综上：本次故障基本原因已经找到，并且临时性地解决了问题，后续还有很多地方需要优化，从操作系统层面到代码层面都存在问题。

看完以后，各位看官，你们认为本次故障，该由谁来负责，测试or开发？ 欢迎留言交流。