(2024) Linux Backdoor

[Bismuth]

Brought to my attention recently.

I am not too well versed with linux lingo, but a backdoor was discovered concerning the XZ repository.

I do not see much talk about Void Linux, but is it possible Void might have been affected by this backdoor?
If so, how to remedy it?

[pid1]

Hello Bismuth,

Both xz and liblzma were reverted to versions accepted by all other Linux distros to be free from questionable contributions.

The pull request can be found here.

Be sure to update your XBPS repository and update packages. Additionally, if you build anything using xbps-src, be sure to pull the latest from the void-packages Github repo.

[Bismuth]

To the best of my understanding, I followed the guidebook and entered twice into the terminal "# xbps-install -Su" to update everything. If I missed anything, please inform me.

Another thing I thought to concern myself with is securing SSH. I looked into fail2ban, but how would one go about securing SSH on Void?
I found this article:
https://www.zdnet.com/article/5-tips-fo ... r-desktop/

But I am not too well-versed on how to implement this strategy on Void. Main thing is I do not want remote logins on my PC, and if its impossible to prevent that, at least make it really really hard to do so.

[pid1]

If you don't want remote logins on your PC the best solution is to disable any services allowing such logins.

Disable SSHd server:

Code: Select all

unlink /var/service/sshd

Enable the ufw firewall and deny any incoming connection:

Code: Select all

sudo xbps-install -S ufw
ln -s /etc/sv/ufw /var/service
sudo ufw enable
sudo ufw default deny incoming

If you do wish to keep SSH access from a local LAN, you can keep SSHd enabled and add an allow rule:

Code: Select all

sudo ufw allow from 192.168.1.0/24 ssh

In the above example, any device from the RFC1918 (aka Private) subnet of 192.168.1.1-192.168.1.254 can access SSH.
In addition, use strong passwords.

I leave SSH enabled on my laptop even when travelling and on many hotel WiFi networks. Since sometimes the hotel networks assign the same RFC1918 subnet that you allowed in the above firewall pinhole, you can use the LIMIT pinhole which limits the number of new connections per unit of time. In my case:

Code: Select all

sudo ufw limit ssh

You can also narrow this down, like before, to a specific device IP or subnet:

Code: Select all

sudo ufw limit from 192.168.1.0/24 to any port 22 proto tcp

SSH on a non-default port configuration is the same as your linked article mentioned, except to restart the service use

Code: Select all

sv restart shd