From d5db0117f213f31c19bee8e78bb373ffe708abb8 Mon Sep 17 00:00:00 2001
From: Rich Bowen
# This is a misconfiguration example, do not use on your server
- <VirtualHost www.abc.dom>
- ServerAdmin webgirl@abc.dom
- DocumentRoot /www/abc
+ <VirtualHost www.example.dom>
+ ServerAdmin webgirl@example.dom
+ DocumentRoot /www/example
</VirtualHost>
ServerName
and at least one
IP address that the server will bind and respond to. The above
example does not include the IP address, so httpd must use DNS
- to find the address of www.abc.dom
. If for some
+ to find the address of www.example.dom
. If for some
reason DNS is not available at the time your server is parsing
its config file, then this virtual host will not be
configured. It won't be able to respond to any hits
- to this virtual host (prior to httpd version 1.2 the server
- would not even boot).
+ to this virtual host.
- Suppose that www.abc.dom
has address 192.0.2.1.
+
Suppose that www.example.dom
has address 192.0.2.1.
Then consider this configuration snippet:
# This is a misconfiguration example, do not use on your server
<VirtualHost 192.0.2.1>
- ServerAdmin webgirl@abc.dom
- DocumentRoot /www/abc
+ ServerAdmin webgirl@example.dom
+ DocumentRoot /www/example
</VirtualHost>
Here is a snippet that avoids both of these problems:
<VirtualHost 192.0.2.1>
- ServerName www.abc.dom
- ServerAdmin webgirl@abc.dom
- DocumentRoot /www/abc
+ ServerName www.example.dom
+ ServerAdmin webgirl@example.dom
+ DocumentRoot /www/example
</VirtualHost>
There are (at least) two forms that denial of service
- can come in. If you are running a version of httpd prior to
- version 1.2 then your server will not even boot if one of the
- two DNS lookups mentioned above fails for any of your virtual
- hosts. In some cases this DNS lookup may not even be under your
- control; for example, if abc.dom
is one of your
- customers and they control their own DNS, they can force your
- (pre-1.2) server to fail while booting simply by deleting the
- www.abc.dom
record.
Another form is far more insidious. Consider this - configuration snippet:
+Consider this configuration snippet:
- <VirtualHost www.abc.dom>
+ <VirtualHost www.example1.dom>
- ServerAdmin webgirl@abc.dom
- DocumentRoot /www/abc
+ ServerAdmin webgirl@example1.dom
+ DocumentRoot /www/example1
</VirtualHost>
- <VirtualHost www.def.dom>
+ <VirtualHost www.example2.dom>
- ServerAdmin webguy@def.dom
- DocumentRoot /www/def
+ ServerAdmin webguy@example2.dom
+ DocumentRoot /www/example2
</VirtualHost>
Suppose that you've assigned 192.0.2.1 to
- www.abc.dom
and 192.0.2.2 to
- www.def.dom
. Furthermore, suppose that
- def.dom
has control of their own DNS. With this
- config you have put def.dom
into a position where
- they can steal all traffic destined to abc.dom
. To
- do so, all they have to do is set www.def.dom
to
+ www.example1.dom
and 192.0.2.2 to
+ www.example2.dom
. Furthermore, suppose that
+ example2.dom
has control of their own DNS. With this
+ config you have put example2.dom
into a position where
+ they can steal all traffic destined to example1.dom
. To
+ do so, all they have to do is set www.example2.dom
to
192.0.2.1. Since they control their own DNS you can't stop them
- from pointing the www.def.dom
record wherever they
+ from pointing the www.example2.dom
record wherever they
wish.
Requests coming in to 192.0.2.1 (including all those where
users typed in URLs of the form
- http://www.abc.dom/whatever
) will all be served by
- the def.dom
virtual host. To better understand why
+ http://www.example1.dom/whatever
) will all be served by
+ the example2.dom
virtual host. To better understand why
this happens requires a more in-depth discussion of how httpd
matches up incoming requests with the virtual host that will
serve it. A rough document describing this is available.
<VirtualHost _default_:*>
server that has no pages to serveThe situation regarding DNS is highly undesirable. Although - we've attempted to make the server at least continue - booting in the event of failed DNS, it might not be the - best we can do. In any event, requiring the use of explicit IP - addresses in configuration files is highly undesirable in - today's Internet where renumbering is a necessity.
- -A possible work around to the theft of service attack - described above would be to perform a reverse DNS lookup on the - IP address returned by the forward lookup and compare the two - names -- in the event of a mismatch, the virtualhost would be - disabled. This would require reverse DNS to be configured - properly (which is something that most admins are familiar with - because of the common use of "double-reverse" DNS lookups by - FTP servers and TCP wrappers).
- -In any event, it doesn't seem possible to reliably boot a - virtual-hosted web server when DNS has failed unless IP - addresses are used. Partial solutions such as disabling - portions of the configuration might be worse than not booting - at all depending on what the webserver is supposed to - accomplish.
- -As HTTP/1.1 is deployed and browsers and proxies start
- issuing the Host
header it will become possible to
- avoid the use of IP-based virtual hosts entirely. In this case,
- a webserver has no requirement to do DNS lookups during
- configuration. But as of March 1997 these features have not
- been deployed widely enough to be put into use on critical
- webservers.
Available Languages: en | diff --git a/docs/manual/dns-caveats.xml b/docs/manual/dns-caveats.xml index 56d8d02319..69357d390b 100644 --- a/docs/manual/dns-caveats.xml +++ b/docs/manual/dns-caveats.xml @@ -29,9 +29,9 @@ configure Apache HTTP Server in such a way that it relies on DNS resolution for parsing of the configuration files. If httpd requires DNS resolution to parse the configuration files then your server - may be subject to reliability problems (ie. it might not boot), - or denial and theft of service attacks (including users able - to steal hits from other users).
+ may be subject to reliability problems (ie. it might not start up), + or denial and theft of service attacks (including virtual hosts able + to steal hits from other virtual hosts).www.abc.dom
. If for some
+ to find the address of www.example.dom
. If for some
reason DNS is not available at the time your server is parsing
its config file, then this virtual host will not be
configured. It won't be able to respond to any hits
- to this virtual host (prior to httpd version 1.2 the server
- would not even boot).
+ to this virtual host.
- Suppose that www.abc.dom
has address 192.0.2.1.
+
Suppose that www.example.dom
has address 192.0.2.1.
Then consider this configuration snippet:
Here is a snippet that avoids both of these problems:
There are (at least) two forms that denial of service
- can come in. If you are running a version of httpd prior to
- version 1.2 then your server will not even boot if one of the
- two DNS lookups mentioned above fails for any of your virtual
- hosts. In some cases this DNS lookup may not even be under your
- control; for example, if abc.dom
is one of your
- customers and they control their own DNS, they can force your
- (pre-1.2) server to fail while booting simply by deleting the
- www.abc.dom
record.
Another form is far more insidious. Consider this - configuration snippet:
+Consider this configuration snippet:
Suppose that you've assigned 192.0.2.1 to
- www.abc.dom
and 192.0.2.2 to
- www.def.dom
. Furthermore, suppose that
- def.dom
has control of their own DNS. With this
- config you have put def.dom
into a position where
- they can steal all traffic destined to abc.dom
. To
- do so, all they have to do is set www.def.dom
to
+ www.example1.dom
and 192.0.2.2 to
+ www.example2.dom
. Furthermore, suppose that
+ example2.dom
has control of their own DNS. With this
+ config you have put example2.dom
into a position where
+ they can steal all traffic destined to example1.dom
. To
+ do so, all they have to do is set www.example2.dom
to
192.0.2.1. Since they control their own DNS you can't stop them
- from pointing the www.def.dom
record wherever they
+ from pointing the www.example2.dom
record wherever they
wish.
Requests coming in to 192.0.2.1 (including all those where
users typed in URLs of the form
- http://www.abc.dom/whatever
) will all be served by
- the def.dom
virtual host. To better understand why
+ http://www.example1.dom/whatever
) will all be served by
+ the example2.dom
virtual host. To better understand why
this happens requires a more in-depth discussion of how httpd
matches up incoming requests with the virtual host that will
serve it. A rough document describing this
The situation regarding DNS is highly undesirable. Although - we've attempted to make the server at least continue - booting in the event of failed DNS, it might not be the - best we can do. In any event, requiring the use of explicit IP - addresses in configuration files is highly undesirable in - today's Internet where renumbering is a necessity.
- -A possible work around to the theft of service attack - described above would be to perform a reverse DNS lookup on the - IP address returned by the forward lookup and compare the two - names -- in the event of a mismatch, the virtualhost would be - disabled. This would require reverse DNS to be configured - properly (which is something that most admins are familiar with - because of the common use of "double-reverse" DNS lookups by - FTP servers and TCP wrappers).
- -In any event, it doesn't seem possible to reliably boot a - virtual-hosted web server when DNS has failed unless IP - addresses are used. Partial solutions such as disabling - portions of the configuration might be worse than not booting - at all depending on what the webserver is supposed to - accomplish.
- -As HTTP/1.1 is deployed and browsers and proxies start
- issuing the Host
header it will become possible to
- avoid the use of IP-based virtual hosts entirely. In this case,
- a webserver has no requirement to do DNS lookups during
- configuration. But as of March 1997 these features have not
- been deployed widely enough to be put into use on critical
- webservers.