given that Secure Boot prevents any modification of your computer’s boot chain
Secure Boot does no such thing. All it does it require that everything in the boot chain is signed by a trusted cert.
Binding TPM PCR7 to FDE (or more brittle options like 0+2+4) is really what protects against boot chain modifications but that’s another topic.
Disabling SB to install the distro, then re-enabling it once installed with either maintainer-signed shim or self-signed UKI/bootloader is perfectly fine.
You need both FDE and Secure Boot, ideally with FDE using a TPM with PIN and PCR 7+15=0. FDE without SB can be trivially boot-kitted and obviously SB without FDE is mostly pointless. Maybe for a server/desktop behind locked doors you don’t worry as much, but for a laptop you absolutely should. Also it’s really easy in Arch to resign the UKI with sbctl via a pacman hook whenever the kernel is updated so there’s no good reason not to use it.
If you’re relying on a LUKS password only, it can be brute-forced. To protect against that you need a decently long password which is annoying to type every boot. A short TPM PIN sealed by SB protecting LUKS is both more convent and more secure.
Finally, if an attacker or malware gets root, FDE isn’t protecting you either.
Yeah this is an issue but not a big one. Most distro’s installation media don’t use shim so you have to disable SB during install anyway.
And installing the 2023 KEK and db certs can be done via firmware without much trouble or you can use sbctl in setup mode which I believe has both the 2011 and 2023 keys.
If you dual boot Windows you’ll want to update it to the new bootmgr signed with the 2023 keys and add the 2011 certs to dbx to protect against BlackLotus or let Windows do it via patches+regfixes.
Also know that any changes to PK, KEK, dB, or dbx will change the PCR 7 measurement so handle that accordingly if you use TPM unlock for FDE.
Most DNS queries are UDP.
I’d do a modified scream test and change old.domain to something like 1.2.3.4. Then run sudo netstat or ss with -tpn, grepping for 1.2.3.4.
Or something like grep -r old.domain /etc.
Yep, that would work fine for the first line of defense. Eventually, you can expand it to copy, replicate, or drive swap the onprem backups offsite somewhere (e.g., cloud, office, or family member) if you want to protect your data from site loss (e.g., house fire).
The only thing missing is a good backup.
If you are storing anything important – especially Immich and Vaultwarden data – you should have a good offsite protection strategy. And even the HASS config should be backed up with versioning because rebuilding from scratch could be painful once you get deep into it.
I’ll let others chime in on possible good backup options because I use Veeam and Azure, which really isn’t in the spirit of this community, and I’d be interested in good open source options myself.
Also, RAID (mirroring) is NOT a backup.
Yep this is exactly right. Too many people are unaware that their votes are not anonymous on Lemmy and blocking the public tool only helps the bad guys who already know this. I’ve always thought this was a major weakness in Lemmy but I don’t have a solution myself without some other major drawback.
I think probably votes should be anonymized or batched between servers so that only your instance’s admins can see individual votes and you just have to trust the instances you federate with that they aren’t pulling any shenanigans or otherwise defederate. That’s not an easy problem to solve, but it’s not like it’s not currently possible to manipulate votes with a federated server, it would just be harder to detect. Regardless I think the need for privacy wins here.
The easiest way that doesn’t affect the main network would be to use a travel router. Its WAN IP would be the private IP it gets from the main network (over wireless since that’s your only option). And it would NAT your network onto that IP and then you can do whatever you want on your network.
I’m not sure if that Mikrotik router will do this but it might. You basically need something that can connect to an SSID and use that interface as its WAN interface. The wireless factor here is really limiting your choices. If you had a wired uplink to the main network you could use any router/gateway/firewall you wanted. You could also use an AP in bridge mode to connect to the main network’s SSID and wire it to the WAN port of any router of your choice.
You don’t really need to use VLANs to separate your network from the main network unless you want to share any of the same layer 2 segments (basically wired Ethernet) while keeping it isolated. But it doesn’t really sound like that applies in your scenario. Of course using VLANs within your network would still make sense if that applies (for example, to separate your server traffic from your IoT traffic).
Multiple monitor support would be nice but that’s probably a ways off.
That’s not on the spreadsheet so it doesn’t count.
Yep that’s how I have Syncthing set up. All global and local discovery disabled, no firewall ports open on the clients, no broadcasting, no relay servers. Just syncing through a central server which maintains versioning and where the backups run. Works like a charm.
Not that it’s my first recommendation for security reasons, and I would never do this in prod, but you can just add the self-signed cert to the local trusted root CA store and it should work fine. No reg changes needed.
If you do this, put it in the store of the user running the client, not LocalMachine. Then you just need to make sure you connect as something in the cert’s SAN list. An IP might work (don’t know since I never try to put IPs in the SAN list), but just use a hosts entry if you can’t modify local DNS.
Edit: after reading the full OP post (sorry), I don’t think it’s necessarily the self-signed cert. If the browser is connecting with https:// and presenting a basic auth prompt, then https is working. It almost sounds like there is a 301/302 redirect back to http after login. Check the Network tab of the browser’s dev pane (F12) to see what is going on.
This is like the epitome of the XY Problem.
I’ve been using Droid48 forever. It’s perfect.
Use a Chromium browser to inspect the cert.
If anyone knows how to get Firefox to show a bad cert before loading the page, I’d love to know.
Assuming you’re the one adding HSTS, you’ll have to inspect the cert and/or view the content that is getting returned. On desktop Chromium you can type “thisisunsafe” to load a page even with HSTS. Not sure how to do it on mobile FF.
Would seem weird for it to be intercepting your domain’s traffic but not the rest of the internet.
Edit: just noticed you’re not even loading an SSL page. Are you using https in the URL?
If you’re sure you’ve got a DNS entry for the Pihole FQDN pointing at Traefik, open the dev panel in your browser (F12), switch it to the Network tab, and visit the pihole URL.
See if you get anything back and especially take note of the HTTP status codes.
Can you see the router and service in the Traefik dashboard and do they show any errors there?
Yep that’s how my desktops and servers are set up. I only recently started adding the TPM PIN to my laptops for a bit of extra protection from cold boot / evil maid attacks.