记一次菜鸡的运维经历--对抗恶意代理攻击

Posted on | In

事情的起因

这是一个悲伤的故事。2017年3月15号，当我开开心心的起床吃中饭的时候，突然发现收到了阿里云的一条邮件：

我就纳闷了，阿里每个月都会送10块钱的流量代金券，1G流量也就8毛钱，为啥才月半就全没了，我的小网站有这么受欢迎？本来想缓缓搞得，不过果然没过多久，服务器就强行被关停了，不得已冲了2块钱，上去研究研究到底是什么鬼。打开阿里云的流量监控器，一脸蒙ｂ：

最左边是前几天正常情况下的流量，3月12号到13号那会的流量基本是0-10kbps的上下行，到了15号12点居然达到了3Mbps的上行,4Mbps的下行。。。难怪瞬间我的流量就被耗光了，照这么下去的话2块钱的流量钱全烧掉也是指日可待。没办法，只有学着去排查原因。

Log分析

首先我想到的肯定是apache的问题，毕竟我在服务器上基本也就开了这一个对外服务。
打开apache的log,查看了下/var/log/apache2/access.log，发现了很多奇怪的请求：

1
2
3
4
5
6
7
8
107.151.148.193 - - [12/Mar/2017:23:36:22 +0800] "POST http://www.proxyjudge.info/azenv.php HTTP/1.1" 502 696 "-" "Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.1; Trident/5.0)"
107.151.148.193 - - [13/Mar/2017:02:34:20 +0800] "GET http://proxyjudge.us/ HTTP/1.1" 200 976 "-" "Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.1; Trident/5.0)"
107.151.148.193 - - [13/Mar/2017:02:34:24 +0800] "POST http://www.sbjudge2.com/azenv.php HTTP/1.1" 200 832 "-" "Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.1; Trident/5.0)"
107.151.148.193 - - [13/Mar/2017:04:04:44 +0800] "GET http://www.proxyjudge.info/azenv.php HTTP/1.1" 200 936 "-" "Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.1; Trident/5.0)"
107.151.148.193 - - [13/Mar/2017:04:04:45 +0800] "POST http://www.proxyjudge.info/azenv.php HTTP/1.1" 200 937 "-" "Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.1; Trident/5.0)"
107.151.148.193 - - [13/Mar/2017:04:05:01 +0800] "GET http://proxyjudge.us/ HTTP/1.1" 200 976 "-" "Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.1; Trident/5.0)"
107.151.148.193 - - [13/Mar/2017:04:44:48 +0800] "GET http://www.sbjudge1.com/azenv.php HTTP/1.1" 200 859 "-" "Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.1; Trident/5.0)"

proxyjudge? 什么鬼？这域名名字起的也太嚣张了吧，这不是大张旗鼓搜寻肉鸡的节奏么，竟然还搜到了我的头上了。。。这请求啥意思啊，用我的服务器做代理去访问他的那个proxyjudge，蛋疼的是我的服务器居然还老老实实的返回了正确的结果(200)。写过爬虫的人都知道，我的服务器这会就变成了一个彻彻底底的代理服务器，使用者的所有http请求都会经由我的服务器以我的名义发起。更有甚者竟然用sbjudge这个名字。。。
越想越气，于是抱着好奇的想法，我试了试用浏览器访proxyjudge.info这个网站，发现他好像只是一个提供一个返回请求信息的公益网站(虽然当我试图查他的whois的时候发现他申请了隐私保护。。。)，并没有什么恶意，而且他还善意的提醒了我们什么是http头，以及如果出现了类似上述场景意味着什么：


原来，这类网站只是被一些恶意的人用来探测网络上的主机是不是开启了正向代理，如果开了就会利用这些主机作为自己的免费代理。正常情况下，显然是404，这对被探测的机子来说并没有什么影响。这就像一个小偷挨家挨户的敲门，如果门是闭着的，那小偷就会去试下一家，如果发现门是开的，那小偷就不客气了：

1
2
3
4
60.10.115.59 - - [13/Mar/2017:04:03:30 +0800] "GET http://reg.163.com/services/checkUsername?username=m53427233031@163.com&product=urs HTTP/1.1" 200 390 "http://reg.163.com/reg/reg.jsp?product=urs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 QIHU 360SE"
60.10.115.59 - - [13/Mar/2017:04:03:30 +0800] "GET http://reg.163.com/services/checkUsername?username=w4711662071@163.com&product=urs HTTP/1.1" 200 390 "http://reg.163.com/reg/reg.jsp?product=urs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 QIHU 360SE"
60.10.115.59 - - [13/Mar/2017:04:03:30 +0800] "GET http://reg.163.com/services/checkUsername?username=jia03142011@163.com&product=urs HTTP/1.1" 200 390 "http://reg.163.com/reg/reg.jsp?product=urs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 QIHU 360SE"
60.10.115.59 - - [13/Mar/2017:04:03:30 +0800] "GET http://reg.163.com/services/checkUsername?username=xueangang20081@163.com&product=urs HTTP/1.1" 200 390 "http://reg.163.com/reg/reg.jsp?product=urs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 QIHU 360SE

我甚至都能猜到这家伙在做啥，估计是想注册163邮箱的什么东西。。。
然而，这只是在最近两三天产生的高达2G的log文件的一部分。。。上面的真的只是冰山一角，可以想见，连log都这么大了，他们爬的东西肯定不少。。。

于此同时，我还发现了一个搞笑的事情，我在log中还发现了一堆这样的请求：

1
2
3
4
5
27.148.156.159 - - [16/Mar/2017:18:08:01 +0800] "GET http://103.198.73.117:9207/ HTTP/1.1" 200 639 "http://103.198.73.117:9207" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
183.131.83.81 - - [16/Mar/2017:18:08:01 +0800] "GET http://138.201.200.253:443/ HTTP/1.1" 200 637 "http://138.201.200.253:443" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
27.148.156.67 - - [16/Mar/2017:18:08:02 +0800] "GET http://66hfw.jxxsjled.cn/ HTTP/1.1" 200 641 "http://66hfw.jxxsjled.cn" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
27.148.156.159 - - [16/Mar/2017:18:08:02 +0800] "GET http://103.198.73.117:9207/ HTTP/1.1" 200 639 "http://103.198.73.117:9207" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
27.148.156.67 - - [16/Mar/2017:18:08:02 +0800] "GET http://66hfw.jxxsjled.cn/ HTTP/1.1" 200 641 "http://66hfw.jxxsjled.cn" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"

咦？乍一看referer好像是baidu的爬虫啊，得好好招待，不过仔细一看，他怎么不好好请求正常的页面，还是把我的服务器当成代理一样在用。好奇的我看了看baidu的spider页面，发现了这样的东西：

用他介绍的方法一试，果然露出了马脚:

1
2
3
myths@pc:~$ host 27.148.156.159
Host 159.156.148.27.in-addr.arpa. not found: 3(NXDOMAIN)

再来看看人家正常的BaiduSpider干的事：

1
2
123.125.71.107 - - [18/Mar/2017:00:46:07 +0800] "GET /page/3/ HTTP/1.1" 200 11633 "-" "Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)"

人家请求的可是正经的网站子页面，再用反向dns一查，果然是靠谱的：

1
2
myths@pc:~$ host 123.125.71.107
107.71.125.123.in-addr.arpa domain name pointer baiduspider-123-125-71-107.crawl.baidu.com.

做这种事情的人不仅是小偷，而且诚信也有问题。。。不过回头想想，为啥人家要假扮成baiduSpider呢？我想这是因为有很多的服务器都会设置User-agent的过滤，对于一般的UA警惕性比较高，而对于baiduSpider的警惕性可能会降低，因此他们才会这样设置。

问题解决

既然找到了问题所在，那解决起来也就很”简单”了，显然这是我不小心给apache配置了未加限制的正向代理导致的，那么修改下apache2的代理配置就好了。打开/etc/apache2/mods-enabled/proxy.conf:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# If you want to use apache2 as a forward proxy, uncomment the
# 'ProxyRequests On' line and the <Proxy *> block below.
# WARNING: Be careful to restrict access inside the <Proxy *> block.
# Open proxy servers are dangerous both to your network and to the
# Internet at large.
#
# If you only want to use apache2 as a reverse proxy/gateway in
# front of some web application server, you DON'T need
# 'ProxyRequests On'.

#ProxyRequests On
<Proxy *>
    Order allow,deny
    Allow from all
    Deny from 123.57.149.196
</Proxy>


注意把ProxyRequests On給注释掉就好了，原因也在注释里说的很清楚。

还没完

不过修改完配置并且重启了之后还是发现了有很多恶意请求。由于我关闭了正向代理，所以返回的基本都是404，但是发现下面对于这种请求竟然我还是返回了200:

1
2
3
4
5
6
7
192.187.101.50 - - [19/Mar/2017:14:43:04 +0800] "GET http://29099b.com/ HTTP/1.1" 200 635 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
192.187.101.50 - - [19/Mar/2017:14:43:06 +0800] "GET http://29099b.com/ HTTP/1.1" 200 635 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
192.187.101.50 - - [19/Mar/2017:14:43:08 +0800] "GET http://29099b.com/ HTTP/1.1" 200 635 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
192.187.101.50 - - [19/Mar/2017:14:43:10 +0800] "GET http://29099b.com/ HTTP/1.1" 200 635 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
192.187.101.50 - - [19/Mar/2017:14:43:14 +0800] "GET http://29099b.com/ HTTP/1.1" 200 635 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
192.187.101.50 - - [19/Mar/2017:14:43:23 +0800] "GET http://29099b.com/ HTTP/1.1" 200 635 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
192.187.101.50 - - [19/Mar/2017:14:43:28 +0800] "GET http://29099b.com/ HTTP/1.1" 200 635 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"

不知道是因为什么原因，如果请求方想以我为代理访问他自己，返回的结果都是200。这就很尴尬了，虽然不知道他这么做的目的是什么，但是他这种方式的确成功的影响了我的服务器性能，得赶快阻止。
研究了半天终于想到了一个算是方法的方法。
我现在对服务器的需求是，开启80端口和443端口，其中443端口访问的是我的博客，同时80端口也要将合理的http请求重定向到443端口的https上。于此同时，我要保证80端口不会响应恶意请求，尤其是上面这种类型。因此，我将80端口对应的DocumentRoot下的.htaccess修改如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
RewriteEngine on
RewriteBase /

RewriteCond %{HTTP_HOST} mythsman.com$ [NC]
RewriteRule ^(.*)$ https://blog.mythsman.com/$1 [L,R=301]

RewriteCond %{HTTP_HOST} blog.ythsman.com$ [NC]
RewriteRule ^(.*)$ https://blog.mythsman.com/$1 [L,R=301]

RewriteCond %{HTTP_HOST} www.mythsman.com$ [NC]
RewriteRule ^(.*)$ https://blog.mythsman.com/$1 [L,R=301]

RewriteRule ^(.*)$ - [F]

其中前三个转移就是将正常的请求转发到443端口，最后一个请求就是将剩余的所有非法请求都返回403Forbidden。经过这样的处理后，对于之前的请求就会产生下面的log:

1
2
3
4
5
6
7
8
9
192.187.101.50 - - [19/Mar/2017:14:50:07 +0800] "GET http://29099b.com/ HTTP/1.1" 403 414 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
192.187.101.50 - - [19/Mar/2017:14:50:16 +0800] "GET http://29099b.com/ HTTP/1.1" 403 414 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
192.187.101.50 - - [19/Mar/2017:14:50:29 +0800] "GET http://29099b.com/ HTTP/1.1" 403 414 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
192.187.101.50 - - [19/Mar/2017:14:50:39 +0800] "GET http://29099b.com/ HTTP/1.1" 403 414 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
192.187.101.50 - - [19/Mar/2017:14:50:57 +0800] "GET http://29099b.com/ HTTP/1.1" 403 414 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
192.187.101.50 - - [19/Mar/2017:14:51:07 +0800] "GET http://29099b.com/ HTTP/1.1" 403 414 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
192.187.101.50 - - [19/Mar/2017:14:51:07 +0800] "GET http://29099b.com/ HTTP/1.1" 403 414 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
192.187.101.50 - - [19/Mar/2017:14:51:12 +0800] "GET http://29099b.com/ HTTP/1.1" 403 414 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)"
192.187.101.50 - - [19/Mar/2017:14:51:17 +0800] "GET http://29099b.com/ HTTP/1.1" 403 414 "http://29099b.com" "Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.h

成功识别了这种恶意访问请求。

最后

虽然上面的配置合理的识别的恶意代理攻击，但是也并不能阻止人家不停的发送请求，只能是一种被动的防御。