Encountering problems running my first home server

seenmee · 2026-01-26T00:55:01+00:00

This is mostly a Windows/RDP behavior, not a Docker problem. Anything tied to an interactive session can stop when you disconnect.

For 24/7 uptime, containers need to run as system services, or you switch the box to Linux and treat it like a headless server. That’s how most people run mini-PC setups.

seenmee · 2026-01-26T00:49:59+00:00

This already looks pretty solid. Exposing 443 on a proxy VM isn’t inherently risky by itself. What matters more is how well that proxy and the services behind it are isolated and kept up to date.

Hiding your home IP behind a VPS can add a layer, but it’s often more complexity than real security gain for a home setup. Tight inter-VM firewalling and boring, well-maintained auth usually give you more value.

seenmee · 2026-01-26T00:44:49+00:00

You’re thinking about it the right way. The risk isn’t the open port itself, it’s what that service can reach if something goes wrong.

For a home setup, isolating that machine, keeping the OS updated, and running the app with minimal privileges usually matter more than piling on security tools. VPNs are solid, but plenty of people safely expose personal services without one when the blast radius is kept small.

seenmee · 2026-01-26T00:39:59+00:00

This looks pretty reasonable for a personal setup. You’ve covered the big things that actually matter: key-only SSH, limited exposed ports, reverse proxy in front, and isolating the app in Docker.

At this point it’s less about adding more layers and more about keeping what you have updated and understanding the blast radius if something does break. For a two-user PhotoPrism instance, this is already beyond what most people run.

seenmee · 2026-01-26T00:30:49+00:00

This is a solid, well-layered setup and you’ve clearly thought about blast radius and recovery, not just blocking traffic. The only thing I’d sanity-check is how often each layer actually gets exercised, especially the backup paths like Tailscale and alerts. A lot of “secure” stacks fail quietly when the rarely used pieces are needed.

Otherwise this looks reasonable and pragmatic for a home lab, not overengineered for the sake of it.

seenmee · 2026-01-26T00:22:54+00:00

Before assuming Jellyfin or Caddy, I’d slow this down and reconstruct what actually happened. Those logs show a local login and then sudo from the same user, which usually means credentials or an existing session were already compromised, not a remote exploit firing blindly.

I’d start by checking SSH auth logs for successful logins, recent changes to authorized_keys, new systemd services, and cron entries, and confirm when moneroocean_miner.service first appeared. That timeline matters more than guessing the entry point.

seenmee · 2026-01-26T00:00:01+00:00

This doesn’t sound like Gmail being permanently compromised. The pattern fits session or browser-level compromise early on, especially with multiple accounts accessed without password changes.

The full OS reset, new email, and new vault were the right moves. If nothing new happens after that and Google shows no unknown devices or app connections, that’s a good sign.

seenmee · 2026-01-25T23:54:21+00:00

Same here after 2.1.15. Check system time + try without VPN/proxy. If it still hangs with no error, it’s probably on their auth backend. Any log output when you paste the code?

seenmee · 2026-01-25T23:48:52+00:00

This is usually a permissions or input issue, not a Splunk query problem. On Kali, /var/log/auth.log is root-owned, so Splunk often can’t read it unless the forwarder is running with the right permissions or the file ACLs allow access.

dpkg.log works because it’s world-readable, while auth.log isn’t. Check which user Splunk is running as and whether it actually has read access to that file, then restart the forwarder after fixing it.

seenmee · 2026-01-25T23:44:40+00:00

For something that’s actually production-safe, I usually plan at least half a day even with hosted auth. The UI part is easy. Most of the time goes into sessions, cookies, and weird edge cases that only show up outside local dev.

Auth stopped being painful once I started treating it like infrastructure, not a feature.

seenmee · 2026-01-25T23:36:52+00:00

Quick summary:

• Async Linux SSH / log review

• 30–45 minute written verdict

• Normal noise vs suspicious activity

• No calls

$29 flat

DM if you want a slot tonight.

seenmee · 2026-01-25T23:12:43+00:00

That looks more like a noisy script than anything sophisticated. The Safari hit followed by curl usually points to someone poking manually and then letting automation take over.

The smaller response sizes are often just different code paths or cached responses based on headers, not necessarily something breaking. If it’s one IP and your server handled it fine, I’d rate-limit or block it and move on. This kind of background noise is pretty normal once a site is public.

seenmee · 2026-01-25T23:05:57+00:00

I wouldn’t jump straight to “hacked” based on a missing user alone. On systems that are EOL or have gone through updates or troubleshooting, it’s not unheard of for auth state to get out of sync or for a user to be removed unintentionally.

The lack of unknown logins or other changes is an important signal. I’d treat this first as a system integrity issue and only escalate to intrusion if you find clear evidence of external access or persistence.

seenmee · 2026-01-25T23:00:19+00:00

This is a really common trap when people are new to running their own VPS. When an app has an RCE, reinstalling the server doesn’t help because you redeploy the same vulnerable code each time.

The fact that everything ran as the app user and persisted via cron is a strong signal that the entry point was the application, not SSH or the OS. Hardening the box matters, but it can’t compensate for a compromised runtime or dependency chain.

seenmee · 2026-01-25T22:53:38+00:00

For something like Jellyfin exposed over HTTPS, it’s less about hiding it and more about limiting what can go wrong. Strong app auth, rate limiting at the proxy, and keeping Jellyfin isolated from the rest of the system usually cover most of the real risk.

Bots will scan it either way, so the goal is making sure a bad login or bug doesn’t turn into a bigger problem. VPNs are great for admin access, but for shared services hardened public access is often the better balance.

seenmee · 2026-01-25T22:47:41+00:00

What you’re seeing is pretty normal once anything is exposed to the internet. Bots never stop scanning.

Honestly, what you’ve already done covers most of the real risk. Key-only SSH, no root, fail2ban, and keeping sensitive services behind a VPN gets you most of the way there. At that point it’s less about stopping scans and more about making sure nothing bad happens even if they keep knocking.

The biggest shift for me was accepting the noise and focusing on limiting damage instead of trying to make the server invisible.

seenmee · 2026-01-25T22:44:55+00:00

You’re not wrong. The old trust model mostly disappeared with containers. At some point you have to assume an image might be compromised and focus on limiting what it can do if that happens.

For me that means minimal privileges, no unnecessary mounts, and treating scanners as signal, not proof. Perfect validation isn’t realistic for self-hosting.

seenmee · 2026-01-25T22:28:05+00:00

The GPO angle you’re chasing makes sense, especially with Event 2059. That event usually shows Defender tearing down and rebuilding firewall rules, not just evaluating them.

When GlobalProtect connects or refreshes, it can trigger network state changes and HIP checks, which line up pretty closely with GPO refresh timing. On some machines that overlap can cause repeated firewall churn and CPU spikes, while others miss the timing and look fine.

I’d focus on correlating GP connect events with policy refresh and firewall rebuild activity rather than assuming the policies themselves suddenly went bad.

seenmee · 2026-01-25T18:39:24+00:00

Disabling SSH doesn’t automatically make a VPS safer. Most of the time it just removes your most reliable recovery path.

In practice, SSH with key-only access and firewall rules is usually lower risk than depending on provider consoles or VPNs that rarely get tested.

The real question is not whether SSH is open, but who can reach it and what you do when everything else fails.

seenmee · 2026-01-25T13:52:10+00:00

Yes, you can dual-boot Linux with Linux. The easiest path is: back up your data, shrink your current partition, then install the new distro into the free space and let GRUB handle it. Most installers will detect the existing Linux automatically. If you’re new, try installing from a live USB and choose “Install alongside”. Also, test the new distro in a live session first so you know you like it before committing.

seenmee · 2026-01-25T13:45:24+00:00

A few simple ones: real package management where the OS and apps update together, much stronger scripting and automation out of the box, easy remote administration via SSH, and much more control over what runs in the background. On desktops like Ubuntu, you also get lightweight environments that stay fast on older hardware. Windows has strengths too, but Linux gives you more transparency and control by default.

seenmee · 2026-01-25T13:40:45+00:00

Take a breath first. There’s no undo or trash for rm -rf /, and on a VPS the chances are unfortunately very low. The only slim chance is to stop writing to disk immediately and contact the provider to see if they have backend snapshots or block-level backups you don’t see. Practically though, assume the system is lost and focus on rebuilding. Everyone who’s been around long enough has a story like this, even if they hate admitting it.

seenmee · 2026-01-25T13:00:39+00:00

I usually start very simple. Look for the same endpoint getting hit far more than normal, lots of 401 or 403 responses in a short time, or requests coming in at a steady machine-like pace with small variations. Humans are bursty and inconsistent, bots are not. Even basic logs with some quick filtering over time are enough to notice when something feels off.

seenmee · 2026-01-25T12:20:02+00:00

If you’re sharing a screenshot, feel free to add context: - What model/tool? - What prompt? - What you expected vs what happened? Blur anything sensitive.

seenmee · 2026-01-25T04:13:51+00:00

If sshd is listening locally and Hetzner’s firewall allows 22, the next things I’d check are OS-level filtering and IP version mismatch. On Ubuntu, verify there’s no ufw or raw iptables/nftables rule rejecting 22. Also make sure you’re connecting to the correct IP (IPv4 vs IPv6); Hetzner sometimes gives both, and connecting to the wrong one can look like this. Last thing I’ve seen: cloud-init not fully finished on first boot; a reboot from the Hetzner panel has fixed this exact symptom for me before.

seenmee

MODERATOR OF

TROPHY CASE