Nextcloud shouldn’t be seeing your MAC address. However, my guess is that Nextcloud has been configured to invalidate the session if the client IP changes, and randomizing the MAC address is one way that can happen.

Are you looking for a VPN or are you looking for an IPv6 tunnel broker like Hurricane Electric?

An immutable distro… like NixOS? Or do you mean your root filesystem is immutable? NixOS can do that too. You could normally mount your nix store as readonly and remount rw during updates if you really care about filesystem immutability, or use some snapshot system if you’re paranoid about adding new files to the store corrupting other files already in the store during an update.

The nixpkgs VM creation module, which I’ve never seen documentation for, has a mode where it generates a kernel, initrd, kernel command line, and erofs image containing a prepopulated /nix directory and that’s enough to boot the VM.

Ansible is disappointing as an IAC tool. It’s good for doing things, but it’s not good for converging systems to a desired state. Too often you end up with playbooks that are not idempotent or rely on something that was done during a previous execution of the playbook or just don’t do something that was done by a previous version, and then unless you are constantly recreating your systems you won’t notice until it’s a problem and you can’t get your system back.

You can host a Proton mail bridge to use different apps running on different machines, including phones.

Self hosting e-mail, particularly SMTP, will likely require a static IP from a reputable provider. Mail servers may reject incoming mail based on the reputation of the sending server. You can avoid this by relaying through another SMTP server and configuring your DNS rules to allow that server to send mail on your behalf, but that’s not really self hosting anymore.

You can use OpenEBS to provision and manage LVM volumes. Host path requires you to manually manage the host paths.

It is impossible. CPV is only going to allow the attacker to know that the device is probably not located next to the VPN server. It can only prove a positive, not a negative.

The second method you’re describing is only possible for people who control internet infrastructure and are able to infer correlations data going into your VPN server with data going out of your VPN server, which is both easier and more difficult than you’re suggesting. The attacker does not need to most of the internet routers because they only care about the data going into and out of the VPN server (it’s onion routing where the attacker needs to control many routers), but the attacker does need to have a powerful enough device to be inferring (hopefully) encrypted network flows on the public network to the packet sizes of encrypted VPN traffic for all of the traffic that is passing through that VPN server at the same time.

The latency to your VPN server is a constant added to the latency between your VPN server and whatever servers you are connected to. As long as the user’s VPN service doesn’t use different VPN servers for different destinations, it is impossible to determine the location of the user behind the VPN based on latency, and in general it is impossible to determine how far a user is from their VPN server because of varying latency introduced by the user’s own network or by bad infrastructure at the local ISP level. You can only know how far they aren’t based on the speed of light across the surface of the earth.

But, without a VPN, this is a real attack that was proven by a high school student using some quirks of Discord CDNs. Even without using Discord’s CDNs, if somebody wanted to locate web visitors using this technique, they could just rent CDN resources like nearly every big company is doing. Of course, if you have the opportunity to pull this off, you normally have the user’s IP address and don’t care about inferring the location by latency. The reason why it was notable with Discord was because the attacker was not able to obtain the victim’s IP address.

That sounds like build automation. You can use some Git forge software.

Some attackers check services that have already cataloged the services you are running, even on uncommon ports. You won’t hear from them unless you are running a potentially vulnerable service.

If you’re self hosting Headscale you can configure your network such that Headscale is reachable on your network with or without internet access and available from the internet.

Don’t expect Gitea to make progress on federation. Forgejo is a fork of Gitea and anybody that cares about federation is probably on the Forgejo side of the fork.

If you’re running Kubernetes, what is the point of LXC or Proxmox in this setup? Kubernetes will give better scaling and utilization.

Giving a container access to the docker socket allows container escapes, but if you’re doing it on purpose with a service designed for that purpose there is no problem. Either you trust Watchtower to manage the other containers on your system or you don’t. Whether it’s managing the containers through a mounted docker socket or with direct socket access doesn’t make a difference in security.

I don’t know if anybody seriously uses Watchtower, but I wouldn’t be surprised. I know that companies use tools like Argo CD, which has a larger attack surface and a similar level of system access via its Kubernetes service user.

Mounting the docker socket into Watchtower is fine from a security perspective, but automatic updates can definitely cause problems. I used to use Rennovate and it would open a pull request to update the version.

Git does have a server component. When git connects to an ssh remote it executes an ssh command that needs to be present.

You’re missing GitLab. I’d be looking at GitLab or Forgejo.

But you might not need this. When you access a private Git repository, you’re normally connecting over SSH and authenticating using SSH keys. By default, if you have Git installed on a server you can SSH to and you have a Git repository on that server in a location you can access, you can use that server as a Git remote. You only really want one these services if you want the CI pipelines or collaboration tools.

The issue says at the bottom that SealedSecrets is unaffected.

At least in the past, if you had a fixed amount of work to complete, underclocking would increase overall power consumption.

Port scanning isn’t abuse but automatically filing frivilous abuse reports is.

It’s not normal for - model-cache:/cache to be deleted on restart or even upgrade. You shouldn’t need to do this.