Limit exposure until you can patch

Choose a measure

• Take systems that are not business-critical offline: staging sites, old websites and test environments.
• Allow only known IP addresses for admin areas and internal tools.
• Put internal applications behind a VPN.
• Use a web application firewall, for example from your CDN, as an extra layer. It does not replace patching.

Start with admin panels and the systems that are most critical for your business.

Allow only known IP addresses in nginx

location / {
    allow 203.0.113.10;     # office
    allow 198.51.100.0/24;  # VPN
    deny all;
}

Replace the example addresses with your own. Test and reload nginx afterwards:

sudo nginx -t && sudo systemctl reload nginx

Allow only known IP addresses in Apache

<Location "/">
    Require ip 203.0.113.10 198.51.100.0/24
</Location>

In an .htaccess file, use only the Require ip line. Test and reload Apache afterwards:

sudo apachectl configtest && sudo systemctl reload apache2    # or: httpd

Block at the server firewall

sudo ufw allow from 203.0.113.10 to any port 443 proto tcp
sudo ufw deny 443/tcp
sudo ufw deny 80/tcp

Add the allow rules before the deny rules, and make sure you keep SSH access for yourself.

Our control panels are closed at the moment, so you can't change the cloud firewall in the customer portal. Use the firewall on the server itself for now.

Show a maintenance page

When you take a website offline, serve a maintenance page with HTTP status 503 and a Retry-After header. Search engines then know the outage is temporary and keep your pages in their index.

location / {
    return 503;
}
error_page 503 /maintenance.html;
location = /maintenance.html {
    root /var/www/maintenance;
    add_header Retry-After 3600 always;
    internal;
}