Guiorgy

I’ve also seen some sites use POWBlock, though, don’t know anything about it.

WireGuard is stateless, so running it “on” 24/7 is cheap, set it up once for them and leave it on, ideally they wouldn’t notice a thing.

Proxmox VM snapshots and backups, plus proxsave I assume?

I actually did that. Or well, I was planning to upgrade the Debian version and instead of doing it in place I replaced the drive (kept the old around for a while just in case) and did a clean install. I didn’t make any new backups or moved configs or anything outside what I already had, the system was back to operations faily quickly. The main reason, I have a markdown file describing every configuration and recovery step needed to get a fresh system to a fully working state in case of a disaster, and my test showed that it worked great. It does take a bit of effort to keep it up-to-date, but as shown, really worth it, and it douples as a small wiki for accumulated knowledge. I do wish to play with Ansible at some point if I have the time, but this works for now.

Wouldn’t be surprised if the big guys got first dibs before everyone else

Synology had a critical system and PHP package update yesterday, could it be related 🤔

I mean, unattended upgrades has it’s own config file where you can specify when to schedule a reboot (when needed), which you’d usually do in off-hours like 2 AM your local time, so changing the Systemd unit activation time seems like the wrong fix.

For frequently changing data hourly up to 24, daily up to 7, weekly upto 4, monthly up to 12.

For daily changing data daily up to 7 and etc. as above.

For seldom changing data a backup every 3 days with rotation based on a storage quota, and retention of manually held samples.

Did you read it to the end?

Without root user login, the attacker would have to guess not only the password to the user but also the username (hopefully it’s not something simple like admin), and once you are logged in you can use sudo -i to chage into root, which will require a password, therefore, we also disable password login so if someone does manage to somehow compromise the SSH user, they’d still need the password to become root.

You could spin a publicly exposed WireGuard daemon firewalled to allow peers access to the non-public SSH port only, which would result in double encryption, but would give you the peace of mind that an attacker would have to compromise both at the same time, which is very unlikely. Plus, WireGuard is very cheap to deploy and produces no logs. We use that model in my office to access our server.

Not in the US, at work we pay 6 times the rate I pay at home for 1/6 the speed I get at home, everyone hates our office internet speed 😂, at least it’s static do we can host stuff

Either use a dynamic DNS service, as many others have mentioned and probably easiest, or, assuming you only want yourself to have access to the services, another option is to use something like Tailscale or a WireGuard/FRP instance in a static VPS as the rendezvous point.

I was flat out rejected by my ISP to have a static IP, though I only had it changed once since I started hosting services, so ahatever.

The way a reverse proxy works is to literally stand in the middle of a connection, so either side only sees them communicating with the proxy, oblivious to the actual endpoint. The only “solution” to this, though it’s more of a hack really, is to somehow send the original IP as additional data in a way that both sides agree on, e.g. the X-Forwarded-For header as others have mentioned, however, as I’ve said, both sides need to support and aggree with that, so you may have to find a setting/config to enable on the services behind the proxy. Think of it this way, if services blindly trusted that header and you weren’t using a reverse proxy, a bad actor could send a request to your service with that header included thereby spoofing their identity in your logs, therefore, this kind of thing is usually opt-in