They aren't on the internet mainly.
My router (opnsense) has a wireguard server which is how I access things when out of the house.
I do have a minecraft server for my friends and I, but that VM is on its own network isolated from everything else.
To add some points, that I do:
I put up a sign that says, "No hackers allowed plz"
How has that been going?
"All your containers are belong to us."
As many others have said, not allowing inbound WAN connections into my LAN is an important step. I also run k3s on my server with Calico as the CNI and make heavy use of network policies to keep anything I’m running from misbehaving. That, along with easy ingress makes k3s worth it for me over Docker Compose. I use OpenWRT on my router and force certain devices to run through a VPN and block other devices from the internet entirely.
Some I haven't yet found in this thread:
127.0.0.1:8080:8080)Does adding 127.0.0.1 make it so only that server can access it or what? I’ve seen that but not understand
Yes. 127.0.0.0 is the localhost. This is the IP the container is listening on. Even if there was no firewall it wouldn't allow any connection except from the host. If it's set to 0.0.0.0 it means it'll allow connections from any IP (which might not be an issue depending on your setup).
The reverse proxy runs on localhost anyway, so any other IPs have no reason to ever have access.
I assume #2 is just to keep containers/stacks able to talk to each other without piercing the firewall for ports that aren't to be exposed to the outside? It wouldn't prevent anything if one of the containers on that host were compromised, afaik.
Containers can talk to each other without any ports exposed at all, they just need to be added to the same docker network.
I was getting more at stacks on a host talking, ie: you have a postgres stack with PG and Pgadmin, but want to use it with other stacks or k8s swarm, without exposing the pg port outside the machine. You are controlling other containers from interacting except on the allowed ports, and keeping those port from being available off the host.
You can do that by joining the containers to the same docker network, you don't need to expose ports even to localhost.
I mustn't be communicating well, but that's fine.
It's mostly to allow the reverse proxy on localhost to connect to the container/service, while blocking all other hosts/IPs.
This is especially important when using docker as it messes with iptables and can circumvent firewall like e.g. ufw.
You're right that it doesn't increase security on case of a compromised container. It's just about outside connections.
OK, yah, that's what I was getting at.
Disable password authentication on SSH
Enable firewall and block all ports you're not using(most firewalls do this by default)
Switch to a LTS kernel(not security related, but it keeps things going smooth... Technically it is safer since it gets updated less often so it is a bit more battle tested? Never investigated whenever a LTS kernel is safer than a standard one)
Use Caddy to proxy to services instead of directly exposing them out
HTTPS for web stuff(Caddy does it automatically)
Caddy or any other (reputable) reverse proxy. I think Nginx Proxy Manager would be best for beginner thanks to GUI.
This and fail2ban
Anything else?
There are ip lists that let you iptables drop all traffic from China and Russia.
Strongly recommend.
My UDM has this capability. I've blocked quite a few countries that it logged as trying to get into my network. Great little internet cylinder.
Have the rack mounted one, I usually roll my own router but I'm glad to have someone else making sure I don't do anything stupid for security.
It's not perfect, but it's peace of mind.
I was auto banning all countries but my own but now I’m hosting one resource that has an audience including Chinese…
Good advice outside of this use case! :)
Yeah, there were other countries to ban, but those 2 cut my attacks down 90%.
Also consider a honeypot that triggers when anyone tries to ssh it at all.
Dropping instead of blocking might technically be better because it wastes a bit more bot time and they see it as "it doesn't exist" rather than an obsticle to try exploits on. Not sure if that is true though.
For me:
ssh server only with keys
absolutely no ssh forwarding, only available to local network via firewall rules
docker socket proxy for everything that needs socket access
drop non-used ports, limit IPs for local-only services (e.g. paperless)
crowdsec on traefik for the rest (sadly it blocks my VPN IPs also)
Authelia over everything that doesn't break the native apps (jellyfin and home assistant are the two that it breaks so far, and HA was very intermittent so I made a separate authelia rule and mobile DNS entry for slightly reduced rules)
proper umask rules on all docker directories (or as much as possible)
main drive FDE with a separate boot drive with FDE keyfile on a dongle that is removed except for updates and booting to make snatch-and-grabs useless and compromising bootloader impractical
full disk encryption with passworded data drives, so even if a smash and grab happens when I leave the dongle in, the sensitive data is still encrypted and the keys aren't in memory (makes a startup script with a password needed, so no automated startups for me)
For more info, I followed a lot of stuff on: https://github.com/imthenachoman/How-To-Secure-A-Linux-Server
This, but I prefer nginx.
And no real need for tailscale or cloudflare. If you do not like to depend on a third party service, either port forward and ddns or an external vps+wire guard if you have gcnat
This is a valid solution but honestly how is using VPS not depending on third party?
It is, but you are free to switch at any time provider, there is no technological lock in like with cloudflare or tailscale (i know there is a free self hostable version, not talking about that).
So just rent a new one and switch your wireguard there.
One thing I do is instead of having an open SSH port, I have an OpenVPN server that I’ll connect to, then SSH to the host from within the network. Then, if someone hacks into the network, they still won’t have SSH access.
Thanks :)
I do the same, but with Wireguard instead of OpenVPN. The performance is much better in my experience and it sucks less battery life.
I’ve been meaning to learn how to make my own
I found the guide/examples on their website a bit irritating at first (that's on me) but it works well once understood and configured.
Thanks! I’ll do that
I don't put it on the Internet.
I have automatic updates enabled and once in a while I scan with Nessus. Also I have backups. Stuff dying or me breaking it is a much greater risk than getting hacked.
I agree - I don’t expose anything to the internet other than the WireGuard endpoint.
I’m only hosting services that my immediate family need to access, so I just set up WireGuard on their devices, and only expose the services on the LAN.
I used to expose services to the internet, until one of my #saltstack clients was exploited through a very recent vulnerability I hadn’t yet patched (only a week or so since it was announced). I was fortunate that the exploit failed due to the server running FreeBSD, so the crontab entry to download the next mailicious payload failed because wget wasn’t available on the server.
That’s when I realised - minimise the attack surface - if you’re not hosting services for anyone in the world to access, don’t expose them to everyone in the world to exploit.
I don’t expose anything to the internet other than the WireGuard endpoint.
This is the way
If I need remote access, I just log into NPM and I have certain URL's created for Plex, or Sonarr, Radarr etc. No issues so far.
Fail2ban config can get fairly involved in my experience. I'm probably not doing it the right way, as I wrote a bunch of web server ban rules
anyone trying to access wpadmin gets banned, for instance (I don't use WordPress, and if I did, it wouldn't be accessible from my public facing reverse proxy).
I just skimmed my nginx logs and looked for anything funky and put that in a ban rule, basically.
Thanks!
Here’s the setup I followed. It seems like it might take away some manual work for you: https://m.youtube.com/watch?v=Ha8NIAOsNvo&t=1294s&pp=ygUIRmFpbDJiYW4%3D
Tailscale and being at my house is the only two ways in so I feel those are pretty good for me.
My new strategy is to block EVERY port except WireGuard. This doesn't work for things you want to host publicly ofc, like a website, but for most self host stuff I don't see anything better than that.
My new strategy is to block EVERY port
Wow! All 65535 +/-, in and out? That's one way to skin a cat.
ez pz:
#!/usr/sbin/nft -f
table inet filter {
chain input {
type filter hook input priority raw; policy accept;
iif "lo" accept
ct state established,related accept
iif "enp1s0" udp dport 51820 accept
iif "enp1s0" drop
}
chain forward {
type filter hook forward priority raw; policy accept;
iif "lo" accept
ct state established,related accept
iif "enp1s0" udp dport 51820 accept
iif "enp1s0" drop
}
chain output {
type filter hook output priority raw; policy accept;
}
}
I've seen it done as such:
sudo ufw deny out 1:19/tcp sudo ufw deny out 1:19/udp sudo ufw deny out 22:52/tcp sudo ufw deny out 22:52/udp sudo ufw deny out 54:79/tcp sudo ufw deny out 54:79/udp sudo ufw deny out 81:122/tcp sudo ufw deny out 81:122/udp sudo ufw deny out 124:442/tcp sudo ufw deny out 124:442/udp sudo ufw deny out 444:65535/tcp sudo ufw deny out 444:65535/udp
But your way seems a bit more elegant
use a cheap vlan switch to make an actual vlan DMZ with the services' router
use non-root containers everywhere. segment services in different containers
Default block for incoming traffic is always a good starting point.
I'm personally using crowdsec to good results, but still need to add some more to it as I keep seeing failed attacks that should be blocked much quicker.
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!