apache – How to Block Certain URLs in Apache HTTPD When Using Proxy Pass

apache-2.4httpdnode.js

My site is using apache httpd to do the reverse proxy to an app running in Express (Node.js app). Have 2 express servers, one for backend, another for frontend hosting.
Right now I'm trying to block malicious requests that is coming to my site so it returns a 404 or bad request.

My some-site-ssl.conf sample is below, but it doesnt look like its blocking the malicious websites, any help would be awesome!! Thank you.


<VirtualHost _default_:443>
      ServerAdmin webmaster@localhost

      ErrorLog ${APACHE_LOG_DIR}/error.log
      CustomLog ${APACHE_LOG_DIR}/access.log combined

      SSLEngine on

      SSLCertificateFile      /etc/letsencrypt/live/some-site.com/fullchain.pem
      SSLCertificateKeyFile /etc/letsencrypt/live/some-site.com/privkey.pem
      Include /etc/letsencrypt/options-ssl-apache.conf

      RewriteEngine On
      RewriteCond %{HTTP_REFERER} ^http://(www\.)?.*(-|.)?bad-word(-|.).*$  [NC]
      RewriteCond %{HTTP_REFERER} ^https://(www\.)?.*(-|.)?bad-word(-|.).*$  [NC]
      RewriteRule ^(.*)$ - [F,L]

      ProxyRequests On

      ProxyPass /api http://some-site.com:3000/api
      ProxyPassReverse /api http://some-site.com:3000/api

      ProxyPass / http://some-site.com:4226/
      ProxyPassReverse / http://some-site.com:4226/
</VirtualHost>

Best Answer

You can control access to any resource using the Location tag, and with it, you can disable access from certain hosts to your resources, like this:

<Location "/denied/resource">
    <RequireAll>
        Require not ip 1.2.3.4
        Require not host spammer.domain
        Require all granted
    <RequireAll>
</Location>

The access rights are inherited from top to bottom, so denying access to / will practically lock out that client from your site (unless, of course, access is granted to a lower level resource, so it is possible not to have access to /, but being able to access /this/one/). See the Apache HTTP server documentation for more info.

And like @Freddy said, you really should remove that ProxyRequests On line.

Related Solutions

Apache – How to Fix ‘Logjam’ Vulnerability in Apache (httpd)

From the article you linked, there are three recommended steps to protect yourself against this vulnerability. In principle these steps apply to any software you may use with SSL/TLS but here we will deal with the specific steps to apply them to Apache (httpd) since that is the software in question.

Disable Export Cipher Suites

Dealt with in the configuration changes we'll make in 2. below (!EXPORT near the end of the SSLCipherSuite line is how we'll disable export cipher suites)

Deploy (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE)

For this, you need to edit a few settings in your Apache config files - namely SSLProtocol, SSLCipherSuite, SSLHonorCipherOrder to have a "best-practices" setup. Something like the following will suffice:

SSLProtocol             all -SSLv2 -SSLv3

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLHonorCipherOrder     on

Note: as for which SSLCipherSuite setting to use, this is always changing, and it is a good idea to consult resources such as this one to check for the latest recommended configuration.

3. Generate a Strong, Unique Diffie Hellman Group

To do so, you can run

openssl dhparam -out dhparams.pem 2048.

Note that this will put significant load on the server whilst the params are generated - you can always get around this potential issue by generating the params on another machine and using scp or similar to transfer them onto the server in question for use.

To use these newly-generated dhparams in Apache, from the Apache Documentation:

To generate custom DH parameters, use the openssl dhparam command. Alternatively, you can append the following standard 1024-bit DH parameters from RFC 2409, section 6.2 to the respective SSLCertificateFile file:

(emphasis mine)

which is then followed by a standard 1024-bit DH parameter. From this we can infer that the custom-generated DH parameters may simply be appended to the relevant SSLCertificateFile in question.

To do so, run something similar to the following:

cat /path/to/custom/dhparam >> /path/to/sslcertfile

Alternatively, as per the Apache subsection of the article you originally linked, you may also specify the custom dhparams file you have created if you prefer not to alter the certificate file itself, thusly:

SSLOpenSSLConfCmd DHParameters "/path/to/dhparams.pem"

in whichever Apache config(s) are relevant to your particular SSL/TLS implementation - generally in conf.d/ssl.confor conf.d/vhosts.conf but this will differ depending on how you have configured Apache.

It is worth noting that, as per this link,

Before Apache 2.4.7, the DH parameter is always set to 1024 bits and is not user configurable. This has been fixed in mod_ssl 2.4.7 that Red Hat has backported into their RHEL 6 Apache 2.2 distribution with httpd-2.2.15-32.el6

On Debian Wheezy upgrade apache2 to 2.2.22-13+deb7u4 or later and openssl to 1.0.1e-2+deb7u17. The above SSLCipherSuite does not work perfectly, instead use the following as per this blog:

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-AES256-SHA256:!DHE-RSA-CAMELLIA128-SHA:!DHE-RSA-CAMELLIA256-SHA

You should check whether your Apache version is later than these version numbers depending on your distribution, and if not - update it if at all possible.

Once you have performed the above steps to update your configuration, and restarted the Apache service to apply the changes, you should check that the configuration is as-desired by running the tests on SSLLabs and on the article related to this particular vulnerability.

Tomcat – Basic auth Apache with Tomcat

It made me suspicious that I got a 401 error from the tomcat application. it seems, that apache fowarded the authorization request, though it shouldn't. I had to remove the "Authorization" parameter from the request header.

To do this. I enabled mod_headers and added RequestHeader unset "Authorization" just before the ProxyPass directives.

So my config looks like the following now:

<VirtualHost *:80>

        ProxyRequests           Off
        ProxyPreserveHost       On

        RequestHeader unset "Authorization"       

        <Location "/tickets/rest/">
                  Satisfy Any
                  Order allow,deny
                  Allow from all
        </Location>

        <Location />
                AuthType Basic
                AuthName "Restricted Content"
                AuthUserFile /etc/apache2/.htpasswd
                Require user myuser
        </Location>

        ProxyPass                /tickets       http://localhost:8081/tickets
        ProxyPassReverse         /tickets       http://localhost:8081/tickets

</VirtualHost>

EDIT:

Jira uses its own REST-API for the gadgets, so I had to define a Location-Tag for /tickets/rest path.

removed proxy-tag
added Location-Tag for the jira-rest API

Got ideas to solve the problem from:

Best Answer

Related Solutions

Apache – How to Fix ‘Logjam’ Vulnerability in Apache (httpd)

Tomcat – Basic auth Apache with Tomcat

Related Topic