Keep the Wolves at Bay: Securing an Application from the Outside

Security is a chief concern for any web application, whether or not it's handling sensitive user information. For a small team, it can feel impossible to stay on top of the threats and develop strategies that respond to them.

Managed platforms like Heroku and Pantheon offer to solve much of this for developers, but what does that mean? One starting point is to control what kind of traffic is allowed to reach the application.

Often this involves using a dedicated resource that receives all inbound requests, filtering for the good ones that are permitted to reach the application. Being able to distinguish the good from the bad is hard through, and depends on the type of application.

This recent post is a great window into how that is managed by Acquia, a big Drupal-centered platform:

Custom Cloudflare WAF rules that every Drupal site should run

Much of the wisdom here is knowing what are sensitive URLs for a given application, like Drupal or Wordpress. If you're curious what sort of naughty traffic your sites gets, you can try logging requests that trigger a 404 or "access denied." Drupal does this by default.

Some of this traffic is malicious. Bots trying to probe weak user logins, mis-configured permissions, etc.

Some of it is just a bad link which can waste cycles on your application, slowing it down. The application server is probably not designed to handle this, but a tool like Cloudflare is.

One good example of this is autodiscover requests from Microsoft Exchange. I've never seen this, myself, but the author above recommends this strategy:

description: Autodiscover
action: block
filter:
  expression: '(http.request.uri.path matches "/autodiscover\.xml$") or (http.request.uri.path matches "/autodiscover\.src/")'

Cloudflare is the tool of choice here, but other tools can do this job too, albeit with different syntax.

Nginx

Nginx is a great reverse proxy that, in my opinion, is far easier to learn how to configure than the old standard Apache. The syntax for blocking paths is pretty easy to understand:

# Disallow access to user and admin URIs
location ^~ /user { return 404; }
location ^~ /admin { return 404; }
if ($arg_q ~ "^user") { return 404; }
if ($arg_q ~ "^admin") { return 404; }

Sourced from: Nginx configuration

Apache

What's so hard about Apache, you ask? Well ...

<ifmodule mod_rewrite.c="">
    RewriteEngine on
    RewriteCond %{SCRIPT_FILENAME} index.php [NC]
    RewriteCond %{QUERY_STRING} (^|&)q=admin(/|&|$) [NC]
    RewriteRule .* - [F,L]
</ifmodule>

Sourced from: Apache config

.htacess

And going further back in time, the standard way of controlling Drupal sites was the old .htacces layer. While this works, it typically did not prevent the traffic from hitting your application server.

RewriteRule ^(scripts|profile|includes|cron\.php|install\.php|update\.php|xmlrpc\.php|filter($|/)|user($|/)|admin($|/)) - [F,L] 

Sourced from: .htaccess configuration