Ajankohtainen tilanne: PHP2Shell. Kaksi kriittistä PHP-haavoittuvuutta (CVSS 9.2) sallii haittakoodin suorittamisen ilman kirjautumista. Korjaukset 21.10.2026 alkaen.Mitä nyt on tehtävä →

Varoitusmerkki: verkkopalvelin käynnistää shellin

Jos PHP-FPM- tai verkkopalvelinprosessi käynnistää shellin, se on yksi vahvimmista murron varoitusmerkeistä. Näin tarkistatte prosessipuun, arvioitte poikkeukset ja seuraatte kaavaa pysyvästi.

Tilanne Lukuaika 5 minHavaitseminen ja forensiikka

Lyhyesti: Jos PHP-FPM, Apache tai jokin muu verkkopalvelinprosessi käynnistää shellin kuten sh tai bash, se on yksi vahvimmista varoitusmerkeistä verkkosivuston kautta tehdystä murrosta. Tarkistakaa prosessipuu, shellin komentorivi ja työhakemisto, ennen kuin lopetatte mitään. Yksittäiset lyhyet shellit voivat olla oikeutettuja; pitkään toimivat shellit verkkotyökaluineen ovat sitä lähes ei koskaan.

Miksi tämä kaava kertoo niin paljon

Verkkopalvelin vastaa pyyntöihin. PHP-FPM, eli prosessinhallinta, joka ajaa PHP-skriptejä verkkopalvelimelle, ei normaalisti käynnistä sitä varten muita ohjelmia. Verkkopalvelimen alla oleva shell tarkoittaa, että PHP-koodi on tietoisesti kutsunut ohjelmaa. Joko sovellus tekee sen tarkoituksella, tai joku muu on lisännyt koodia.

PHP2Shellille ei ole julkaistuja, vahvistettuja Indicators of Compromise -tunnisteita, eli kiinteiden tunnistusmerkkien luetteloa. Havaitseminen perustuu käyttäytymiseen. Käytössämme olevien raporttien mukaan verkkopalvelin- tai PHP-FPM-prosessit, jotka käynnistävät shellin, kuuluvat vahvimpiin yleisiin varoitusmerkkeihin. Se pätee jokaiseen aukkoon, jonka kautta hyökkääjät voivat ajaa koodia palvelimella. Yleiskatsauksen muista merkeistä antaa Olenko jo vaarantunut?.

Miksi shell on hyökkääjälle niin tärkeä? Aukon kautta hän voi aluksi antaa vain yksittäisiä komentoja PHP-prosessin kautta. Shell tekee siitä mukavan työpisteen: hän voi katsella ympärilleen, ladata työkaluja, lukea tunnuksia asetustiedostoista ja asettua pysyvästi. Kun shellin tunnistaa, hyökkääjän tunnistaa siis usein juuri sillä hetkellä, kun hän siirtyy ensimmäisestä pääsystä varsinaiseen aikeeseensa.

PHP-FPM käynnistää bashin: prosessipuun lukeminen

Jokaisella Linux-prosessilla on vanhempiprosessi. Kysymys on, toimiiko shell verkkopalvelinprosessin lapsena. Seuraavat komennot vain lukevat:

# Prosessipuu käyttäjän, vanhemman PID:n ja käynnistysajan kanssa
ps -eo user,pid,ppid,lstart,cmd --forest | grep -B2 -A4 -E "[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp"

# Shellit, jotka toimivat tyypillisten verkkopalvelinkäyttäjien alla
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) " | grep -E "[ /](ba|da)?sh( |$)"

# Puu vanhimmasta PHP-FPM-prosessista alkaen
pstree -alp "$(pgrep -o php-fpm)"

Jos olette löytäneet epäilyttävän shellin, /proc-hakemiston merkinnät antavat lisävihjeitä, nekin vain lukien:

PID=12345   # epäilyttävän shellin PID
tr '\0' ' ' < /proc/$PID/cmdline; echo        # täydellinen komentorivi
ls -l /proc/$PID/cwd /proc/$PID/exe            # työhakemisto ja ohjelmatiedosto
ls -l /proc/$PID/fd 2>/dev/null | grep socket  # avoimet verkkoyhteydet

Debianilla ja Ubuntulla prosessien nimet ovat usein php8.3-fpm tai vastaavia; mukauttakaa hakukaavat. Työhakemistot polussa /tmp, /dev/shm tai upload-kansioissa ovat selvä merkki.

Oikeutetut poikkeukset ja todelliset varoitusmerkit

Jotkin sovellukset kutsuvat ohjelmia PHP:n kautta. Silloin voi hetkeksi syntyä shell, esimerkiksi kun PHP välittää viestejä sendmail_path-asetuksen kautta tai sovellus käsittelee kuvia ulkoisella työkalulla. Tällaiset shellit elävät vain sekunteja ja kutsuvat aina samaa ohjelmaa. Dokumentoikaa nämä odotetut tapaukset kerran huolella; silloin jokainen poikkeama huomataan heti sen sijaan, että se hukkuisi tuttujen ilmoitusten tulvaan.

Havainto Todennäköisesti harmiton, jos Epäilyttävä, jos
Lyhyt shell PHP-FPM:n alla se käynnistää sovelluksen tunnetun ohjelman kohde ja tarkoitus ovat epäselviä
Pidempään toimiva shell ei koskaan se toimii minuutteja tai tunteja
Verkkotyökalut lapsiprosessina sovelluksen tunnettu päivitys- tai API-kysely seuraa latauksia väliaikaisiin hakemistoihin
Työhakemisto sovelluksen projektikansio /tmp, /dev/shm, upload-kansiot
Ajankohta sopii tunnettuun toimintoon, esim. sähköpostin lähetykseen yöllä, ilman käyttäjäaktiivisuutta, toistuvasti

Jos ette tiedä, kutsuuko sovelluksenne ohjelmia, kysykää kehittäjältä tai etsikää koodista funktioita kuten exec, shell_exec, system, passthru, proc_open ja popen. Osumat omassa koodissa ovat normaaleja, osumat tuntemattomissa tiedostoissa eivät.

Seuratkaa pysyvästi sen sijaan, että katsotte kerran

Hetkellinen ps-kuva tavoittaa vain parhaillaan toimivat shellit. Lyhytikäiset prosessit livahtavat läpi. Luotettavampaa on kirjata verkkopalvelinkäyttäjän ohjelmakäynnistykset pysyvästi. Linuxissa sen hoitaa auditd-palvelu säännöllä, joka koskee verkkopalvelinkäyttäjän ohjelmakäynnistyksiä. Arviointi tehdään lukien:

# Näytä kirjatut ohjelmakäynnistykset säännön avaimen alla (avain esimerkkinä)
sudo ausearch -k web_exec --start today -i | grep -E "exe=|proctitle="

Miltä sääntö näyttää, riippuu jakelusta ja käyttäjätunnuksesta; testatkaa se ensin, sillä voimakkaasti kuormitetuilla palvelimilla syntyy paljon merkintöjä.

Kaksi lisäystä tekee seurannasta kestävän. Ensinnäkin lokit pitäisi lähettää lisäksi keskitettyyn järjestelmään, sillä root-oikeudet saanut hyökkääjä voi poistaa paikalliset lokit. Toiseksi tarvitaan hälytys: verkkopalvelinkäyttäjän ohjelmakäynnistyksen, jota ei ole lyhyellä odotettujen ohjelmien listalla, pitäisi laukaista ilmoitus eikä pelkkä lokimerkintä. Jos käytätte jo päätelaitteiden tai palvelimien havaitsemisratkaisua, saman säännön voi toteuttaa siinä. Ennaltaehkäisevästi disable_functions estää sen, mitä sovellus ei tarvitse. Se ei sulje aukkoa tulkissa, mutta vaikeuttaa hyökkääjän seuraavaa askelta. Yksityiskohdat sivulla disable_functions oikein käytettynä.

Mitä tehdä, kun löydätte shellin verkkopalvelimen alta

  1. Dokumentoikaa: Tallentakaa ps-tuloste, komentorivi, työhakemisto ja avoimet yhteydet tiedostoon verkkohakemiston ulkopuolelle.
  2. Älkää siivotko: Älkää poistako tiedostoja tai lopettako prosesseja ennen kuin jäljet on varmistettu.
  3. Eristäkää: Irrottakaa palvelin verkosta tai rajatkaa pääsyä voimakkaasti.
  4. Etsikää syy: Tarkistakaa lokit, uudet tiedostot ja pysyvyys kuten cron-työt, ks. Epäilyttävien prosessien löytäminen Linux-palvelimilta.
  5. Vaihtakaa tunnukset: Kaikki salasanat ja avaimet, jotka olivat palvelimella, katsotaan tunnetuiksi.

Jos sovellus toimii konteissa, sama periaate pätee pienessä mittakaavassa. Shell PHP-kontissa on yhtä epäilyttävä kuin perinteisellä palvelimella, ja konttikuvissa se on usein vain siksi, että peruskuva tuo sen mukanaan. Varmistakaa kontin tila ennen sen uudelleenkäynnistystä, sillä kontin mukana katoavat myös jäljet katoavasta tiedostojärjestelmästä.

Tarkistakaa myös naapurusto. Verkkopalvelimella shellin saanut hyökkääjä yrittää usein päästä sieltä muihin järjestelmiin, esimerkiksi tietokantaan, varmuuskopiotallennukseen tai sisäisiin hallintakäyttöliittymiin. Sovelluksen asetustiedostojen tunnukset tekevät sen hänelle helpoksi.

Toimi heti

Pitkään toimiva shell PHP-FPM:n alla palvelimella, jossa on asiakastietoja, on tietoturvapoikkeama. Käsitelkää se sellaisena: varmistakaa, eristäkää, selvittäkää jäsennellysti, tarkistuttakaa ilmoitusvelvollisuudet.

Miten PHP SOS auttaa konkreettisesti?

  • Löydöksen arviointi: Tarkistamme prosessipuun, komentorivit ja yhteydet ja erotamme sovelluksen käyttäytymisen murtojäljistä.
  • Jälkien varmistus: Varmistamme järjestelmän tilan jäljitettävästi, ennen kuin mitään muutetaan.
  • Tapauksen käsittely: Incident Response -palvelulla vastaamme eristämisestä dokumentoituun päätökseen asti.
  • Pysyvä suojaus: Otamme käyttöön ohjelmakäynnistysten kirjaamisen ja rajaamme PHP-funktiot tarpeelliseen. Miten PHP-FPM toimii sisäisesti, selittää PHP-FPM selitettynä.

Usein kysytyt kysymykset

Onko jokainen PHP-FPM:n alla oleva shell hyökkäys?

Ei jokainen. Jotkin sovellukset kutsuvat PHP:n kautta tarkoituksella ohjelmia, esimerkiksi kuvankäsittelyyn tai sähköpostin lähetykseen, ja siinä voi hetkeksi syntyä shell. Epäilyttäväksi tilanne muuttuu, kun shell toimii pidempään, käynnistää verkkotyökaluja tai työskentelee epätyypillisistä hakemistoista.

Pitäisikö epäilyttävä prosessi lopettaa heti?

Ensin dokumentoikaa, sitten toimikaa. Kirjatkaa prosessitiedot, komentorivi, työhakemisto ja verkkoyhteydet. Sen jälkeen eristätte palvelimen. Hätäinen lopetus tuhoaa jälkiä eikä estä hyökkääjää palaamasta.

Onko PHP2Shellille vahvistettuja tunnistusmerkkejä?

Ei. Julkaistuja, vahvistettuja Indicators of Compromise -tunnisteita ei ole. Verkkopalvelimen alla toimivat shellit ovat yleinen varoitusmerkki verkkosovellusten kautta tehdyistä murroista, eivät erityisesti PHP2Shellille ominaisia.

Miten estän, ettei PHP käynnistä shellejä lainkaan?

disable_functions-asetuksella voi estää funktiot kuten exec, shell_exec, system ja proc_open, jos sovellus ei tarvitse niitä. Se ei sulje aukkoa PHP-tulkissa, mutta vaikeuttaa hyväksikäyttöä.

Lähteet

Pikayhteys

Jokainen tunti on tärkeä. Kirjoittakaa meille nyt.

Kuvatkaa lyhyesti järjestelmä, PHP-versio ja havainnot. Otamme yhteyttä, selvitämme tilanteen ja työskentelemme etänä, kunnes tapaus on käsitelty loppuun ja dokumentoitu.

Pikaapu