千万当心！不启用代理功能，网站也有可能被恶意用作垃圾邮件发送服务器
yanghan 2012-02-02
摘要： 最近巡检网站时，发现有大量的异常链接，如“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.nethttp://hhrz.org中均存在）
#/bin/netstat-a|greptcp|sort+6
tcp0912hhrz.org:80125.224.196.186:1087LAST_ACK
tcp0912hhrz.org:80125.224.196.186:1117LAST_ACK
tcp0912hhrz.org:80125.224.196.186:1270LAST_ACK
tcp0912hhrz.org:80125.224.196.186:2994LAST_ACK
tcp0912hhrz.org:80125.224.196.186:3546LAST_ACK
tcp0912hhrz.org:80205.209.140.102:1198LAST_ACK
tcp0912hhrz.org:80205.209.140.102:1307LAST_ACK
tcp0912hhrz.org:80205.209.140.102:1531LAST_ACK
。。。。。。
tcp0912hhrz.net:80205.209.140.102:4379LAST_ACK
tcp0912hhrz.net:80205.209.140.102:4395LAST_ACK
tcp0912hhrz.net:80205.209.140.102:4472LAST_ACK
tcp0912hhrz.net:8067.215.241.234:1090LAST_ACK
tcp0912hhrz.net:8067.215.241.234:1112LAST_ACK
tcp0912hhrz.net:8067.215.241.234:1302LAST_ACK
。。。。。。
tcp01561chq.name:80125.224.196.186:1118LAST_ACK
tcp01561chq.name:80125.224.196.186:1445LAST_ACK
tcp01561chq.name:80125.224.196.186:1578LAST_ACK
tcp01561chq.name:80125.224.196.186:1680LAST_ACK
tcp01561chq.name:80125.224.196.186:2798LAST_ACK
tcp01561chq.name:80125.224.196.186:3362LAST_ACK
。。。。。。2：网站日志的异常访问记录（在网站http://chq.namehttp://hhrz.nethttp://hhrz.org中均存在）：
#tailaccess_log
205.209.140.102--[03/Aug/2009:04:16:19+0800]"CONNECT140.112.65.3:25HTTP/1.0"2001144"-""-"
205.209.140.102--[03/Aug/2009:04:18:20+0800]"CONNECT211.75.100.49:25HTTP/1.0"2001144"-""-"
......
205.209.140.102--[03/Aug/2009:04:21:59+0800]"CONNECT168.95.6.157:25HTTP/1.0"404723"-""-"
205.209.140.102--[03/Aug/2009:04:21:59+0800]"CONNECT59.124.98.13:25HTTP/1.0"404723"-""-"
67.215.241.234--[03/Aug/2009:18:00:07+0800]"CONNECT203.188.197.10:25HTTP/1.0"403-"-""-"
205.209.140.102--[03/Aug/2009:18:00:07+0800]"CONNECT168.95.5.62:25HTTP/1.0"403-"-""-"
205.209.140.102--[03/Aug/2009:18:00:07+0800]"CONNECT203.133.1.212:25HTTP/1.0"403-"-""-"
......
67.215.241.234--[02/Aug/2009:17:54:39+0800]"CONNECT203.188.197.9:25HTTP/1.0"404723"-""-"
125.224.200.238--[02/Aug/2009:17:54:40+0800]"CONNECT203.188.197.9:25HTTP/1.0"404723"-""-"
125.224.200.238--[02/Aug/2009:17:54:39+0800]"CONNECT209.85.147.27:25HTTP/1.0"404723"-""-"
205.209.140.102--[02/Aug/2009:17:54:40+0800]"CONNECT168.95.5.43:25HTTP/1.0"404723"-""-"
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.nethttp://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>
ServerNamedefault.only
<Location/>
Orderallow,deny
Denyfromall
</Location>
</VirtualHost><VirtualHost *:80>
ServerNamerealhost1.example.com
ServerAliasalias1.example.comalias2.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:luodarouPosted:2003-06-2512:10Length:1,015byte(s)
[Original][Print][Top]
158.252.208.31--[30/May/2003:12:45:08+0800]"CONNECT64.58.76.227:80HTTP/1.0"3020
158.252.208.31--[30/May/2003:12:45:20+0800]"CONNECT64.58.76.227:80HTTP/1.0"3020
158.252.208.31--[30/May/2003:12:45:45+0800]"CONNECT64.58.76.227:80HTTP/1.0"3020
158.252.208.31--[30/May/2003:12:46:13+0800]"CONNECT64.58.76.227:80HTTP/1.0"3020
158.252.208.31--[30/May/2003:12:47:32+0800]"CONNECT64.58.76.227:80HTTP/1.0"3020
158.252.208.31--[30/May/2003:12:49:52+0800]"CONNECT64.58.76.227:80HTTP/1.0"3020
以上是我apache日志中的记录，是不是有人妄图proxy？从记录看他成功了么?
系统是新装的，其它日志分析没有任何入侵迹象，tripwire也没有报告文件系统有任何变化
我的httpd.conf中没有设置proxy。我也没装squid。
我用iptables-AINPUT-ieth0-s158.252.0.0/16-jDROP不能阻止它，还是每天产生这样的记录。
请大侠们救命！指点怎么解决？
--------------------
2：為何我的ApacheLog裡會出現這個訊息?
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"2001362
為何會出現不是我網站所屬的位址呢?這有啥含意呢?
-----
abelyang：我想這是個測試你的apache有沒有用proxy吧再來可能就是寄spam的行為了(OpenProxy)
沒有用到建議拿掉httpd.conf中有關proxy的mod，最後的httpcode為200(OK)
218.154.135.125--[30/May/2004:12:18:21+0800]"GEThttp://www.online.sh.cn/HTTP/1.1"2001362
所以,連到你的 WWW, 要求說要 GET 另一站的資料(這不是 proxy 嗎?) ，最後回傳 200 成功再來,你看看http://httpd.apache.org/docs/mod/mod_proxy.html
有很多說明,建議你自己研讀看看,一定會有很多收獲的
你可以設定好後,再用上面的例子自己測試,只到出現4xx的returncode為止看看,不同ReturnCode:
http://www.cknow.com/ckinfo/def_h/httpreturncodes.shtml
再提供你幾個我的apache上的log供你參考:
有人連我的apache,企圖寄信到別人的MailServer
而不被允許(405),他傳的信size是1070或1049
61.173.41.160--[28/Apr/2004:11:25:17+0800]"CONNECTmaila.microsoft.com:25HTTP/1.0"4051070"-""-"
61.173.41.160--[28/Apr/2004:11:25:17+0800]"CONNECTmaila.microsoft.com:25HTTP/1.0"4051070"-""-"
68.192.66.97--[03/May/2004:06:17:22+0800]"CONNECT64.12.138.89:25HTTP/1.1"4051049"-""-"
68.192.66.97--[03/May/2004:06:17:22+0800]"CONNECT64.12.138.89:25HTTP/1.1"4051049"-""-"
下一個例子同你的狀況,但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"4041133"-""Mozilla/4.0(compatible;MSIE5.5;WindowsNT4.0)"
218.80.146.212--[06/May/2004:01:45:45+0800]"GEThttp://www.ebay.com/HTTP/1.1"4031123"-""Mozilla/4.0(compatible;MSIE5.00;Windows98)"
希望我的解釋看的懂
----
Apache：感謝abelyang學長的指導:lol:
我是有把mod_proxy及相關moudle給comment起來，只是沒想到Apache會在這狀況下的Returncode會是200(OK)，(不知道這算不算是bug?)
小弟剛做了個小測試,就是在IE裡,把Proxy設成我的Web的網址,再連到YahooKimo，在log裡得到如下的記錄:
211.21.137.29--[30/May/2004:16:18:42+0800]"GEThttp://tw.yahoo.com/HTTP/1.0"2001362
211.21.137.29--[30/May/2004:16:18:42+0800]"GEThttp://tw.yahoo.com/apache_pb.gifHTTP/1.0"2002326
211.21.137.29--[30/May/2004:16:18:42+0800]"GEThttp://tw.yahoo.com/poweredby.pngHTTP/1.0"2001154
結果是...在IE裡看到的是我的Web的首頁,而非看到YahooKimo的首頁，也就是說,在無安裝Proxy相關module時,在log發現這種記錄是無害的.
小弟甫接觸Apache,尚在摸索階段,再次感謝abelyang學長的指點,解開那股疑團!
.......
--------------------
3：5.1.2Request-URI
--------------------
http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html
TheRequest-URIisaUniform.ResourceIdentifier(section3.2)andidentifiestheresourceuponwhichtoapplytherequest.
Request-URI="*"|absoluteURI|abs_path|authority
ThefouroptionsforRequest-URIaredependentonthenatureoftherequest.Theasterisk"*"meansthattherequestdoesnotapplytoaparticularresource,buttotheserveritself,andisonlyallowedwhenthemethoduseddoesnotnecessarilyapplytoaresource.Oneexamplewouldbe
OPTIONS*HTTP/1.1
TheabsoluteURIform.isREQUIREDwhentherequestisbeingmadetoaproxy.Theproxyisrequestedtoforwardtherequestorserviceitfromavalidcache,andreturntheresponse.NotethattheproxyMAYforwardtherequestontoanotherproxyordirectlytotheserver
specifiedbytheabsoluteURI.Inordertoavoidrequestloops,aproxyMUSTbeabletorecognizeallofitsservernames,includinganyaliases,localvariations,andthenumericIPaddress.AnexampleRequest-Linewouldbe:
GEThttp://www.w3.org/pub/WWW/TheProject.htmlHTTP/1.1
ToallowfortransitiontoabsoluteURIsinallrequestsinfutureversionsofHTTP,allHTTP/1.1serversMUSTaccepttheabsoluteURIform.inrequests,eventhoughHTTP/1.1clientswillonlygeneratetheminrequeststoproxies.
Theauthorityform.isonlyusedbytheCONNECTmethod(section9.9).
Themostcommonform.ofRequest-URIisthatusedtoidentifyaresourceonanoriginserverorgateway.InthiscasetheabsolutepathoftheURIMUSTbetransmitted(seesection3.2.1,abs_path)astheRequest-URI,andthenetworklocationoftheURI(authority)MUSTbetransmittedinaHostheaderfield.Forexample,aclientwishingtoretrievetheresourceabovedirectlyfromtheoriginserverwouldcreateaTCPconnectiontoport80ofthehost"www.w3.org"andsendthelines:
GET/pub/WWW/TheProject.htmlHTTP/1.1
Host:www.w3.org
followedbytheremainderoftheRequest.Notethattheabsolutepathcannotbeempty;ifnoneispresentintheoriginalURI,itMUSTbegivenas"/"(theserverroot).
TheRequest-URIistransmittedintheformatspecifiedinsection3.2.1.IftheRequest-URIisencodedusingthe"%HEXHEX"encoding[42],theoriginserverMUSTdecodetheRequest-URIinordertoproperlyinterprettherequest.ServersSHOULDrespondtoinvalidRequest-URIswithanappropriatestatuscode.
AtransparentproxyMUSTNOTrewritethe"abs_path"partofthereceivedRequest-URIwhenforwardingittothenextinboundserver,exceptasnotedabovetoreplaceanullabs_pathwith"/".
Note:The"norewrite"rulepreventstheproxyfromchangingthe
meaningoftherequestwhentheoriginserverisimproperlyusing
anon-reservedURIcharacterforareservedpurpose.Implementors
shouldbeawarethatsomepre-HTTP/1.1proxieshavebeenknownto
rewritetheRequest-URI.
------------------------------------------------------------------------
4:ProxyAbuse
--------------
http://wiki.apache.org/httpd/ProxyAbuse
WhydoIseerequestsforforeignsitesappearinginmylogfiles?
Anaccess_logentryshowingthissituationcouldlooklikethis:
63.251.56.142--[25/Jul/2002:12:48:04-0700]"GEThttp://www.yahoo.com/HTTP/1.0"2001456
Thisisusuallytheresultofmaliciousclientstryingtoexploitopenproxyserverstoaccessawebsitewithoutrevealingtheirtruelocation.Theycouldbedoingthistomanipulatepay-per-clickadsystems,toaddcommentorlink-spamtosomeoneelse'ssite,orjusttodosomethingnastywithoutbeingdetected.
Itisimportanttopreventyourserverfrombeingusedasanopenproxytoabuseothersites.
HowcanIpreventtheserequestsfromaccessingtheforeignserverthroughmyserver?
First,ifyoudon'tneedtorunaproxyserver,disablemod_proxybycommentingoutitsLoadModulelineorsettingProxyRequestsoffinhttpd.conf.RememberthatdisablingProxyRequestsdoesnotpreventyoufromusingareverseproxywiththeProxyPassdirective.
IfyoudoneedtohaveApacheactasaproxyserver,besuretosecureyourserverbyrestrictingaccesswithasectioninhttpd.conf.
Myserverisproperlyconfigurednottoproxy,sowhyisApachereturninga200(Success)statuscode?
ThatstatuscodeindicatesthatApachesuccessfullysentaresponsetotheclient,butnotnecessarilythattheresponsewasretrievedfromtheforeignwebsite.
RFC2616section5.1.2mandatesthatApachemustacceptrequestswithabsoluteURLsintherequest-URI,evenfornon-proxyrequests.Thismeansthatevenwhenproxyingisturnedoff,Apachewillacceptrequeststhatlooklikeproxyrequests.Butinsteadofretrievingthecontentfromtheforeignsite,Apachewillservethecontentatthecorrespondinglocationonyourwebsite.Sincethehostnameprobablydoesn'tmatchanameforyoursite,Apachewilllookforthecontentonyourdefaulthost.
Intheaboveexample,sincewww.yahoo.comisobviouslynotavalidvirtualhostonyoursystem,Apachewillservethehomepagecontentfromyourdefault(virtual)host.Thesizeoftheresponse(1456intheaboveexample)canbecomparedtothesizeofthecorrespondingpageonyourdefaultsitetoconfirmthattheresponsewasservedlocallyandnoproxyingwasinvolved.
ButhowcanIbereallysurethatIamnotallowingtheabuseofothersites
Youcantryyourselftouseyourserverasaproxytoaccessothersitesandmakesurethatyougeteitherafailure,orlocalcontentfromyoursite.Amongthewaystodothis:
1.Configureyourbrowsertouseyourwebserverasitsdefaultproxyserverandthentrytorequestforeignsites.Youshouldgetonlyyourownwebsitecontentbackinreply.
2.Manuallyconstructrequestsusingtelnet:
telnetyoursite.example.com80
GEThttp://www.yahoo.com/HTTP/1.1
Host:www.yahoo.com
Thenpressentertwice.Ifyourserverisproperlyconfigured,youshouldreceivecontentfromyourownsiteandnotYahoo.
WhataboutthesestrangeCONNECTrequests?
Avariantofthisproblemisanaccess_logentrythatlookslike
63.251.56.142--[25/Jul/2002:12:48:04-0700]"CONNECTsmtp.example.com:25HTTP/1.0"2001456
TheCONNECTmethodisusuallyusedtotunnelSSLrequeststhroughproxies.Butinthiscase,theport25onthetargetshowsusthatsomeoneisattemptingtouseourHTTPproxytosendmail(probablyspam)toaforeignsite.
Everythingmentionedaboveappliesequallytothiscase.Butnormally,aslongastheproxyisdisabled,Apachewouldrespondtosuchrequestswithstatuscode405(Methodnotallowed).Thefactthatasuccessstatuscodeisreturnedindicatesthatathird-partymoduleisprocessingtheCONNECTrequests.Themostlikelyculpritisphp,whichinitsdefaultconfigurationwillacceptallmethodsandtreatthemidentically.
Thisisn'tinherentlyaproblemsincephpwillhandletherequestlocallyandwillnotproxytotheforeignhost.Butitisstillagoodideatoconfigurephptoacceptonlyspecificmethods(usingthephpconfigurationsettinghttp.allowed_methods)orhaveyourphpscript.rejectrequestsfornon-standardmethods.
Idon'tliketheideaofmyserverrespondingtorequestsforrandomhostnames,evenifitserveslocalcontent.HowcanIdenytheserequests?
YoucanconfigureApachetodenyaccesstoanyhostthatisn'tspecificallyconfiguredbysettingupadefaultvirtualhost:
NameVirtualHost *:80<VirtualHost *:80>
ServerNamedefault.only
<Location/>
Orderallow,deny
Denyfromall
</Location>
</VirtualHost><VirtualHost *:80>
ServerNamerealhost1.example.com
ServerAliasalias1.example.comalias2.example.com
DocumentRoot/path/to/site1
</VirtualHost>
SeealsotheCanonicalHostNamesrecipe.
Can'tIjustdroptheserequestsentirely?
ApacheisanHTTPserverandrespondstoHTTPrequestswithHTTPresponses.Itdoesnotsimplydroprequestsonthefloor,sincethiswouldmakeitdifficulttodebugproblemswithclient-serverinteractions.
Ifyoureallywanttosendnoresponseatall,thethird-partymodulemod_securityisabletodroprequests.Butthesavingsinresourceusagewillbeminuscule.
Unfortunately,evenifyourserverisproperlyconfigured,youmayseethistypeofexploitattemptrecur.Sincetheoffendingclientisusuallyitselfacompromisedcomputer(orabotnet),thereislittlethatcanbedonetostopthembeyondassuringthatyoursitedoesnotactasanopenproxy.
lastedited2008-01-2021:39:04byChrisPepper
