Force Apache to only Respond to Known V-Hosts

Configuring Apache to only respond to known v-host entities is an good way to prevent certain virtual host probing that could, in some cases, be an open door for privacy issues. E.g. Perhaps you have multiple network interfaces configured (Multiple WAN IP addresses that hosts different websites), and you do not want to reveal that the websites are hosted on the same server.

Or, maybe you are simply a perfectionist that value concise configurations with little room for ambiguity. Obviously, a web server should not be responding to HTTP requests for unknown hosts. Some administrators may be of the opinion that it should, if nothing else to tell users that the requested host is unknown. E.g. throw them a 400 error explaining what happened. That's no problem. You can do that by serving up a "void" directory and even have your own professional design on your error pages.

I highly recommend an IP-based virtual host configuration for the sake of conciseness. This means, no room for ambiguous configurations like *:80 and _default_:80 – this is an advantage if you later decide to connect another WAN IP address to your server.

Now, Apache, when first installed in Ubuntu, has a nasty default configuration that will serve up the first loaded v-host configuration, even for unknown host names that are obviously not handled by your server. This, is, in my opinion a serious design-flaw, but probably done on purpose for some technical reason.

It gets even more confusing for HTTPS; if a configuration does not exist for a given website, the same thing will happen for HTTPS! Typically it will result in a certificate error and a wrong site being served if the user ignores the invalid certificate – but this will not necessarily happen! E.g. If you are using Cloudflare, you could actually have a situation where non-configured HTTPS will instead serve up a different website (virtual host) than what a client requested – and with a valid certificate!!

This is so stupid. And dangerous! Someoe should fix this horrible mess!

Having said that, let me give you the best solution I found to this problem.

<VirtualHost 127.0.1.1:80>
    DocumentRoot "/var/www/void"

    <Location />
        Require all granted
        Options None
    </Location>
</VirtualHost>

<IfModule mod_ssl.c>
  <VirtualHost 127.0.1.1:443>
    DocumentRoot "/var/www/void"
    ServerName catch-all
    <Location />
        Require all granted
        Options None
        ErrorDocument 403 Forbidden.
    </Location>
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
  </VirtualHost>
</IfModule>

SSLCertificateFile  /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

Avoid wildcard (*) in your 000-default.conf

Many examples you find on the internet will either use the domain name, or wildcards (*) in their VirtualHost blocks, but this will not work with a default VHOST.

The problem is that when you have a default configuration, such as a 000-default.conf file that uses the following;

<VirtualHost *:80>
# ...

It appears to "override" all other VirtualHost blocks. That is a problem, because we only want it to apply when the name request header does not match any of the VHOSTs that we defined in other VHOST files. This problem has often happened to me on fresh installs of ubuntu+apache.

To solve the problem, we should instead specify the local IP address of the server; to determine what the local IP address is, we can use the following command:

ip addr show

Result:

ink/ether 0a:12:f5:df:1b:26 brd ff:ff:ff:ff:ff:ff
    inet 172.31.1.1/20 brd 172.31.15.255 scope global dynamic eth0
       valid_lft 3110sec preferred_lft 3110sec
    inet 172.31.15.25/20 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet6 fe30::815:f2ff:fedd:1b26/64 scope link 
       valid_lft forever preferred_lft forever

The local IP address is one of theinet addresses. I.e. 172.31.15.25; we can use this in our 000-default.conf file:

<VirtualHost 172.31.1.1:80>
# ...

If your server got multiple WAN IP addresses (and thereby multiple network interfaces), and you want the default configuration to apply for all of them, simply include them, separated by space:

<VirtualHost 172.31.15.25:80 172.31.1.1:80>
# ...

Wildcards can be unpredictable, so I recommend using IP-based virtual hosting — and by "IP-based" is really just meant that you should configure the VHOSTs to listen on a specific network interface. Unless you got multiple WAN IPs configured, there is probably only one interface. What's weird is, perhaps dependent on the hosting infrastructure, sometimes you might need to use the actual WAN IP in the VirtualHost block rather than the internal LAN IP of the interface – I had that happen on Hetzner, and that's while on AWS EC2 I had to use the LAN IP.

Also, Apache's official documentation mentions you have to use one IP per host, but that's not true; even when using IP-based hosting, you can in fact have multiple hosts on same IP. Or, perhaps, this setup is more of a hybrid of IP-based and name-based, since we use both? Regardless, it can work just fine.

Picking a default Virtual Host

Apache's way of defining a default VHOST is horrible; I would much prefer a way to explicitly define a default host, or simply have Apache reject the HTTP request while returning a 403 forbidden or 400 Bad Request.

I have even had cases where I did actually have a VirtualHost block that matched the requested host, but the request would still be passed on to the "default host", and I would be fumbling in the dark as to why Apache was serving up the wrong website.

In my case, it turned out I had more than one VHOST configuration file that contained the same ServerName value. This apparently causes Apache to instead serve up the default host for both domains.

When you got domains that share the same directory—probably because they are handled by the same code base—then this problem tends to become less apparent. If one domain uses a different DirectoryIndex, then you might notice that the same index file is being used to handle requests for all of the domains.

Safely adding new Virtual Hosts

Another thing you need to be aware of is when adding a new domain (Virtual Host) to your Apache server. It is tempting to simply copy one of the existing files and replace the relevant directives; the problem with doing this, however, is that you often overlook something, and then you might not only end up with a VHOST that is incorrectly configured, you might also break the VHOST that you based your new configuration on.

For example, I have myself, quite a few times, made the above mistake, even thinking I had memorized everything I needed to replace, only to find out I forgot to change the ServerName directive, resulting in all kinds of strange behaviour.

Instead, you could create a VHOST template file, and then copy this whenever you need to setup a new domain name.

Then you might ask, who is manually setting up new domain names anyway? Hosting companies will handle this automatically, no doubt? Probably they will. They probably should. I still have not automated it, and I do not think I will do that for my own personal use. I rarely need to add new domains, and when I do, it is usually because I want to create a local domain on my laptop to test my code.

Tell us what you think: