go to  ForumEasy.com   
JavaPro
Home » Archive » Message


[Email To Friend][View in Live Context][prev topic « prev post | next post » next topic]
  Httpd's default virtual host -- Should it be considered as a design bug?
 
Subject: Httpd's default virtual host -- Should it be considered as a design bug?
Author: AwsEC2
In response to: How to prevent someone others from pointing their domains to your EC2 instance
Posted on: 09/17/2012 07:32:31 PM

With Apache httpd.conf, you may have the following configuration for the 'main' server:

#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/home/ec2-user/public_html"

<Directory "/home/ec2-user/public_html">
    Options Indexes FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>


The request with htpp://www.example.com/ will return the contect from /home/ec2-user/public_html/index.html as expected. But if you starts to add virtual hosts to your server like the following:

#
# Use name-based virtual hosting.
#
NameVirtualHost *:80

<VirtualHost *:80>
  ServerName example1.com
  ServerAlias www.example1.com
  DocumentRoot /home/ec2-user/example1.com/html
  SuexecUserGroup ec2-user ec2-user
  CustomLog "/home/ec2-user/example1.com/access_log" "combined"
  ErrorLog "/home/ec2-user/example1.com/error_log"
  <Directory /home/ec2-user/example1.com/html>
    Options Indexes Includes FollowSymLinks
    AllowOverride All
  </Directory>  
</VirtualHost>

<VirtualHost *:80>
  ServerName example2.com
  ServerAlias www.example2.com
  DocumentRoot /home/ec2-user/example2.com/html
  SuexecUserGroup ec2-user ec2-user
  CustomLog "/home/ec2-user/example2.com/access_log" "combined"
  ErrorLog "/home/ec2-user/example2.com/error_log"
  <Directory /home/ec2-user/example2.com/html>
    Options Indexes Includes FollowSymLinks
    AllowOverride All
  </Directory>
</VirtualHost>


The request with htpp://www.example.com/ will return the content from /home/ec2-user/example1.com/index.html rather than /home/ec2-user/public_html/index.html.

More annoying is that any un-matched domain name will default to the first VirtualHost in the list. For example, if anyone points their bogus domain names to your server's ipAddress by mistake, all request to the bogus server would rush to your server by following the ipAddress and get the content from /home/ec2-user/example1.com/. Ouches! Let's take a look at the SPEC:

"If no matching virtual host is found, then the first listed virtual host that matches the IP address will be used.

As a consequence, the first listed virtual host is the default virtual host. The DocumentRoot from the main server will never be used when an IP address matches the NameVirtualHost directive. If you would like to have a special configuration for requests that do not match any particular virtual host, simply put that configuration in a container and list it first in the configuration file."

That's stink! Should it be considered as a design bug?


 

> On 09/17/2012 01:45:31 PM AwsEC2 wrote:

Technically, you can not do anything prevent this kind of things happening, just like you can not forbid anyone naming their dog after yours. DNS routing table is in their controls. The only thing you can do is to control what you can control -- more or less refusing the traffic.

For web traffic, you can set up one or more virtual hosts for your own domains and a default entry catching everything else. If someone ends up on your server through a misconfigured domain, you can hand back with an error message or an redirect to your default page.

If you have a security concern about middle-man hi-jacking your traffic, you can set up one more defense barrier at application level by checking domain name before serving any sensible requests.





References:

 


 
Powered by ForumEasy © 2002-2022, All Rights Reserved. | Privacy Policy | Terms of Use
 
Get your own forum today. It's easy and free.