Wat te doen als uw VPS is gehackt

Reinig een gecompromitteerde VPS niet

Wanneer uw VPS is gecompromitteerd, is de belangrijkste beslissing die u neemt degene die u neemt voordat u enig commando uitvoert. Probeer de machine niet te reinigen. Isoleer de server bij de provider, maak een snapshot van de schijf als bewijsmateriaal, roteer alle inloggegevens die op de server stonden en herbouw de omgeving vervolgens op een nieuwe server vanaf bronnen die u vertrouwt.

U kunt niet bewijzen dat een rootkit is verwijderd, omdat de tools die dit zouden moeten aantonen, de tools zijn die de aanvaller beheert.

Dat is het volledige argument. Hier volgt het mechanisme erachter. Een aanvaller die root-toegang heeft verkregen, kan ps vervangen zodat een specifiek proces-ID nooit in de uitvoer verschijnt. Eén regel in /etc/ld.so.preload laadt aanvallerscode in elk dynamisch gelinkt programma op de server, waardoor ls, ss en find allemaal op dezelfde consistente wijze liegen. Een laadbare kernelmodule kan bestanden verbergen onder de systeemoproep, waardoor zelfs een vers gedownload binair bestand een schone schijf ziet. U verwijdert de miner, de CPU-grafiek daalt en de server wordt stil. Stilte is echter ook hoe een werkende achterdeur eruitziet.

Herbouwen kost minder dan het lijkt. Een typische VPS bestaat uit een handvol pakketten, één configuratiemap en één dataset; een herbouw is dus een eindige taak met een duidelijk einde. Het zoeken naar elke wijziging die een aanvaller heeft aangebracht is een open proces en leidt nooit tot zekerheid.

Bevestig dat er daadwerkelijk sprake is van een inbreuk

Veel servers die als gehackt worden gerapporteerd, zijn dat niet. Duizenden mislukte SSH-aanmeldingen per dag zijn achtergrondruis op het internet, omdat elk openbaar IPv4-adres continu wordt gescand. Een lastb-uitvoer vol met root- en admin-pogingen betekent dat de scanners uw poort hebben gevonden. Het betekent niet dat iemand is binnengekomen.

Deze signalen betekenen wel iets:

• Een geslaagde aanmelding die u niet kunt verklaren, zoals Accepted password for root from 203.0.113.7.
• Een sleutel in authorized_keys die u niet zelf heeft toegevoegd.
• Een misbruikmelding van uw host over verkeer dat uw server verlaat.
• Een proces op 100% CPU met een naam die is gekopieerd van een kernel-thread. Miners die via blootgestelde Redis- en Docker-sockets zijn geplaatst, worden vaak gerapporteerd onder namen zoals kdevtmpfsi en kinsing.
• Uitgaande verbindingen naar adressen die geen van uw services gebruikt.

De vermomming als kernel-thread heeft een snelle test. Echte kernel-threads worden weergegeven tussen vierkante haken en hebben geen uitvoerbaar bestand erachter, dus sudo ls -l /proc/<pid>/exe faalt voor hen met No such file or directory. Als een proces dat wordt weergegeven als [kworker/0:2] een exe-link heeft die wijst naar iets onder /tmp, dan is het een gewoon gebruikersprogramma dat een kernelnaam gebruikt.

Voer deze controles uit met de wetenschap dat de server u kan misleiden. Ze zijn voldoende om te bepalen dat er iets mis is. Ze zijn niet voldoende om te bepalen dat er niets mis is.

Verbreek de netwerkverbinding bij de provider, niet vanuit de server zelf

Isolatie is de eerste prioriteit, omdat elke daaropvolgende stap zinloos is zolang iemand anders nog toegang heeft tot een shell. Het uitlezen van logs, het roteren van sleutels en het herstellen van data zijn nutteloos zolang een aanvaller live meekijkt.

Voer dit uit in het configuratiescherm van uw provider, in de netwerkfirewall die buiten uw besturingssysteem draait. Blokkeer al het inkomende en uitgaande verkeer en gebruik de webconsole als uw enige toegangsweg. Regels die daar worden afgedwongen, overleven alles wat er op de schijf gebeurt.

Er zijn twee redenen om dit niet vanuit de server zelf te doen. Een firewall die u configureert binnen een gecompromitteerde kernel wordt afgedwongen door diezelfde kernel; root kan sudo ip link set enp1s0 down net zo eenvoudig wissen als u het kunt instellen. Bovendien verbreekt het uitvoeren van sudo ip link set enp1s0 down via SSH eerst uw eigen sessie, waardoor u wordt buitengesloten van een machine die u op dat moment aan het onderzoeken bent.

Blokkeer zowel uitgaand als inkomend verkeer. Een reverse shell maakt verbinding vanuit uw server naar de aanvaller; een blokkade op alleen inkomend verkeer laat een reeds tot stand gebrachte verbinding dus perfect in stand. Als uw provider alleen inkomende regels ondersteunt, zijn de resterende opties het loskoppelen van de netwerkinterface of het uitschakelen van de instance.

Start de server nog niet opnieuw op. Controleer eerst of /var/log/journal bestaat. Als die map ontbreekt, schrijft journald naar /run/log/journal, wat zich in het geheugen bevindt; een herstart verwijdert dan het bewijs van de inbraak. Actieve processen verdwijnen ook bij een herstart, terwijl hun command lines vaak het duidelijkste bewijs zijn dat u zult vinden.

Maak een snapshot van de schijf voordat u wijzigingen aanbrengt

Een snapshot en een back-up vervullen hier verschillende taken. De snapshot die u nu maakt, is een kopie van een gecompromitteerde schijf: dit is uw bewijsmateriaal en het is de enige manier om terug te keren nadat u per ongeluk iets heeft overschreven. Uw oudere back-ups vormen het herstelpad. Als het paneel van uw provider de twee termen door elkaar gebruikt, lees dan eerst hoe VPS-snapshots verschillen van echte back-ups, omdat de bewaarregels en het herstelgedrag niet hetzelfde zijn.

Maak de snapshot via het paneel van de provider voordat u opnieuw inlogt. Een live-snapshot is crash-consistent: het legt de schijf vast zoals deze op dat moment was, vergelijkbaar met het plotseling verbreken van de stroomtoevoer. Dat is prima voor bewijsvoering. Geef de snapshot een naam zodat niemand deze per ongeluk terugzet. Iets direct als COMPROMISED-do-not-restore-2026-08-12 is de juiste mate van subtiliteit. Bewaar deze totdat uw onderzoek is afgerond en eventuele abuse-tickets bij uw host zijn gesloten.

Toegang verkrijgen wanneer SSH niet beschikbaar is

Er zijn twee methoden, beide beschikbaar in het paneel van de provider. De webconsole (VNC of serieel) maakt verbinding met de machine alsof u een fysiek toetsenbord heeft aangesloten. Dit werkt wanneer sshd niet draait, wanneer de firewall onjuist is geconfigureerd en wanneer een aanvaller de SSH-poort heeft gewijzigd. De authenticatie verloopt via een lokaal wachtwoord; bij een server die enkel op sleutels is ingesteld, moet mogelijk eerst het root-wachtwoord worden gereset voordat de console bruikbaar is.

Rescue mode is de betere optie. Hierbij wordt een klein live-systeem opgestart waarbij uw schijf is aangekoppeld maar niet actief is. Uw commando's zijn hierdoor betrouwbaar: de gecompromitteerde kernel en de gecompromitteerde binaries worden niet uitgevoerd. Koppel de schijf aan in alleen-lezen modus.

lsblk -f
sudo mkdir -p /mnt/victim
sudo mount -o ro /dev/vda1 /mnt/victim

Als lsblk LVM-volumes (logical volume manager) toont in plaats van een standaard partitie, activeer deze dan eerst met sudo vgchange -ay en koppel vervolgens het apparaat dat verschijnt onder /dev/mapper/.

Voer geen chroot uit naar de aangekoppelde schijf om rond te kijken. Een chroot voert de binaries van de aanvaller uit met uw rechten, waardoor het volledige nut van het opstarten in rescue mode teniet wordt gedaan.

Verzamel bewijsmateriaal dat nog betrouwbaar is

Voer deze commando's uit vanuit de rescue-modus, waarbij de schijf als read-only is aangekoppeld op /mnt/victim. Begin met de inloggegevens, omdat deze de inbraak dateren; al het overige is eenvoudiger zodra u een tijdsvenster heeft.

sudo grep -aE 'Accepted (password|publickey)' /mnt/victim/var/log/auth.log
sudo last -f /mnt/victim/var/log/wtmp
sudo lastb -f /mnt/victim/var/log/btmp
sudo journalctl -D /mnt/victim/var/log/journal -u ssh --since "2026-07-01"

Een ontbrekend /var/log/auth.log is op zichzelf niet verdacht. Sommige huidige Ubuntu-images worden geleverd zonder rsyslog, waardoor sshd alleen naar de journal logt; dit is wat de journalctl -D-regel uitleest. Wat wel opvalt, is een gat in anderszins doorlopende logs, of een logbestand dat is afgekapt tot nul bytes. Het wissen van logs komt vaak voor en gebeurt meestal onhandig.

Vervolgens de accounts en de sleutels.

sudo find /mnt/victim/root /mnt/victim/home -name 'authorized_keys*' -exec ls -l {} +
sudo awk -F: '$3 == 0 {print $1}' /mnt/victim/etc/passwd
sudo lsattr /mnt/victim/root/.ssh/authorized_keys

De awk-regel toont elk account met user ID 0. Alles behalve root in die uitvoer is een tweede root-account. Het find-patroon komt bewust ook overeen met authorized_keys2, omdat OpenSSH standaard beide bestandsnamen leest en de tweede gemakkelijk over het hoofd wordt gezien. Als lsattr een i in de attributenlijst toont, is het bestand onveranderlijk (immutable): een aanvaller zet deze vlag zodat uw poging om de sleutel te verwijderen faalt met Operation not permitted, en een vermoeide beheerder gaat ervan uit dat de bewerking is geslaagd.

Persistentie verbergt zich op een klein aantal plaatsen, dus controleer ze allemaal.

sudo ls -lt /mnt/victim/etc/systemd/system
sudo ls -l /mnt/victim/etc/cron.d /mnt/victim/var/spool/cron/crontabs
sudo cat /mnt/victim/etc/ld.so.preload
sudo grep -rnE 'curl|wget|base64|/dev/tcp' /mnt/victim/etc/update-motd.d /mnt/victim/etc/rc.local /mnt/victim/root/.bashrc /mnt/victim/root/.profile

/etc/ld.so.preload bestaat niet op een standaard Ubuntu- of Debian-systeem, dus No such file or directory is het gezonde resultaat en elke inhoud verdient uw aandacht. Een login-bestand dat de uitvoer van base64 -d naar een shell sluist, is hetzelfde verhaal: legitieme configuraties hoeven hun eigen tekst niet te verbergen.

Bouw de tijdlijn op basis van de wijzigingstijd (change time) in plaats van de aanpassingstijd (modification time).

sudo find /mnt/victim -xdev -newerct '2026-08-01' -type f -printf '%TF %TT %p\n' | sort

touch stelt de aanpassingstijd in op elke waarde die de aanvaller wil, dus mtime liegt gemakkelijk. De wijzigingstijd (ctime) wordt bijgewerkt bij elke wijziging aan de inode, en touch kan deze niet terugdraaien, dus -newerct geeft een eerlijker overzicht van wat er recent is geschreven. Het is nog steeds geen bewijs, omdat root de systeemklok kan verzetten of direct naar het block device kan schrijven.

Pakketintegriteit is één commando en één waarschuwing waard. Op een live-systeem print sudo dpkg --verify een regel voor elk pakketbestand waarvan de checksum niet langer overeenkomt, met een 5 in de checksum-kolom, en sudo debsums -ac doet hetzelfde inclusief configuratiebestanden wanneer het debsums-pakket is geïnstalleerd. Lees het resultaat slechts in één richting. Een gewijzigd /usr/sbin/sshd is echt bewijsmateriaal. Een schoon rapport bewijst niets, omdat hetzelfde root-account dat het binaire bestand heeft vervangen, de checksum-lijsten onder /var/lib/dpkg/info/ kan herschrijven. Rootkit-scanners zoals rkhunter en chkrootkit volgen dezelfde regel: een treffer is informatie, een schone scan is geen vrijbrief.

Kopieer wat u heeft verzameld van de machine af voordat u destructieve acties onderneemt.

sudo tar --ignore-failed-read -C /mnt/victim -czf /root/evidence-2026-08-12.tgz \
  var/log etc root/.ssh root/.bash_history home
sha256sum /root/evidence-2026-08-12.tgz

Noteer die hash ergens buiten de server. Als dit ooit een verzekeringsclaim of een politierapport wordt, is het kunnen aantonen dat het archief sinds de verzameling niet is gewijzigd het verschil tussen bewijsmateriaal en een map met bestanden. Per ongeluk dingen verwijderen tijdens een onderzoek is normaal, en de snapshot plus dit archief maakt het overleefbaar. Het ongedaan maken van een foutieve rm achteraf is veel moeilijker dan mensen verwachten, zoals herstellen van bestanden verwijderd met rm -rf uitlegt.

Vind de toegangspoort die is gebruikt

Een herbouw van de server die de toegangspoort niet afsluit, leidt er vaak binnen enkele dagen toe dat u opnieuw wordt gecompromitteerd, omdat de scan die u de eerste keer vond, nooit stopt. Vier toegangspoorten verklaren de meeste inbreuken op servers met één host.

SSH-wachtwoordauthenticatie. Een Accepted password for root-regel vanaf een adres dat u niet herkent, is op zichzelf al het antwoord. Controleer PasswordAuthentication in /etc/ssh/sshd_config en in elk bestand onder /etc/ssh/sshd_config.d/. sshd gebruikt de eerste waarde die het voor een trefwoord verkrijgt, en de Include-regel staat bovenaan het hoofdbestand op Ubuntu. Hierdoor overschrijft een toegevoegd configuratiebestand stilletjes de instelling die u verderop in het bestand heeft bewerkt.

Een service die zonder authenticatie is gepubliceerd. Redis op 6379, de Docker API op 2375, of een database die is gebonden aan 0.0.0.0 in plaats van 127.0.0.1. Docker is de meest voorkomende verrassing. Het publiceren van een containerpoort voegt DNAT-regels (destination network address translation) toe die worden geëvalueerd vóór de chains van ufw. Hierdoor kan ufw status rapporteren dat een poort is geblokkeerd, terwijl de container erachter antwoordt aan het hele internet. Begrijp dit vóór de herbouw: waarom Docker gepubliceerde poorten ufw omzeilen behandelt de volgorde van de regels en de oplossing.

Een ongepatchte webapplicatie. Doorzoek het access log van de webserver rondom uw vroegst verdachte tijdstempel naar een POST-verzoek naar een uploadpad of een admin-pad. Zoek vervolgens naar bestanden onder de web root met een overeenkomstige wijzigingstijd. Een verdwaald PHP-bestand in een uploadmap is het klassieke resultaat.

Een gelekt inloggegeven. Een sleutel die is gecommit naar een repository, een token dat in een chat is geplakt, of een .env-bestand dat als statisch bestand wordt geserveerd door een verkeerd geconfigureerde webserver. Automatisering maakt het gemakkelijk om dit per ongeluk te doen; dit is het argument voor het buiten houden van geheimen uit AI-agents en hun configuratiebestanden.

Als u na dit alles de toegangspoort niet kunt aanwijzen, ga er dan vanuit dat er een inloggegeven is gelekt en behandel elk geheim dat op de machine stond als openbaar.

Roteer alle inloggegevens die de machine heeft kunnen inzien

Roteer pas nadat het netwerk is verbroken, nooit daarvoor. Roteren terwijl de aanvaller nog een verbinding heeft, overhandigt simpelweg de nieuwe geheimen.

• Elke SSH private key die op de server was opgeslagen, plus elk account elders dat de bijbehorende public key vertrouwde.
• Elke key die u met ssh -A naar de machine heeft geforward. Agent forwarding laat een socket achter onder /tmp, en root op die machine kan deze gebruiken om zich als u te authenticeren op elke plek waar uw key wordt geaccepteerd, zolang uw sessie open blijft.
• API-tokens in .env-bestanden, in systemd Environment=-regels, in CI-configuratie en in provider-inloggegevens.
• Database-wachtwoorden en de applicatie-accounts die deze gebruiken.
• TLS (transport layer security) private keys die de server in bezit had. Vraag het certificaat opnieuw aan en trek het oude in.
• Het wachtwoord van uw hostingaccount, met tweefactorauthenticatie ingeschakeld. Dat paneel kan elke server die u bezit opnieuw opbouwen, snapshots maken en via de console benaderen; het is dus de werkelijke perimeter.
• Elk wachtwoord dat in een shell-sessie op die host is getypt terwijl deze gecompromitteerd was, omdat root een terminalsessie live kan opnemen.

Als een wachtwoord op die machine ergens anders wordt gebruikt, wijzig het daar dan ook. Hergebruik is de manier waarop één gecompromitteerde VPS verandert in een gecompromitteerd e-mailaccount.

De checklist voor herbouw

1. Maak een nieuwe server aan op basis van een schone distributie-image. Gebruik hiervoor niet de snapshot van de gecompromitteerde server en voer geen volledige restore van het root-bestandssysteem uit.
2. Installeer pakketten vanuit de repositories van de distributie. Kopieer nooit een binary vanaf de oude schijf.
3. Herstel uitsluitend data vanaf een back-up die dateert van vóór het vroegste bewijs in uw tijdlijn. Dit betreft database-dumps, uploads en applicatiestatus. Laat /etc, /usr en de oude unit-bestanden achterwege.
4. Voer de geroteerde geheimen handmatig in. Kopieer het oude .env niet.
5. Inspecteer herstelde webcontent op bestanden die zijn toegevoegd tijdens het tijdsbestek van de inbreuk voordat u deze opnieuw aanbiedt.
6. Verhard de server voordat u deze blootstelt aan het internet: gebruik uitsluitend SSH-keys, een werkaccount zonder root-rechten, een firewall die standaard al het inkomende verkeer blokkeert (default-deny), en publiceer geen enkele service breder dan strikt noodzakelijk. Doorloop de eerste tien minuten op een nieuwe VPS, verhard vervolgens SSH op de juiste wijze, en voeg daarna fail2ban op Ubuntu 24.04 toe om het aantal inlogpogingen te beperken. Geef elke service een eigen account met minimale rechten, zodat een volgend toegangspunt geen root-toegang biedt.
7. Schakel de oude server uit en bewaar de snapshot totdat het onderzoek en eventuele abuse-meldingen zijn afgesloten.
8. Herstel de back-ups. Als stap 3 gebaseerd was op giswerk, is de belangrijkste les dat uw back-uphistorie te kort was om voorbij het moment van de inbreuk te kijken. Versiebeheerde back-ups op een externe locatie met een lange bewaartermijn zorgen de volgende keer voor een schoon herstelpunt: restic backups op een VPS biedt beide.

Als u de inbreuk niet kunt dateren, kunt u geen veilige back-up kiezen. Herstel in dat geval alleen data die u handmatig kunt inspecteren: een SQL-dump die u kunt lezen of een map met afbeeldingen die u kunt controleren. Beschouw alles wat uitvoerbaar is als verdacht en installeer dit opnieuw vanuit de repositories.

Wat de misbruikmelding van uw host betekent

De meeste mensen vernemen dat hun server is gecompromitteerd via hun provider, niet door eigen monitoring. Hosts zien het uitgaande netwerkverkeer: SSH brute force-aanvallen op andere netwerken, spam op poort 25 of een aandeel in een reflection-aanval. De melding bevat doorgaans tijdstippen, poorten en een voorbeeld van de datastromen, samen met een deadline die in uren wordt uitgedrukt.

Reageer op de melding, zelfs als uw enige antwoord is dat de server is geïsoleerd en opnieuw wordt opgebouwd. Providers blokkeren het netwerkverkeer (null-route) of schorten een server op wanneer een ticket onbeantwoord blijft, waardoor uw incident verandert in een volledige uitval. Vraag vervolgens om de ruwe logregels die ten grondslag liggen aan het rapport. Deze tijdstippen zijn buiten uw machine geregistreerd; ze vormen het enige deel van de tijdlijn dat de aanvaller niet kon wijzigen en ze dateren de inbreuk vaak nauwkeuriger dan wat dan ook op de schijf.

Een gecompromitteerde klantserver is routinewerk voor een host en het correct afhandelen ervan wordt niet tegen u gebruikt. De bredere vraag over of VPS-hosting veilig is hangt grotendeels af van wat de klant configureert, wat precies het onderdeel is dat u nu vanaf nul opnieuw mag uitvoeren.

Wanneer u een professional moet inschakelen

• De server bevatte persoonsgegevens van anderen. Onder de AVG (Algemene Verordering Gegevensbescherming) moet een inbreuk in verband met persoonsgegevens zonder onredelijke vertraging, en waar mogelijk uiterlijk 72 uur nadat de inbreuk is vastgesteld, worden gemeld bij de toezichthouder. Het beoordelen of die termijn is ingegaan, is juridisch werk, geen systeembeheer.
• Betaalkaartgegevens vielen binnen de scope. De kaartorganisaties vereisen een erkende forensisch onderzoeker; zelf onderzoek doen kan het bewijsmateriaal beschadigen.
• Er is sprake van een afpersingseis of uw gegevens zijn versleuteld.
• De machine kon andere machines bereiken: een intern netwerk, een hypervisor, of een CI-runner met productie-inloggegevens. Eén gecompromitteerde host in een groep is een incident voor de gehele groep, totdat het tegendeel is bewezen.
• U heeft bewijsmateriaal nodig dat standhoudt voor verzekeringen of wetshandhaving. Stop bij de snapshot, maak een volledige schijfkopie en leg vast wie deze wanneer heeft behandeld.

Voor een enkele VPS waarop u uw eigen diensten draait, zonder gegevens van anderen, is het bovenstaande draaiboek de volledige taak. Isoleer bij de provider. Maak een snapshot voor bewijsvoering. Verzamel wat nog betrouwbaar is. Roteer alle inloggegevens. Bouw de server schoon opnieuw op.

FAQ

Kan ik een gecompromitteerde VPS opschonen in plaats van deze opnieuw op te bouwen?

Niet met enige zekerheid, omdat u het gecompromitteerde systeem vraagt om over zichzelf te rapporteren. Een vervangen ps verbergt een proces, een regel in /etc/ld.so.preload injecteert code in elk dynamisch gelinkt hulpprogramma dat u uitvoert, en een kernelmodule kan bestanden voor elk programma tegelijk verbergen. U kunt zaken vinden, dus een treffer is betekenisvol. U kunt echter niet aantonen dat iets afwezig is, dus een schoon resultaat is dat niet. Opschonen is alleen verdedigbaar als de server niets bevat waar u waarde aan hecht en u accepteert dat deze opnieuw gecompromitteerd kan worden.

Moet ik een gecompromitteerde server uitschakelen of laten draaien?

Verbreek eerst de netwerkverbinding bij de provider en laat de server vervolgens lang genoeg draaien om een snapshot te maken en de actieve processen te bekijken. Uitschakelen vernietigt de proceslijst en verwijdert het logboek volledig wanneer /var/log/journal niet bestaat, omdat journald dan naar het geheugen schrijft onder /run. Schakel de server alsnog uit als deze actief andere netwerken aanvalt en u geen mogelijkheid heeft om het uitgaande verkeer te blokkeren. Het stoppen van de schade is belangrijker dan het behouden van bewijsmateriaal.

Hoe achterhaal ik wanneer de aanvaller is binnengekomen?

Zoek de vroegste Accepted password- of Accepted publickey-regel die u niet kunt verklaren in /var/log/auth.log of in het logboek. Controleer dit aan de hand van een lijst met wijzigingstijden, find / -xdev -newerct 'YYYY-MM-DD' -type f, aangezien ctime moeilijker te vervalsen is dan mtime. Vergelijk beide vervolgens met de tijdstempels in het abuse-ticket van uw provider; deze zijn buiten de machine om geregistreerd en konden niet worden bewerkt. Kies een back-up die ouder is dan de vroegste van die drie data. Als er niets overeenkomt, ga er dan vanuit dat de inbreuk ouder is dan uw back-uphistorie en herstel alleen gegevens die u kunt inspecteren.

Zijn mijn back-ups veilig om te herstellen na een inbreuk?

De gegevens zijn dat meestal wel, mits ze worden geïnspecteerd. De systeembestanden zijn dat niet. Een back-up die na de inbreuk is gemaakt, bevat de achterdeur; het herstellen van een volledig root-bestandssysteem herstelt dus ook de aanvaller. Controleer ook de back-uprepository zelf: als de inloggegevens hiervoor op de gecompromitteerde server stonden, kan de geschiedenis zijn verwijderd of gewijzigd. Dit is het argument voor back-updoelen die alleen toevoegingen toestaan (append-only) of die werken via een pull-mechanisme. Herstel applicatiegegevens en installeer de software vervolgens opnieuw vanuit de distributierepository's.

Moet ik iemand vertellen dat mijn VPS is gecompromitteerd?

Reageer altijd op de abuse-melding van uw host. Verder hangt het ervan af wiens gegevens op de machine stonden. Persoonsgegevens van anderen kunnen een wettelijke meldplicht activeren, zoals de 72-uurs notificatie aan een toezichthouder onder de AVG. Als er inloggegevens van gebruikers op de server stonden, informeer deze gebruikers dan zodat zij hun wachtwoorden elders kunnen wijzigen. Als sleutels op de machine toegang gaven tot systemen van derden, zoals een code-host of een cloudaccount, informeer dan die providers zodat zij kunnen controleren op misbruik. Een puur persoonlijke server zonder gegevens van anderen brengt geen verplichtingen met zich mee buiten het afhandelen van het abuse-ticket.