The security quagmire that is selfhosting

The security quagmire that is selfhosting
Photo by David Rangel / Unsplash

Preface

Selfhosting and how to limit the exposure of your trusted network.

Today it becomes increasingly hard to avoid the vendor lock-ins that treading the waters are murky and full of predators out to kill you.
When you start delving into the idea of self hosting applications, functions and services, the check list becomes a very long one, and unfortunately security and exposure of your trusted network doesn’t always come to mind.

It is very exciting to see how things comes together when you self host things, and here in lies the danger where putting services and apps into DMZ might be a tempting aspect to avoid all the challenges around firewalls and other security measures.

Far too many apps and guides out there only shows you how to deal with the app and the internet connection where other aspects of it is totally glossed over or not mentioned at all, such as nefarious scripts running in the containers etc.
How do you detect this? How can you protect yourself against this? Are there any mitigations that makes sense around this?

Securing the perimeter

We often see that it is recommended to only open the ports that are required, this is sound advice, but not always sufficient.
What a better option is is to not have any inbound connections to you network configured at all, only do outbound tunnels that allows for internal access of resources.
There are quite a few ways of doing this, and today it seems that Cloudflare Argo Tunnel is the preferred solution for this, however there are other options out there like various VPN solutions (I myself use wireguard for this purpose).

I should also practice what I preach, but I have 2 ports exposed on my network, and those are port 80 and 443, which are forwarded to my local instance of Nginx Proxy Manager and the management of this instance is not exposed externally at all.
What I should be doing is standing up tunnels that are outbound for the services that needs to be exposed to the outside world.

The problem that we face here is… I am lazy and do not feel like doing a lot of rework to get things done.
I have IDS and IDP present on my perimeter as well as a robust firewall, DNS filtering and other goodies helping keeping me and my family secure, but this is not always enough as the best tools are the ones we teach our immediate circle.
If we can educate our immediate circle about good online hygiene and what sings to look for, quite a bit of the heavy lifting is already done there.

It is a shame, that my family looked at me weirdly 20 years ago when I started talking about being safe online, not using the same passwords and identity on all the services etc.
I know it was something that was not easy for them to admit just a few short years ago where the resounding message was “You were right, it is dangerous out there and thankfully you instilled some good practices that we can build on”.

Limiting exposure and services

Not everything needs to be exposed to the outside world, certain services, only you and your internal network needs access to.
With the understanding of that comes the realisation that not everything needs to be on the internet… Not everything needs to be accessible at all times without extra security measures.
We need to protect ourselves and with this we need to understand the requirements we have, does the HomeAssistant UI need to be accessible outside of my home without additional layers of security?
I rather not have strangers snoop anything on my network and then sit there and being able to turn my lights on or off… Who would even want that? (Unless you are setting up a honeypot )

I would like to think of this as: How much skin do I expose to the sun? How much skin do I actually need to expose to the sun? And if I expose more, I put on SPF to ensure I stay safe and reduce the risks.

Trusted sources of applications and information.

Today unfortunately, people are not critical enough of where they source information nor applications and services.
This can create a lot of problems and should not be the norm when standing up services at home that has the potential to make your day a not so good one.
We see that many repositories, apps and services recommends that you wget/curl a script and | to bash directly as root or via sudo… This is a very bad idea and horrible practice when looking at the security aspects of it.
Make sure that you download the script, investigate what it does and how it does it’s thing, DO NOT blindly trust what is written in the instructions for it.
Be critical, stay vigilant!

I would only use the outline method above if it was my own scripts and such where I can fully trust them to be unchanged from when I created them and keep them safe in my own repository.
Everything else requires a much higher level of scrutiny and vigilance before I will even dream of executing anything, and this is the same for whichever operating system you are dealing with, be it Windows, Linux or Mac OS.

Philosophical Actions…

  1. Do not expose what is not needed.
  2. Do not use the same username on all services.
  3. Do not use the same password on all services (use a password manager if possible).
  4. Be critical of all information you received about the service or app.
  5. Follow up with all other best practices.
  6. Keep your devices updated with the latest firmware.