Tag: security

Zero Trust SSH

SSH is arguably the most basic service on a linux based server. It’s secure as well, when using SSH keys (and with root login and passwords disabled) but it’s still a big target for the “bad guys” (mostly automated bots). You can run SSH on a non-standard port (not port 22), but that is just security through obscurity, which really isn’t good practice.

Well, then along came Zero Trust. Cloudflare perhaps didn’t invent this, but they are the biggest proponent of it.
What is it? In my own words, it’s VPN less authentication for web and anything else you can access via the internet. Now we can authenticate down to the user, not just the entire network (like a VPN).
How does it work? You authenticate to the Zero Trust Service via a webpage and once that is done, any applications that you have been given access to are automatically authenticated or protected behind the Zero Trust Provider, in this case Cloudflare
Can you do the same for SSH? YES SECURELY and IN THE BROWSER. It’s not new, it’s free (for up to 50 applications) and it’s easy to setup. See the original blog post here.

The basic steps are:

  • A domain pointed to your Cloudflare account
  • Setup a Cloudflare tunnel
  • Add an application, making sure you follow these specific steps
    At this point you can actually login to SSH in the browser, but you will need to authenticate yourself
  • Configure a short lived certificate to allow automatic login to SSH in the browser
    A word of warning, the SSO identity you use to authenticate with Cloudflare access will be the username passed to your server, read this section to understand this

The possibilities are endless once you get your head around this. You could protect a WordPress admin login page (though automatic login to WordPress is not something I’ve explored yet). Grant secure access to a server running in another location, and as discussed here, actually login to SSH in the browser.

With this done (Zero Trust SSH) you can go ahead and close port 22 of your server. How much safer do you feel?

Further Cloudflare Security – Authenticated Origin Pulls

Further Cloudflare Security – Authenticated Origin Pulls

Previously we posted about the importance of ensuring that all traffic to your website is actually going via Cloudflare (if you use Cloudflare in this way).

Quick recap, why is this so important?

Unless you ensure this is the case a malicious actor could possibly reach your content/website via your server IP address. Ensuring that only traffic via Cloudflare is accepted secures your web site or app and means that other tools (like Cloudflare Access, Workers etc can work correctly) can also be used to enhance your security.

So, Authenticated Origin Pulls

In plain English, your web server presents a cryptographic signature and says that only if the visitor presents the other part of the certificate should they be allowed to load the web page. Your web server actually enforces this. This way, if traffic does not come from Cloudflare, it will be rejected.

Limitation: You will only be able to configure this if you have full access to your web server ie root access, VPS, dedicated server etc. A basic level of knowledge of server administration is required.

Setup

There are 3 steps involved. I’ll provide an example below for NGINX. Apache is just as easy.

  1. In your Cloudflare dashboard enable Authenticated Origin Pulls, a quick link to this page in your account is here. Please note, enabling this now is a good idea, it will allow Cloudflare the few minutes it needs to start sending the one part of the cryptographic signature from all parts of their network. Until you start to enforce it (step 3) there will be no change or downtime on your web site.
  2. Download the certificate Cloudflare provides for this purpose. You can find it here. Save this to your server, a good location is:

    /etc/ssl/certs/cloudflare.crt

    (other locations are probably quite acceptable)
  3. Now update your Nginx configuration to use Authenticated Origin Pulls. Open the configuration file for your domain, or include the following:
ssl_client_certificate /etc/ssl/certs/cloudflare.crt;
ssl_verify_client on;

At this point, the moment you restart NGINX, your web server will ensure that only traffic via Cloudflare will be permitted.

Test

Test things by visiting your website directly via the IP address. You should see something like:

400 Bad Request

No required SSL certificate was sent

openresty

That’s it! A huge step in securing your server has now been completed. Any issues/questions please let us know in the comments below. Keep safe!

Restrict access to only traffic from Cloudflare

After finding it confusing and difficult to find clear information on this, even after checking Cloudflare’s own documentation, I’ve decided to put this post together in the hope of helping others.

The issue:

You have a website you protect (among other things) using Cloudflare. However, it’s still possible for traffic to reach your website directly, ie going around Cloudflare. This is quite easy if you do manage to find out the IP address a website is running on.

Side point: Cloudflare offer solutions such as Cloudflare Access which allow you to have VPN level protection for your website (or a section of it if you choose). These are great solutions, but only work properly if you can ensure that ALL traffic is forced to go via Cloudflare (and the protection they offer).

The solution:

After wasting days with keywords like: cloudflare restrict access, lock down traffic to only Cloudflare, restrict access to only Cloudflare IP addresses etc etc.. I stumbled on this post: Stop Cloudflare bypassing on shared hosting unfortunately the title is not as intuitive as it could be, however the solution is excellent (bar one small technicality which I will explain later). And I quote:


With a very simple Cloudflare Worker, we can add a request header, a header that will be sent from the edge (any of Cloudflare’s 180+ data centers) to the origin (your server), and therefore won’t be visible to site visitors. As long as the header name and value are kept secret by the site admin, any requests not coming through Cloudflare will not have this header, and will therefore trigger a rewrite condition at the origin server, and be redirected back to, well, Cloudflare – where a Firewall Rule will block it.

The Cloudflare worker (taken from this recipe 18). You’ll need to configure the Cloudflare worker via your Cloudflare account. For most sites, this will be free.

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

/**
 * Send header to origin, allowing for
 * .htaccess to block requests
 * not coming from Cloudflare
 */

async function handleRequest(request) {
  // Make the headers mutable by re-constructing the Request.
  request = new Request(request)
  request.headers.set('Secret-Header', 'SeCrEt-kEy')

  return await fetch(request)
}

And then on your own website the following .htaccess directives (place them at the top of the file):

# Route visitors not coming from Cloudflare to, well, Cloudflare
<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteBase /
	# Both the header and the value should be kept secret
	RewriteCond "%{HTTP:Secret-Header}" "!SeCrEt-kEy"
	# Uncomment and edit w/ IP of services such as certs, cron, Softaculous etc
	# RewriteCond "%{REMOTE_HOST}" "!^xxx\.xxx\.xxx\.xxx$"
	RewriteRule .* "accessdenied.php" [R,L]
</IfModule>

What these directives do is check every request to see if it has a request header named “Secret-Header” and whether its value does not contain the string “SeCrEt-kEy”. If the header does not exist, or does not contain the key, the request will be redirected to a non-existing URI named here “accessdenied.php”, (a fictitious, non-existing file) which must be added in a Firewall Rule.


/end quote.

This works wonderfully. The problem with the suggested firewall rule (at Cloudflare) is that it won’t be triggered if traffic comes in from somewhere other than Cloudflare.. makes it redundant/useless. So, well.. edit that yourself or find another solution if you wish to gracefully block traffic this way.

Conclusion:

While the concept of restricting access to IP addresses and/or blocking access to some (via .htaccess) is fairly well documented, using Cloudflare (and I do recommend it) makes some of this quite complex when wanting to restrict access to ONLY traffic via Cloudflare. The solution above is elegant in that it adds a header to each request (via Cloudflare Worker) and then the .htaccess file checks to make sure that header is present (ie did it come from Cloudflare), if not, traffic is blocked or redirected to a file of your choosing (or even a 404 if you wish). Sadly not enough airtime is given to this solution, perhaps due to the wrong keywords being used. Hopefully this post help with that.

PS If you wish to avail yourself of our services for things like this (securing your existing or new website, website hosting that ensures your site is always kept up to date and secure along with regular off-site backups (which we can automatically send to you each time) be sure to get in touch with us to find out more.

Edit: For a simpler solution to this problem, but only if you have full server access it explained here: https://xyzuluhosting.com/further-cloudflare-security-authenticated-origin-pulls/

Scroll to Top