For backup and sync I use Syncthing. I can specify which folder on which devices I want to sync to which folder on the server.

I use a folder based gallery on my phone so when I move stuff around on my phone (or on my server) it gets replicated on all my devices.

I also have a policy to sync specified folders (and subfolder) with my family’s devices. No more " hey can you send me all the pics from the XYZ trip"

We take a trip. Make a subolder for that trip in a shared folder dump all our pictures there, get home and open the folder on the computer and prune together.

Debian has the advantage of not using snapd like Ubuntu does. You have to not only remove snaps but also instruct the package manager not you pull in snaps as dependencies and not to favor snap packages.

I have fond memories of Ubuntu being my first distro many years ago but pushing snaps onto users to compete with flatpak is a nuisance.

newsblur

The statement is very informative. The bug happens under increased read/write operations to the same file causing a race condition.

I also found interesting:

Despite the bug being present in OpenZFS for many years, this issue has not been found to impact any TrueNAS systems. The bug fix is scheduled to be included in OpenZFS 2.2.2 within the next week

This is the best suggestion for DIY, I can even get away without a printer and just write by hand. Perfect! Wish I could pin this comment.

nothing wrong with being self taught, you could follow these basics topics before poking holes in firewall.

1. VLANS: learn how to separate your LAN into networks with different security requirements. For wireless, try to make a “main” and “IoT” network so that IoT network that can’t talk to your “main” network but “main” can reach IoT devices. For wired, try to have a Management network, and a “Dirty network” etc.
2. Firewalls and Routing: You will need to be able to route between your VLANS and set firewall rules to allow certain traffic. Best practice is block everything and allow only what you need.
3. NMAP: learn how to do NMAP scans of your network to discover hosts and their open ports/services. This is a similar approach that “hackers” and script kiddies use on the public internet to find vulnerae and open services. Being able to probe your own network is crutial in understanding how others might approach in penetrating it.
4. Wireguard VPN: Learn to access your network remotely by setting up a wireguard VPN. Wireguard is preferred because it is “stealthy” and will not respond to unsolicited attempted to probe your network. Start small by using wireguard to access between VLANs so you don’t run the risk of using the internet.
5. NGINX and Reverse Proxy: If necessary, learn to expose your services or blog or website by only exposing nginx and proxying to your services. Many guides on securing NGINX exist. Try not to expose anything, but sometimes necessary if you want others to reach your website/blog/hosting etc.

That’s a rough outline that you can use to guide yourself and achieve milestones with hands on experience. In your pursuit you’ll run into certificates and domain name hosting and stuff. But all this is on the web so let your curiosity (and paranoia) drive! Have fun!!

The table of contents hints there is only one section relevant to security, Lab Firewall Config.

Anyone have experience with this book that could vouch for other chapters that explore best practices for security?

thanks for the masterclass in CF tunnels.

I am ready to accept everything you’ve said but there is the SSH case that keeps tripping me up. For reference, here is the CF docs on Connecting SSH through CF Tunnels.

Can you help me clear up the misunderstanding here? From the docs it appears you can create a SSH key pair on a client and then copy the public key to the server. It does not appear that the docs state you need to share those keys with CF, so I assume (perhaps incorrectly) that my session will be encrypted with my private key (on client) and public key (on server).

Again, what you said appears to make sense, perhaps SSH is the only edge case that is implemented differently?

hmm, I’m not sure I agree - or perhaps I didn’t explain myself well previously and caused confusion between us.

Yes I agree with you in your description of how cloudflare encrypts -> decrypts -> encrypts; they are allowing you to ride over their network. If you remove cloudflare from the picture entirely, then you just have the internet facing server.

What I’m saying is, if the client and endpoint (server) talk in an encrypted protocol, then cloudflare cannot MiTM the data, only the IP headers. This is similar if you were to connect to any ol’ website over an ISP’s network. If your session is not HTTPS, then your application data can be read. You can have encrypted sessions inside of CF tunnel-network-tunnel.

If your services support encryption, great. But you can also expose a wireguard endpoint so you have the following

wg client --(tunnel to CF)–> CF network --(tunnel to your server)–> wireguard server

the real advantage to CF tunnel is hiding your IP from the public internet, not poking any holes in your firewall for ingress traffic, and cloudflare can apply firewall rules to those clients trying to reach your server by DNS hostname.

interesting, I’ll have to read about this some more then. thanks for pointing me in the right direction

I apologize, I misread the chain of comments. Your explanation is perfectly adequate for someone who has a basic grasp on networking and VPN and tunnels and encryption.

I would just like to add that if your endpoints communicate via an encrypted transport (HTTPS, SSH, etc) then doesn’t matter if cloudflare tries to inspect your packets. There would be 2 layers of encryption while traversing the public web, then 1 layer when traversing CF’s network.

And to some, packet inspection is not a downside since they can offer more protection - but that is totally up to your attack vector tollerence

WARP (a client) just connects you to CF’s network.

If your server is running cloudflared (an outbound-only tunnel) then you can enroll your WARP client to reach your server, while your server is never accessible on the public web. That’s the principal behind Zero Trust.

While techinically yes, WARP can be considered as a VPN, it is just a secure tunnel to an endpoint. In which case you can argue any point-to-point tunnel is a VPN.

discovered tailscale from this post and after reading their “how tailscale works” I was hoping to get some clarification from an activer user (you).

CF tunnels setup an outbound-only tunnel from my private network via cloudflared, I have no ingress holes in my firewall to access my services. cloudflared does all the proxying. Plus my IP changes monthly as I don’t pay for a static one from my ISP. This “outbound-only” connection is resilient to that.

Tailscale is point-to-point (for data plane) connection and only the control plane is “hub and spoke”. This sounds like I need to allow ingress rules on my private network so my server can be connected to? Is this true or where did I misunderstand?