This article is… a little underwhelming. WIth the exception of blocking ICMP (which you certainly should not do), it's not bad advice, but the justifications are largely hollow. This is fine. Note...
This article is… a little underwhelming. WIth the exception of blocking ICMP (which you certainly should not do), it's not bad advice, but the justifications are largely hollow.
Use disk encryption, particularly with laptops.
This is fine. Note that the intersection of FDE, filling empty sectors with random data, and SSD wear leveling is not a particularly happy place. Personally, I let empty sectors get blanked and enable TRIM (this makes it possible to tell which sectors contain legit data, which leaks a bunch of metadata, but doesn't force the drive's wear leveling to act as though it's completely full); I'm not aware of a consensus on the right course of action here.
Put strong passwords on your root user and any sudoer/sudo enabled user
Absolutely. In fact, you should only use strong passwords, and you should never repeat passwords. Using a password manager is functionally mandatory. KeePass is popular, and packaged in Debian's repos; pass might be attractive to commandline junkies.
Create separate users for less trustworthy applications
This is not a bad idea, but is unfortunately utterly impractical for almost all GUI and commandline applications, especially given the inherent insecurity of the X protocol.
On the other hand, server applications should always run under their own user, since there's a network (or at least socket) boundary when talking to them regardless.
Start by activating some kind of firewall and setting it to blocking incoming connections.
A firewall on a Linux system is a protection against local malware and possibly vulnerable software you didn't know you were running, not remote exploits. There's no discernible difference between hitting a closed port and a firewalled port. To be clear, making it difficult for malware or other software you didn't know you were running to open listen ports is definitely a good thing; but a local firewall is closing a relatively small hole.
Configure Debian to update over TOR with apt-transport tor
This is fine, though the hole it closes is small (an attacker listening to your connection could notice that you've downloaded a vulnerable package and attempt to exploit it), and unless your Internet connection is very slow, it will hurt your package download bandwidth badly.
Utilize sandboxing
Note that AppArmor is enabled by default in Debian as of Buster, and can't do anything to secure X; and Firejail unfortunately has a bad track record. Flatpak has nontrivial issues separate from the sandboxing. IMO, the state of sandboxing in the desktop Linux world is pretty bad at the moment; hopefully with the better security properties of Wayland over X, this can start to make better progress.
This article is… a little underwhelming. WIth the exception of blocking ICMP (which you certainly should not do), it's not bad advice, but the justifications are largely hollow.
This is fine. Note that the intersection of FDE, filling empty sectors with random data, and SSD wear leveling is not a particularly happy place. Personally, I let empty sectors get blanked and enable TRIM (this makes it possible to tell which sectors contain legit data, which leaks a bunch of metadata, but doesn't force the drive's wear leveling to act as though it's completely full); I'm not aware of a consensus on the right course of action here.
Absolutely. In fact, you should only use strong passwords, and you should never repeat passwords. Using a password manager is functionally mandatory. KeePass is popular, and packaged in Debian's repos;
passmight be attractive to commandline junkies.This is not a bad idea, but is unfortunately utterly impractical for almost all GUI and commandline applications, especially given the inherent insecurity of the X protocol.
On the other hand, server applications should always run under their own user, since there's a network (or at least socket) boundary when talking to them regardless.
A firewall on a Linux system is a protection against local malware and possibly vulnerable software you didn't know you were running, not remote exploits. There's no discernible difference between hitting a closed port and a firewalled port. To be clear, making it difficult for malware or other software you didn't know you were running to open listen ports is definitely a good thing; but a local firewall is closing a relatively small hole.
Also, as noted above, don't block ICMP.
This is fine, though the hole it closes is small (an attacker listening to your connection could notice that you've downloaded a vulnerable package and attempt to exploit it), and unless your Internet connection is very slow, it will hurt your package download bandwidth badly.
Note that AppArmor is enabled by default in Debian as of Buster, and can't do anything to secure X; and Firejail unfortunately has a bad track record. Flatpak has nontrivial issues separate from the sandboxing. IMO, the state of sandboxing in the desktop Linux world is pretty bad at the moment; hopefully with the better security properties of Wayland over X, this can start to make better progress.