Enrich life today. Yesterday is history. Tomorrow is mystery.

人生如负重远行,不可急于求成

windows下phpstudy等apache环境带宽使用高的排查和处理


                   

本次的问题的表象是一台纯净系统的windows2008服务器,用户安装phpstudy环境,服务器带宽跑得很高。本文针对这个现象,提供一些基本的排查步骤,思路和方法,供大家参考。如有不足还望指正和补充。

1、定位进程

首先远程进入服务器,打开资源监视器,win+R,输入resmon回车或者开始菜单运行中输入resmon。我们切换到带宽栏目查看,带宽跑到7M一上去了,对一般的企业站,这种带宽有点高,如图我们发现httpd进程占用大量的发包,这个表示有网站在被大量访问,或者有资源被频繁请求所致。

《windows下phpstudy等apache环境带宽使用高的排查和处理》《windows下phpstudy等apache环境带宽使用高的排查和处理》

2、发现带宽占用较高后,如何快速定位出问题网站?

(这里先说些题外话,笔者不是很建议使用phpstudy这个环境,权限分离做的很不好,特别是数据库部分,每个站点连接用户居然直接采用root,很多用户网站有漏洞,黑客获取程序配置文件后,直接拿到root

帐号密码,把整个数据库黑了,另外在我遇到的很多服务器上经常发现phpstudy目录下被挂马的,一般集成环境,目前看国内来看,在windows环境下,宝塔面板和西部数码的建站助手是不错的

对于此类集成环境,特别是apache,由于在任务管理器中的进程都是一个,给我们的 排查工作带来一些问题,特别是当apache下的在站点数量很多时,比如笔者平时维护接触的虚拟主机服务器有上万台,每台站点1000多个,这种情况来看排查工作会很麻烦。

下面我们来排查这个服务器上的问题站点,当一个网站访问量很大时候比较适用此方法:

首先进入apache的配置目录conf下找到httpd.conf,找到<IfModule log_config_module>节,将站点的访问日志开启,可参考如图配置:

《windows下phpstudy等apache环境带宽使用高的排查和处理》

打开日志后可以重启apache服务使配置生效。然后我们等待一段时间,打开log目录下的access.log进行分析,通过日志我们查看到很多类似的请求。这种其实并不是很正常的访问。

《windows下phpstudy等apache环境带宽使用高的排查和处理》

这里的请求的url看不到,还是无法找到问题站点,原因是这个用户是在被伪装的蜘蛛大量爬取网站,我们需要重新打开apache配置文件,对日志配置部分进行一些调整,在如图地方增加%v,这个表示响应请求的服务器的ServerName。

《windows下phpstudy等apache环境带宽使用高的排查和处理》

再次重启apache后查看access.log,大量访问的站点主机名就找到了。

《windows下phpstudy等apache环境带宽使用高的排查和处理》

3、处理这个站点

问题找到了,继续查看日志记录,这里我复制了两段比较有代表的日志中的内容

220.243.136.111 – – [14/Feb/2019:11:11:10 +0800] “www.s****t.com.cnGET /index.php?do=tasklist&i=384&m=3&o=3&p=32&pd=369&s=4 HTTP/1.1” 200 87130 “-” “Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.8356.513 Mobile Safari/537.36”

46.229.168.136 – – [14/Feb/2019:11:11:12 +0800] “www.s****t.com.cnGET /index.php?do=tasklist&i=372&i=492&m=2&p=22&pd=369&pd=482&twoid=345 HTTP/1.1” 200 97899 “-” “Mozilla/5.0 (compatible; SemrushBot/3~bl; +http://www.semrush.com/bot.html)”

我们看到访问请求都是200,也就是访问到了站点的,这种就会造成资源的大量消耗了,第一段日志中,是模拟手机访问对站点进行请求,第二段是模拟一个蜘蛛SemrushBot,对网站进行请求,实际上都不是正常的访问。肯定这个站点的内容要么在做百度推广要么就是和同行产生了一些冲突,在被有计划地恶意攻击。这还算轻的,很多虚拟主机站点就因为这种悄悄咪咪的攻击流量耗尽,要是来猛地直接ddos。

针对上面问题有两个解决思路:

(1)屏蔽ua

在网站根目录下新建.htaccess文件(如果不会建立,windows下面新建文件时候前后两个点就能建立了,这样输入.htaccess.)

填入以下内容:

<IfModule mod_rewrite.c>
RewriteEngine On
#Block spider
RewriteCond %{HTTP_USER_AGENT} "SemrushBot|Webdup|AcoonBot|AhrefsBot|Ezooms|EdisterBot|EC2LinkFinder|jikespider|Purebot|MJ12bot|WangIDSpider|WBSearchBot|Wotbox|xbfMozilla|Yottaa|YandexBot|Jorgee|SWEBot|spbot|TurnitinBot-Agent|mail.RU|curl|perl|Python|Wget|Xenu|ZmEu" [NC]
RewriteRule !(^robots\.txt$) - [F]
</IfModule>

保存,RewriteCond %{HTTP_USER_AGENT}这部分后面的是平时收集的一些垃圾蜘蛛,如果你在日志中发现有新的恶意访问蜘蛛,也可以添加进来,以“|”竖线隔开。

如果是windowsIIS7及以上的站点,则新建web.config,填入下面代码:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
     <rewrite>  
       <rules>         
<rule name="Block spider">
      <match url="(^robots.txt$)" ignoreCase="false" negate="true" />
      <conditions>
        <add input="{HTTP_USER_AGENT}" pattern="SemrushBot|Webdup|AcoonBot|AhrefsBot|Ezooms|EdisterBot|EC2LinkFinder|jikespider|Purebot|MJ12bot|WangIDSpider|WBSearchBot|Wotbox|xbfMozilla|Yottaa|YandexBot|Jorgee|SWEBot|spbot|TurnitinBot-Agent|curl|perl|Python|Wget|Xenu|ZmEu" ignoreCase="true" />
      </conditions>
      <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>
        </rules>  
      </rewrite>  
     </system.webServer>
</configuration>

(2)屏蔽IP

屏蔽IP的方式比较粗暴但是立马有效,不过也许攻击者换一个IP,又没辙了

新建.htaccess文件,键入下面规则代码经行屏蔽:

<IfModule mod_rewrite.c>
RewriteEngine On
#Block ip
RewriteCond %{http:X-Forwarded-For}&%{REMOTE_ADDR}&%{http:X-Real-IP} (8.8.4.4|8.8.8.) [NC]
RewriteRule (.*) - [F]
</IfModule>

这里我不是要屏蔽google的dns,8.8.4.4|8.8.8.是一个例子,8.8.4.4换成要屏蔽的IPv4地址,8.8.8.换成要屏蔽的段,多个IP和段之间用竖线“|”分割,比如这个问题,我打算屏蔽220.243.这个段,因为它连接太多了。

<add input="%{HTTP_X_FORWARDED_FOR}&amp;%{REMOTE_ADDR}&amp;%{HTTP_X_Real_IP}" pattern="(220.243.)" />

这样操作后带宽立马降下来了。

可能你会发现在日志中这些恶意的请求还是能够请求到服务器地址。但是细心地话会发现是403的请求结果而非之前的200,说明屏蔽已经生效。

《windows下phpstudy等apache环境带宽使用高的排查和处理》

这个现象在我平时的工作中非常普遍的遇到,所以你的站点也可能正在受到类似问题,打开日志看看吧


点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注

hi~

你好,欢迎来到我的博客,欢迎留言。

快速搜索:







Generic selectors

Exact matches only


Search in title


Search in content



Search in posts


Search in pages

欢迎关注我:

微博
steam
QQ
500px
网易云音乐