@Nicomo here are some security tips.
By the way the ~ character in your terminal prompt indicates that you are in your home directory /home/username, which the shell (command interpreter) abbreviates to ~, so it’s not part of your username. If you enter a different directory with the cd command, it will change.
Linux geeks don’t say a system is infected. It creates a false understanding of how malware works (or even what is malware). Maybe no malware was used for the attack. The attacker could simply log in on SSH to your system by guessing the password. So it’s correctly said your system is compromised.
Using 4 digit PIN is wrong. It can be brute-forced with a 15 years old machine in less than 1 minute (using John the Ripper).
Hacking passwords can mostly happen in 2 scenarios:
- Trying login repeatedly (e.g. from SSH), and in this case your system checks the password. It usually inserts a few seconds of waiting between allowing to login again. In this case, you can harden your login procedure. You will find some tips about it in this comment.
- The other scenario is when the attacker has obtained the cryptographic hash of the password from the /etc/shadow file which stores your password in a hashed form. In this case they can check the correctness of the tried password against the hash without waiting time between attempts. The attacker can also use ASIC hardware which is especially made for password cracking, and is capable of cracking thousands times faster than a GPU. But worth noting that the permissions of the
/etc/shadowfile only allows read access forrootuser, so if the attacker could read it, then he hadrootaccess to your system, and could do anything with your system. So cracking the password will unlikely to happen in this scenario as there are better attack possibilities withrootpermissions (unless the attacker explicitly needs your password).
Never use passwords on your local PC that you use for web services. Most web service providers can see your password in the DB, so they can try to log-in to your system with it.
Linux can’t run .exe files. The kernel simply can’t interpret them. The Linux binary executable format is ELF (but Linux executables usually don’t have a filename extension as it would make it harder to use them from the command line).
By default, an user can execute any Linux program files that has executable permissions, but the process launched this way can only change the user’s files, not system files as they are owned by root. So they can’t compromise your system, but they can access and change e.g. config files. For example turning off VPN/proxy settings in the browser, or stealing unencrypted passwords.
There is a noexec mount option that you can use for external partitions that doesn’t contain programs. But you have to be careful about your /home directory, because it usually doesn’t have noexec mount option. (Don’t forget that directories need the execute permission to be able to list their content, but that doesn’t mean that files within them will be executable, so noexec only applies to regular files.)
Also, malicious unprivileged programs could install e.g. a modified Firefox in your /home/username directory, and add a Firefox .desktop launcher in /home/username/.local/share/applications that shows up as the real Firefox in your application menu but launches the modified Firefox. The .desktop launcher spec is messed up and has serious security issues. The solution to the launcher problem is to use a launcher that doesn’t read .desktop files but instead lists binaries installed in your $PATH environment variable. There are some solutions using dmenu or rofi (Arch Wiki article).
You can use a sandboxing program, like Firejail, that isolates e.g. the browser so it can only see the parts of the system that is required for it to run and the files/directories you allow (e.g. it sees that you have no files on your computer, only your Downloads directory).
You should never install or run closed-source applications as their source code can’t be audited, and they do whatever they want. MS Teams, Skype, and Steam are closed source. The Opera and Vivaldi browsers are also closed source.
There are 2 protocols on Linux that programs use to talk to the system about what they want to display on the screen, and also to receive keyboard/mouse/touchscreen input. The old protocol is X11, and the new is Wayland. In X11, every program can access the clipboard and the keyboard input. Also, any program can take screenshots. This can be used by a background process to steal credentials. Under Wayland, only the focused window can receive keystrokes and read the clipboard. To capture a screenshot, a program have to ask for permission from the Wayland compositor software (window manager), which can be configured to allow taking screenshots only to certain applications.
Nearly every Linux distro (including Manjaro) uses X11 by default, because it’s the most broadly supported. Wayland requires some tweaking, because not every program supports it out of the box. Software have to be ported to Wayland, because it’s a completely different architecture. Most software has been ported already, however they may even in this case require some configuration. There are Wayland-compatible alternatives for some software that has not been ported, like bemenu instead of dmenu, and wofi instead of rofi. There is a good guide for setting up a Wayland-compatible desktop environment in the Arch Wiki: Wayland.
Linux uses PAM for authentication, which makes it possible to create custom login procedures. For example, there is a 2FA PAM module, which is when configured, after you enter your password, will ask for a 2FA code also. (By the way, I recommend the open-source Aegis authenticator, which is compatible with the closed-source Google Authenticator (since both uses the open standard TOTP algorithm), and is also available on F-Droid).
You can configure different authentication procedures in PAM for different scenarios (e.g. local login, SSH login, sudo, etc.)
If you don’t want to type even the TOTP codes, you can use a hardware 2FA device, such as YubiKey. There is a YubiKey PAM module too (it is covered in the Arch Wiki article), which will require your YubiKey when authenticating on your Linux session.
You can set up transparent disk encryption with LUKS, which protects (to some extent) from an attacker with physical access to your drive and access under other operating systems (e.g. Windows). Arch Wiki: dm-crypt
If you dual-boot Windows, you should get a switchable drive case, which you plug into your computer and has a physical switch between 2 different drives (one Windows and one Linux), so while one system runs, the other drive is disconnected.
The Rkhunter program can be used to search for known rootkits on your system.
You should set up a firewall, but it’s quite complicated as it requires network knowledge (what protocols are used, network topology, etc), and knowledge of the nftables tool which is for configuring the Netfilter module in the Linux kernel.
Also, there is a Security article in the Arch Wiki where you can find more tips.