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

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

摘要：???????? 最近巡检网站时，发现有大量的异常链接，如“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

万万当心！不启用代理功能网站也有可

热点推荐