You're likely thinking one of the following:
- There's not much to securing a static site generator (SSG)
- The writer is spilling all their secrets
- What is Bashblog?
Yes, Bashblog is a static site generator. No, there isn't much to securing the Bashblog SSG by default. But embedded code and man-in-the-middle (MITM) attacks can cause vulnerabilities. You still have to harden the web server, especially if you run other services on your system. And to be fair, everything I mention below is public knowledge, if you know where to look. I'm going to show you where to look.
Don't Generate the Site From the Server
Bashblog creates two backups during site generation: an updated TAR file and one from the day before. Since it has no special dependencies, there's no reason you need to use that bb.sh file on the server. If you're uncomfortable running Secure Shell (SSH) to upload files to your web server, use the FileZilla file transfer protocol (FTP) app. Using cPanel or another server administration tool? Learn how to upload files from your computer.
Use SSL Certificates
This one is simple. cPanel servers have AutoSSL which renews domain-validated (DV) Comodo SSL certificates. From what I've seen, that's been the standard for years. Other server management software might have something similar using Let's Encrypt. If not, there's always Certbot Certbot or manual installations.
And of course, ensure your website redirects to use HTTPS with and without the "www" prefix. You'll configure that in your web server (Apache, NGINX, LiteSpeed, etc.).
Use Security HTTP Headers
I mentioned this in my blame game blog. But I try to seize every opportunity to talk about security HTTP headers. They're easy to add on Apache servers with the .htaccess file and NGINX configuration files. WordPress and other web builders have graphical menus to ease configuration. For Bashblog users, you have a text editor and plain .htaccess text file.
I'll share an example code block for security HTTP headers in the Apache .htaccess file. No, it isn't guaranteed to work with your website, especially that Content Security Policy (CSP) header.
<IfModule mod_headers.c> Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" Header set X-XSS-Protection "1; mode=block" Header set X-Frame-Options "deny" Header set X-Content-Type-Options: nosniff Header set Content-Security-Policy "default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self'; connect-src 'self'; font-src 'self' https://fonts.gstatic.com/; report-uri 'self'; worker-src 'self'; form-action 'self'; frame-ancestors 'self'; child-src 'self' https://www.youtube-nocookie.com/ https://open.spotify.com/ https://twitter.com/ https://soundcloud.com/; manifest-src 'self'; base-uri 'self'; block-all-mixed-content; require-trusted-types-for 'script';" Header set Permissions-Policy: geolocation=();midi=();notifications=();push=();sync-xhr=();microphone=();camera=();magnetometer=();gyroscope=();speaker=(self);vibrate=();fullscreen=(self);payment=(); Header set Referrer-Policy: same-origin Header set Clear-Site-Data: * Header set Expect-CT: max-age=86400 Header set Cross-Origin-Opener-Policy: same-origin Header set Cross-Origin-Embedder-Policy: unsafe-none Header set Cross-Origin-Resource-Policy: unsafe-none </IfModule>
Remove Web Server Header Info
I was excited when I finally figured out how to not just hide my server version number but completely hide my server name. This makes it harder for cyber attackers to determine vulnerabilities for your specific web server version. Three lines in my web server configuration file:
SecRuleEngine on ServerTokens Full SecServerSignature "SupraSecretServer"
The easiest ways I know to test the results:
curl terminal command:
curl --head example.com
wget terminal command:
wget --server-response -qO /dev/null example.com
Add Subresource Integrity (SRI)
When you add external sources like Bootstrap and JQuery, SRI protects users against code injection attacks. If you don't add such scripts in your
head section, you can skip to the next section. It's simply a binary SHA hash (256, 384, or 512) of the package that the browser checks before loading it. Here's an example script for adding Bootstrap CSS from JSDelivr with a SHA384 has:
<!-- CSS only --> <link href="https://firstname.lastname@example.org/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-KyZXEAg3QhqLMpG8r+8fhAXLRk2vvoC2f3B09zVXn8CA5QIVfZOJ3BCsw2P0p/We" crossorigin="anonymous">
The easiest ways I've found to get binary checksums is SRIhash.org or the
openssl terminal command:
cat FILE | openssl dgst -sha384 -binary | openssl base64 -A
Took me a while to realize
sha384sum doesn't give a binary checksum.
Consider Implementing Domain Name System Security Extensions (DNSSEC)
DNSSEC basically ensures you're sent to the correct website by validating the DNS path - nameserver (NS), A, CNAME, etc. If the user's DNS path doesn't match your intended DNS settings, the browser will only show a white page so as to protect the user. Again, I went deeper into the topic in my last cybersec blog. It requires a lot of work to set up, even on cPanel servers. First, you have to ask your web hosting provider and domain registrar if they support it.
Use the Latest TLS Version
Configure a Firewall
Firewalls can protect you from Denial-of-service (DoS) attacks. If you're only serving Bashblog, ports 80 (HTTP), 443 (HTTPS), and SSH are probably all you need.
Random thought: if you're using shared cPanel server hosting just for a blog, you're wasting money. Learn how to SSH into a server or use secure FTP (FTPS/SFTP) and get a bare Linux cloud server. Determining which Linux operating system (OS) you should use for a server can be time consuming. I'll say that Ubuntu server is a safe bet for popularity and community support.
Most popular firewall applications I know:
- ConfigServer Security & Firewall (CSF)
- UncomplicatedFirewall (UFW)
- ModSecurity (more sophisticated but works well with other firewalls)
Content delivery networks (CDNs) like Cloudflare and web application firewalls (WAFs) such as Sucuri might also have firewall features. But you still need to have one on the server because cyber attackers can find ways to bypass CDNs and WAFs.
Use an Antivirus (AV) Scanner
Since securing Bashblog is primarily about server hardening, it is helpful to scan system files as a failsafe. This is especially true if there are other apps on the server. The most popular AV scanners I know are ClamAV and ImunifyAV.
Enable Two / Multi-factor Authentication (TFA/MFA)
Enable it on your web hosting account. Enable it on your computer if you can. You know your password. Is there a way to authenticate by something you have (USB dongle) or are (fingerprint scanner)? I've read mixed reviews about fingerprint scanners on computer years ago, but things change..
Regularly copy the backups auto-generated by Bashblog to another directory on your system for safekeeping. If you do a lot of other stuff on your server, backup the server every few weeks and save it on your local system. You can use cron jobs (scheduled tasks) to do this. And don't simply create a compressed zip or tar file and call it good. Make sure the backups work so you have confidence in your ultimate failsafe.
There are a lot of web apps that will do free, comprehensive website scans. Some of my favorites:
- MX Toolbox for checking DNS propogation and realtime blacklist or realtime blockhole lists (RBLs)
- ImmuniWeb to find potential typosquatting and phishing issues
- UpGuard for things I don't remember to check
Later, I'll talk about making Bashblog more accessible.