Filter by HTTP(S) request by host

tgurske

Hey,

Short version:
I would like to block certain HTTP(S) requests by the destination hostname. What's the best rule type or plugin to use?

Long version:
I have a website "example.com" which uses an IP address of "1.2.3.4". I have an SSL on "example.com" but not on "1.2.3.4". Apache will allow a user to visit "https://1.2.3.4" and it'll give them an SSL error. There is no way that I have found to configure Apache vhosts that will disallow this - it always does the TLS handshake first and gives the error. I need to eliminate that error for security audit reasons.

My last resort is to block "https://1.2.3.4" requests with a firewall. The host is unencrypted and I would like to block requests that contain that IP address as the host.

I would like to make sure this software can do it before I buy hardware and start learning it. Any help would be appreciated!

mcury

Tried this ?

<VirtualHost *:80>
ServerName 1.2.3.4
Redirect 403 /
UseCanonicalName Off
</VirtualHost>

<VirtualHost *:80>
ServerName example.com
Redirect permanent / https://example.com/
DocumentRoot /var/www/html
</VirtualHost>

SteveITS

@tgurske the certificate name mismatch will happen before the redirect.

The browser connects to the server IP and requests the hostname. You cannot block by IP without blocking the entire server.

Whatever is trying to connect via HTTPS with an IP should not do that. The mismatch is expected in that case.

tgurske

@mcury

Yes, HTTP works perfectly. It's HTTPS that I have the issue with. I cannot kill an HTTPS request directly to the IP without also killing the desired requests to the named virtual host.

tgurske

@SteveITS

I am not sure if this is an accurate example of an encrypted HTTPS request but I was hoping to let this through:

Remote Address: 1.2.3.4:443
Request URL: https://www.example.com

but block this:

Remote Address: 1.2.3.4:443
Request URL: https:1.2.3.4

Does the encrypted request separate those two pieces of information?

SteveITS

@tgurske Firewalls block IP addresses. You can make a domain not resolve, but that’s not your goal.

Perhaps a proxy server could do this. Given HTTPS, it would probably need a certificate on the client device so it could intercept the encrypted connection.
https://docs.netgate.com/pfsense/en/latest/packages/cache-proxy/index.html

tgurske

@SteveITS

Thank you for your help!

BassStation70

If you own the CA that issues the certificate, you can generate a new SSL certificate which contains an IP:xxx.xxx.xxx.xxx in the SubjectAlternativeName. (Third party CAs will almost certainly not issue a certificate that has an IP address in the SAN, since they cannot validate an IP address). Then the redirect should work without the client getting a SSL error.

Because a third party CA will probably not issue a cert with an IP address in the SAN, this would only work if you own the CA and have pushed your CA's signing root to all clients who will access this server, such as a home network or managed office LAN.

Of course, clients shouldn't be using the IP address for https, since it's not practically possible to ensure that the connection is secure. My approach in this case would be to provide a static page that returns a 400 or 500 error and a html page which includes the "correct" https URL with instructions to change their bookmarks or configuration settings, but not do a redirect. They're likely to click-through the handshake error, but then they'll have instructions on how to "fix" their misconfiguration.