Lyhyesti: Kryptolouhija palvelimella näkyy yleensä jatkuvasti suurena suorittimen kuormana ilman havaittavaa syytä, vieraina prosesseina, usein verkkopalvelinkäyttäjän alla, ja lähtevinä yhteyksinä tuntemattomiin kohteisiin. Älkää lopettako prosessia hätiköiden: varmistakaa ensin jäljet, etsikää mekanismit, jotka käynnistävät sen uudelleen, ja sulkekaa sisääntuloportti. Louhija tarkoittaa, että joku on voinut suorittaa koodia palvelimellanne.
Kun pilvitoimittajan lasku on ensimmäinen varoitus
Kryptolouhija huomataan usein ei tietoturvahälytyksestä vaan ohimennen. Verkkosivusto muuttuu hitaaksi, hosting-yritys ilmoittaa laskenta-ajan ylityksestä, oman konesalin tuuletin pyörii jatkuvasti tai pilvitoimittajan lasku nousee ilman uusia hankkeita. Hyökkääjälle louhija on helppo tapa saada vaarantuneesta palvelimesta rahaa.
Louhinta tarkoittaa vieraan järjestelmän laskentatehon käyttämistä kryptovaluutan tuottamiseen. Vahinko vaikuttaa vähäiseltä, koska dataa ei salata. Se on harhaa: joka voi käynnistää louhijan, voi myös lukea tunnuksia, kopioida tietokantoja ja luoda uusia takaovia.
PHP2Shellin jälkeen tarkistus kannattaa erityisesti. Aukot CVE-2026-109618 ja CVE-2026-109619 sallivat haittakoodin suorittamisen ilman kirjautumista. Vahvistettuja Indicators of Compromise -tunnisteita ei ole, eikä louhija ole erityinen merkki näistä aukoista. Suuri kuorma tuntemattomista prosesseista kuuluu kuitenkin yleisiin merkkeihin, jotka on kuvattu sivulla Olenko jo vaarantunut?.
Kryptolouhijan merkkien oikea tulkinta
Suurella kuormalla on monia harmittomia syitä. Taulukko auttaa ensiarvioinnissa:
| Havainto | Harmiton selitys mahdollinen | Mitä tarkistatte |
|---|---|---|
| Suoritin pysyvästi lähellä täyttä käyttöä | varmuuskopio, kuvankäsittely, indeksin rakentaminen | Onko kuorma tasainen myös yöllä ja viikonloppuna? |
| Prosessi, jolla on järjestelmäpalvelun nimi | harvoin | Onko ohjelmatiedosto odotetussa järjestelmäpolussa? |
Prosessi käyttäjällä www-data, apache tai nginx, joka ei ole PHP |
tuskin | Kuka sen on käynnistänyt, mistä kansiosta? |
Ohjelma polussa /tmp, /var/tmp tai /dev/shm |
tuskin | Mistä lähtien tiedosto on olemassa, kenelle se kuuluu? |
| Pysyvä lähtevä yhteys tuntemattomaan kohteeseen | seuranta, päivitykset | Kuuluuko kohde tunnettuun palveluun? |
| Kuorma laskee, kun kirjaudutte sisään | harvoin | Jotkin haittaohjelmat pysähtyvät, kun valvontatyökalut ovat käynnissä |
Mitä useampi rivi pitää paikkansa, sitä todennäköisempi löytö on. Se, että verkkopalvelinkäyttäjä käynnistää ylipäätään vieraita ohjelmia, on jo sinänsä vahva varoitusmerkki, kuten artikkeli Verkkopalvelin käynnistää shellin osoittaa.
Näin tarkistatte prosessit ja yhteydet
Seuraavat komennot vain lukevat. Kirjatkaa tulos ja kellonaika ennen kuin muutatte mitään:
# Prosessit suorittimen käytön mukaan, käyttäjän, käynnistysajan ja täyden komennon kanssa
ps -eo pid,ppid,user,lstart,%cpu,%mem,args --sort=-%cpu | head -20
# Epäilyttävän prosessin ohjelmatiedosto ja työhakemisto (syötä PID)
sudo ls -l /proc/PID/exe /proc/PID/cwd
# Lähtevät yhteydet prosessin kanssa
sudo ss -tnp state established
# Suoritettavat tiedostot väliaikaisissa kansioissa
sudo find /tmp /var/tmp /dev/shm -type f -perm -u+x -ls 2>/dev/null
Jos /proc/PID/exe osoittaa tiedostoon, jonka perässä on (deleted), ohjelma on poistettu käynnistyksen jälkeen. Se on tyypillinen naamioyritys. Prosessi toimii edelleen, ja niin kauan kuin se toimii, ohjelmatiedoston voi vielä varmistaa /proc-hakemiston kautta. Sen pitäisi tehdä joku, joka osaa käsitellä haittaohjelmia; älkää koskaan suorittako tiedostoa.
Miten prosessit käydään louhijaa laajemmin järjestelmällisesti läpi, kuvaa Epäilyttävien prosessien löytäminen Linux-palvelimilta.
Miksi louhija palaa aina
Monet ylläpitäjät lopettavat prosessin, ilahtuvat kuorman laskusta ja huomaavat seuraavana päivänä, että kaikki alkaa alusta. Louhijat asennetaan lähes aina uudelleenkäynnistysmekanismin kanssa. Tyypillisiä paikkoja ovat:
- Cron-työt, verkkopalvelinkäyttäjän tai järjestelmänlaajuiset, jotka tarkistavat muutaman minuutin välein, onko louhija käynnissä, ja lataavat sen muuten uudelleen.
- Järjestelmäpalvelut huomaamattomilla nimillä, jotka käynnistyvät käynnistyksessä.
- Web shell verkkohakemistossa, jonka kautta hyökkääjä käynnistää louhijan uudelleen milloin tahansa.
- Muutetut käynnistysskriptit tai käyttäjien profiilitiedostot.
- Vieraat SSH-avaimet, joilla hyökkääjä kirjautuu suoraan takaisin.
# Verkkopalvelinkäyttäjän cron-työt ja järjestelmänlaajuiset merkinnät
sudo crontab -u www-data -l
ls -la /etc/cron.d /etc/cron.hourly /var/spool/cron 2>/dev/null
# Viimeksi muutetut systemd-yksiköt
sudo find /etc/systemd/system /lib/systemd/system -name '*.service' -newermt "2026-10-17" -ls
Vasta kun kaikki mekanismit on löydetty, palvelin pysyy pysyvästi rauhallisena. Jos hyökkääjällä oli root-oikeudet, uudelleenrakennus puhtaalle järjestelmälle on yleensä luotettavampaa kuin jokaisen piilopaikan etsintä.
Oikea järjestys löydön jälkeen
Louhija vaikuttaa teknisesti harmilta, mutta on tietoturvapoikkeama. Toimikaa siksi järjestyksessä:
- Varmistakaa: Kopioikaa prosessiluettelo, yhteydet, epäilyttävät tiedostot ja lokit tarkistussumman kanssa, ennen kuin mitään lopetetaan.
- Rajatkaa: Eristäkää palvelin tai estäkää lähtevät yhteydet, jos se on mahdollista menettämättä dataa.
- Sulkekaa syy: Viekää PHP korjatulle tasolle (8.5.12, 8.4.27, 8.3.36, 8.2.35 tai vahvistettu backport), käynnistäkää kaikki workerit uudelleen, päivittäkää CMS ja laajennukset.
- Siivotkaa tai rakentakaa uudelleen: Poistakaa louhija, uudelleenkäynnistysmekanismit ja takaovet, epäselvässä tapauksessa asentakaa uudelleen.
- Tarkistakaa seuraukset: Voitiinko tunnuksia tai henkilötietoja lukea? Selvittäkää silloin tietosuoja ja mahdolliset ilmoitusvelvollisuudet.
Ottakaa hosting-yritys tai pilvitoimittaja mukaan ajoissa. Monet toimittajat estävät palvelimet, joilla on poikkeava kuorma tai verkkoliikenne, ennalta varautuen. Joka itse tiedottaa toimittajaa ja sopii toimintatavasta, säilyttää todennäköisemmin kontrollin katkaisun ajankohtaan. Kysykää samalla toimittajan verkko- ja käyttölokeja, sillä ne ovat palvelimenne ulkopuolella ja hyökkääjän vaikea muuttaa.
Johdolle tärkeää on lyhyt, rehellinen arvio: louhija itse maksaa lähinnä laskenta-aikaa ja suorituskykyä. Varsinainen kysymys on kuitenkin, mitä hyökkääjä on lisäksi nähnyt. Kunnes se on selvitetty, tapausta ei pidä pitää päättyneenä, vaikka kuorma olisi taas normaali.
Kryptolouhija osoittaa, että palvelimellanne on suoritettu koodia. Käsitelkää kaikkia palvelimella olleita tunnuksia mahdollisesti vuotaneina ja uusikaa ne siivouksen jälkeen.
Miten PHP SOS auttaa konkreettisesti?
- Arvioimme kuorman ja erotamme harmittomat syyt vieraista prosesseista.
- Varmistamme prosessit, tiedostot ja yhteydet, ennen kuin louhija lopetetaan.
- Etsimme kaikki uudelleenkäynnistysmekanismit ja takaovet ja siivoamme palvelimen haittaohjelmien poiston puitteissa tai rakennamme sen uudelleen.
- Suljemme sisääntuloportin, uusimme pääsyt ja otamme käyttöön kuormanseurannan, joka ilmoittaa epätavallisista kaavoista ajoissa.
Usein kysytyt kysymykset
Mistä tunnistan kryptolouhijan palvelimellani?
Tyypillistä on jatkuvasti suuri suorittimen kuormitus, joka ei sovi kävijämääriin tai ajastettuihin tehtäviin. Lisäksi tulevat prosessit tuntemattomilla tai viattomalta kuulostavilla nimillä, usein verkkopalvelinkäyttäjän alla, ja lähtevät yhteydet vieraisiin osoitteisiin. Yksittäinen piirre ei vielä ole todiste.
Riittääkö louhintaprosessin lopettaminen?
Ei. Louhijat käynnistetään yleensä uudelleen cron-töillä, järjestelmäpalveluilla tai web shellillä. Joka vain lopettaa prosessin, näkee sen usein pian uudelleen. Lisäksi sisääntuloportti, jonka kautta louhija pääsi palvelimelle, pysyy auki.
Onko kryptolouhija vaaraton, koska se vain varastaa laskentatehoa?
Ei. Joka pystyi asentamaan louhijan, pystyi suorittamaan koodia palvelimella. Silloin olivat yleensä tavoitettavissa myös asetustiedostot, tunnukset ja tietokannat. Louhija on murron näkyvä oire.
Mitkä harmittomat syyt voivat aiheuttaa suuren palvelinkuorman?
Varmuuskopiot, kuvankäsittely, hakuindeksin rakentaminen, aggressiiviset indeksointirobotit tai virheellinen laajennus voivat myös kuluttaa paljon laskenta-aikaa. Nämä syyt voi yleensä yhdistää tunnettuun prosessiin ja aikatauluun. Jos kuorma jää selittämättömäksi, kannattaa tarkistaa tarkemmin.