Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Filter by HTTP(S) request by host

    Scheduled Pinned Locked Moved Firewalling
    8 Posts 4 Posters 447 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      tgurske
      last edited by

      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!

      M S 2 Replies Last reply Reply Quote 0
      • M
        mcury Rebel Alliance @tgurske
        last edited by

        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>
        

        dead on arrival, nowhere to be found.

        T 1 Reply Last reply Reply Quote 1
        • S
          SteveITS Galactic Empire @tgurske
          last edited by

          @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.

          Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
          When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
          Upvote 👍 helpful posts!

          T 1 Reply Last reply Reply Quote 1
          • T
            tgurske @mcury
            last edited by

            @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.

            1 Reply Last reply Reply Quote 0
            • T
              tgurske @SteveITS
              last edited by

              @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?

              S 1 Reply Last reply Reply Quote 0
              • S
                SteveITS Galactic Empire @tgurske
                last edited by

                @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

                Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
                When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
                Upvote 👍 helpful posts!

                T 1 Reply Last reply Reply Quote 1
                • T
                  tgurske @SteveITS
                  last edited by

                  @SteveITS

                  Thank you for your help!

                  1 Reply Last reply Reply Quote 0
                  • B
                    BassStation70
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.