千万当心！不启用代理功能，网站也有可能被恶意用作垃圾邮件发送服务器

摘要：         最近巡检网站时，发现有大量的异常链接，如“tcp        0    912 hhrz.org:80          125.224.196.186:1087    LAST_ACK ”以及异常访问记录-" 205.209.140.102 - - [03/Aug/2009:04:21:59 +0800] "CONNECT 59.124.98.13:25 HTTP/1.0" 404 723 "-" "-"“，经查，为非法主机恶意通过网站发送垃圾邮件，经调整后，恢复正常。报告有这种异常现象的较多，但解决的较少，发布本文，希望引起站长们的注意。
关键字：linux,apache,CONNECT,:25,linux下apache日志的CONNECT,垃圾邮件,VirtualHost,proxy,虚拟主机,代理服务器

作者： 陈海青（josonchen，"船长"）
(http://chq.name)
(http://hhrz.org) （航海日志）
(http://hhrz.net) （航海日志）
日期：2009.08.03

一、问题现象描述
最近在对网站 http://hhrz.net,http://chq.name,http://hhrz.org进行例行检查时，发现一个奇怪的现象，存在大量奇怪的连接,导致系统资源被大量占用，apache的日志里记录了大量异常访问记录......
1：网络监测结果异常：（在网站http://chq.namehttp://hhrz.net http://hhrz.org中均存在）
#/bin/netstat -a |grep tcp |sort +6
tcp        0    912 hhrz.org:80          125.224.196.186:1087    LAST_ACK   
tcp        0    912 hhrz.org:80          125.224.196.186:1117    LAST_ACK   
tcp        0    912 hhrz.org:80          125.224.196.186:1270    LAST_ACK   
tcp        0    912 hhrz.org:80          125.224.196.186:2994    LAST_ACK   
tcp        0    912 hhrz.org:80          125.224.196.186:3546    LAST_ACK   
tcp        0    912 hhrz.org:80          205.209.140.102:1198    LAST_ACK   
tcp        0    912 hhrz.org:80          205.209.140.102:1307    LAST_ACK   
tcp        0    912 hhrz.org:80          205.209.140.102:1531    LAST_ACK   
。。。。。。
tcp        0    912 hhrz.net:80          205.209.140.102:4379    LAST_ACK   
tcp        0    912 hhrz.net:80          205.209.140.102:4395    LAST_ACK   
tcp        0    912 hhrz.net:80          205.209.140.102:4472    LAST_ACK   
tcp        0    912 hhrz.net:80          67.215.241.234:1090     LAST_ACK   
tcp        0    912 hhrz.net:80          67.215.241.234:1112     LAST_ACK   
tcp        0    912 hhrz.net:80          67.215.241.234:1302     LAST_ACK   
。。。。。。
tcp        0   1561 chq.name:80          125.224.196.186:1118    LAST_ACK   
tcp        0   1561 chq.name:80          125.224.196.186:1445    LAST_ACK   
tcp        0   1561 chq.name:80          125.224.196.186:1578    LAST_ACK   
tcp        0   1561 chq.name:80          125.224.196.186:1680    LAST_ACK   
tcp        0   1561 chq.name:80          125.224.196.186:2798    LAST_ACK   
tcp        0   1561 chq.name:80          125.224.196.186:3362    LAST_ACK   
。。。。。。

2：网站日志的异常访问记录（在网站http://chq.namehttp://hhrz.net http://hhrz.org中均存在）：
#tail access_log
205.209.140.102 - - [03/Aug/2009:04:16:19 +0800] "CONNECT 140.112.65.3:25 HTTP/1.0" 200 1144 "-" "-"
205.209.140.102 - - [03/Aug/2009:04:18:20 +0800] "CONNECT 211.75.100.49:25 HTTP/1.0" 200 1144 "-" "-"
......
205.209.140.102 - - [03/Aug/2009:04:21:59 +0800] "CONNECT 168.95.6.157:25 HTTP/1.0" 404 723 "-" "-"
205.209.140.102 - - [03/Aug/2009:04:21:59 +0800] "CONNECT 59.124.98.13:25 HTTP/1.0" 404 723 "-" "-"
67.215.241.234 - -  [03/Aug/2009:18:00:07 +0800] "CONNECT 203.188.197.10:25 HTTP/1.0" 403 - "-" "-"
205.209.140.102 - - [03/Aug/2009:18:00:07 +0800] "CONNECT 168.95.5.62:25 HTTP/1.0" 403 - "-" "-"
205.209.140.102 - - [03/Aug/2009:18:00:07 +0800] "CONNECT 203.133.1.212:25 HTTP/1.0" 403 - "-" "-"
......
67.215.241.234 - -  [02/Aug/2009:17:54:39 +0800] "CONNECT 203.188.197.9:25 HTTP/1.0" 404 723 "-" "-"
125.224.200.238 - - [02/Aug/2009:17:54:40 +0800] "CONNECT 203.188.197.9:25 HTTP/1.0" 404 723 "-" "-"
125.224.200.238 - - [02/Aug/2009:17:54:39 +0800] "CONNECT 209.85.147.27:25 HTTP/1.0" 404 723 "-" "-"
205.209.140.102 - - [02/Aug/2009:17:54:40 +0800] "CONNECT 168.95.5.43:25 HTTP/1.0" 404 723 "-" "-"
205.209.140.102 - - [02/Aug/2009:17:54:40 +0800] "CONNECT 202.8.15.31:25 HTTP/1.0" 404 723 "-" "-"

二、问题分析
总结这些异常现象，主要特点是：
1：同一个ip地址，在同一时刻建立了大量的连接
2：这些链接均是通过建立到网站(http://chq.namehttp://hhrz.net http://hhrz.org)的链接后，再通过网站访问其他的服务器的25号端口，即发送邮件的SMTP端口
3：虽然大部分连接返回了403、404代码--访问失败，但有个别的访问是成功的-即返回结果为200

三、解决办法
其产生的原因可能为：
1：web网站开启了代理服务。如查询ip地址：67.215.241.234，就常可以发现出现在一些代理服务器的访问清单上，这一般是由于有一些恶意的访访问者试图通过代理服务器去访问一些网站，并且隐藏其真实位置，如发送垃圾邮件等。

---解决办法：如果不需要代理服务，在httpd.conf将代理服务Module注解掉，或设置ProxyRequests 为off；如果你要使用代理服务，请在httpd.conf中的 部分进行安全设置，限制访问。具体操作详见本文最后的参考资料及其他有关资料。

2：网站没开启了代理服务，但apache仍然会响应代理请求。这是因为根据RFC2616 section 5.1.2 的要求， Apache必须接受request-URI中的绝对URL请求，即使是非代理的请求，这意味着，即使代理服务关闭，apache仍然响应看起来像代理请求的请求。

解决办法：修改设置（httpd.conf或其他配置文件），拒绝访问非配制的虚拟主机：
NameVirtualHost *:80

<VirtualHost *:80>
  ServerName default.only
  <Location />
    Order allow,deny
    Deny from all
  </Location>
</VirtualHost>

<VirtualHost *:80>
  ServerName realhost1.example.com
  ServerAlias alias1.example.com alias2.example.com
  DocumentRoot /path/to/site1
</VirtualHost>

--------------------------------------------------------------------------------
 

参考资料：
=====================
1:救命！linux下apache日志的"CONNECT"记录是什么意思？
http://www.unixresources.net/linux/clf/security/archive/00/00/42/34/423464.html
Subject: 救命！linux下apache日志的"CONNECT"记录是什么意思？
Author: luodarou    Posted: 2003-06-25 12:10    Length: 1,015 byte(s) 
[Original] [Print] [Top] 
158.252.208.31 - - [30/May/2003:12:45:08 +0800] "CONNECT 64.58.76.227:80 HTTP/1.0" 302 0
158.252.208.31 - - [30/May/2003:12:45:20 +0800] "CONNECT 64.58.76.227:80 HTTP/1.0" 302 0
158.252.208.31 - - [30/May/2003:12:45:45 +0800] "CONNECT 64.58.76.227:80 HTTP/1.0" 302 0
158.252.208.31 - - [30/May/2003:12:46:13 +0800] "CONNECT 64.58.76.227:80 HTTP/1.0" 302 0
158.252.208.31 - - [30/May/2003:12:47:32 +0800] "CONNECT 64.58.76.227:80 HTTP/1.0" 302 0
158.252.208.31 - - [30/May/2003:12:49:52 +0800] "CONNECT 64.58.76.227:80 HTTP/1.0" 302 0
以上是我apache日志中的记录，是不是有人妄图proxy？从记录看他成功了么?
系统是新装的，其它日志分析没有任何入侵迹象，tripwire也没有报告文件系统有任何变化
我的httpd.conf 中没有设置proxy。我也没装squid。
我用iptables -A INPUT -i eth0 -s 158.252.0.0/16 -j DROP 不能阻止它，还是每天产生这样的记录。
请大侠们救命！ 指点怎么解决？
--------------------
2：為何我的 Apache Log 裡會出現這個訊息?
http://phorum.study-area.org/index.php/topic,23765.msg117715.html#msg117715
----
Apache：剛查了一下 Apache(2.0.49) log,發現一個記錄  驚訝
218.154.135.125 - - [30/May/2004:12:18:21 +0800] "GEThttp://www.online.sh.cn/HTTP/1.1" 200 1362
為何會出現不是我網站所屬的位址呢? 這有啥含意呢?
-----
abelyang：我想這是個測試你的 apache 有沒有用 proxy 吧 再來可能就是寄 spam 的行為了 (Open Proxy)
沒有用到建議拿掉 httpd.conf 中有關 proxy 的 mod，最後的 http code 為 200 (OK)
218.154.135.125 - - [30/May/2004:12:18:21 +0800] "GEThttp://www.online.sh.cn/HTTP/1.1" 200 1362
所以,連到你的 WWW, 要求說要 GET 另一站的資料(這不是 proxy 嗎?) ，最後回傳 200 成功

再來,你看看http://httpd.apache.org/docs/mod/mod_proxy.html
有很多說明,建議你自己研讀看看,一定會有很多收獲的
你可以設定好後,再用上面的例子自己測試,只到出現 4xx 的 return code 為止看看,不同 Return Code:
http://www.cknow.com/ckinfo/def_h/httpreturncodes.shtml
再提供你幾個我的 apache 上的 log 供你參考:
有人連我的 apache , 企圖寄信到別人的 Mail Server
而不被允許(405),他傳的信 size 是 1070 或 1049
61.173.41.160 - - [28/Apr/2004:11:25:17 +0800] "CONNECT maila.microsoft.com:25 HTTP/1.0" 405 1070 "-" "-"
61.173.41.160 - - [28/Apr/2004:11:25:17 +0800] "CONNECT maila.microsoft.com:25 HTTP/1.0" 405 1070 "-" "-"
68.192.66.97 - - [03/May/2004:06:17:22 +0800] "CONNECT 64.12.138.89:25 HTTP/1.1" 405 1049 "-" "-"
68.192.66.97 - - [03/May/2004:06:17:22 +0800] "CONNECT 64.12.138.89:25 HTTP/1.1" 405 1049 "-" "-"
下一個例子同你的狀況,但 404 / 403 的回應
198.211.138.100 - - [28/Apr/2004:00:32:21 +0800] "GEThttp://207.36.18.60/cgi-bin/textenv.pl?80HTTP/1.0" 404 1133 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)"
218.80.146.212 - - [06/May/2004:01:45:45 +0800] "GEThttp://www.ebay.com/HTTP/1.1" 403 1123 "-" "Mozilla/4.0 (compatible; MSIE 5.00; Windows 98)"
希望我的解釋看的懂
----
Apache：感謝 abelyang學長的指導  :lol:
我是有把 mod_proxy 及相關moudle 給 comment起來，只是沒想到 Apache 會在這狀況下的 Return code 會是 200(OK)，(不知道這算不算是bug ? )
小弟剛做了個小測試,就是在IE裡,把Proxy設成我的 Web 的網址,再連到Yahoo Kimo，在  log裡得到如下的記錄:
211.21.137.29 - - [30/May/2004:16:18:42 +0800] "GEThttp://tw.yahoo.com/HTTP/1.0" 200 1362
211.21.137.29 - - [30/May/2004:16:18:42 +0800] "GEThttp://tw.yahoo.com/apache_pb.gifHTTP/1.0" 200 2326
211.21.137.29 - - [30/May/2004:16:18:42 +0800] "GEThttp://tw.yahoo.com/poweredby.pngHTTP/1.0" 200 1154
結果是...在 IE 裡看到的是我的 Web 的首頁, 而非看到 Yahoo Kimo 的首頁，也就是說, 在無安裝 Proxy 相關 module時, 在log 發現這種記錄是無害的.
小弟甫接觸 Apache,尚在摸索階段,再次感謝abelyang學長的指點, 解開那股疑團 !
.......
--------------------
3：5.1.2 Request-URI
--------------------
http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html
   The Request-URI is a Uniform. Resource Identifier (section 3.2) and identifies the resource upon which to apply the request.
          Request-URI    = "*" | absoluteURI | abs_path | authority
   The four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily apply to a resource. One example would be
          OPTIONS * HTTP/1.1
   The absoluteURI form. is REQUIRED when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, and return the response. Note that the proxy MAY forward the request on to another proxy or directly to the server
   specified by the absoluteURI. In order to avoid request loops, a proxy MUST be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example Request-Line would be:
          GEThttp://www.w3.org/pub/WWW/TheProject.htmlHTTP/1.1
   To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form. in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
   The authority form. is only used by the CONNECT method (section 9.9).
   The most common form. of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI, and the network location of the URI (authority) MUST be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines:
          GET /pub/WWW/TheProject.html HTTP/1.1
          Host:www.w3.org
   followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original URI, it MUST be given as "/" (the server root).
   The Request-URI is transmitted in the format specified in section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding [42], the origin server MUST decode the Request-URI in order to properly interpret the request. Servers SHOULD respond to invalid Request-URIs with an appropriate status code.
   A transparent proxy MUST NOT rewrite the "abs_path" part of the received Request-URI when forwarding it to the next inbound server, except as noted above to replace a null abs_path with "/".
      Note: The "no rewrite" rule prevents the proxy from changing the
      meaning of the request when the origin server is improperly using
      a non-reserved URI character for a reserved purpose.  Implementors
      should be aware that some pre-HTTP/1.1 proxies have been known to
      rewrite the Request-URI.
------------------------------------------------------------------------
4:ProxyAbuse
--------------
http://wiki.apache.org/httpd/ProxyAbuse
Why do I see requests for foreign sites appearing in my log files?
    An access_log entry showing this situation could look like this:
    63.251.56.142 - - [25/Jul/2002:12:48:04 -0700] "GEThttp://www.yahoo.com/HTTP/1.0" 200 1456
    This is usually the result of malicious clients trying to exploit open proxy servers to access a website without revealing their true location. They could be doing this to manipulate pay-per-click ad systems, to add comment or link-spam to someone else's site, or just to do something nasty without being detected.
    It is important to prevent your server from being used as an open proxy to abuse other sites.
    How can I prevent these requests from accessing the foreign server through my server?
    First, if you don't need to run a proxy server, disable mod_proxy by commenting out its LoadModule line or setting ProxyRequests off in httpd.conf. Remember that disabling ProxyRequests does not prevent you from using a reverse proxy with the ProxyPass directive.
    If you do need to have Apache act as a proxy server, be sure to  secure your server by restricting access with a section in httpd.conf.
    My server is properly configured not to proxy, so why is Apache returning a 200 (Success) status code?
    That status code indicates that Apache successfully sent a response to the client, but not necessarily that the response was retrieved from the foreign website.
    RFC2616 section 5.1.2 mandates that Apache must accept requests with absolute URLs in the request-URI, even for non-proxy requests. This means that even when proxying is turned off, Apache will accept requests that look like proxy requests. But instead of retrieving the content from the foreign site, Apache will serve the content at the corresponding location on your website. Since the hostname probably doesn't match a name for your site, Apache will look for the content on your default host.
    In the above example, sincewww.yahoo.comis obviously not a valid virtual host on your system, Apache will serve the homepage content from your default (virtual) host. The size of the response (1456 in the above example) can be compared to the size of the corresponding page on your default site to confirm that the response was served locally and no proxying was involved.
    But how can I be really sure that I am not allowing the abuse of other sites
    You can try yourself to use your server as a proxy to access other sites and make sure that you get either a failure, or local content from your site. Among the ways to do this:
    1. Configure your browser to use your web server as its default proxy server and then try to request foreign sites. You should get only your own website content back in reply.
    2. Manually construct requests using telnet:
    telnet yoursite.example.com 80
    GEThttp://www.yahoo.com/HTTP/1.1
    Host:www.yahoo.com
    Then press enter twice. If your server is properly configured, you should receive content from your own site and not Yahoo.
    What about these strange CONNECT requests?
    A variant of this problem is an access_log entry that looks like
    63.251.56.142 - - [25/Jul/2002:12:48:04 -0700] "CONNECT smtp.example.com:25 HTTP/1.0" 200 1456
    The CONNECT method is usually used to tunnel SSL requests through proxies. But in this case, the port 25 on the target shows us that someone is attempting to use our HTTP proxy to send mail (probably spam) to a foreign site.
    Everything mentioned above applies equally to this case. But normally, as long as the proxy is disabled, Apache would respond to such requests with status code 405 (Method not allowed). The fact that a success status code is returned indicates that a third-party module is processing the CONNECT requests. The most likely culprit is php, which in its default configuration will accept all methods and treat them identically.
    This isn't inherently a problem since php will handle the request locally and will not proxy to the foreign host. But it is still a good idea to configure php to accept only specific methods (using the php configuration setting http.allowed_methods) or have your php script. reject requests for non-standard methods.
    I don't like the idea of my server responding to requests for random hostnames, even if it serves local content. How can I deny these requests?
    You can configure Apache to deny access to any host that isn't specifically configured by setting up a default virtual host:
NameVirtualHost *:80

<VirtualHost *:80>
  ServerName default.only
  <Location />
    Order allow,deny
    Deny from all
  </Location>
</VirtualHost>

<VirtualHost *:80>
  ServerName realhost1.example.com
  ServerAlias alias1.example.com alias2.example.com
  DocumentRoot /path/to/site1
</VirtualHost>
   
    See also the CanonicalHostNames recipe.
    Can't I just drop these requests entirely?
    Apache is an HTTP server and responds to HTTP requests with HTTP responses. It does not simply drop requests on the floor, since this would make it difficult to debug problems with client-server interactions.
    If you really want to send no response at all, the third-party module mod_security is able to drop requests. But the savings in resource usage will be minuscule.
    Unfortunately, even if your server is properly configured, you may see this type of exploit attempt recur. Since the offending client is usually itself a compromised computer (or a botnet), there is little that can be done to stop them beyond assuring that your site does not act as an open proxy.
    last edited 2008-01-20 21:39:04 by ChrisPepper