Thanks, Neville, for your views on the matter. 
Let´s hope for the best.
Cheers from Rosika 
1 Like
If I understand correctly, the backdoor was open to connect to the affected system via SSH using a pre-configured magic key. So if JiaTan utilized the backdoor, he/she could have done just anything.
Generally, I’d restore a previous system snapshot (older than the backdoor may have appeared), and reupdate the system to the current state.
So it must be clean theoretically.
If there was some password or stored key stolen (you don’t know), change them.
Personally, I don’t think there’s a high probability of your server being hacked.
You say:
ssh arch@192.168.122.243
That suggests, your server is in your LAN, behind a NAT. Is there a port forward in your router, that makes the servers SSH port to be accessible from “outside”?
If not, I think there was no way to utilize the backdoor.
3 Likes
Hi László, 
thanks so much for providing your insights into the matter.
Wow, that sounds terrible. 
That´s the worst-case-scenario, I think. Let´s hope it hasn´t come to it.
When you´re saying this: Do you mean my Archlinux virtual machine?
I hope it couldn´t have affected the host (Linux Lite) this way… 
.
I´d have to look for the snapshots which I have for my Archlinux VM.
Thanks for the heads-up, László.
Yes, I think so, too.
That´s difficult to answer, László, as I don´t have a router the way you´re probably imagining it.
My inernet connection is established via a web-stick (Huawei E3372h), which connects to the mobile network.
Technically it works a router though, as my host recognizes it as “wired connection”.
The other means of establishing internet connection is via my smartphone (tethering).
That I use for bigger updates/upgrades of my Archlinux vm.
Thanks again and many greetings from Rosika
P.S.:
I was thinking of running security scans or audits on the system using tools like Lynis or AIDE to detect any anomalies.
I don´t know whether this would help at all though…
2 Likes
Hi Rosika,
That is the key point. Laszlo understands this better than me,
but I do know that noone, not even yourself, can ssh into your machine that is behind a NAT., from the internet.
If someone had to ssh into your machine for this malicious code to be used, then the code could have been present but
it could not have done anything… an unused entry point.
If you then remove it by updating , then it is gone. There should be no residual presence.
I think only servers exposed to the internet are at risk. What
happens when you use NAT is that it only allows incoming packets from sites that you have sent outgoing packets to.
Packets from anywhere else are rejected. .
In addition to that, your ssh is probably set to only accept
requests from machines on your local net.
Regards
Neville
3 Likes
Thanks for showing the command to list the xz program.
I checked my system and it is also version 5.2.
2 Likes
There may be a case here for being slow to do updates.
1 Like
@Rosika I do not use Arch right now, but I do use the rolling release openSUSE Tumbleweed. The day the malicious code was discovered, the Tumbleweed team recompiled all packages that used that package to use a non-malicious version. They released this as part of their daily release, posted warnings on all social media and displayed a prominent warning when you ran the package manager. This update was large, it took well over an hour for me to get everything downloaded and I have a very fast internet connection.
I do not know for certain Arch did the same, but I would hope that they did. Maybe there is a way to check.
4 Likes
That’s it!
@Rosika, imagine it as your house in the middle of your big garden. You also have a garage, and a summer-house in your big garden. You have all the doors of all your buildings locked, as well as the gates of your garden. Now imagine someone finds, that the manufacturer of the lock of your housedoor implemented a masterkey, and anyone having such a key can open the locked door (having that lock), and visit your living room in your house. But before getting to the door of your house, that visitor has to find first the gate of your garden, and enter it. Now if the gate is opened, the visitor could enter, has to find the way to the house with the affected lock. The “visitor” has to succeed all this, before could use the masterkey.
That surely won’t harm 
If you don’t know, you surely don’t have working port forwards, as configuring this requires special actions and doing this carefully, so it’s definitely not something you can just enable by accident.
I tried to look up your device, I found something not completely relevant:
On the second image I see the menu: Network settings, and I bet we should look into that menu to find something about port forwarding. Getting there, look for the words “port forward”, “virtual server” or such. Or “DMZ”, it is a special case of port forward. Is there anything enabled? Is there anything pointing towards your Arch server? Well, if not, you can be sure, noone could utilze tha backdoor, even if it was really present for a limited time period.
But you can test it easily. Connect your LAN to the net as usual via that stick, and start your server inside the LAN. Then connect your laptop (or any different machine) with your smartphone tethering. Observe the public IP of your LAN’s connection, look up something like whatismyip.com or checkip.dyndns.org.
Try to ssh to your server from the tethered network. If it succeeds, that means you have correctly set up port forwading for the used ssh port on your “router” towards your server. If you get something like “network unreachable” from ssh client, then there’s no port forwarding (as I suspect, the case is in your situation).
If I’m right, you don’t have to be scared.
Your visitor should have known your house number before (your current public IP), just to be able to get near… Then your visitor has to get to your actual (back)door, which is impossible, if there’s no portforwarding correctly set up.
I’m quite confident, you weren’t hacked, and can sit down, take it easy, and just have another cup of coffe (or 2) 
3 Likes
It works without grep too. Just pass the package name to dpkg:
root@ubuserver:~# dpkg -l xz-utils
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Név Verzió Architecture Leírás
+++-==============-=================-============-=============================>
ii xz-utils 5.2.5-2.1~deb11u1 arm64 XZ-format compression utiliti>
4 Likes
Hi all,
thanks so much for your latest comments and help.
@nevj :
That´s reassuring indeed.
Well, the fact that my Archlinux VM has version 5.6.1-3 of xz right now (the updated good one) leads me to the conclusion then that I may use Arch as it is with no need to roll back to a previous snapshot. I hope I´m right in my assessment.
That´s certainly great. 
Thanks for the clarification.
@easyt50 :
That´s fine, Howard. Thanks for the feedback.
@Akatama :
Wow, they´re really fast taking some action over there.
Uh, I´m not good with social media, I´m afraid. I would´ve missed all warnings provided by them.
I don´t even know what kind of social media to use and how to use them… 
.
Thanks for the additional information, Jimmy.
thanks a lot for providing such a vivid analogy, László.
You certainly put a lot of work into coming up with it. I hope it will be of help to others, too.
Thanks also for looking up the site displaying the information regarding my web-stick.
They seem to use an older version of web-interface though.
This is what my stick currently displays (ot´s in German though):
E3372h-320
Aktuelle Version 11.0.1.1(H697SP1C983)
Weboberflächen-Version WEBUI 11.0.1.1(W13SP2C7201)
Never mind.
Well, I looked through all of the available settings options but I couldn´t find “port forward”, “virtual server” or “DMZ”.
At least I can say: nothing is pointing to it.
O.K., I´ll still have to do that. Thanks for detailed instructions.
But I´m not quite sure if I understood you correctly:
- connect the host as per usual to the net (via sthe stick)
- start Achlinux vm from the host
- how to proceed now
- should I check whatismyip.com this way?
- doing the same with tethering instead of with web-stick?
- “Try to ssh to your server from the tethered network.” , i.e. from the host to Archlinux vm?
Thanks a lot, László.
Well, I ran lynis on my Archlinux vm yesterday. It was the first time I was dealing with lynis.
There are even man pages available for it:
Ubuntu Manpage: Lynis - System and security auditing tool .
I don´t know whether it was good enough to determine if eveyrthing was alright.
I certainly lack the expertise for evaluation. But as far as I can tell it doesn´t look bad:
+] Initializing program
------------------------------------
###################################################################
# #
# NON-PRIVILEGED SCAN MODE #
# #
###################################################################
NOTES:
--------------
* Some tests will be skipped (as they require root permissions)
* Some tests might fail silently or give different results
- Detecting OS... [ DONE ]
- Checking profiles... [ DONE ]
---------------------------------------------------
Program version: 3.1.1
Operating system: Linux
Operating system name: Arch Linux
Operating system version: Rolling release
Kernel version: 6.8.4
Hardware platform: x86_64
Hostname: no-hostname
---------------------------------------------------
Profiles: /home/arch/Ergänzungen_zu_Programmen/zu_lynis/lynis/default.prf
Log file: /home/arch/lynis.log
Report file: /home/arch/lynis-report.dat
Report version: 1.0
Plugin directory: ./plugins
---------------------------------------------------
Auditor: [Not Specified]
Language: en
Test category: all
Test group: all
---------------------------------------------------
[...]
-[ Lynis 3.1.1 Results ]-
Great, no warnings
Suggestions (36): [...]
Thanks to all of you once more and many greetings from Rosika
2 Likes
Aaaaargh 
Forget my stupid recommendation. I did not read carefully, I completely overlooked, that you run Arch in a VM. I really thought it’s a different machine.
My bad.
2 Likes
No problem, László.
Thanks for your feedback and for your kind help .
Cheers from Rosika
2 Likes
Still there’s a chance to check it.
Install Connectbot on your phone (is it Android, right?).
Then try to ssh into your server from the phone’s network…
I bet it won’t succeed, but still, you can try 
2 Likes
Hi Laśzló,
yes, it´s Android.
O.K., I will look into it.
Thanks so much for the suggestion.
BTW:
I looked at the xz installation dates on Archlinux:
arch@archlinux ~> cat /var/log/pacman.log | grep "installed xz"
[2022-01-27T05:05:21+0000] [ALPM] installed xz (5.2.5-2)
So it looked as if 5.2.5-2 was the previous version installed on the system.
I already frolicked, but then:
arch@archlinux ~> cat /var/log/pacman.log | grep "xz"
[2022-01-27T05:05:21+0000] [ALPM] installed xz (5.2.5-2)
[2024-02-09T16:29:54+0100] [ALPM] upgraded xz (5.2.5-2 -> 5.4.6-1)
[2024-02-26T15:54:27+0100] [ALPM] upgraded xz (5.4.6-1 -> 5.6.0-1)
[2024-03-14T17:44:50+0100] [ALPM] upgraded xz (5.6.0-1 -> 5.6.1-1)
[2024-04-09T15:20:47+0200] [ALPM] upgraded xz (5.6.1-1 -> 5.6.1-3)
Oh well… 
.
Never mind, 5.6.1-3 is the present one and lynis seems to have provided just good results.
I´m thinking of installing AIDE and/or fail2ban for hardening the system(s).
I´d like to be on a safer side in the future. But I´m not quite sure about them yet.
Would they do me any good? I don´t know. I´ll have to research.
At the moment I´m doing quite some reading up on them.
Many greetings from Rosika
2 Likes
Hi Rosika,
You might look into your sshd config.
Restrict it to accepting requests only from your local machines.
I forget details… can look it up if you want… the parameter is called ListenAddress … set it to listen to your local ethernet, but not to the modem ethernet
The file is /etc/ssh/sshd_config
and
I thought you could get your temporary ISP’s IP number using
the ip command? Might be wrong there, Laszlo seems to think you need a special app ?
Regards
Neville
2 Likes
I just upgraded my Artix
trinity:[root]:/run/service# cat /var/log/pacman.log | grep "xz"
[2024-03-21T21:29:58+1100] [ALPM] upgraded xz (5.4.4-1 -> 5.6.1-1)
[2024-04-13T20:54:01+1000] [ALPM] upgraded xz (5.6.1-1 -> 5.6.1-3)
So it is the same as your Arch.
I am not worried. … Just as an exercise in S6 , I stopped sshd
trinity:[root]:/run/service# s6-rc -d change sshd-srv
trinity:[root]:/run/service# s6-svstat /run/service/sshd-srv
down (exitcode 0) 54 seconds, ready 54 seconds
2 Likes
Hi Neville,
thanks for the suggestions.
That´s /etc/ssh/sshd_config, right?
Oh, I just noticed you updated your post. Yes, that´s the one then.
I´m not quite sure what you´re referring to. Should I do it on Arch vm or on the host? Or both?
Thanks. I´ll look into it.
Thanks for looking it up on your system, Neville.
Great. I shouldn´t be worried either, I guess.
Many greetings from Rosika
1 Like
I was wrong. It does not show with ip
But you can get it by logging into your modem.
1 Like
Do it in any distro running sshd. Most important one is Lite.
It is only a second line of defence. They have to get past NAT first.
That´s /etc/ssh/sshd_config, right?
Right.
You will find theis
#ListenAddress 0.0.0.0
#ListenAddress ::
Leave those alone and add a line
ListenAddress 192.168.32.0
thats my local net, not the modem
That will override the default and it will only listen to requests from the local ethernet.
2 Likes
Thanks, Neville.
Yes, I get it. Seems plausible.
Thanks a lot for the instructions.
Many greetings from Rosika
1 Like