httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Spam Using SMTP "Over" HTTP-Proxy
Date Thu, 28 Aug 2003 18:22:33 GMT
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 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

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;

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 
>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 
>This problem would be a simple fix with implementing the AllowConnect 
>configuration option within proxy_http, to prevent outbound 

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:
#<IfModule mod_proxy.c>
#    ProxyRequests On

#    <Directory proxy:*>
#        Order deny,allow
#        Deny from all
#        Allow from
#    </Directory>

    # 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

# 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;

  "This allows or prevents Apache from functioning as a proxy server. 
   Setting ProxyRequests to 'off' does not disable use of the <>ProxyPass


  "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;


View raw message