-1

I have a server with Arch Linux installed and for some reason, it gets infected after a period of inactivity. I reinstall, remain inactive for some time and it gets infected again. Every time I reinstall the server, I run a script that also installs the following:

With pacman

  • core/gcc
  • extra/nginx
  • extra/python-pip
  • extra/python-django
  • extra/postgresql
  • community/python-psycopg2
  • community/nodejs
  • community/npm

With pip

  • uwsgi

Is it possible, that after I install one of those, my server can get infected because of it? It has happened about 4 times now. The server installation is done by my provider, which I fully trust (they host other servers of mine and never had problems).

Another possibility could be that someone gained access to my server through my root login, which seems impossible since I've always checked the 'last login' whenever I login, and it was always me (I wrote down every time I logged on).

After a while, the servers starts a Large DDoS Attack

Something that I get a lot as a response is "Reinstall the server, no other choice". That's where I get stuck, because I've done it already so many times, and I get the feeling my provider is really getting fed up with me "returning with this DDoS attack".

Albêr
  • 1
  • 2
  • Define "infection" – Anubioz Sep 30 '16 at 10:45
  • Infection as in, clamav frequently spotting multiple rootkits. They seem to be appearing out of nowhere. – Albêr Sep 30 '16 at 11:25
  • You know that there is no way you can clean a linux rootkit without lreinstalling, right? And by "reinstalling" I mean that you cannot keep any binary, library, grub loader and/or configuration files? And if that "rootkit" appears every time it's either you moved it from the old system or it's included by your hosting provider (maybe their hypervisor was hacked) – Anubioz Sep 30 '16 at 11:41
  • Ok, than that's where my problem is :| sorry I'm not so familiar with this stuff. The way I 'reinstall' my server is simply by clicking a button 'reinstall'. My provider takes care of this. Should I contact them for this? – Albêr Sep 30 '16 at 11:56
  • Definitely, if you don't keep any data & virus keeps appearing, it's your provider who is infected, not you. And there is no way you can fix their hypervisor from inside a virtual machine... So I suggest you just open a support ticket & let them do their job :) – Anubioz Sep 30 '16 at 12:00
  • According to the provider, if I reinstall the server with Arch Linux, the malware will be removed. The provider also claims that keeping my server 'quarantined' (read, no activity after boot and password change) will still provide a risk to it. Is this true? Can a server be vulnerable when its access is extremely limited? – Albêr Sep 30 '16 at 14:19
  • That means that your provider uses broken, outdated arch linux VM template with exploitable vulnerabilities. You should try to explain them that it should be absolutely impossible to hack a newly installed OS, which hasn't been accessed by user in any way. They should just delete that template if something like this happens – Anubioz Oct 01 '16 at 06:37
  • @Anubioz It's unclear how the machine gets infected in the first place. It's entirely possible (and more likely) the configuration done by the OP is to blame because it's insecure and/or installs custom software with vulnerabilities. After all, he installs Nginx and node.js, so it's not just SSH that's facing the internet. – Sven Oct 01 '16 at 08:55
  • @Sven While most certainly your version describes what is actually happening, i based my assumption on that unprofessional support claims that ">keeping server 'quarantined' (read, no activity after boot and password change) will still provide a risk to it.". I assumed that newly installed non-accessible server must not be affected with anything by definition :) – Anubioz Oct 01 '16 at 09:18
  • So, reinstalling the server without installing any software on it and accessing it (other than changing the std password) should not be able to be infected in any way? – Albêr Oct 01 '16 at 09:52

2 Answers2

1

First of all, we need to know what infection this is (at least in a generic way). This helps us know where it stores itself, and what it's capable of. Without that information, I can provide you with some general recommendations based on the most common and likely scenarios.

Arch's repos are extremely trustworthy. This is another problem.

Nowhere in your process did you mention blanking at least the beginning of your disk. Many rootkits store themselves in the beginning of a disk so they get loaded at boot time by the BIOS or bootloader. This is good for driver injection, and is especially useful for simple things like DDoS attacks.

This code also won't go away with an OS reinstall, and will stay there until you blank where it's stored exactly (which is always in the beginning of the drive - so it can be loaded at boot).

Use "dd" or something similar to write zeros to your drive or array. Blank the whole thing if you want, but the first megabyte is all you should really need.

Also make sure you don't have any other storage devices attached to this system (such as flash drives). In addition to that, check the other machines on your network. You may have something that can automatically traverse your network, but those are quite rare and you would very likely see it elsewhere (assuming you check these things).

Lastly, if you are using a caching proxy such as squid, check that machine. It may have something nasty cached.

Spooler
  • 7,016
  • 16
  • 29
  • Thanks for the quick answer! I never really doubted the arch repositories, I'm just at the end of my latin. I'm not the physical owner of this server, just renting it. I'm not using squid, I'm planning on using nginx's caching function for that. Thanks for the extra insights, I haven't thought about those! – Albêr Sep 30 '16 at 10:03
-3
  1. They are trustworthy.
  2. Don't use a bleeding - edge OS for your server(just Google for it, you will find several answers, why you shouldn't) .
  3. Rootkit.
enkeyz
  • 1
  • 2
  • And please do not use Arch for your server OS. – enkeyz Sep 30 '16 at 10:08
  • Why not? It seems to be a very performing OS. – Albêr Sep 30 '16 at 11:27
  • Arch is a perfectly valid distribution to be using, especially if bleeding edge features are required. Not all production environments require massive stability, and some can benefit greatly from new technologies. This is also not a place for product recommendations, solicited or otherwise. – Spooler Sep 30 '16 at 12:28
  • Gentoo >> Arch :) – Anubioz Oct 01 '16 at 08:19