Hoge load CentOS 7 op meerdere servers (VPS)

[Rido]

Goedemorgen,

Enige tijd geleden zijn er wat problemen ontstaan op mijn CentOS 7 hosting servers. Zelf heb ik van alles geprobeerd maar ik krijg het helaas niet opgelost.

Op mijn CentOS 7 servers worden er constant processen gestart die 100-200% CPU verbruiken. Deze processen doen zich voor als een normale service maar dat zijn ze niet.
Na de volledige reboot van de server verandert het type proces ook, zo heb ik al processen gehad als chrond, nginx, httpd, sendmail, atd & crond.

Screenshot htop:


Vervolgens heb ik van zo'n proces de proc bekeken:

code:

[root@hosting01 log]# ll /proc/4179/exe
lrwxrwxrwx 1 root root 0 Feb 19 08:23 /proc/4179/exe -> /usr/local/bin/.~50F36b7 (deleted)

Het proces wordt gestart vanuit een bestand wat steeds tijdelijk wordt aangemaakt en dan meteen weer wordt verwijderd.

Met "journalctl -r | grep crond" ben ik dit tegen gekomen:

code:

Feb 19 09:20:46 [e-mail] kernel: crond[17436]: segfault at 137b008 ip xxxxxxx sp xxxxxxxx error 4 in .~50F36b7 (deleted)[400000+165000]
Feb 19 09:19:46 [e-mail] kernel: crond[17149]: segfault at 155f000 ip xxxxxxx sp xxxxxxxx error 6 in .~50F36b7 (deleted)[400000+165000]
Feb 19 09:13:46 [e-mail] kernel: crond[15446]: segfault at 1761000 ip xxxxxxx sp xxxxxxxx error 6 in .~50F36b7 (deleted)[400000+165000]
Feb 19 09:10:46 [e-mail] kernel: crond[14584]: segfault at 1a74000 ip xxxxxxx sp xxxxxxxx error 6 in .~50F36b7 (deleted)[400000+165000]
Feb 19 09:08:46 [e-mail] kernel: crond[14028]: segfault at 2657000 ip xxxxxxx sp xxxxxxxx error 6 in .~50F36b7 (deleted)[400000+165000]
Feb 19 09:07:46 [e-mail] kernel: crond[13755]: segfault at 15d5000 ip xxxxxxx sp xxxxxxxx error 6 in .~50F36b7 (deleted)[400000+165000]
Feb 19 09:06:46 [e-mail] kernel: crond[13309]: segfault at 1e21000 ip xxxxxxx sp xxxxxxxx error 6 in .~50F36b7 (deleted)[400000+165000]
Feb 19 09:05:46 [e-mail] kernel: crond[12933]: segfault at 2544000 ip xxxxxxx sp xxxxxxxx error 6 in .~50F36b7 (deleted)[400000+165000]
Feb 19 09:04:46 [e-mail] kernel: crond[12596]: segfault at 1305000 ip xxxxxxx sp xxxxxxxx error 6 in .~50F36b7 (deleted)[400000+165000]
Feb 19 09:03:46 [e-mail] kernel: crond[12330]: segfault at 217f000 ip xxxxxxx sp xxxxxxxx error 6 in .~50F36b7 (deleted)[400000+165000]
Feb 19 09:01:46 [e-mail] kernel: crond[11688]: segfault at a7f000 ip xxxxxxxx sp xxxxxxxx error 6 in .~50F36b7 (deleted)[400000+165000]
Feb 19 09:00:46 [e-mail] kernel: crond[11400]: segfault at 2231000 ip xxxxxxx sp xxxxxxxx error 6 in .~50F36b7 (deleted)[400000+165000]
Feb 19 08:59:46 [e-mail] kernel: crond[11060]: segfault at 1d35000 ip xxxxxxx sp xxxxxxxx error 6 in .~50F36b7 (deleted)[400000+165000]

Inmiddels heb ik de server al gecontroleerd met ClamAV & Rkhunter maar daar is niks uitgekomen. De server is ook helemaal bijgewerkt tot de laatste versie.

Heeft iemand nog ideeën?

Alvast bedankt!

[Hero of Time]

Backup maken en nieuwe VPS install aanvragen. Je systeem is overgenomen door iemand die 'm misbruikt voor naar ik denk cryptominen. Dit proberen op te schonen helpt niet omdat degene die dit heeft veroorzaakt al toegang heeft tot je systeem.

Zorg dan gelijk voor de nieuwe install dat je alleen met SSH keys inlogt ipv met wachtwoord, zet er fail2ban op en beperk je services tot het minimale mbt toegang (chroot ze als 't even kan). En zet SELinux aan, die zal waarschijnlijk wel uit staan nu.

[NaliXL]

Gehakt ben je zeker. Weinig kans dat je dit nog gaat recoveren zonder ergens een backdoor achter te laten. Je /usr/local/bin is normaal immers niet bereikbaar voor scripts e.d.

Anyway, wil je het toch proberen, probeer dan eens met een cron job te maken die bijvoorbeeld iedere seconde iets als dit draait:

code:

find /usr/local/bin/ -mmin 1 -exec ls -lah {} \; >> ~/malwarelog.txt

Dan zou je in ieder geval wat details over de aangemaakte executables kunnen krijgen. Zoals: onder welke user worden ze aangemaakt. Misschien heb je nog het geluk dat de rechten voor je /usr/local/bin gewoon iets verkeerd stonden, en dat je root account nog niet compromised is. In dat geval kun je zoeken naar alles wat behoort aan de geïnfecteerde account en dat wegmieteren.

[Rido]

Bedankt voor jullie reacties. Hier was ik al bang voor

Met het find scriptje elke seconden laten draaien krijg ik het helaas niet voor elkaar. Ik krijg de ls op een gegeven moment wel door maar het bestand is volgens mij instant weer verwijderd dus deze zie ik niet.

Heb net geprobeerd de sshd service te disablen en de ssh poort te sluiten maar die worden steeds weer gestart en geopend dus ben bang dat mijn root compromised is.

Dat wordt vanavond maar de servers opnieuw installeren.

Mocht iemand nog een idee hebben om het anders op te lossen hoor ik het natuurlijk graag.

[RvV]

Ik ben dan toch wel een beetje benieuwd hoe dat ze aan je root ww zijn gekomen. Was het relatief simpel te brute-forcen?

[Rido]

RvV schreef op maandag 19 februari 2018 @ 10:52:
Ik ben dan toch wel een beetje benieuwd hoe dat ze aan je root ww zijn gekomen. Was het relatief simpel te brute-forcen?

Mijn wachtwoord was 13 tekens dus dat valt niet simpel te brute-forcen lijkt me. Verder hadden we SSH op een andere poort draaien en inloggen als root stond uitgeschakeld.
Ook hebben we CSF draaien dus een brute-force zou automatisch geblokkeerd moeten worden.

Vind het erg apart. Een server heeft het blijkbaar al 1,5 week en de andere pas sinds eergisteren.

[DennusB]

Het hoeft niet via SSH overgenomen te zijn. Kan ook dat je ergens een lek in je PHP (?) code heb zitten en ze er op die manier door zijn gekomen!

[Rido]

DennusB schreef op maandag 19 februari 2018 @ 10:58:
Het hoeft niet via SSH overgenomen te zijn. Kan ook dat je ergens een lek in je PHP (?) code heb zitten en ze er op die manier door zijn gekomen!

We hebben Patchman draaien en die heeft de afgelopen tijd geen lekken gevonden.

De enige user met sudo rechten heeft geen webhosting account. En we maken gebruik van DirectAdmin & Cloudlinux voor deze servers.

[Hero of Time]

Ah, DirectAdmin. Daar zit je fout. Dat is sowieso een broddelpakket van heb ik jou daar. En het draait standaard als root. Hoppa, attack point gevonden en is keihard uitgebuit.

Dus, voor je volgende installatie, ga GEEN DA gebruiken.

[DJMaze]

Rido schreef op maandag 19 februari 2018 @ 10:57:
Verder hadden we SSH op een andere poort draaien

Dat is geen beveiliging

[Rido]

Hero of Time schreef op maandag 19 februari 2018 @ 11:17:
Ah, DirectAdmin. Daar zit je fout. Dat is sowieso een broddelpakket van heb ik jou daar. En het draait standaard als root. Hoppa, attack point gevonden en is keihard uitgebuit.

Dus, voor je volgende installatie, ga GEEN DA gebruiken.

Tot op heden nog nooit problemen mee gehad en werkt op zich wel mooi
Maar wat voor pakket zou jij adviseren? Plesk?

DJMaze schreef op maandag 19 februari 2018 @ 11:19:
[...]

Dat is geen beveiliging

Klopt, maar was meer als "extraatje"

[Hero of Time]

Rido schreef op maandag 19 februari 2018 @ 11:22:
[...]


Tot op heden nog nooit problemen mee gehad en werkt op zich wel mooi
Maar wat voor pakket zou jij adviseren? Plesk?

Liever niets, maar als je echt niks kan, dan is Plesk de mist slechte van al het kwade.

[DJMaze]

Hero of Time schreef op maandag 19 februari 2018 @ 11:24:
Liever niets, maar als je echt niks kan, dan is Plesk de mist slechte van al het kwade.

Ik gebruik zelf cPanel op alle servers. Tot nu toe ook weinig problemen mee.
De nieuwe EasyApache4 is wel fijn in cPanel.
Er kleven ook nadelen aan, en je moet bepaalde features gewoon uitzetten.

Inderdaad het beste is geen, maar dan moet je zelf iets bouwen om bij alle hosting pakketten de (sub)domeinen en e-mailadressen te beheren.
Tja, en dan zie je maar al te vaak dat men scripts bouwt met root toegang, heb je weer de single point of failure.

[ Voor 5% gewijzigd door DJMaze op 19-02-2018 11:31 ]

[Rido]

Bedankt voor het advies!

Migreren naar een nieuw controlpanel wordt wel een flinke klus, dus twijfel om over te stappen.
Zit er zelf nu aan te denken om via CSF een IP whitelist te zetten op de SSH & DirectAdmin poorten.

En natuurlijk PasswordAuthentication uit voor de sshd server.

[Sneezydevil]

Werd DirectAdmin wel van updates voorzien? Want ze hebben wel een issue gehad, maar dat is al enige tijd opgelost.

Ik draai meestal ook niks, maar veel klanten draaien wel DirectAdmin en heb recent geen gekke dingen gezien.

[Hero of Time]

Als je echt met iets moet werken, probeer het dan achter een VPN te hangen. Dus stel bijvoorbeeld OpenVPN in en alles wat je met de machine moet doen, vereist dat de VPN up is voordat je ergens bij kan. Zeker als je iets als DA wilt blijven gebruiken gooi je die niet publiekelijk open.

Whitelisten kan, maar let er ook op dat het mogelijk al met spoofing omzeilt kan worden.

[DJMaze]

Rido schreef op maandag 19 februari 2018 @ 11:35:
Migreren naar een nieuw controlpanel wordt wel een flinke klus, dus twijfel om over te stappen.

Heb je je in die "flinke klus" verdiept?
Ik had mij ooit 2 uur ingelezen en vervolgens een complete migratie simpel uitgevoerd.

[Rido]

DJMaze schreef op maandag 19 februari 2018 @ 13:09:
[...]

Heb je je in die "flinke klus" verdiept?
Ik had mij ooit 2 uur ingelezen en vervolgens een complete migratie simpel uitgevoerd.

Bedankt. Ik zal eens kijken naar de mogelijkheden om DirectAdmin te migreren naar Plesk.
Zo te zien heeft Plesk hier een tool voor gemaakt

Hero of Time schreef op maandag 19 februari 2018 @ 12:47:
Als je echt met iets moet werken, probeer het dan achter een VPN te hangen. Dus stel bijvoorbeeld OpenVPN in en alles wat je met de machine moet doen, vereist dat de VPN up is voordat je ergens bij kan. Zeker als je iets als DA wilt blijven gebruiken gooi je die niet publiekelijk open.

Whitelisten kan, maar let er ook op dat het mogelijk al met spoofing omzeilt kan worden.

Dit is wel lastig voor een shared webhosting server. Maar misschien het migreren naar Plesk al wat gaat verhelpen.


Met behulp van een collega & Stackoverflow heb ik de binary file weten te bemachtigen die steeds het proces start. Dit heb ik gedaan met het onderstaande bash script. We gaan nu even kijken of we wat informatie uit het bestand kunnen halen.

Bash:

#!/bin/bash

watchedDir="/usr/local/bin/"

inotifywait -m "$watchedDir" -e create,modify -e moved_to |
    while read path action file; do
        echo "The file '$file' appeared in directory '$path' via '$action'"

        cp "$path$file" "/root/moved_files/tmp_file_$action"
    done

[ Voor 64% gewijzigd door Rido op 19-02-2018 14:45 ]