Feuerfest

Like many IT people, I pay to have my own server for personal projects and self-hosting. As such, I am responsible for securing these systems as they are, of course, connected to the internet and provide services to everyone. Like this blog for example. So I often read about people installing Fail2Ban to "increase the security of their systems".

And every time I read this, I am like this popular meme from the TV series Firefly:

As I don't share this view of Fail2Ban - in fact, I'm against the view that it improves security - but I'll keep quiet, knowing that starting this discussion is simply not helpful. Nor that it is wanted.

For me, Fail2Ban is just a log cleanup tool. Its only benefit is that it will catch repeated login attempts and deny them by adding firewall rules to iptables/nftables to block traffic from the offending IPs. This prevents hundreds or thousands of extra logfile lines about unsuccessful login attempts. So it doesn't improve the security of a system, as it doesn't prevent unauthorised access or strengthen authorisation or authentication methods. No, Fail2Ban - by design - can only act when an IP has been seen enough times to trigger an action from Fail2Ban.

With enough luck on the part of the attacker - or negligence on the part of the operator - a login will still succeed. Fail2Ban won't save you if you allow root to login via SSH with the password "root" or "admin" or "toor".

Granted, even Fail2Ban knows this and they write this prominently on their project's GitHub page:

Though Fail2Ban is able to reduce the rate of incorrect authentication attempts, it cannot eliminate the risk presented by weak authentication. Set up services to use only two factor, or public/private authentication mechanisms if you really want to protect services.

Source: https://github.com/fail2ban/fail2ban

Yet, the number of people I see installing Fail2Ban to "improve SSH security" but refusing to use public/private key authentication is staggering.

I only allow public/private key login for select non-root users specified via AllowUsers. Absolutely no password logins allowed. I've changed the SSH port away from port 22/tcp and I don't run Fail2Ban. As with this setup, there are not that many login attempts anyway. And those that do tend to abort pretty early on when they realise that password authentication is disabled.

Although in all honesty: Thanks to services like https://www.shodan.io/ and others finding out the changed SSH port is not a problem. There are dozens of tools that can detect what is running behind a port and act accordingly. Therefore I do see my fair share of SSH bruteforce attempts. Denying password authentication is the real game changer.

So do yourself a favour: Don't rely on Fail2Ban for SSH security. Rely on the following points instead:

• Keep your system up to date! As this will also remove outdated/broken ciphers and add support for new, more secure ones. All the added & improved SSH security gives you nothing if an attacker can gain root privileges via another vulnerability.
• AllowUsers or AllowGroups: To only specified users to login in via SSH. This is generally preferred over using DenyUsers or DenyGroups as it's generally wiser to specify "what is allowed" as to specify "what is forbidden". As the bad guys are pretty damn good in finding the flaws and holes in the later one.
  • If you don't see what I mean, read this hilarious article about how "virtual Minecraft Denmark" was blown up with minecarts using TNT: https://www.gamespot.com/articles/danish-government-creates-entire-country-in-minecraft-users-promptly-blow-it-up-and-plant-american-flag/1100-6419412/
• DenyUsers or DenyGroups: Based on your groups this may be useful too but I try to avoid using this.
• AuthorizedKeysFile /etc/ssh/authorized_keys/%u: This will place the authorized_keys file for each user in the /etc/ssh/authorized_keys/ directory. This ensures users can't add public keys by themselves. Only root can.
• PermitEmptyPasswords no: Should be self-explaining. Is already a default.
• PasswordAuthentication no and PubkeyAuthentication yes: Disables authentication via password. Enabled authentication via public/private keys.
• AuthenticationMethods publickey: To only offer publickey authentication. Normally there is publickey,password or the like.
• PermitRootLogin no: Create a non-root account and use su. Or install sudo and use that if needed. See also AllowUsers.

gethomepage.dev: https://gethomepage.dev/assets/homepage_demo_clip.webp

homepage (GitHub) - the dashboard I use to keep an overview of all the services I run in my LAN released their 1.0 version yesterday on March 14th 2025.

With that they introduced a new parameter to limit which hosts can show the dashboard. I haven't yet read about why this was introduced, but it's fixed quickly.

As Watchtower does all the maintenance work for the containers running on my installation of Portainer I was already greeted with the following error message:

In the logfile for the container running homepage I saw the following error:

[2025-03-15T16:54:13.497Z] error: Host validation failed for: portainer.lan:3000. Hint: Set the HOMEPAGE_ALLOWED_HOSTS environment variable to allow requests from this host / port.

As I don't use a separate IP or hostname for the dashboard and just forward the port 3000/tcp towards the homepage-container I access it using the hostname of my Portainer host. Therefore this message makes sense.

Luckily the documentation for the newly required environment variable is already on their homepage: https://gethomepage.dev/installation/#homepage_allowed_hosts

Armed with this knowledge we can change the stack file (Portainers term for a docker-compose file - not to be confused with the docker swarm command docker stack) and introduce the HOMEPAGE_ALLOWED_HOSTS parameter. I added the IP-address too, in case the DNS servers in my LAN should stop working.

services:
  homepage:
    image: ghcr.io/gethomepage/homepage:latest
    container_name: homepage
    ports:
      - 3000:3000
    environment:
      HOMEPAGE_ALLOWED_HOSTS: 192.168.178.21:3000,portainer.lan:3000
    volumes:
      - /opt/docker/homepage.dev/config:/app/config # Make sure your local config directory exists
      - /var/run/docker.sock:/var/run/docker.sock # (optional) For docker integrations
      - /opt/docker/homepage.dev/icons:/app/public/icons # icons, reference as /icons/picture.png in YAML

After that just hit the "Update the stack" button and it's working again.

Screenshot from my old Heimdall dashbaord https://admin.brennt.net/bl-content/uploads/pages/cb8f048b5b607d6bbe95db2008f4ad14/heimdall-dashboard.jpg

When you are in IT chances are high you've got a homelab for your selfhosted applications or just a spare RaspberryPi to try out new software or configurations. After all not having to care about damaging or interrupting anything when trying out new stuff is a relaxing thought.

How do you maintain an overview of your environment? Easy: Just use a dashboard.

There are numerous ones and I'll list a few at the bottom of these article. However the main reason for this blog post is that I recently switched from Heimdall (Website, GitHub) to homepage (Website, GitHub) - Yes, their project name could be better in terms of searchability. Reasons were that Heimdall development simply isn't moving forward and it turned out that the layout options are too limited when the number of services grew.

homepage is just offering more options here.

Screenshots

This was my old Heimdall dashboard:

And here is a screenshot of my new homepage dashboard:

I especially like that homepage supports tabs which then displays different (service-)widgets according to the tabs configuration. This saves so much space.

Icons

When you have a dashboard you want some eye-catchers. Small, easily identifiable logos which support you navigating your dashboard. Now, of course I could go to Google search & download each picture on my own. Alas this is a cumbersome process and there are way better options.

Let me introduce you to: Self-Hosted Dashboard Icons (selfh.st/icons/)

This is a site which gathers all sorts of logos. No matter if they are from vendors, projects, brands or various other logos. Basically it's your one-stop-shop for everything regarding logos. And you even can choose between PNG, SVG and WEBP.

homepage even has means to include the icons right away from their site (read https://gethomepage.dev/configs/services/#icons). Although I still opted to download them via wget into the mounted Docker volume.

Another site is Simple Icons. They offer only minimalized black & white icons. As I wanted some color I didn't use them.

And the third option is Material Design Icons by pictogrammers.com. However they are discontinuing their offering of brand logos. This effectively means that many IT & software related logos will vanish. As they are also just black & white I didn't use them too.

But with these 3 sites you have enough options to choose from!

Other dashboards

In case you don't like Heimdall and homepage I can provide you with a small list of other dashboards you can use. Feel free to add a comment in case I missed one!

• Dashy: https://github.com/lissy93/dashy
• Fenrus: https://github.com/revenz/Fenrus
• Flame: https://github.com/pawelmalak/flame
• Heimdall: https://github.com/linuxserver/Heimdall
• Homarr: https://github.com/ajnart/homarr
• Homepage: https://github.com/gethomepage/homepage
• Homer: https://github.com/bastienwirtz/homer
• Organizr: https://github.com/causefx/Organizr