Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 74341 invoked from network); 28 Aug 2003 18:37:24 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 28 Aug 2003 18:37:24 -0000 Received: (qmail 66537 invoked by uid 500); 28 Aug 2003 18:23:08 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 66345 invoked by uid 500); 28 Aug 2003 18:23:05 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 66241 invoked from network); 28 Aug 2003 18:23:03 -0000 Received: from unknown (HELO tonnant.cnchost.com) (207.155.248.72) by daedalus.apache.org with SMTP; 28 Aug 2003 18:23:03 -0000 Received: from RCSV650.rowe-clan.net (www1.rowe-clan.net [208.176.192.146]) by tonnant.cnchost.com id OAA16233; Thu, 28 Aug 2003 14:22:50 -0400 (EDT) [ConcentricHost SMTP Relay 1.15] Errors-To: Message-Id: <5.2.0.9.2.20030828120747.0372fb08@pop3.rowe-clan.net> X-Sender: wrowe%rowe-clan.net@pop3.rowe-clan.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 28 Aug 2003 13:22:33 -0500 To: dev@httpd.apache.org From: "William A. Rowe, Jr." Subject: Re: Spam Using SMTP "Over" HTTP-Proxy Cc: Eli Marmor , dev@httpd.apache.org, apache-modules@covalent.net In-Reply-To: References: <3F4DA577.CCA9CCF1@netmask.it> <3F4DA577.CCA9CCF1@netmask.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N The issue that the reporter, Jason Robertson, suggested to partially solve this proble is that we should add another AllowConnect directive, such as AllowHttpProxy, to restrict the ports that you can use to proxy HTTP traffic. We already have this restriction available for CONNECT (usually https) traffic. The point to this is actually a good one. When you consider that one way to exploit the proxy issue is to hijack one or more machines to chain the traffic, and thereby bypass other security restricting the machines allowed to connect to the proxy. Also consider that major ISPs allow proxy traffic from their entire local subnet. The request for this feature is not unreasonable, but it also should not be considered an end-all to the issue [more inline]; >> If you look at how restrictive the default AllowConnect directive is, then >> it isn't unreasonable to consider the reporter's orginal suggestion for some >> AllowProxy directive as well. Your suggestion would eliminate port 25, >> if it behaves as we expect, but that doesn't solve the problem for other ports. > >I thought about this, and the idea of an Allow(Forward)Proxy directive >isn't bad, but I don't think I would want it in the default config. We >would be encouraging a policy where a proxy administrator would say "http >is only allowed on ports 80 and 8080". And I think most of us agree that >is silly and doesn't do much to help security. Then why, exactly, is our default setting for AllowConnect so restrictive? I think it's entirely appropriate to limit http proxy 'by default' to 80/8080 and allow the user to expand on that list. No great hardships here. Yes it would help with traffic control. No, it would not prevent folks from exploiting bad 'send email' cgi scripts that are advertised on 80 or 8080. One point. We should *never* deploy a directive that handles proxy GET differently from proxy POST differently. Such a distinction would violate the RFC with unexpected side effects. So it's limit-by-port or limit-by-origin name or IP address. If the user wants to abuse the LIMIT directive in some other, interesting ways - that should be an exercise left to the reader :-) At 02:13 AM 8/28/2003, Cliff Woolley wrote: >On Thu, 28 Aug 2003, Eli Marmor wrote: > >> According to research companies, most of the current spamming is done >> using HTTP proxies. Spammers assistant scripts scan the net 24 hours a >> day, looking for open proxies, and then use them to spread the spam. > >Correct. And people continue to submit this to security@apache.org as a >bug on a fairly regular basis, even though it is due to a misconfiguration >on their part. And yes - in 95% of the cases this was their failure: >All you have to do is configure mod_proxy correctly, which lots of sites >do not. In particular, setting "ProxyRequests on" without proper access >controls will create the kind of bad situation that leads to this problem. >Most of the time what has happened is that the site admin really only >wanted to provide a REVERSE proxy (as with ProxyPass), not a forward one. >"ProxyRequests on" is not required for ProxyPass to work. All of this is 100% correct, but not the end of the entire issue. >Someone suggested adding a directive to control which ports the proxy will >connect to (note there's already a directive that controls this for >CONNECT requests), but since open HTTP proxies are bad for the internet in >general (in the anonymous-HTTP-to-third-parties sense as well as the >backdoor-to-your-SMTP-server sense), it didn't seem worth it to block >_some_ of the bad behavior when fixed configurations would easily block >ALL of it -- using already existing directives. And again - we should document, if we add AllowHttpProxy to list the ports the user wants to restrict proxy traffic to, we should *highlight* that this will not prevent their server from being used to proxy web-spam to badly written CGI scripts. It doesn't invalidate the usefulness of the directive. At 08:19 AM 8/28/2003, Joshua Slive wrote: >ProxyBlock :25 >would probably do it. But I still haven't tested this, since I don't use >the proxy myself. > >But as Cliff said, "ProxyRequests Off" is the real fix. I spent a few >hours doing a substantial rewrite of the proxy documentation to try to >clarify this issue (not with respect to SMTP, but with respect to open >proxies in general). It is not *the* real fix, it is one of several fixes. The docs improvements are terrific, thank you Joshua!!! But there are justifications for a new directive in conjunction with properly controlling access to the proxy. Here is my original bugtraq response to Jason's comments; To: "Jason Robertson" Subject: Re: Apache 1.3.27 mod_proxy security issue Cc: bugtraq@securityfocus.com, security@apache.org The Security Team responded 13 minutes after Jason's initial report, attempting to explain how he had misconfigured his server. While we acknowledge that new directives might be desirable in limited cases, the team determined that this is clearly a user configuration error. The Apache HTTP Server Documentation Project has been working to improve and further clarify the risks of open proxies, including open faux-HTTP proxies into SMTP servers. They actively solicit contributions to the documentation (preferably with a patch) for any ambiguous or insufficiently covered topics; http://httpd.apache.org/docs-project/ More details follow; At 11:52 AM 7/22/2003, Jason Robertson wrote: >I have found that recently a spammer has been using a mod_proxy >configuration, (that was meant to allow for an easier transition to a >new naming scheme, as well as changes to a backend software) as a spam >relay. >The spammer has been using HTTP POST requests to send these messages >with POST HTTP://mailserver:25/ HTTP/1.1 >With some research it looks like this is an automated process including >the initial scan stage. > >When I contacted Apache in regards to this, the response was not very >promising. > >This problem would be a simple fix with implementing the AllowConnect >configuration option within proxy_http, to prevent outbound >connections. As described in the default configuration, open proxies are never recommended [from Apache 1.3.27 conf/httpd.conf-dist]; # # Proxy Server directives. Uncomment the following lines to # enable the proxy server: # # # ProxyRequests On # # Order deny,allow # Deny from all # Allow from .your-domain.com # # # Enable/disable the handling of HTTP/1.1 "Via:" headers. # ("Full" adds the server version; "Block" removes all outgoing Via: headers) # Set to one of: Off | On | Full | Block # # ProxyVia On # # To enable the cache as well, edit and uncomment the following lines: # (no cacheing without CacheRoot) # # CacheRoot "@@ServerRoot@@/proxy" # CacheSize 5 # CacheGcInterval 4 # CacheMaxExpire 24 # CacheLastModifiedFactor 0.1 # CacheDefaultExpire 1 # NoCache a-domain.com another-domain.edu joes.garage-sale.com # # End of proxy directives. If (for the purposes of collecting several machine's collective content) you are attempting to ProxyPass a number of URI's to different boxes, you should NOT be enabling ProxyRequests. The final statements in the ProxyRequests directive documentation are; http://httpd.apache.org/docs/mod/mod_proxy.html#proxyrequests "This allows or prevents Apache from functioning as a proxy server. Setting ProxyRequests to 'off' does not disable use of the ProxyPass directive." "Warning: Do not enable proxying until you have secured your server. Open proxy servers are dangerous both to your network and to the Internet at large." Access control is briefly illustrated further with additional references in; http://httpd.apache.org/docs/mod/mod_proxy.html#access Bill