An incident regarding the security of your IONOS server has been detected. We have been informed that attacks have been carried out from your server against third parties.
Details on the incident :
May 10 17:24:21 server770 sshd[17729]: Invalid user test from 82.165.61.178 port 55896 May 10 17:24:22 server770 sshd[17729]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=82.165.61.178 May 10 17:24:23 server770 sshd[17729]: Failed password for invalid user test from 82.165.61.178 port 55896 ssh2 May 10 17:24:23 server770 sshd[17729]: Received disconnect from 82.165.61.178 port 55896:11: Bye Bye [preauth] May 10 17:24:23 server770 sshd[17729]: Disconnected from 82.165.61.178 port 55896 [preauth]
I asked to IONOS to unblock my server but what can i do to repair the breach ?
It is not related to Diaspora. As I understand it they sent you log from affected server which your server attempted to connect over SSH. Diaspora doesn’t use SSH itself so the cause is elsewhere.
Possible reasons:
You have something using SSH (like some script) which accidentally points at wrong address so when it runs, it causes these errors.
Your server was compromised and how is used to attack other servers.
It is a mistake. Is 82.165.61.178 your IP?
If you don’t have anything which can cause #1 and it is not a mistake (it likely isn’t) then consider your server hacked. Take full backup of everything immediately and store it elsewhere. Change your hosting credentials. Perhaps email passwords too for mail which is linked to the hosting and any services on the affected server.
After you make sure you have everything backed up, the simplest way would be just getting a new server, setting it up independently. Be sure to set it up with complex passwords, firewall, everything properly updated. Then just switch domain name to it and reinstall everything, then recover data from backups. Change all admin passwords for all services, check that there are no new admin accounts created and existing ones are linked to correct e-mails. After you check that everything works in new place, just delete the old server.
Disinfecting existing server can be extremely complex and there are no ready complete solutions so it is not a topic for this forum.
As said earlier, it’s unlikely that diaspora* is the culprit, as our attack surface is generally low and we push security hotfixes within hours of learning about vulnerabilities, including upstream-libraries. Quite often, the entry point for attackers are unmaintained PHP applications like WordPress, or weak SSH passwords and/or brute-forces because no fail2ban was installed. However, that’s really hard to tell without doing a proper investigation, if that’s even possible on a system that’s not really set up.
We can’t really give you any concrete steps to take, but I wanted to provide you with a few details:
Do not attempt to clean up the server. Do a full reinstall of the operating system, and leave absolutely nothing behind. You have no way of telling if the attacker has placed backdoors, and how many, or where.
Do not copy over old directories onto the new server. Not /etc, but also not whole applications. Backdoors might be placed inside these directories or files, and you’d immediately compromise your new server if you just copy things over.
Instead, do a fresh reinstall of everything you had, and only copy over database data and config files.
For config files you copy, make sure there’s nothing in it that you don’t expect there to be.
For database dumps, make sure you have a look at the data as well. For example, if you run a WordPress blog, make sure that there isn’t a new admin user, or configs for a plugin you didn’t install, … anything that you didn’t do, basically. If, let’s say, the attacker has created an admin user on your WordPress, restoring a database backup without checking everything very carefully would allow an attacker to just sign into your blog and upload a malicious file.
If the services you run are not only used by yourself and other people have access to them, please inform your users that this happened. Even if you don’t know all the details of what went on, staying quite is not a good move.
Thank you for your valuables advices, I followed your recommendations and reinstalled everything with a new image of Debian 10 on my vps. I had taken care to save the database of my diaspora and so I could reinject it but I don’t know if I have proceeded properly. Is there a recovery procedure in case of crash as in my situation? What is the most important data in the database for the site to return properly ?
If you restored the database, you should have the most important stuff, the private-keys for the users (without them your users can not federate). Did you also copy over the uploaded images (they are outside of your database)?
To restore it’s the same as installation, but instead of db:create command you just restore your backup.
