摘要： 最近巡檢網站時，發現有大量的異常鏈接，如“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