Introduction
You have total control over your online appearance with self-hosting, whether you're using it for personal projects, apps, or blogging. But enormous power also comes with great responsibility, particularly in terms of security.
In this post I'll share my experience of self-hosting Ghost CMS on a Raspberry Pi, making sure that the system is secure and hardened. I automated the process of protecting my server and NGINX configurations by utilizing the DevSec Hardening Framework. Every server setup is now automatically hardened during deployment thanks to the hardening playbooks I built to my CI/CD pipeline using GitHub Actions to make the process even more seamless!
I'll also discuss how I overcame persistent issues with Content Security Policies (CSP) to maintain the functionality and security of my website.
This article is for you if you're trying to figure out how to host your own website safely without going over budget!
Table of Contents
Why Hardening Matters
Protecting your server from vulnerabilities is your direct responsibility when self-hosting. Inadequate security measures allow hackers to take advantage of configuration flaws, obtain illegal access, or interfere with your services.
This is when hardening—locking down your server to ensure seamless operation and make it resistant to threats—comes into play. Fortunately, I discovered the DevSec Hardening Framework, a fantastic group of tools that automates recommended practices for hardening web servers, operating systems, and other components.
The DevSec.io Hardening Framework
DevSec.io is an open-source, modular hardening platform that makes it easy to safeguard your infrastructure. It applies industry-standard security measures across several tiers of your stack using Ansible, Chef, or Puppet, and leverages Inspec to find security flaws and misconfigurations.
The DevSec Ansible hardening playbooks offer extensive security improvements for NGINX web servers and operating systems. Here is a summary of their salient characteristics:
Operating System Hardening
The OS hardening playbook establishes a robust security baseline by:
- User and Group Settings: Include enforcing strong password regulations, regulating user privileges, and maintaining secure group configurations.
- Service and Port Management: Disabling superfluous services and closing unused ports to reduce the attack surface.
- SSH Hardening: Securing SSH access by requiring key-based authentication, preventing root login, and defining the necessary SSH parameters.
- System Updates and Patches: Ensuring that the most recent security patches and updates are installed to ensure system integrity.
- Kernel and Filesystem Protections: Enforcing kernel-level security settings and defining filesystem permissions to prevent unauthorized access.
NGINX Hardening
The NGINX hardening playbook enhances web server security by:
- TLS/SSL Configuration: Strict TLS settings are enforced using modern ciphers and protocols to ensure secure communication.
- HTTP Security Headers: To guard against common online vulnerabilities, use headers such as
Content-Security-Policy,X-Frame-Options, andX-Content-Type-Options. - Request and Connection Management: Implementing rate limiting and request size restrictions to protect against denial-of-service attacks and resource exhaustion.
- Access Controls: Limiting access to critical areas and resources using IP whitelisting and adequate authentication measures.
- Logging and Monitoring: Setting up thorough logging to monitor traffic trends and find anomalies.
These playbooks ensure that systems are protected against a wide range of threats by adhering to industry-standard security baselines.
The official repositories provide more detailed information.
dev-sec
dev-sec
CI/CD Integration with GitHub Actions
I included the hardening playbooks in my GitHub Actions CI/CD pipeline to speed up and improve the consistency of deployments. In this manner, the hardening is implemented automatically each time I deploy a new server.
An example GitHub Actions workflow file for using the playbooks can be seen here:
name: Apply Hardening
on:
push:
branches:
- main
jobs:
harden-server:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v3
- name: Set Up Ansible
uses: ansible/ansible-lint-action@v6
- name: Install Required Roles
run: ansible-galaxy install devsec.hardening devsec.nginx-hardening
- name: Apply OS Hardening
run: ansible-playbook os-hardening.yml
- name: Apply NGINX Hardening
run: ansible-playbook nginx-hardening.yml
In addition to saving time, this automation guarantees that each new server has the same robust security baseline.
Fixing Content Security Policy Issues
Putting in place a strong yet practical Content Security Policy (CSP) was one of the difficulties I faced. Enhancing website security requires the use of the HTTP Content-Security-Policy (CSP) response header. By limiting the resources that a browser is allowed to load, administrators can reduce dangers like cross-site scripting (XSS) attacks. The CSP serves as a whitelist for the resources on your website by identifying script endpoints and trusted server origins.
Website adminscan regulate the resources that the user agent is permitted to load for a specific page by using the HTTP Content-Security-Policy response header. Policies typically entail defining script endpoints and server origins, with a few exceptions. This protects against attacks using cross-site scripting.
Initially, after using the NGINX hardening playbook, my CSP was extremely stringent. By default, the directive was:
Content-Security-Policy "script-src 'self'; object-src 'self'";
While this directive provided a high level of security, it blocked critical functionality on my site, such as:
- Stripe JS for payments:
https://js.stripe.com/v3/ - Prism.js for syntax highlighting:
https://cdnjs.cloudflare.com/ajax/libs/prism/1.28.0/ - Fonts and styles from trusted sources like Google Fonts and Bunny Fonts.
To resolve these issues, I carefully updated the CSP to allow trusted external domains while maintaining security. The updated CSP includes:
- Specific third-party domains (e.g., Stripe, Prism.js, Google Fonts).
- Script hashes for inline scripts to allow safe execution without enabling
unsafe-inline. - Additional directives like
object-src 'none';andbase-uri 'self';to guard against potential vulnerabilities.
This method strikes a balance between functionality and security by:
- Permitting only reliable external sources.
- Avoiding needless risks by using directives such as
object-src 'none'andbase-uri 'self'. - Allowing safe inline script execution without turning on
unsafe-inlineby using nonces and script hashes.
I made sure the site stays safe while supporting necessary third-party integrations by meticulously designing and evaluating the CSP.
Google's CSP Evaluator
Final Thoughts
Self-hosting Ghost on a Raspberry Pi has been a satisfying project. Using the DevSec Hardening Framework, I was able to secure my server with minimal effort while focusing on providing a flawless experience for my visitors.
Integrating the playbooks into a GitHub Actions pipeline made deployment easier and guaranteed consistent security across all configurations.
Remember, security is a continuous process. Regular upgrades, log monitoring, and configuration refinement will help keep your server secure against new attacks.
Have any queries or want to share your own self-hosting experience? Please leave a remark below! 🚀
