Debian 12 … is amazing! How to: Create your custom codehouse [Part 3A/4]

Protecting your Debian against malware.

In the Part 1 of this Debian 12 series, I covered many details about the Debian distribution — what Debian offers, how it packages software, the main releases besides Stable, and how to use Debian in a “Debian” way (from the standpoint of software package installation). In Part 2, I went into detail about the Debian 12 installation process, with a strong focus on the Disk Partitioning step. This third part will be dedicated to the post-installation steps aimed at securing your freshly installed Debian system against malware.

At the end of the previous part, a Debian 12 installation was completed. And if you followed my steps, when you boot in you see a black screen with terminal prompts. That’s because I purposely skipped installing any Desktop Environment (further, “DE”):

In this article I’ll perform all actions using the terminal only. After setting up my system and installing the necessary packages (a tiling window manager plus a few DE components), eventually I’ll end up with a GUI (the last part of this series of articles will be dedicated to it). If you already have a desktop environment installed (like GNOME or KDE, etc.), you can still follow along by running my commands in your GUI’s terminal.

Debian OS has a reputation for being rock-solid and secure. Even though I installed it with netinstall — meaning it starts with a minimal set of packages and might seem like it’s missing some super-magic security software — it’s actually the opposite. Debian by default is quite well set up: the system is finely tuned, permissions on critical files are set correctly, and the default preinstalled software is carefully chosen.

Debian takes security very seriously. We handle all security problems brought to our attention and ensure that they are corrected within a reasonable timeframe.
The Debian project coordinates many security advisories with other free software vendors, and as a result. (Debian — Security Information)

You might wonder, then,_ what these articles about "securing" something more are for_. Well, a freshly installed Debian system is secure, but the moment you start using it, there are two possible paths: your Debian system remains just as secure, or it becomes vulnerable — or even compromised.

To keep us on the same page, I want to clarify how I understand a system became compromised and the main threats that can lead to it:

1. ಠ_ಠ Your system got affected by malware or a virus. The primary risk here is when you download/install/run third-party software that turns out to be malicious.
2. ಠ_ಠ An outside attacker hacked in and got access to your stuff, when you exposed your system to the internet without adequate protection.
3. ಠ_ಠ Someone unauthorized gained physical access to your PC, and accessed your system directly without your permission, because you made your system access easy for them to do so.

‘When you…’ and ‘because you…’ are the key moments here, as you might guess. But I’m not here to ‘bully’ you right from the start—in fact, I’ve put a lot of effort into these 2 articles (3A and 3B) because my intentions are quite the opposite. I want to encourage and empower you, showing that it’s actually not that hard to use your system mindfully. This way, you can avoid those periodically emerging uneasy thoughts like, ‘What if someone is tracking my keystrokes and watching everything I do right now?’.

Avoiding the 3 risks listed above first requires knowing how to avoid them. Many security breaches happen unintentionally because users simply don’t realize what they’re doing when they run a command or enable something which does not look like something nasty at all.

And if you’re here, reading this article, I’m guessing you’re ready to understand better how security mechanisms of Debian system work and which actions could compromise your system. So, let’s get started!

I have made the decision to split the broad topic "Debian security mechanisms and how to administer the system securely" due to the amount of content and the length of the article if both parts were combined. The first part, which you are reading now, focuses on protecting your Debian system against malware. Here’s the roadmap:

① About The Best Debian Securing Tools EVER — Brain & Patience & Curiosity

② Managing your system’s software: configuring package repositories & package updates & private repositories dilemma and about antivirus tools.

③ Managing Passwords & Permissions

The following article, that is focused on securing Debian against Network-Based attacks covers following topics:

④ Monitoring systemd services for security oversight.

⑤ Configuring Network & Open ports & Firewall

① About Brain & Patience & Curiosity

If you post a question in any Linux-related subreddit on Reddit, asking something like: “What’s the best tool to secure Linux OS/secure internet browsing/protect me from malware?” there’s a 90% chance someone will answer with one word — Brain. And they’re right.

Think carefully about what you’re doing, and if you’re about to try something risky or especially something you don’t fully understand but found an online guide for (with little explanation of steps), take the time to learn about it first.

To this “security mechanism”- Brain, I would also add Patience. Sure, it’s faster to run commands as root instead of using a sudo user and typing sudo each time; it is faster to copy-paste commands from online tutorial in the terminal and press enter; it is quicker to add the -y flag to automatically accept everything when you install a package; it is easier to hit enter-enter-enter to dismiss installation prompts without reading. Is it wise and secure way to administer your system? Nope. So, have patience. Read what Debian tells you—warnings, information, and details—before proceeding with whatever you are doing in terminal. Don’t suppress warnings, even if they’re annoying, and don’t ignore them. Instead, look them up to understand what they mean and whether you should be concerned and try to resolve them.

Speaking of looking things up, this brings to Curiosity. Curiosity about how Debian (and Linux OSs in general) and shell scripting work. Instead of rushing to install software from private repository for every small need, try first to meet these needs with what’s already available — maybe by writing a custom script that runs on your system rather than installing a questionable package.

② Managing your system’s software.

How most of the software applications are distributed in Debian? In form of packages.

A Debian package is a collection of files that allow for applications or libraries. A package consists of one source package, and one or more binary packages. Binary packages contain executables, standard configuration files, other resources required for executables to run, documentation, data etc. Source packages contain the configuration for the package build system, list of runtime dependencies and conflicting packages, initial configuration for the software, and more. (source)

What is malware? Malware is a malisious software (in Italian, "male" means "bad").

is any software intentionally designed to cause disruption to a device, server, client, leak private information, gain unauthorized access to information or systems, deprive access to information, or which unknowingly interferes with the user's computer security and privacy (source)

Malware can come in various forms: scripts or executable code that, once run with elevated permissions, performs harmful actions by executing commands that compromise system security, delete files, or attempt to escalate privileges; infected packages bundled with backdoors, spyware, or other malicious code that activates when the package is installed or executed; and trojanized software, which appears to be legitimate but includes hidden malicious code.

Therefore, it is very important to strictly control what and how is getting installed and executed on your system.

②.① Managing your system’s packages: Installing new software

How do you install new software (a package) on a freshly installed Debian system?

❧ You can run apt search <package>, and if it’s found, you proceed with apt install <package>. This will install the software of your interest from the Debian repository (I'm using Debian Stable, so the software will be installed from one of its repos).
❧ It’s third-party software not available in the Debian repos, it might have its own private repository, with the software of your interest packaged specifically for Debian-based systems. To install it from private repo, you will have to add it to the list of sources (repos) from which apt can fetch packages.
❧ The software is open-source, you can build it from source.
❧ You can install the software as a Snap or Flatpak, if this software is packaged in those formats.

I will cover first two options from the security standpoint.

②.② Managing your system’s packages: configuring package repositories (maintained by Debian developers)

In Part 1, I already covered how Debian packages software and explained the three main Debian releases — Sid (unstable), Trixie (testing), and Debian Stable. I also discussed why it’s a bad idea to install anything in Debian Stable from Sid or Trixie repositories, and how packages can break because of such actions. Quick reminder: it’s not always the specific package you’re trying to lure into Debian Stable — let’s say from Debian Sid (Unstable) — that breaks. Often, it pulls along a bunch of dependencies in major versions, which then break other packages that are already installed in your system and rely on older versions of those dependencies. I also described how Debian backports repository work, which I will be using.

Let’s take a look at the pre-configured list of sources (repositories) that apt uses to update and install packages. First, a quick recap of what apt is and what package repositories are all about:

Advanced Package Tool (or APT) is the main command-line package manager for Debian. Apt downloads packages from one or more software repositories (sources) and installs them onto your computer.
A repository is generally a network server, such as the official DebianStable repository. Local directories or CD/DVD are also accepted. The specific repositories (package sources) configured on your machine affect: what software packages are available for download; what versions of packages are available; who packaged the software (source)

The list of sources from which apt updates itself and installs software is a configuration file, so naturally, it’s located in the /etc directory. Since it’s specifically for apt, you’ll find it in /etc/apt. If I navigate there and list its contents with ls, here’s what I see:

The key files and directories here are sources.list (file) and the sources.list.d (directory, which is empty for now). The sources.list.d directory is meant for managing private repositories that you will add eventually more easily — /etc/apt/sources.list.d allows you to add new repositories without editing the main /etc/apt/sources.list file. You can place a uniquely named file (corresponding to the name of the software installed from a private repo, for example) into this directory, and apt will use it. To remove a source, you can simply delete its file—no need to modify /etc/apt/sources.list. This is a user friendly and “clean” way to manage private repositories automatically (though you can still add them directly to /etc/apt/sources.list if you prefer).

When I run cat /etc/apt/sources.list to check the contents of sources.list, here’s what I see:

Nothing unusual — just the main Debian 12 (Bookworm) repos, along with bookworm-updates and bookworm-security repos. All active lines in this file follow the same format (lines starting with a hash # are comments, so if you comment out any line here, your system will ignore that repo when you run apt update or apt install <package>).

How to read the sources.list file?

❧ The first word on each line, “deb” indicates the type of archive. Deb indicates that the archive contains binary packages (deb).
❧ The second entry on the line is a URL to the repository that you want to download the packages from. The main list of Debian repository mirrors is located here.
❧ The third entry on each line is the distribution name, quick reminder that Debian 12 will have the distribution name “bookworm”.

After the distro name there are entries like main, contrib and non-free-firmware. These are the repository components. For more details, consult SourcesList — Debian Wiki.

②.③ Managing your system’s packages: third party software PPAs.

Private repositories (aka PPAs (Personal Package Archives) aka third-party software: adding them to the list of sources for apt updates or not?

Maybe you’ve already done a bit of research on whether to add a private repository to the /etc/apt/sources.list or not. Perhaps you’ve seen answers to this question on Debian or Ubuntu subreddits, and you’ve likely noticed that responses are often quite negative about doing this and installing software from there. But why?

The answer comes down to two main concerns. First concern, are you sure that installing that softwarino (excuse my Italian outbreaks here and there) you wish to install is just about that one “program”, or could there be more to it? What if this softwarino requires Package B version 2.x, but you currently have Package B 1.6 installed on your system, which is also used by 10 other packages in your system? What will happen then? The second concern relates to how package installations work in Debian.

Here’s an extreme example of a first concern:

a PPA providing a video game emulator shouldn’t be able to override something like libc6 (the essential C library used by nearly all system programs).

Or, a more realistic case—you want just a music player (third party software) but you definitely don’t want that its PPA UNEXPECTEDLY ships you not only music player itself but also pulseaudio audio server when you already have pipewire as your audio server.

To prevent such unexpected “shipments”, Debian has a standardized procedure for safely adding third-party repositories, ensuring that only a specific set of packages is delivered securely to your system. You can find details on this here DebianRepository/UseThirdParty — Debian Wiki.

Now about the second concern: how package installation works. While apt manages fetching, installing, and removing packages, it’s actually dpkg that performs the “true” installation— "injecting" binaries into your system. And it’s not just about the fact that it’s doing it, but how it does it…

dpkg runs all the maintainer scripts as root and installs files anywhere in the hierarchy with any set of permissions (suid, /etc files, etc). This is somewhat expected for some packages (say passwd) but less so of others (say coreutils).
To put it more explicitly — during the installation process, your system is running an installation script written by some dude (if the software in questions is a very small project developed by one person with very small activity on GitHub) as root. And trust isn’t just about just possible risks of malicious stuff like trackers. Poorly written software can also drain your hardware resources or break something on your system.
Read more here about why it is a problem: UntrustedDebs — Debian Wiki

Speaking about executing/running something as root, it seems like the right place to explain, in general, how Debian is vulnerable to viruses and whether it is prone to them.

The Unix security model makes a distinction between privileged (root) processes and user-owned processes, therefore a “hostile” executable that a non-root user receives or creates and then executes cannot “infect” or otherwise manipulate the whole system. (source)

Any malicious software is really scary when it gets executed with root privileges, because it will affect your WHOLE SYSTEM.

And here is the simple math about software installed from PPA by adding PPA to apt sources.list:

(dpkg runs all the maintainer scripts as root and installs files anywhere in the hierarchy with any set of permissions) + (“hostile” executable in a packaged that is executed by **a root user) = disaster in your system**

Keeping these things in mind, adding a PPA to your sources.list or sources.list.d (both have the same effect on apt update) is up to you. But there are really only two approaches to help you to take the decision whether to add this or that private repo or not:

❧ Dive in: Dedicate some time to reading the links above and other resources on dpkg and apt to learn how software is packaged and what happens during installation. This way, you can make an informed, knowledge-driven decision.

❧ Trust and go: If you are not willing to dive in, then most probably you will never find a precise answer to the question whether it’s “good” or “bad” to add a software X’s PPA, as there’s no universal answer for how it will impact your system if it will do it at all.

❧ Common sense think-about: If you are in doubts about whether you trust the developers that packed for you a software or not to add their third party repo to the sources list, why would you even use this software which was developed by same dev team?

In general, when installing software on Debian, it’s worth checking the version in the Debian repositories first — if outdated, adding a private repository may be beneficial, especially for popular software like browsers, Docker, or databases, which need frequent updates for security. Moreover, such big projects usually do not mess up with their packages.

To conclude this section, the opinion of Debian Devs:

Editing software sources: Precautions
Being able to change the repositories used by your package management system is a powerful feature but this power comes with some responsibility. Users are cautioned that it is possible to break your system (in a way that could be difficult or impossible to cleanly fix) by adding third-party repositories, or repositories for a Debian version that does not match your current version — these repository create a risk of conflicting package versions, creating what’s sometimes called a “Franken-Debian” system. The whole concept behind a Debian stable release is that the Debian developers have picked a set of software and their versions that function nicely together. While this software is patched to fix security issues, the software is frequently not the latest version. It takes some experience to know how the repos may be changed without risk of breaking your system. Users of all levels are advised to change repos cautiously. (source)

Another important point about the packages (unrelated to repos) is: don’t install unnecessary packages. Avoid falling for YouTube or web guides like “20 Steps to Do After Debian Installation” where some steps are to install Python or C compiler. If you don’t use Python, there’s no need to install it “just in case.” Same with the C compiler — it’s essential for building packages from source, but if you don’t plan to do that, do not install it. Install packages based on actual needs, not hypothetical ones.

Since you already know what the system is for (don’t you?) you should only install software that is really needed for it to work. Any unnecessary tool that is installed might be used by a user that wants to compromise the system or by an external intruder that has gotten shell access (or remote code execution through an exploitable service).
The presence, for example, of development utilities (a C compiler) or interpreted languages (such as python) may help an attacker compromise the system even further: allowing him to do privilege escalation. It’s easier, for example, to run local exploits in the system if there is a debugger and compiler ready to compile and test them!
Of course, an intruder with local shell access can download his own set of tools and execute them, and even the shell itself can be used to make complex programs. Removing unnecessary software will not help prevent the problem but will make it slightly more difficult for an attacker to proceed (and some might give up in this situation looking for easier targets) (Source)

Less installed packages = more secure ecosystem, since any additional part of the system could be affected by security bugs.

I’m not here to scare you though! Security concerns should be balanced, and they shouldn’t get in the way of enjoying your PC. It’s all pretty personal — it depends on how much of a “security/control freak” you are. Tons of people experiment and try new stuff on their PCs, and if that’s what you want, go for it. Just don’t fall into the tempting trap of relying on some “magic software” (usually an antivirus is considered as the one) to make everything carefree, especially when it comes to things in the global net.

②.④ Managing your system’s packages: package updates.

Keeping packages updated is another security measure. Later, I’ll show you that Debian has a default background service running to update and upgrade apt daily. You can turn this off if it’s inconvenient— it can be so, if you have many private repositories in your sources list. In that case, you might prefer to update manually. Just be responsible about it: set a day, maybe once a week, to manually update your system and all packages.

In my experience, often, users avoid updates out of fear that something might break, especially if they’re running complex applications that rely on multiple technologies. This fear usually builds up when you start a project and skips updates throughout development; by the time an app is done, you may worry that a system update will mess all app’s components up. Avoid this by updating regularly. Core packages updates are not just about features — they are about security.

NB! Understand the difference between apt update and apt upgrade.

❧ apt update downloads package information from configured sources (in /etc/apt/sources.list and /etc/apt/sources.list.d/…) , so your system knows which packages are available for upgrade and where to find them.
❧ apt upgrade then uses this info to upgrade all installed packages to their latest available versions, but it won’t install new packages unless needed for dependencies, and it won’t remove any packages. If a package removal is required, it’ll skip the upgrade and keep your system stable.
❧ On the contrary, apt full-upgrade will remove the installed packages if that is needed to upgrade the whole system.

②.⑤ Managing your system’s packages: about Antiviruses.

I won’t be installing any third-party antivirus software on my Debian OS because, for me, that feels contradictory. However, this is my personal view and it fits my way of working, feel free to research the topic. There is one pretty famous antivirus for Linux OS — CalamAV (ClamAV — Debian Wiki).

Why personally wouldn’t I install it? First, as I mentioned above, malicious software on a Debian system largely boils down to permissions. If I execute some malware with root privileges, is there antivirus or not on my system, I’m cooked. Will any antivirus stop something I’ve ALREADY executed as the root user? I don’t think so. To me, most antivirus tools for Linux is more about peace of mind.

Moreover, according to ClamAV’s website, Debian 12 is not a part of the list of supported platforms yet (and it’s not just Debian — Ubuntu support tops out at version 20, and Debian support at version 11).

In general, an antivirus software does two main things: it patches security issues in system’s software if the user neglects updates, and it tries to prevent users from running malware by detecting known threats and blocking execution. For this, though, an antivirus needs a massive, constantly updated malware database, which is tough to maintain. At best, it might prevent a user from running the most obvious malware. Both functions are really only helpful if the user uses its system in pretty inadequate way.

Summarizing:

• 🦄 Modify with cautions the list of sources for apt.
• 🦄 Update and upgrade your system regularly, with particular attention to security updates.
• 🦄 Do not install packages that you do not plan to use.

②.⑥ Managing your system’s packages: Post-installation actions I perform that fall into this category

In order to pass to the administration of my system with a user with elevated permissions, I need to install sudo package (yep, it is not a part of standard system utilities on Debian), what is sudo by the way?

Sudo (sometimes considered as short for Super-user do) is a program designed to let system administrators allow some users to execute some commands as root (or another user). The basic philosophy is to give as few privileges as possible but still allow people to get their work done. Sudo is also an effective way to log who ran which command and when.

# install sudo
apt install sudo
# list existing users (you will see various users created by the system)
cat /etc/passwd 
...
alisa:x:1000:1000:alisa,,,:/home/alisa:/bin/bash

# Each field (separated by : ) represents user's account details:

# alisa: Username
# Password Placeholder (x): An "x" indicates that the password is stored securely in the /etc/shadow file, not directly in /etc/passwd.
# (1000) - User ID (UID): The unique identifier for this user. The first regular (non-system) user typically has a UID of 1000.
# (1000) - Group ID (GID): The primary group ID associated with the user. This number references a group in /etc/group.
# alisa,, ,: This field often contains the user’s full name or other personal information. In this case, it's empty except for the name "alisa."
# /home/alisa - Home Directory : The path to the user’s home directory.
# /bin/bash :Default Shell : The login shell that will run when the user logs in.

Okay this is my user alisa and I want to grant this user sudo privileges by adding my user to sudo group.

# check existing groups
cat /etc/group
...
sudo:x:27:
...

# sudo - Group Name: 
# x - Password Placeholder: The "x" indicates that the group password, if any, is stored securely in /etc/gshadow, not directly in /etc/group. Most groups don’t use passwords
# 27 - Group ID (GID): This is the unique identifier for the group. Each group has a unique GID.
# : __ (empty) - Group Members (empty in this case): This field lists the usernames of members of the sudo group. 

#check member of which groups is your current account in use (root)
root@wonderland:~# groups
root 

# adding my user (alisa) to rhe group sudo 
root@wonderland:~# adduser alisa sudo
Adding user 'alisa' to group 'sudo'...
Done.

#logging out from system
root@wonderland:~# exit

#relogging as alisa

#trying to update apt with sudo

alisa@wonderland:~$ sudo apt update
[sudo] password for alisa: _
...
...
All packages are up to date

# Optionally: check changes in /etc/passwd and /etc/group

③ Passwords management & Permissions management

If you read Part 2 of this series, particularly the installation step on disk partitioning, you might already have some idea about mounting options for different directories.

Mounting options are, in a way, foundational to setting permissions. A partition, whether logical or physical, holds data. When you mount any partition, whether it’s a functional part of your system or just a USB pen drive, for example, in READ ONLY mode, it doesn’t matter if you’re a regular or root user—there’s simply no way to write to it at the filesystem level. The same goes for option like noexec. If you have a partition with applications but mount it with noexec, there’s no way to execute anything from there.

If you installed the entire system on a single partition, you’re limited with mounting options, as you’ll only have the / (root) partition. For example, if you want to mount /tmp with the noexec option, it’s impossible unless /tmp is on a separate partition.

About /tmp and the noexec option. There’s ongoing debate about this since some software installers still place temporary executables in /tmp. So, what’s the solution? Should you just allow /tmp to be executable? Well, not necessarily. I want to share a great answer from Server Fault that covers not only /tmp and mounting options but also provides a broader approach to system administration.

Convenience is not a relevant factor in this. "Oh, I didn't lock down /tmp because then I need a few more minutes when I update my software next year". A great reason? I don't think so.
How about this one:
"We learned that enemies can attack without notice. They could also use hundreds of spies to poison the food. So we stopped handing out guns to our soldiers."
Wait, WHAT?
There's other measures that require a lot more effort, experience and luck to secure a system, and knowing people have limited money, lifespans and also would like to spend time with their families: Don't skip the easy stuff.

The nosuid mount option is another nice tool, it specifies that the filesystem cannot contain set userid files. Preventing setuid binaries on a world-writable filesystems (like /var and /tmp) mitigates a risk of root escalation or other awfulness there. Personally I mount also /home with this option.

Some people even keep the partition mounted to /usr as read-only by default. Whenever they need to install something, they temporarily remount this directory with read-write permissions and then switch it back to read-only afterward. This can even be configured automatically in apt.conf.

Mounting options are a great tool in preventing the spread of anything nasty that you occasionally bring onto your system. However, it’s all about permissions at the end. Who can remount a filesystem in a more desirable way for a malware? Root user.
And who can change or elevate permissions? A sudo user can, and root has unrestricted power in this field.

So, "strong defense mechanisms" + "careful system administration practices" + "root password 1234admin and sudo password for the user is 1234user" +"malware" = you’re cooked anyway.

Avoid using simple passwords. I know it can be annoying to type a long and complicated password each time, especially if you’re not using the root account (which, by the way, you shouldn’t use carelessly). But after setting up your system, it’s more common to work within your user space rather than system-wide, so you won’t need sudo as much. Set a strong password for root and separate, equally strong passwords for all user accounts. By “strong,” I mean at least 14 characters, with uppercase, lowercase, special characters, and numbers.

Worried about forgetting these passwords? If you’re not already using a password manager, it’s time to start. Try KeyPass for local storage or 1Password and BitWarden for remote storage — some are free, some require payment. If you’re concerned about security risks, there’s always the paper method or relying on your memory (with a small risk of forgetting and locking yourself out of your own PC). However, any method for storing strong passwords is better than using “admin1234” as a password if you care about security.

And what else should you do with passwords, even if they’re long and strong? Right — you need to update them regularly. For password management, you can configure /etc/login.defs by editing these key settings:

• PASS_MAX_DAYS: Sets the maximum number of days a password is valid before a change is required. Don’t set this too low — excessive changes can lead to predictable, weak passwords.
• PASS_WARN_AGE: Sets the number of days before expiration that users receive a warning. A value of 0 warns only on the expiration day; negative values disable warnings.
• ENCRYPT_METHOD: Defines the password hashing algorithm. Options include SHA256, SHA512, BCRYPT, and YESCRYPT (recommended for strong security). Avoid weaker algorithms like DES. About system file permissions… I prefer that the owner of files like /etc/passwd, /etc/group, /etc/shadow, /etc/gshadow, /etc/shells, and /etc/security/opasswd is set to root, with only root having write permissions. By default on Debian, it’s configured this way. However, you can double-check with commands:

stat -Lc '%#a %A %u %U %g %G' /etc/passwd #and other files
# permissions and ownershup as I expected
0644 -rw-r - r - 0 root 0 root
#%#a — Access permissions in octal format
#%A — Access permissions in human-readable format
#%u — User ID of owner
#%U — Username of owner
#%g — Group ID of owner
#%G — Group name of owner

Additional details: How I do stuff on my Debian System

• 🦄I add PPAs to /etc/apt/sources.list.d/ only for major projects—essential technologies for my development stack (e.g Docker, MongoDB).
• 🦄For other third-party software with smaller scope and functionality, I build it from source in a bootstrapped Debian (Debootstrap — Debian Wiki). In the last part of this series, I’ll demonstrate how I do this for one useful tool.
• 🦄 When it comes to NVIDIA graphics drivers, I always install them from Debian repos (in the next part of series I will cover it in more details)
• 🦄 Before buying new piece of Hardware (it is mostly about Bluetooth adapters) I first check its compatibility with Linux OS — drivers, and the presence of firmware in Debian repos, so I can avoid using “community maintained” drivers/firmware.
• 🦄 I do not run anything from Windows OS on my PC with tools like wine.
• 🦄 I use a password manager to manage all my passwords and update them periodically.
• 🦄 Whenever I browse Internet — so, open a browser — I use a different user account. I log in with this alternate user and close the session with my default user, which is part of the sudo group. So, whenever I’m using the browser, my user never has sudo privileges enabled. My favorite browsers are Brave and DuckDuckGo, though I have almost all browsers installed on my PC for web development testing purposes. For browsing, I mostly use Brave. One key point about browsers: they must be kept updated. Regular updates address new threats and security measures—not just fancy features. They should also have an ad blocker to protect you from a barrage of pop-ups, malicious redirects, trackers, and harmful JavaScript.
• 🦄 I use secure mail provider (not Google) and I use e-mail aliases, so I do not use same e-mails addresses for everything where registration/logins are needed.

See you in the next part!