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

Protecting your Debian against malware.

In the , 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

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. (

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. ()

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 for Debian. Apt downloads packages from one or more 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 (

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:

).

❧ The second entry on the line is a URL to the .

❧ 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

Good old days when when something “unexpected” was fun

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

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. ()

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) ().

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 ).

When I run the command to check the Linux kernel version my system is using (uname -r), I get this output:

CODE Kopieren

root@wonderland:~# uname -r

6.1.0–26-amd64

I know the bookworm backports repo (.

In the editor, I append this line:

CODE Kopieren

deb http://deb.debian.org/debian bookworm-backports main contrib non-free-firmware

Running apt update will apply your modifications to the sources list of apt. Any future changes you make to the sources.list file should also be followed by this command.

Check what’s available for the kernel version (considering also the newly added bookworm-backports repo):

CODE Kopieren

apt search linux-image | more  # Remember to pipe to 'more' since in runlevel 3 you have no scroll bar, so you won’t see the start of the output if it’s long

apt search linux-image | grep backports | more

).

I can run apt install with the --simulate tag to see what will happen if I install a package. In fact, you can see that if I don’t specify that I want to install something from the Bookworm Backports repository, apt install automatically fetches packages from the Debian Stable repository.

CODE Kopieren

apt --simulate install -t bookworm-backports linux-image-amd-64

apt --simulate install linux-image-amd-64

(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 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 ). In the last part of this series, I’ll demonstrate how I do this for one useful tool.

See you in the next part!