This comes hot on the heels of my previous post about making a Gatsby site under Proxmox, using an LXC container. That is still a great option, and is a great way to get started and learn the ropes of Gatsby, and site hosting in general. However, after I had gone through all the steps to setup this blog, I started thinking about the security implications of hosting a public facing website on my home network.
I Don’t Wish to Be Hacked
Does anyone?
I do IT work for a living, so I am fairly well accustomed to configuring networks, setting up firewalls, and generally doing my best to make sure nothing gets broken into, or broken in general. However, to paraphrase Schneier’s law anyone can make a system so secure that they can’t think of a way to break it. However, this only means that the system is secure against someone who is dumber than the designer. Nothing is truly un-hackable, and I don’t really want a hobby blog to become the undoing my home network, so I decided to do some research
There are some things you can do to make your site more secure, if you do decide to host it on a home network, but I think there are better options which offer more peace of mind, and much easier setup and maintenance.
Isolate Public Facing Service on Separate Subnet/DMZ
One common approach is to make sure that anything public facing goes in the Demilitarized Zone (DMZ). This is often a separate subnet where device to device communication is extremely restricted, or outright banned. This also is used to make sure that if a device in the DMZ is compromised, that it cannot get to any other machines to compromise them as well. It’s like a quarantine zone for your network. This works well for minimizing damage after the device is compromised, but doesn’t do much for preventing breach in the first place.
Using a Static Site Generator (Already Done!)
Here is where something like Gatsby and other site generators already have an advantage over other public facing services or websites; they are static! The beauty of a static site is that once it has been compiled and has been hosted, the attack surface for the site itself becomes very small. Now, you could still have a static site, and a poorly configured firewall, and it would all be a wash, but as far as site security goes, being static is a step in the right direction.
Don’t Host in Your Home Network?
This one is kind of a gimme. If you don’t host your website on your own hardware, and in your own network, it takes care of many of the above suggestions for you automatically. For instance, hosting through a web provider will often come with free Let’s Encrypt certificates, that can bet setup to renew themselves automatically. They often have firewalls setup right, since they deal in web hosting, and are very experienced in preventing unauthorized access. Other benefits include; not needing to use your own hardware, having easy integration with other things like public DNS, Domain Name Registration, etc. And, on top of all that, if your site was compromised, it would not be letting someone right into your home network, which is a huge bonus.
Web Hosts
There are a TON of options for web hosts. You could go with an actual web hosting company, like a go-daddy, or Inmotion, but that is way overkill for what we are doing, and we’ve already done a lot of the legwork to build our site. Also, I said this was going to be free, and very few web hosts have free hosting options.
Container Hosts
Option 2, is that we use a service like Digital Ocean or Linode. This would let us host a VM or Container in the cloud, which takes care of the hardware problem, and the not being on our network problem. However, these are often priced by compute time, or traffic. What may be cheap now could end up getting expensive quickly if your site got hit by bots, or a DDoS attack. Even AWS Lightsail, which has fantastic options for getting started with web hosting, charges you for extra compute, meaning your monthly bill of a few dollars can quickly grow to be several tens or hundreds of dollars if you are not monitoring it carefully. Hosting a site on any of these platforms can typically be done for under $10/month, but its still not FREE!
Static Site Hosts
My personal favorite option, use a static site host. There are services like Github Pages and Cloudflare Pages that integrate directly with static site generators to allow you to host a website for FREE! Here is another benefit of using a static site Generator like Gatsby; the site is really cheap to run. Services like Github Pages and Cloudflare Pages only work with static sites, but our site is already static because it’s being generated by Gatsby. Additionally, if you have setup your Gatsby site in a Github Repo already, even a private one, hosting it on either of these services is incredibly simple.
Hosting on Cloudflare Pages
My personal favorite of the two static site hosts mentioned above is Cloudflare. They offer free DDoS protection, their sites are very fast, and you get unlimited bandwidth and sites with a free account. Their documentation is also excellent, and as an aside, their tech blog is fantastic for breakdowns of new technology, security incidents, internet trends, and more. They also have easy integrations for Workers, to handle non-static tasks, Public DNS, Domain Name Registration and Management, and a whole lot more that I haven’t even gotten to discover yet.
To give you an idea of just how simple it is to host a Gatsby site on Cloudflare, just take a look at their docs. I am going to paraphrase them here for convenience.
If you already followed parts of my previous blog post to install
gatsby-cliand make a Git Repo, then you can skip down to step #5.
-
On a computer or VM, install Gatsby
npm install -g gatsby-cli -
Create a Gatsby Project
npx gatsby new gatsby-starter-blog https://github.com/gatsbyjs/gatsby-starter-blog -
Create a Git Repo using https://repo.new
-
Push your gatsby project into
mainin the Git Repo
git remote add origin https://github.com/<your-gh-username>/<repository-name>
git branch -M main
git push -u origin main- Connect Cloudflare to Github
- Press build and wait for it to complete.
Now your site is available under https://repo-name.pages.dev!
I did have a brief issue with getting mine to build, since my Git Repo was not the root of my Gatsby site, as it would be if you followed these directions. You can use the
Advancedtab on the Cloudflare Pages Dashboard when creating your deployment, and set a different sub-directory to be your Gatsby root folder. Mine just needed to start one folder lower than root, and it was then able to build and deploy just great.
If you want to go further and set up a public domain so it can be blog.example.com or whatever, that is easy to do too, and you can purchase a domain directly through cloudflare for just a few dollars a year. This is not required though, as you can still get to your site publicly using the pages.dev domain, whether or not you own your own domain name.
There is one catch here, and that is that you are only allowed to do 500 site changes per month. Thankfully though, since it is connected to Git, and specifically to the main branch, you can do all your dev work in a separate branch, and only merge to main when you are ready for the changes to go live. The site builds using commits made to the main branch, so as long as you work in a separate branch, and don’t merge more than 500 times a month, you should be well under the limits of the free tier.