Usually these drives will be mounted on Linux. But occasionally they will be mounted on Windows 10 where I do not have admin or developer mode access, so I cannot depend on symlinks.

Thanks for the wonderful info. I think I will go with the iStorage datAshur PRO+C because it has the best speeds out of all of them. It is slightly more involved to activate read-only mode than a simple switch, but it should be negligible compared to the time to boot the system and other overhead.

There is no way for me to verify how the write-protect works with this drive, but that is true for all of them, so I have to trust one. However, this company seems very competent. And importantly there are many 3rd party reviews of this and similar iStorage products. Also the firmware is supposedly signed so it should be immune to badUSB. But you do make the point that there is no way to be sure.

I plan to use root on LUKS anyway (I want persistent storage), so I can keep / encrypted and checksum my /boot every boot to search for anomalies. Once LUKS is decrypted, theoretically malware could get embedded in there, but I feel like it would be unlikely for malware to infect one partition and not the other.

I wonder if there is a way to setup a “honeypot” partition which holds no useful data but exhibits traits that are appealing for malwares to embed themselves in. It would be checksummed regularly while the system was running and alert me if anything changed.

That open source flash drive looks awesome, and I will keep my eye on it, maybe I would consider it if my threat model was tougher.

Note: I haven’t tested this yet, but I don’t see any reason why it wouldn’t.

You can have the best of both worlds by importing modules and then enabling/disabling them with config options.

The idea is that every single module, whether you want to be able to toggle them on/off or not, gets imported into your configuration.nix. For options that you want to permanently be enabled, there is no more work to do. For options or groups of options that you want to be toggleable on/off, you put them behind a lib.mkIf.

In the following video, Vimjoyer essentially makes an option that enables/disables an entire module, even though it is already imported. He creates an options.module1.enable option, and then hides the entire contents of module1 behind a lib.mkIf options.module1.enable

https://youtu.be/vYc6IzKvAJQ?t=147

Not yet, I am looking to buy my printer in a couple months. If I get this one then I will test it and do a write up of it and post it somewhere.

In the past I have used Proxmox with ZFS raid on a basic mini PC. With ZFS raid it syncs everything except /boot. Proxmox has a tool called “proxmox-boot-tool-refresh” which will syncs /boot between drives. ZFS kernel module can be loaded in the initramfs so it will boot fine, even if missing a drive.

For this project I do not plan to use ZFS, but AFAIK software raid is now standard. Here is a popular video from Level1Techs talking about the flaws of hardware RAID: https://youtu.be/l55GfAwa8RI

Thank you for the detailed reply. You seem very knowledgeable. I will implement your suggestions as I redesign my network.

Thanks. Some of these entries maybe (20%) have IOMMU groups listed under “lspci_all”. But it is extremely awkward to search through. So maybe I will put a feature request in the forum to make IOMMU more searchable. But this is still likely the largest database of IOMMU groupings on the web, even if it is not easily searchable.

Thanks but these are only lists of CPUs and motherboards that support IOMMU, not the IOMMU groups. For me (and many others) the groupings are just as important as whether there is support at all.

The groupings are defined by the motherboard. In my experience, all motherboards that support IOMMU will put at least 1 PCIe slot in its own own group, which is good for Graphics Card passthrough. However, the grouping of other stuff like SATA controllers and NICs varies wildly between board, and that is what I am interested in.

Thank you, that is a very good point, I never thought of that. Just to confirm, best standard practice is for every connection, even as simple as a Nextcloud server accessing an NFS server, to go through the firewall?

Then I could just have one interface per host but use Proxmox host ID as the VLAN so they are all unique. Then, I would make a trunk on the guest OPNsense VM. In that way it is a router on a stick.

I was a bit hesitant to do firewall rules based off of IP addresses, as a compromised host could change its IP address. However, if each host is on its own VLAN, then I could add a firewall rule to only allow through the 1 “legitimate” IP per VLAN. The rules per subnet would still work though.

I feel like I may have to allow a couple CT/VMs to communicate without going through the firewall simply for performance reasons. Has that ever been a concern for you? None of the routing or switching would be hardware accelerated.

Search eBay for used gaming laptops. Comes with a built in UPS.

Thanks for the wise words. However I have some questions:

If you’re worried about someone malicious having access to your network connection, ssh is going to do a DNS lookup to map the hostname to an IP for the client.

Are you sure that this is true for Tor? .onion addresses never resolve to an IP address, even for the end user client. If I was on an untrusted network, both for the client and the server, the attacker could find out that I was using Tor, but not know literally anything more than that.

And attackers have aimed to exploit things like buffer overflows in IDSes before – this is a real thing.

I would expect an IDS to be an order of magnitude larger attack surface than Wireguard, and significantly less tested. Although I could also say that about SSH, and we had the recent backdoor. However, I think it is a lot more likely that a bug will cause a security method to be ineffective than actively turn it in to a method for exfiltration or remote access though. For example, with the recent SSH backdoor, if those servers had protected SSH behind Wireguard then they would have been safe even if SSH was compromised.

To my knowledge there is no way to index Tor v3 hostnames unless the owner of the address explicitly shares them. Therefore, even if an attacker knew that I was behind Tor, they would have no way to find out the hostname of my service and connect to it, so it is not security through obscurity. They would have to get into my password manager and steal my public key. Am I wrong about this?

Whatever the case of the hostname being public or not, do you think it is important to add another layer of security such as Wireguard in this case, or is hardening the SSH config enough?