Much appreciated stranger. Hopefully now I can stop exposing the two most attacked ports in existence from my LAN XD.

This

Tailscale is the super easy version of this. Otherwise make sure your containers don’t have root etc. block inter container networking as much as you can. Lots of relatively simple things work unless you’re actually an interesting target.

I moved all my files to one share. At the root of that share is a robot_readme.md file that lists all the contents of my share with a note that says read everything you want, you will anyway.

They left a note that said “nah, bruh, you’re good”.

I guess I’m okay.

Maybe not, but maybe, just maybe, the people with these exploits aren't running round attacking Joe bloggs personal photo album server to steal some photos, but in fact are only using the exploit very carefully and sparingly so as not to be detected, and only targeting high value and highly confidential services, where even if they were hacked or a specific exploit was deployed, either are too big to notice, or to proud to divulge the fact they lost some data 🤷

You're determined that I worry about my public server aren't you? Your initial question wasn't actually a question, but just a trap for you to lure me into to be converted to your way of thinking?!?! rumbled! 😂 There are always experts to quote for any argument. Personally, I don't feel any more vulnerable than before ai decimated the security landscape.

I'm re-thinking a few things, mostly moving exposed services onto a VM or two that are on their own VLAN, and don't contain any important data (it would be my website, gameservers like Minecraft, etc..). I might move to podman as well so nothing has a possibility of running as root, docker can run rootless but that setup seems more confusing to me.

I already use a VPN via Wireguard on my router for access to my private services when out of the house, so my changes are just separating the public from the private as much as possible on the server side of things..

Essentially if someone manages to drop a crypto miner or something on my website that's fine, I'll get an alert pretty quickly through Beszel that the server load is high and I can go roll back a backup or whatever. I just want to make sure there's no access to anything else for them.

I have my ops agent constantly checking SBOMs against current CVEs and if something triggers, I get a report with severity and repair options researched. I can then decide how I want it to proceed. I'm much less concerned about internal only services. SBOMs are refreshed after updates for future checks.

I went the other way this week. Nothing public anymore, and the only thing open on the WAN is the WireGuard port. I lost the easy Jellyfin share links for family and gained sleep. The PHP mess made the call easy.

You should also use a default self-signed cert for something generic like "localhost" on your reverse proxy so random IP scan don't see any domain when they hit your IP, but legitimate queries coming through the domain name still see the right cert.

Ipv6 only hosting still seems as good as an airgap😅

I patch as soon as possible and If I were to get pwned id restore a backup and patch again. All my public facing services are sitting in a own, isolated network so an attacker wouldnt get far.
If my Hypervisor got compromised id do the same.
Id be very fucked if something got into my Proxmox Backup Server tho.

In my case I have defined a fallback in Caddy so any request that doesn't match one of the explicitly handled domains will be an error.

I use a route {} block with handle {} blocks inside it, and the last handle has an error directive in it.

https://*.example.com {
  route {
    @foo host "foo.example.com"
    handle @foo {
      reverse_proxy http://whatever:12334/
    }
    ... more proxy hosts ...
    handle {
      error 400
    }
  }
}

The route block is essential here because handlers inside a route block are processed strictly in the order they are defined. Outside route blocks that is not true, caddy will try to optimize and can execute directives in any order it sees fit.

It certainly isn't good to depend on it but security by obscurity is your first and probably most important line of defense. When these vulnerabilities come out they need to know your service exists to exploit it.

The best way to do that is to setup a reverse proxy to reject invalid hostnames. A single port is all you need exposed for multiple web services, and the IP scans won't find the script kiddies anything valuable. Be careful with lets encrypt, there is a public journal of all issued certs, so make sure to get yourself a wildcard cert so that you aren't advertising your valid hostnames to the world.

Use the reverse proxy to put basic auth in front of your services (if they can handle that). Basic auth is very simple, no web forms to attack, just a single header. If your php site is vulnerable they won't ever be able to even attempt to reach it without a valid username/password.

I've got a mix of containers and VMs behind that reverse proxy. The containers have network security groups around them limiting network access. The VMs are in a Harvester hypervisor with KubeOVN for software defined networking. That means each VM is in its own subnet with network security groups around the subnet preventing any unnecessary network access.

For machines/containers that need Internet access I have a Squid proxy with an explicit whitelist of allowed URLs so that the machines can't reach out to unauthorized sites to download their malware or contact command and control nodes.

Unattended updates for the VMs, and FluxCD keeping helm charts up to date hourly for the containers. For my own containers, weekly scheduled container rebuilds.

I do have one public website that I host for a friend (indexed by search engines so the sites name is known to the world). My friend had originally deployed that as a WordPress site, but WordPress/PHP don't have the best security track record so I was concerned about that. The site was pretty simple so I recreated it as 100% static content, so now the attack surface is just a nginx container with a read-only filesystem.