De vraag komt zelden uit het niets. De server werd trager, de hoster schreef over uitgaand verkeer, of in de mail staat een aanmeldmelding die niet van u was. Daarna begint het onaangename deel: het is onduidelijk waar u moet kijken en in welke volgorde, en de eerste ingeving — alles wissen en opnieuw installeren — is bijna altijd voorbarig.

Hieronder een controlevolgorde die een minuut of twintig kost en in de meeste gevallen een duidelijk antwoord geeft. Ze gaat van het goedkoopste naar het duurste: eerst wat meteen zichtbaar is, daarna wat vergelijking vereist.

Stap één: wie er inlogde

Begin bij de aanmeldingen. Als een vreemde binnenkwam, kwam hij vrijwel zeker via SSH, en er is een spoor.

last -20
lastb | head -20
who

last toont de laatste geslaagde aanmeldingen, lastb de mislukte, who wie er op dit moment verbonden is. Wat telt is niet het aantal maar de vorm. Duizenden mislukte pogingen vanaf adressen die nooit terugkeren zijn het gewone achtergrondgeluid: dat gebeurt bij elk publiek adres onafgebroken en betekent niets.

Verontrustend is iets anders:

  • een geslaagde aanmelding vanaf een adres waar niemand van u zit;
  • een aanmelding onder een gebruikersnaam die u nooit hebt aangemaakt;
  • mislukte pogingen onder een naam die op deze machine werkelijk bestaat — dan kent iemand uw gebruikerslijst en werkt hij geen woordenboek af;
  • een sessie die nu open staat en die u niet hebt geopend.

Controleer ook of er vreemde sleutels zijn bijgekomen. Het bestand ~/.ssh/authorized_keys is de gebruikelijkste manier om zich te nestelen: het wachtwoord kan zo vaak worden gewijzigd als u wilt, de sleutel blijft.

cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys

Elke regel daar is iemands toegang. Als u niet kunt zeggen van wie, beschouw hem dan als vreemd.

Stap twee: wat er in het systeem veranderde

Een inbraak laat bijna altijd sporen op de schijf achter: een vervangen programmabestand, een toegevoegde regel in een configuratie, een nieuw bestand in de map van de webserver. Dat met het blote oog nagaan is zinloos — er is een referentie nodig.

Op Debian en Ubuntu bestaat die referentie al: elk pakket kent de controlesommen van zijn eigen bestanden.

sudo apt install debsums
sudo debsums -c

Het commando somt de bestanden op die afwijken van wat de distributie heeft geïnstalleerd. Een deel van de vondsten is legitiem — configuratiebestanden onder /etc bestaan juist om te worden aangepast. Een gewijzigd programmabestand in /usr/bin, /usr/sbin of /bin op een server waar u nooit met de hand aan hebt gezeten, is echter een ander verhaal.

De tweede bron zijn recente bestanden waar er geen horen te zijn. Een webshell ligt meestal in de uploadmap en ziet eruit als een onschuldig .php:

find /var/www -type f -name '*.php' -mtime -14 -ls

Veertien dagen zijn slechts een startpunt; vul de periode in waarin u zeker niets hebt gepubliceerd.

Stap drie: wat er naar buiten gaat

Een gehackte server wordt zelden om zichzelf overgenomen. Hij wordt gebruikt: om spam te versturen, om te minen, om andere netwerken te bereiken, om andermans bestanden te hosten. Dat alles maakt uitgaande verbindingen die er eerder niet waren.

ss -tulpn
ss -tp state established

Het eerste commando toont wat er luistert, het tweede wat er nu tot stand is gebracht. Lees de kolom met het proces. Vragen roepen op: een onbekend proces dat op 0.0.0.0 luistert; uitgaande verbindingen naar hoge poorten bij adressen waar uw toepassing niets mee te maken heeft; en vooral een proces dat is gestart vanuit /tmp of /dev/shm — uit die mappen draait niets legitiems.

Kijk meteen ook naar de belasting. Een miner verraadt zich doordat de processor voortdurend bezet is terwijl de site geen enkele populariteit geniet.

Als de signalen er zijn

De eerste ingeving is snel opruimen: de vreemde sleutel wissen, het proces afbreken, het bestand verwijderen. Doe dat niet — u vernietigt juist datgene waaruit later valt op te maken hoe hij binnenkwam. En blijft dat onbegrepen, dan komt hij terug, misschien morgen al.

Een volgorde die zowel de gegevens als het beeld bewaart:

  1. Bij de hoster een schijfmomentopname maken, als dat mogelijk is. Dat is de enige stap die later niet kan worden herhaald.
  2. De machine van het netwerk afsluiten of alles dichtzetten behalve uw eigen IP — maar niet uitschakelen. Bij uitschakelen verliest u de proceslijst en de open verbindingen, en dat is de helft van het bewijs.
  3. De logboeken naar buiten wegschrijven: /var/log/auth.log, die van de webserver, de uitvoer van de drie commando's hierboven.
  4. Pas nu uitzoeken hoe de toegang is verkregen.

Een volledige herinstallatie is het juiste einde als de toegang met rootrechten is verkregen. Geen enkele opschoning garandeert dat er niets is achtergebleven. Maar herinstalleren zonder de oorzaak te hebben begrepen is zinloos: u zet hetzelfde gat terug op een vers systeem.

Zodat de vraag niet plotseling opduikt

Al het bovenstaande is een eenmalige handmatige controle, en die beantwoordt de vraag «wat gebeurt er nu». Het probleem is dat men hem meestal laat stelt: wanneer de hoster al heeft geschreven of de site is uitgevallen.

Elk van deze controles bestaat als zelfstandig hulpmiddel dat voortdurend kan meekijken: mislukte aanmeldingen — fail2ban, bestandswijzigingen — AIDE, pakketintegriteit — debsums, open poorten — een regelmatige momentopname van ss. Ze afzonderlijk installeren is niet moeilijk; moeilijk is het om er een gewoonte van te maken elke dag zes verschillende uitvoeren te lezen, waardoor ze in de praktijk niet gelezen worden.

Precies dat is de zin van een samengebracht paneel: dezelfde gegevens, maar op één pagina en met historie, zodat «gisteren was dit anders» zichtbaar wordt zonder dat u er speciaal naar op zoek moet. Hieronder de demopagina's die laten zien hoe dat er samengesteld uitziet.