Onderwerp: Apache 1.3.27 mod_proxy security issue

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.

Jason

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

# <Directory proxy:*>
# Order deny,allow
# Deny from all
# Allow from .your-domain.com
# </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 a-domain.com another-domain.edu joes.garage-sale.com

#</IfModule>
# 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...#proxyrequests

"This allows or prevents Apache from functioning as a proxy server.
Setting ProxyRequests to 'off' does not disable use of the <http://httpd.apache.org/docs/mod/mod...html#proxypass>ProxyPass
directive."

"Warning: Do not enable proxying until you have <http://httpd.apache.org/docs/mod/mod_proxy.html#access>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

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

# <Directory proxy:*>
# Order deny,allow
# Deny from all
# Allow from .your-domain.com
# </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 a-domain.com another-domain.edu joes.garage-sale.com

#</IfModule>
# 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...#proxyrequests

"This allows or prevents Apache from functioning as a proxy server.
Setting ProxyRequests to 'off' does not disable use of the <http://httpd.apache.org/docs/mod/mod...html#proxypass>ProxyPass
directive."

"Warning: Do not enable proxying until you have <http://httpd.apache.org/docs/mod/mod_proxy.html#access>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

--aM3YZ0Iwxop3KEKx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Jul 22, 2003 at 05:30:39PM -0500, William A. Rowe, Jr. wrote:
> As described in the default configuration, open proxies are never
> recommended [from Apache 1.3.27 conf/httpd.conf-dist];

[skip]

> # Allow from .your-domain.com

Is it reasonable to use something intentionally broken like
..your_domain.com (not even example.*) in configuration samples
like this one?

--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/

--aM3YZ0Iwxop3KEKx
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/Jj/AbsPDprYMm3IRAjJXAJsEA2oC6s6Knqxi7VXWgfU04keR8gCeK xoZ
UMx/5e3yj9YkXkz388vQKJA=
=CMPn
-----END PGP SIGNATURE-----

--aM3YZ0Iwxop3KEKx--

--aM3YZ0Iwxop3KEKx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Jul 22, 2003 at 05:30:39PM -0500, William A. Rowe, Jr. wrote:
> As described in the default configuration, open proxies are never
> recommended [from Apache 1.3.27 conf/httpd.conf-dist];

[skip]

> # Allow from .your-domain.com

Is it reasonable to use something intentionally broken like
..your_domain.com (not even example.*) in configuration samples
like this one?

--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/

--aM3YZ0Iwxop3KEKx
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/Jj/AbsPDprYMm3IRAjJXAJsEA2oC6s6Knqxi7VXWgfU04keR8gCeK xoZ
UMx/5e3yj9YkXkz388vQKJA=
=CMPn
-----END PGP SIGNATURE-----

--aM3YZ0Iwxop3KEKx--

At 04:34 AM 7/29/2003, Michael Shigorin wrote:
>On Tue, Jul 22, 2003 at 05:30:39PM -0500, William A. Rowe, Jr. wrote:
>> As described in the default configuration, open proxies are never
>> recommended [from Apache 1.3.27 conf/httpd.conf-dist];
>
>[skip]
>
>> # Allow from .your-domain.com
>
>Is it reasonable to use something intentionally broken like
>.your_domain.com (not even example.*) in configuration samples
>like this one?

No, it's not. We recently attempted to standardize the occurrences
of 'invalid' domain names to the accepted 'example.*' faux domains.
The stock configurations in the next releases of Apache Web Server
have corrected the few that were missed, including the example above.

On the other side of this issue, it's not unreasonable to use a class
of addresses that doesn't exist, for the purposes of prohibiting all
access until the user takes the time to properly update their conf,
IMHO.

At 12:31 PM 7/23/2003, Greg A. Woods wrote:

>I don't know how clients are matched against domains in ACL statements
>such as the above in Apache, but I will note that it is NEVER safe to
>rely on the Reverse DNS alone to implement ACLs that affect the ability
>of a random remote client system.

On this point, too, it would be valuable to provide an example subnet as
a preferable alternative to reverse DNS queries. That change has not been
made yet - but is referred to our documentation project.

Bill

At 04:34 AM 7/29/2003, Michael Shigorin wrote:
>On Tue, Jul 22, 2003 at 05:30:39PM -0500, William A. Rowe, Jr. wrote:
>> As described in the default configuration, open proxies are never
>> recommended [from Apache 1.3.27 conf/httpd.conf-dist];
>
>[skip]
>
>> # Allow from .your-domain.com
>
>Is it reasonable to use something intentionally broken like
>.your_domain.com (not even example.*) in configuration samples
>like this one?

No, it's not. We recently attempted to standardize the occurrences
of 'invalid' domain names to the accepted 'example.*' faux domains.
The stock configurations in the next releases of Apache Web Server
have corrected the few that were missed, including the example above.

On the other side of this issue, it's not unreasonable to use a class
of addresses that doesn't exist, for the purposes of prohibiting all
access until the user takes the time to properly update their conf,
IMHO.

At 12:31 PM 7/23/2003, Greg A. Woods wrote:

>I don't know how clients are matched against domains in ACL statements
>such as the above in Apache, but I will note that it is NEVER safe to
>rely on the Reverse DNS alone to implement ACLs that affect the ability
>of a random remote client system.

On this point, too, it would be valuable to provide an example subnet as
a preferable alternative to reverse DNS queries. That change has not been
made yet - but is referred to our documentation project.

Bill

On Tue, 29 Jul 2003, William A. Rowe, Jr. wrote:
> At 12:31 PM 7/23/2003, Greg A. Woods wrote:
>
> >I don't know how clients are matched against domains in ACL statements
> >such as the above in Apache, but I will note that it is NEVER safe to
> >rely on the Reverse DNS alone to implement ACLs that affect the ability
> >of a random remote client system.
>
> On this point, too, it would be valuable to provide an example subnet as
> a preferable alternative to reverse DNS queries. That change has not been
> made yet - but is referred to our documentation project.

Apache does double-reverse lookups to assure that nothing too funky is
going on, so using dns names is relatively safe. It is still better to
use an IP subnet for performance reasons, but the hostname may be easier
to understand as an example.

Joshua.

On Tue, 29 Jul 2003, William A. Rowe, Jr. wrote:
> At 12:31 PM 7/23/2003, Greg A. Woods wrote:
>
> >I don't know how clients are matched against domains in ACL statements
> >such as the above in Apache, but I will note that it is NEVER safe to
> >rely on the Reverse DNS alone to implement ACLs that affect the ability
> >of a random remote client system.
>
> On this point, too, it would be valuable to provide an example subnet as
> a preferable alternative to reverse DNS queries. That change has not been
> made yet - but is referred to our documentation project.

Apache does double-reverse lookups to assure that nothing too funky is
going on, so using dns names is relatively safe. It is still better to
use an IP subnet for performance reasons, but the hostname may be easier
to understand as an example.

Joshua.