Mar 29 14:38:13 icefall fail2ban.filter[1097]: INFO [...] Found 176.126.240.158 - 2024-03-29 14:38:13 Mar 29 14:40:11 icefall fail2ban.filter[1097]: INFO [...] Found 176.126.240.158 - 2024-03-29 14:40:11 Mar 29 14:40:29 icefall fail2ban.filter[1097]: INFO [...] Found 185.8.165.204 - 2024-03-29 14:40:29 Mar 29 14:40:40 icefall fail2ban.filter[1097]: INFO [...] Found 162.212.154.58 - 2024-03-29 14:40:40 </code></pre> Within the past few minutes, I've already got a few IP addresses from all over the world taking a peak at my services. If I had my SSH port set to the standard 22</code>, I could have expected a few rogue login attempts to have been made, too. And, speaking of not having my SSH port set to the standard 22</code>, I'll now move on to what you should be done to secure a home server. One thing that I think should be noted, however, is that security doesn't need to be very strong, and you generally don't need to go too far out of your way with security measures (though this definitely depends on invdividual circumstance). Honestly speaking, you probably don't have competent black hats looking to get in to your server - what you probably do have, however, are a bunch of script kiddies and perversive bots. The list#</a></h1> The fairly basic stuff you'd need to do in this case doesn't make much room for detail. So, here it all is in the form of a simple list (I've included the relevant NixOS configuration where I think it'd be useful1</a>): Move your SSH daemon to a non-default port, like 3291</code>. services.openssh = { ports = [ 3291 ]; # whatever you like }; </code></pre> </li> Force public key authentication with SSH and disable root logins. services.openssh.settings = { PermitRootLogin = "no"; PasswordAuthentication = false; }; </code></pre> </li> Set up a pretty basic firewall - something like ufw</code> would do the trick. networking = { nftables.enable = true; # use the newer nftables firewall = { enable = true; rejectPackets = true; # explicit deny interfaces.enp1s0 = { # obviously, replace `enp1s0` with your interface allowedTCPPorts = [ ... ]; # put in the ports you need here }; }; }; </code></pre> </li> This probably doesn't need to be said, but use strong passwords! </li> Host a fail2ban</a> instance to ban hosts making bruteforce attempts. </li> </ul> I think that's all there is for almost everyone, and is basically the minimal amount of effort a home server administrator should do. Personally, I would prefer to enforce a VPN connection in order to access my personal services for that extra layer of security (because why'd they need to be exposed to the internet?). This can be done faily easily with tailscale, and for the slightly more paranoid - headscale</a> is a viable...alternative? Anyways, I've got a blog post that explores headscale in a little more detail, which might be worth checking out. Well, that's all I wanted to say. It's been a while since my last blog post, and the inspiration for this one came seemingly randomly - I hope someone finds this useful. ^{1 Naturally, you shouldn't just copy and paste the snippets into </div>}

Take control of tailscale with headscale

2024-01-10T00:00:00+00:00

Tailscale #</a></h1>
Tailscale</a> is a modern tunnel VPN service based on WireGuard®</a> which provides a 'free' and secure means of communication between devices within a tailnet</a> - a private network which Tailscale provides its users.
Essentially, it provides a private and secure way of accessing any of your devices, no matter where you are in the world - a personal WAN encompassing the entire world.
And on top of this, Tailscale is completely free and open-source! At least, on the surface...

Not FOSS? What do you mean?#</a></h2>
There's a quite popular saying within the free and open-source software community, which goes along the lines of:

If you aren't paying for the product, then you are the product. </blockquote>
Which makes perfect sense. It's the modern era so anything significant is powered by some form of modern technology, data is the new oil, and so on. In exchange for offering you 'free' services, companies collect and use your data; while there supposedly are laws in place preventing the inconcensual collection of data in most countries around the world, your personal data may still be traded unethically and inconsensually.
I personally am of the opinion that these laws are worth absolutely nothing if people aren't educated in how their data is being used, and what specifically is being collected. But I digress, and that's a blog post for another time.
I also think it's quite unfortunate that users of paid services still have their personal data collected in the unethical manner outlined above, despite the fact that they are paying for the service...
In the context of Tailscale: while their clients are all open-source, their control server - the thing that's managing and rerouting everything going through what they advertise as your 'secure' VPN, isn't. You've got no idea what this thing is doing with the traffic it recieves.
Headscale#</a></h1>
For every problem, there's probably a solution somewhere. And luckily for this one (which may or may not actually be a problem for you), we've got Headscale</a> as our solution. Headscale's a self-hostable, open-source alternative to the Tailscale control server, and aims to 'provide self-hosters and hobbyists with an open-source server they can use for their projects and labs'.
Installing on NixOS #</a></h2>
Moving on to installing and setting up Headscale on NixOS.
# ... { # ... services.headscale = { enable = true; address = "0.0.0.0"; port = 7070; settings = { logtail.enabled = false; server_url = "https://headscale.devraza.duckdns.org"; dns_config.base_domain = "devraza.duckdns.org"; }; }; # ... } </code></pre> This starts up the headscale</code> systemd service on our host machine at port 7070</code>. After that, we make Headscale available over the clearnet with an NGINX reverse proxy, per the usual:
{ services.nginx = { enable = true; virtualHosts = { "headscale" = { addSSL = true; serverName = "headscale.devraza.duckdns.org"; sslCertificate = ./services/nginx/certs/subdomains/fullchain.pem; sslCertificateKey = ./services/nginx/certs/subdomains/privkey.pem; # Headscale proxy locations."/" = { proxyPass = "http://127.0.0.1:${toString config.services.headscale.port}"; proxyWebsockets = true; }; }; }; }; } </code></pre> And that's it. A self-hosted, truly open-source Wireguard®-based VPN is now at your fingertips. Enjoy! Oh, but please read the conclusion before doing that:
Conclusion#</a></h1>
For those of you who wish to have access to something like Tailscale but value your privacy above all, you would genuinely be greatful for Headscale. However, I've found that some are fine with what Tailscale does provide in regards to FOSS, and are satisfied by the raw convenience and simplicity of a non-selfhosted Tailscale control server - exactly what it hopes to provide, as shown by their self-description on their website: 'a zero-config, no-fuss VPN [provider]'.
Or you could just settle with bare Wireguard®.

Host your own private search engine with SearXNG

2023-12-31T00:00:00+00:00

Introduction #</a></h1>

SearXNG</a>, put in its own words, is a 'free internet metasearch engine'. Note that it describes itself as a metasearch engine specifically - unlike your traditional search engine like Google or Bing, SearXNG does things a little bit differently: It aggregrates the results produced by search services like those aforementioned, and feeds them back to you.

Because of this key detail and a great deal of effort by those who've helped shape it, SearXNG protects your privacy, and does so very well:

Private data from requests going to the search services it aggregrates results from is removed</li>
It does not forward anything to any third parties through search services</li>

Private data is also removed from requests going to the results pages</li> </ul> Furthermore, SearXNG can be configured to use Tor</a>.
However, the aspect of privacy isn't the only great selling feature of the engine; from my use of the engine so far, it's also great at...searching (is that a surprise?). The fact that it's a metasearch engine plays a key role in this, as it provides SearXNG the ability to pull content more efficiently and gives you the ability to further tailor your experience.
Setting up SearXNG#</a></h1>
Installing the service #</a></h2>
As you may have expected if you've used NixOS for a while, searxng is packaged and has a service on NixOS. This makes setting it up just that much easier.
To get started, place somewhere in your system config the following:
{ # ... services.searx = { enable = true; settings = { server = { port = 8888; bind_address = "127.0.0.1"; secret_key = "@SEARX_SECRET_KEY@"; base_url = "https://search.devraza.duckdns.org/"; # replace with wherever you want to host yours }; }; }; # ... } </code></pre> The snippet above starts the searx</code> systemd service for listening on port 8888</code>, and assumes a base_url</code> of https://search.devraza.duckdns.org</code>. Now that we've got the actual searx</code> instance running, we can now set up a reverse proxy allowing the service to be accessed remotely (whether this is within your local network or across the internet is up to you).
Setting up a reverse proxy#</a></h2> What is a reverse proxy?#</a></h3> Before I get started with the technical details of setting this up, I'd like to briefly clarify what a reverse proxy exactly is (to my understanding). Let's get the wikipedia definition of reverse proxy out of the way first: [...] a reverse proxy is an application that sits in front of back-end applications and forwards client requests to those applications. [...] </blockquote> However, you might be confused as to what this actually means; I'll give an example of the usage of reverse proxies to better explain this: Suppose you've got a few services running on a server (for demonstration purposes, let's name these x</code>, y</code> and z</code>), each running on their own unique port.</li> Assuming you had a domain, and wanted to access all of these services from their own unique sub-domains (e.g. x.yourdomain.com</code>, y.yourdomain.com</code> and z.yourdomain.com</code>), you would have to use a reverse proxy.</li> This reverse proxy would take in requests from clients going to sub-domains, and forward these requests to the appropriate port on your machine for the service being requested.</li> </ul> The concept should be clear now, if it wasn't already. Using NGINX to set up the reverse proxy#</a></h3> NGINX is a popular web server that supports the creation of virtual hosts and the usage of reverse proxies. To accomodate our searx</code> instance, we append the following to our NixOS server configuration: 1</td> { </td></tr> 2</td> # ... </td></tr> 3</td> services.nginx = { </td></tr> 4</td> enable = true; </td></tr> 5</td> # any extra configuration here </td></tr> 6</td> virtualHosts = { </td></tr> 7</td> "search" = { # this can be anything, being an arbitrary identifier </td></tr> 8</td> forceSSL = true; </td></tr> 9</td> serverName = "search.yourdomain.com"; # replace this with whatever you're serving from </td></tr> 10</td> # SearX proxy </td></tr> 11</td> locations."/" = { </td></tr> 12</td> proxyPass = "http://${toString config.services.searx.settings.server.bind_address}:${toString config.services.searx.settings.server.port}"; </td></tr> 13</td> proxyWebsockets = true; </td></tr> 14</td> recommendedProxySettings = true; </td></tr> 15</td> }; </td></tr> 16</td> }; </td></tr> 17</td> }; </td></tr> 18</td> }; </td></tr> 19</td> # ... </td></tr> 20</td> } </td></tr></tbody></table></code></pre> Note The expression highlighted above is used to dynamically adjust the location NGINX will forward requests to, depending on your searx</code> config </div> </blockquote> After saving your changes and rebuilding your server's system configuration (as usual), you should have a working private instance of SearXNG that you can access using the serverName</code> you've given it. Set your browser to use this as your search engine using the relevant documentation (with Firefox this is as easy as right-clicking on the URL after opening up the page and clicking a button). Enjoy! Setting up Zola on NixOS 2023-12-29T00:00:00+00:00 Introduction#</a></h1> Zola</a> is a static site generator (similarly to the infamous Hugo</a>, which you may have already heard of) and is written in Rust. It also happens to be the framework that this site is built on! This blog post is a guide on setting up the site engine on NixOS specifically. Installation#</a></h1> Installing the package#</a></h2> zola</code> is packaged in the nix package repository, so you just declaratively add the package to your configuration as usual: For the purposes of this guide, zola can be installed either as a system or user package. As a system package:</li> </ul> { pkgs, ... }: { # ... environment.systemPackages = with pkgs; [ zola # Append the package name to the list ]; # ... } </code></pre> As a user package (with home-manager):</li> </ul> { pkgs, ... }: { # ... home.packages = with pkgs; [ zola # Append the package name to the list ]; # ... } </code></pre> Now that zola</code> itself is installed, we can move on setting up the pages it serves - continue reading... Setting up a theme#</a></h2> Zola actually has a section of its website showcasing several community-made themes which you can choose from to be the theme for your static site here</a>. Simply choose a theme that you like (demos are usually available for each theme listed) and follow its appropriate documentation to set it up - this site uses a version of the serene theme</a> with my custom colours. Custom themes You can also make your own theme if that better suits you (I recommend giving the documentation</a> a read if so). </div> </blockquote> Setting up NGINX#</a></h2> After selecting a theme (or making your own) you should now have a directory somewhere on your server containing your static site. For the following snippet, we'll assume this is at /var/lib/blog</code>. NGINX</a> is a popular webserver which we're going to use for the purposes of hosting and serving our site. To do so, append the following somewhere in your configuration: # ... { # ... services.nginx = { enable = true; virtualHosts = { "blog" = { forceSSL = true; serverName = "blog.devraza.duckdns.org"; # replace this with wherever your site will be root = "/var/lib/blog/public"; # the path to the `public` folder in our site directory }; }; }; # ... } </code></pre> Finishing up#</a></h1> You should now have your own static site built with Zola! You can use this for a bunch of things, like: Your personal blog (as I've done)</li> A way to showcase your projects (as I've also done</a>)</li> Hosting documentation (check out this Zola theme</a>, for example)</li> </ul> Help, my changes aren't sticking! When you make new markdown files (or any other changes to the structure of your site), remember to run zola build</code> in your site directory (/var/lib/blog</code>) for the changes to build into the actual site. </div> </blockquote>

1</td>	{ </span></td></tr>
2</td>	</span># ... </span></td></tr>
3</td>	</span>services</span>.</span>nginx </span>= { </span></td></tr>
4</td>	</span>enable </span>= true; </span></td></tr>
5</td>	</span># any extra configuration here </span></td></tr>
6</td>	</span>virtualHosts </span>= { </span></td></tr>
7</td>	</span>"search" </span>= { </span># this can be anything, being an arbitrary identifier </span></td></tr>
8</td>	</span>forceSSL </span>= true; </span></td></tr>
9</td>	</span>serverName </span>= </span>"search.yourdomain.com"</span>; </span># replace this with whatever you're serving from </span></td></tr>
10</td>	</span># SearX proxy </span></td></tr>
11</td>	</span>locations</span>.</span>"/" </span>= { </span></td></tr>
12</mark></td>	</span>proxyPass </span>= </span>"http://${toString </span>config</span>.</span>services</span>.</span>searx</span>.</span>settings</span>.</span>server</span>.</span>bind_address</span>}:${toString </span>config</span>.</span>services</span>.</span>searx</span>.</span>settings</span>.</span>server</span>.</span>port</span>}"</span>; </span></mark></td></tr>
13</td>	</span>proxyWebsockets </span>= true; </span></td></tr>
14</td>	</span>recommendedProxySettings </span>= true; </span></td></tr>
15</td>	}; </span></td></tr>
16</td>	}; </span></td></tr>
17</td>	}; </span></td></tr>
18</td>	}; </span></td></tr>
19</td>	</span># ... </span></td></tr>
20</td>	} </span></td></tr></tbody></table></code></pre> Note</strong></p> The expression highlighted above is used to dynamically adjust the location NGINX will forward requests to, depending on your `searx</code> config</p> </div> </blockquote>` `After saving your changes and rebuilding your server's system configuration (as usual), you should have a working private</em> instance of SearXNG that you can access using the serverName</code> you've given it.</p>` `Set your browser to use this as your search engine using the relevant documentation (with Firefox this is as easy as right-clicking on the URL after opening up the page and clicking a button). Enjoy!</p>` Setting up Zola on NixOS 2023-12-29T00:00:00+00:00 Introduction#</a></h1> Zola</a> is a static site generator (similarly to the infamous Hugo</a>, which you may have already heard of) and is written in Rust. It also happens to be the framework that this site is built on!</p> This blog post is a guide on setting up the site engine on NixOS specifically.</p> Installation#</a></h1> Installing the package#</a></h2> zola</code> is packaged in the nix package repository, so you just declaratively add the package to your configuration as usual: For the purposes of this guide, zola can be installed either as a system or user package.</p> As a system package:</li> </ul> { </span>pkgs</span>, ... }: { </span> </span># ... </span> </span>environment</span>.</span>systemPackages </span>= with </span>pkgs</span>; [ </span> </span>zola </span># Append the package name to the list </span> ]; </span> </span># ... </span>} </span></code></pre> As a user package (with home-manager):</li> </ul> { </span>pkgs</span>, ... }: { </span> </span># ... </span> </span>home</span>.</span>packages </span>= with </span>pkgs</span>; [ </span> </span>zola </span># Append the package name to the list </span> ]; </span> </span># ... </span>} </span></code></pre> Now that zola</code> itself is installed, we can move on setting up the pages it serves - continue reading...</p> Setting up a theme#</a></h2> Zola actually has a section of its website showcasing several community-made themes which you can choose from to be the theme for your static site here</a>.</p> Simply choose a theme that you like (demos are usually available for each theme listed) and follow its appropriate documentation to set it up - this site uses a version of the serene theme</a> with my custom colours.</p> Custom themes</strong></p> You can also make your own theme if that better suits you (I recommend giving the documentation</a> a read if so).</p> </div> </blockquote> Setting up NGINX#</a></h2> After selecting a theme (or making your own) you should now have a directory somewhere on your server containing your static site. For the following snippet, we'll assume this is at /var/lib/blog</code>.</p> NGINX</a> is a popular webserver which we're going to use for the purposes of hosting and serving our site. To do so, append the following somewhere in your configuration:</p> # ... </span>{ </span> </span># ... </span> </span>services</span>.</span>nginx </span>= { </span> </span>enable </span>= true; </span> </span>virtualHosts </span>= { </span> </span>"blog" </span>= { </span> </span>forceSSL </span>= true; </span> </span>serverName </span>= </span>"blog.devraza.duckdns.org"</span>; </span># replace this with wherever your site will be </span> </span>root </span>= </span>"/var/lib/blog/public"</span>; </span># the path to the `public` folder in our site directory </span> }; </span> }; </span> }; </span> </span># ... </span>} </span></code></pre> Finishing up#</a></h1> You should now have your own static site built with Zola! You can use this for a bunch of things, like:</p> Your personal blog (as I've done)</li> A way to showcase your projects (as I've also done</a>)</li> Hosting documentation (check out this Zola theme</a>, for example)</li> </ul> Help, my changes aren't sticking!</strong></p> When you make new markdown files (or any other changes to the structure of your site), remember to run zola build</code> in your site directory (/var/lib/blog</code>) for the changes to build</em> into the actual site.</p> </div> </blockquote>

Conclusion #</a></h1>
The information above, which I deem accurate, is there. What I suggest be taken away from this is pretty much the same as what is was for my blog post on hoaxes</a> - do some fact-checking!</strong></p>

Setting up Zola on NixOS

Blog Posts

Home server security

Selecting hardware for a (home) server

Misconceptions about NFC

Take control of tailscale with headscale

An overview on hoaxes

Host your own private search engine with SearXNG