When configuring name-based virtual hosting in Apache, many administrators face uncertainty about what to do with the default site configurations (default and default-ssl). These files serve as fallback configurations that handle requests not matching any defined virtual hosts.

The default configuration points to /var/www, which creates potential security implications:

<VirtualHost *:80>
    ServerName _
    DocumentRoot /var/www
    # Other default directives...
</VirtualHost>

Without proper handling, this allows:

• Direct IP access to server contents
• Potential directory listing exposure
• Information disclosure if vhost directories are under /var/www

Here are three professional approaches with implementation examples:

1. Disable Default Site Completely

sudo a2dissite 000-default
sudo a2dissite default-ssl
sudo systemctl restart apache2

2. Create a Custom Default Site

<VirtualHost *:80>
    ServerName _
    DocumentRoot /var/www/default
    ErrorDocument 403 "Access denied"
    <Directory "/var/www/default">
        Require all denied
    </Directory>
</VirtualHost>

3. Redirect to Primary Domain

<VirtualHost *:80>
    ServerName _
    Redirect permanent / https://yourprimarydomain.com/
</VirtualHost>

When implementing name-based virtual hosting:

• Always create separate DocumentRoot directories for each vhost
• Set proper directory permissions (typically 755 for dirs, 644 for files)
• Consider implementing a default SSL site that rejects non-SNI clients

For a server hosting example.com and test.com:

# Disable default site
sudo a2dissite 000-default

# Create custom default site
sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/000-custom.conf
# Edit the file as shown in approach #2 above
sudo a2ensite 000-custom

# Configure virtual hosts
sudo nano /etc/apache2/sites-available/example.com.conf
sudo nano /etc/apache2/sites-available/test.com.conf

sudo a2ensite example.com
sudo a2ensite test.com
sudo systemctl restart apache2

Remember to create appropriate directory structures and set correct permissions for each virtual host.

---

When setting up name-based virtual hosting in Apache, the default configuration files (default and default-ssl in /etc/apache2/sites-available/) serve as fallback options. These configurations handle requests that don't match any defined virtual hosts or come via direct IP access.

Leaving the default configuration active presents potential security risks:

# Default configuration typically looks like:
<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

This means any direct IP access exposes your default web root. If you're hosting multiple sites in subdirectories under /var/www/, this could unintentionally expose directory structures.

Option 1: Disable Default Site

The simplest approach is to disable the default site:

sudo a2dissite default
sudo systemctl restart apache2

Option 2: Customize Default Configuration

For servers that need to handle direct IP access:

# Modify /etc/apache2/sites-available/000-default.conf
<VirtualHost *:80>
    ServerName _
    DocumentRoot /var/www/empty-directory
    <Directory /var/www/empty-directory>
        Require all denied
    </Directory>
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Option 3: Redirect to Primary Domain

For production environments with a primary domain:

# Redirect all IP access to primary domain
<VirtualHost *:80>
    ServerName server.ip.address
    Redirect permanent / https://yourprimarydomain.com/
</VirtualHost>

The same principles apply to the default SSL configuration:

sudo a2dissite default-ssl
# Or customize it similarly to the HTTP configuration

Always verify your changes:

sudo apache2ctl configtest
sudo systemctl reload apache2

Test using curl to simulate direct IP access:

curl -I http://your-server-ip

For maximum security in production:

• Completely disable default configurations if not needed
• Implement proper directory permissions
• Consider adding firewall rules to restrict direct IP access
• Monitor access logs for unexpected IP access attempts