from the docs on minimal templates, ‘If your network devices need extra packages for the template to work as a network VM, use the lspci command to identify the devices, then run dnf search firmware (replace firmware with the appropriate device identifier) to find the needed packages and then install them.’
enable ufw (or if you want to use nftables instead, dnf remove ufw and install nftables and set our rules.
systemctl enable ufw
remove default rules in ufw and allow incoming from sys-firewall (ip will be different in your case, just find ip address of sys-firewall)
ufw delete 1 (x4)
ufw allow in from 10.x.x.x
(optional) run comprehensive system security audits with lynis
dnf install lynis
lynis audit system
dnf update && dnf upgrade
finishing up (run commands one after another)
clamscan -r /
exit the XTerm and shutdown net-dvm, make a clone of default-dvm named network-dvm and change the template of network-dvm to net-dvm.
shutdown sys-net and change the template from default-dvm to network-dvm. majority should be done right here, unless you want to go and help out sys-firewall too. IF you didnt choose to make it disposable, open a dom0 terminal and edit /var/lib/qubes/qubes.xml
sudo nano /var/lib/qubes/qubes.xml
scroll down until you find the actual properties of sys-net qube (might take a while, might not, depends on how good of an observer you are) and edit “class=“AppVM”” to say DispVM. copy the entire autostart property line, the entire line of the property for autostart being true, and make a new line right below that property, paste in your copied property, and change the name from autostart to dispid, and change True to a unique value (just hit 4 random keys on your keyboard). CTRL + O to write out, and CTRL + X to exit. restart QubesOS, and now you can go change the template of sys-net to network-dvm, and if it doesnt work and it says no default dispid for sys-net and that sys-net is still an AppVM, set a different dispid than before.
this section is for sys-firewall, and is the section where your second template is needed, if you created it. if you didnt, and want to follow section 2, go create a new one.
get root terminal access since passwordless root is disabled by default
yes, since sys-net is your weakest link, as in, if it gets hacked, youre fucked. and its quite easy to hack aswell, this makes it more difficult to hack into sys-net, and even if an attacker did get in, this limits what they can do to cause significant damage.
by default, sys-net is based off Fedora-38-Xfce, and not Fedora-38-Minimal, and obviously this is not as good, since minimal would have less attack vectors since its, well, minimal. by default, passwordless-root is also enabled in sys-net, and there isnt a firewall inside of sys-net to prevent attackers from breaking in, with the large attack surface of the default. the minimal templates have a much lesser attack surface, they do not have passwordless root, and if following my guide, will have a firewall, which wont do much since there arent really attack vectors to abuse with the minimal VMs, but its always good to go above and beyond in terms of securing the highest-risk qube. as for sys-firewall, what ive described is only really needed if youre being hunted by the CIA or KGB or something.
to your first statement, if youre referring to sys-firewall, it does not apply to sys-net. if you arent, im unaware of what youre referring to and would appreciate some elaboration. as for your second statement, im gonna have to also ask you to elaborate, since sys-net is indeed the one running network services, which is kind of why i made the guide.
I see, i was unaware of that and will update the guide to remove the firewall part. as for your second statement, according to Qubes docs minimal templates, none. the point im making is that since sys-net is the only qube actually communicating with the ethernet controller (or router if youre on wifi) then its the only qube that an attacker could directly attack, minimizing the attack surface prevents the ways in which an attacker could go about penetrating into sys-net, and we’ve seen examples a few years ago with a user who was being targeted by israeli hackers, having his sys-net being infiltrated as we see here Forensics on sys-net (take his statements with a grain of salt though because some of what he says doesnt make sense)
actually might not remove it, since ufw offers easy to use customizability that would be more beneficial to most users than nftables. especially if you need to set specific rules and configs and arent willing to spend a few hours tweaking. also considering the fact that youd have to config it to be like the previous defaults, which im assuming most people here dont know how to do.
for sure nftables is more customizable, but i dont like scrolling through a ton of code to change 1 setting, and i dont think the increase in customizability is enough for an advanced user ti want to choose it, over ufw. as when youre trying to setup a good firewall config, you dont want to spend 6 days, but instead just 6 minutes.