# Blogi: PHP2Shell, palvelimen tietoturva ja hätäapu

> Blogi PHP2Shellistä ja palvelimen tietoturvasta: tilanne, hosting, havaitseminen, koventaminen, turvallinen kehitys, johtaminen ja päätöksenteon tuki.

Lähde: https://phpsos.de/fi/blog/  
Tilanne: 25.10.2026  
Palveluntarjoaja: PHP SOS, PHP-hätäapu ja palvelimen tietoturva. Pikaapu WhatsAppilla: https://wa.me/491736494914?text=Hei%20PHP%20SOS%2C%20tarvitsemme%20apua%20PHP-palvelimemme%20kanssa.%20Yritys%3A%20%E2%80%A6%20Verkkosivusto%3A%20%E2%80%A6

Tilannearviot, ohjeet ylläpitäjille ja päätöksenteon tuki johdolle. Järjestetty aiheittain, jokaisessa artikkelissa on lähteet.

- [PHP2Shell: mikä on todennettu ja mikä ei](https://phpsos.de/fi/blog/php2shell-was-belegt-ist/): PHP2Shellin faktantarkistus: mitkä väitteet tulevat ensisijaisista lähteistä, mitkä mediaraporteista ja mitkä väitteet eivät kestä tarkastelua.
- [Miksi PHP-aukko tuli tietoon ennen korjausta](https://phpsos.de/fi/blog/php-luecke-vorzeitig-bekannt/): Raporttien mukaan PHP2Shellin yksityiskohdat tulivat julkisiksi ennen embargon päättymistä. Selitämme tapahtumien kulun ja mitä se tarkoittaa päivityssuunnittelullenne.
- [Viranomaiset ottavat verkkosivuja pois verkosta: mitä yritykset voivat oppia](https://phpsos.de/fi/blog/behoerden-webseiten-offline/): Mainz, Hessenin osavaltion hallitus ja BKA ottivat verkkosivuja varotoimena pois verkosta. Mitä yritykset voivat oppia omaa päätöstään varten.
- [BSI:n oranssi varoitustaso: mitä luokitus tarkoittaa](https://phpsos.de/fi/blog/bsi-warnstufe-orange-erklaert/): BSI luokittelee PHP2Shellin tasolle 3 / oranssi. Mitä asteikko kertoo ja mitä ei, ja miten yritykset muuttavat luokituksen päätöksiksi.
- [Mitä CERT-EU ja CERT-Bund suosittelevat PHP2Shellistä](https://phpsos.de/fi/blog/cert-eu-empfehlungen-php/): Viralliset tahot ovat yhtä mieltä: päivittäkää heti, muuten eristäkää. Vertaamme suosituksia ja näytämme, miltä eristäminen käytännössä näyttää.
- [Cloudflaren suojasäännöt PHP2Shelliä vastaan: mitä ne tekevät ja mitä eivät](https://phpsos.de/fi/blog/cloudflare-waf-php2shell/): Cloudflare otti käyttöön suojasäännöt PHP2Shelliä vastaan jo varhain. Miksi se auttaa, miksi se ei silti korvaa PHP-päivitystä ja mitä asetuksia kannattaa tarkistaa.
- [22,6 miljoonaa altistunutta instanssia: lukujen oikea tulkinta](https://phpsos.de/fi/blog/exponierte-instanzen-einordnen/): Unit 42, CybelAngel ja muut mainitsevat PHP2Shellistä hyvin erilaisia lukuja. Selitämme, mitä on laskettu ja mikä luku merkitsee teille todella.
- [PHP2Shell viidessä minuutissa: tiivistelmä johdolle](https://phpsos.de/fi/blog/php2shell-briefing-geschaeftsfuehrung/): PHP-tietoturva-aukko PHP2Shell yhdellä sivulla päättäjille: tilanne, riski, viisi kysymystä IT:lle ja tämän päivän päätökset.
- [PHP-tietoturva-aukko selkeästi selitettynä](https://phpsos.de/fi/blog/php-luecke-einfach-erklaert/): PHP2Shell ei-teknisille: arkisin vertauksin, pienen sanaston ja kolmen tyypillisen lähtötilanteen avulla, mitä verkkosivuston ylläpitäjän kannattaa tehdä.
- [PHP2Shell: 15 kysymystä hosting-asiakkailta](https://phpsos.de/fi/blog/fragen-von-hosting-kunden/): Verkkosivustonne on hosting-yrityksellä ja haluatte tietää, mitä teidän on itse tehtävä PHP2Shellin vuoksi? Tässä 15 yleisintä kysymystä lyhyin vastauksin.
- [Miksi WordPress-päivitys ei auta PHP2Shelliä vastaan](https://phpsos.de/fi/blog/warum-wordpress-update-nicht-hilft/): Moni ylläpitäjä päivitti WordPressin otsikoiden jälkeen ja tuntee olonsa turvalliseksi. Miksi se ei PHP2Shellin kohdalla riitä ja mikä ratkaisee.
- [PHP2Shell ja Log4Shell: mitä aukoilla on yhteistä](https://phpsos.de/fi/blog/php2shell-und-log4shell/): Moni vertaa PHP2Shelliä vuoden 2021 Log4Shelliin. Mitä vertailu kestää, missä se ontuu ja mitkä silloiset opit auttavat nyt.
- [Massaskannaukset päivittämättömän PHP:n perässä: näin automaattiset hyökkäykset etenevät](https://phpsos.de/fi/blog/automatisierte-massenscans/): PHP2Shellin jälkeen hyökkääjät etsivät internetistä automaattisesti haavoittuvia palvelimia. Miten se etenee, miksi koolla ei ole merkitystä ja mikä suojaa.
- [Päivityksen ja hyökkäyksen välinen aikaikkuna](https://phpsos.de/fi/blog/zeitfenster-patch-angriff/): PHP2Shellin kohdalla hyökkäysyrityksiä oli jo ennen korjausta. Selitämme aikaikkunan vaiheet, miten mittaatte omanne ja miten lyhennätte sitä.
- [PHP2Shellin jälkeen: miksi lisäilmoitukset ovat todennäköisiä](https://phpsos.de/fi/blog/weitere-php-meldungen/): PHP2Shell ei ole ohi 21. lokakuuta tulleella päivityksellä. Miksi jatkoilmoituksia on odotettavissa ja miten valmistatte tiiminne niihin.
- [PHP2Shell: ensimmäisen viikon tilannekuva](https://phpsos.de/fi/blog/lagebild-erste-woche/): Viikko ensimmäisen havaitun hyökkäysyrityksen jälkeen: päivitysten, viranomaisvaroitusten, hyökkäysten ja sulkemisten tilanne lähteittäin eroteltuna.
- [Vaaralliset vääränlaiset vinkit PHP2Shellistä, jotka kiertävät juuri nyt](https://phpsos.de/fi/blog/gefaehrliche-falschtipps/): Evästeiden estäminen, virheilmoitusten piilottaminen, vain CMS:n päivitys: yhdeksän PHP2Shell-neuvoa, jotka luovat väärää turvallisuutta, ja mikä todella merkitsee.
- [PHP-version vaihtaminen hosting-asiakasalueella](https://phpsos.de/fi/blog/php-version-hosting-aendern/): Miten vaihdatte PHP-version hosting-yrityksenne asiakasalueella, minkä version valitsette ja mitä tarkistatte ennen ja jälkeen.
- [Debian ja Ubuntu: onko PHP-pakettini päivitetty?](https://phpsos.de/fi/blog/debian-ubuntu-paket-gepatcht/): Mitkä PHP-paketit Debian ja Ubuntu ovat korjanneet PHP2Shelliä vastaan, miten vertaatte asennetun tilan tarkasti ja mihin todistaminen kaatuu.
- [RHEL, AlmaLinux ja Rocky Linux: PHP-päivityksen tarkistaminen](https://phpsos.de/fi/blog/rhel-almalinux-rocky-php/): Mitä Red Hat on julkaissut PHP2Shellistä, miten todistatte pakettitilan RHELillä ja sen jäljennöksillä ja miksi uudelleenlataus ei riitä.
- [sury.org-repositorio: PHP-paketit kolmannelta osapuolelta](https://phpsos.de/fi/blog/sury-repository-php/): Monet Debian- ja Ubuntu-palvelimet hankkivat PHP:n sury-repositoriosta. Mitä se tarkoittaa päivityksille, todisteille ja vanhoille PHP-versioille PHP2Shellin jälkeen.
- [Remi-repositorio: PHP ajan tasalla RHEL-järjestelmissä](https://phpsos.de/fi/blog/remi-repository-php/): Remi toimittaa ajantasaisia PHP-versioita RHEL-perheelle, moduulina tai rinnakkain asennettavina. Näin tarkistatte tilan PHP2Shellin jälkeen ja vältätte unohtuneet haarat.
- [Miksi php -v näyttää päivityksen jälkeen saman numeron](https://phpsos.de/fi/blog/php-v-zeigt-alte-nummer/): Päivitys onnistui, mutta php -v ilmoittaa vanhan version. Yleensä kyse on backportista eikä virheestä. Näin erotatte harmittoman todellisista ongelmista.
- [CVE-numeroiden todistaminen paketin muutoslokista](https://phpsos.de/fi/blog/cve-im-changelog-nachweisen/): Jos PHP-korjaus on todistettava johdolle, tarkastajille tai vakuutusyhtiölle, versionumero ei riitä. Näin muutoslokin merkinnästä tulee todiste.
- [Hosting-yrityksen vaihto tietoturvatapauksen jälkeen: mihin kiinnittää huomiota?](https://phpsos.de/fi/blog/hoster-wechseln-nach-vorfall/): Tapauksen jälkeen halu vaihtaa hosting-yritystä on ymmärrettävä. Jotta hyökkääjä ei muuta mukana, väliä on järjestyksellä ja valinnalla.
- [Useita PHP-versioita yhdellä palvelimella: korjatkaa jokainen erikseen](https://phpsos.de/fi/blog/mehrere-php-versionen-server/): Monella palvelimella toimii rinnakkain kolme, neljä tai useampia PHP-asennuksia. PHP2Shellin jälkeen jokainen on löydettävä, päivitettävä ja käynnistettävä uudelleen.
- [Vanhojen PHP-versioiden poistaminen käytöstä hosting-paneelissa](https://phpsos.de/fi/blog/alte-php-versionen-abschalten/): PHP2Shell on hyvä syy luopua vanhoista PHP-versioista. Näin etenette kolmessa vaiheessa, jotta mikään verkkosivusto tai cron-työ ei lakkaa toimimasta huomaamatta.
- [Plesk: PHP-handlerien ymmärtäminen (FPM, FastCGI, Apache-moduuli)](https://phpsos.de/fi/blog/plesk-php-handler/): Se, mitä PHP-handleria Plesk käyttää verkkosivustolle, ratkaisee erottelun, asetukset ja riskin. Vertailu PHP2Shellin näkökulmasta.
- [CloudLinux ja alt-php: mitä hosting-asiakkaiden pitäisi tietää](https://phpsos.de/fi/blog/cloudlinux-alt-php/): CloudLinux-palvelimilla verkkosivustot toimivat usein omilla alt-php-paketeillaan. Jokainen versio tarvitsee oman korjauksensa, ja sen voi asentaa vain palvelimen ylläpitäjä.
- [PHP NAS-laitteilla, palomuureilla ja appliance-laitteilla: unohdetut järjestelmät](https://phpsos.de/fi/blog/php-auf-nas-und-appliances/): PHP:tä eivät käytä vain verkkopalvelimet. Myös NAS-järjestelmät, palomuurit ja erikoislaitteet, joissa on verkkokäyttöliittymä, voivat olla haavoittuvia. Korjauksen voi yleensä tehdä vain valmistaja, saavutettavuudesta päätätte itse.
- [PHP pilvi- ja PaaS-palveluissa: kuka korjaa ajoympäristön?](https://phpsos.de/fi/blog/paas-php-laufzeit/): Alustapalveluissa PHP-korjaus riippuu toimintamallista. Ratkaisevaa on ajoympäristö, joka todella palvelee pyyntöjä, ei paikallinen ympäristö eikä sovelluskoodi.
- [Viralliset PHP Docker -kuvat: tagit, digestit ja uudelleenrakennus](https://phpsos.de/fi/blog/offizielle-php-docker-images/): Virallisen PHP-kuvan tag on osoitin, joka siirtyy ajan myötä uusiin tiloihin. Kun tiedätte, mitä tag, variantti ja digest tarkoittavat, valitsette oikean kuvan ja voitte todistaa korjaustilan.
- [CI/CD: PHP-kuvien automaattinen uudelleenrakennus](https://phpsos.de/fi/blog/php-images-in-ci-neu-bauen/): Kuva vanhenee ilman koodimuutostakin. Ajastetuilla buildeilla, versiotarkistuksella ja digestiin perustuvalla käyttöönotolla PHP-korjaukset pääsevät luotettavasti tuotantoon.
- [Pitkäaikaistuki vanhoille PHP-versioille: vaihtoehdot ja rajat](https://phpsos.de/fi/blog/langzeitsupport-alte-php-versionen/): Jos ette voi heti siirtyä pois PHP 8.1:stä tai vanhemmasta, pitkäaikaistukea tarjoavat jakelut, kolmannet osapuolet ja kaupalliset palvelut. Mitä nämä tiet tarjoavat, mitä tarvitsette kirjallisena ja missä rajat ovat.
- [PHP:n päivittäminen Windowsissa](https://phpsos.de/fi/blog/php-unter-windows-aktualisieren/): Windowsissa ei ole automaattista PHP-päivitystä. Kun valitsette oikean variantin, tarkistatte latauksen ja käynnistätte kaikki prosessit uudelleen, PHP2Shell-korjaus saadaan siististi jokaiselle koneelle.
- [Varoitusmerkki: verkkopalvelin käynnistää shellin](https://phpsos.de/fi/blog/webserver-startet-shell/): 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.
- [Epäilyttävien prosessien löytäminen Linux-palvelimilta](https://phpsos.de/fi/blog/verdaechtige-prozesse-linux/): Haitalliset prosessit naamioituvat harmittomilla nimillä, toimivat väliaikaisista kansioista tai poistetuista tiedostoista. Muutamalla lukevalla komennolla löydätte poikkeamat ja arvioitte ne.
- [Piilotettujen cron-töiden tunnistaminen takaovena](https://phpsos.de/fi/blog/cronjobs-als-hintertuer/): Hyökkääjät käyttävät ajastettuja tehtäviä palatakseen siivouksen jälkeen. Näin tarkistatte crontabit, cron-hakemistot, systemd-ajastimet ja at-työt kokonaan ja tunnistatte epäilyttävät merkinnät.
- [Äskettäin muuttuneiden tiedostojen etsintä verkkopalvelimelta](https://phpsos.de/fi/blog/geaenderte-dateien-finden/): Mahdollisen murron jälkeen ratkaisevaa on, mikä palvelimella on muuttunut. Näin etsitte aikaikkunoilla, käytätte mtimea ja ctimea oikein ja vertaatte paketteihin, Gitiin ja varmuuskopioihin.
- [PHP-tiedostot upload-kansiossa: löytöjen oikea tulkinta](https://phpsos.de/fi/blog/php-dateien-im-upload-ordner/): PHP-tiedosto upload-kansiossa on lähes aina hälytysmerkki, mutta kaikki eivät ole haittakoodia. Näin arvioitte löydön tuhoamatta jälkiä ja selvitätte, onko joku kutsunut tiedostoa.
- [Hämärretyn PHP-koodin tunnistaminen](https://phpsos.de/fi/blog/verschleierter-php-code/): Lukukelvoton PHP-koodi, jossa on eval ja base64_decode, on klassinen merkki lisätystä haittakoodista. Mitä kaavoja etsitte, miten löydätte ne vaarattomasti ja milloin hämärrys on oikeutettua.
- [Palvelimen lähtevien yhteyksien tarkistus](https://phpsos.de/fi/blog/ausgehende-verbindungen-pruefen/): Verkkopalvelin vastaa pääasiassa pyyntöihin. Jos se itse muodostaa yhteyksiä tuntemattomiin kohteisiin, se voi tarkoittaa hyökkääjän ohjausta tai tietovuotoa. Näin tarkistatte ja rajaatte lähtevää liikennettä.
- [Vieraiden ylläpitäjätilien löytäminen CMS:stä ja palvelimelta](https://phpsos.de/fi/blog/fremde-admin-konten-finden/): Tuntematon ylläpitäjä on usein yksinkertaisin takaovi. Näin etsitte vieraita tilejä tasolta tasolle, myös sellaisia, jotka käyttöliittymä piilottaa.
- [Tuntemattomien SSH-avainten löytäminen ja poistaminen](https://phpsos.de/fi/blog/ssh-schluessel-pruefen/): Lisätty SSH-avain avaa hyökkääjille oven, vaikka kaikki salasanat olisi vaihdettu. Näin löydätte jokaisen authorized_keys-tiedoston ja tarkistatte jokaisen merkinnän.
- [Kryptolouhija verkkopalvelimella: merkit ja toimintatapa](https://phpsos.de/fi/blog/kryptominer-auf-dem-server/): Suoritin jatkuvasti täynnä, vaikka kävijöitä ei ole enempää: se voi olla kryptolouhija. Näin tarkistatte kuorman, löydätte prosessin ja sen uudelleenkäynnistysmekanismit ja etenette järjestyksessä.
- [Palvelin lähettää roskapostia: syiden löytäminen](https://phpsos.de/fi/blog/server-verschickt-spam/): Toimittamattomia viestejä, estolistoja, valituksia: kun oma palvelin lähettää roskapostia, taustalla on yleensä skripti tai kaapattu postilaatikko. Näin löydätte lähteen.
- [SEO-roska ja vieraat sivut Googlen hakemistossa](https://phpsos.de/fi/blog/seo-spam-im-google-index/): Yhtäkkiä lääkkeitä tai merkkituotteita esitteleviä sivuja ilmestyy hakutuloksiin teidän verkkotunnuksenne alla. Näin selvitätte, mistä SEO-roska tulee, ja saatte sen pois hakemistosta.
- [Verkkosivusto ohjaa kävijät vieraille sivuille](https://phpsos.de/fi/blog/website-leitet-um/): Kävijät päätyvät arvontasivuille tai epäilyttäviin verkkokauppoihin, mutta te itse ette näe mitään? Näin löydätte kerroksen, jossa uudelleenohjaus piilee, ja poistatte sen.
- [Varmistakaa todisteet ennen palvelimen uudelleenasennusta](https://phpsos.de/fi/blog/beweise-sichern-vor-neuinstallation/): Uudelleenrakennus poistaa hyökkääjän mutta myös kaikki jäljet. Kun käytätte tuntiin todisteiden varmistamiseen ensin, voitte myöhemmin kertoa, mitä tapahtui.
- [Tapauksen aikajanan laatiminen](https://phpsos.de/fi/blog/zeitleiste-eines-vorfalls/): Milloin hyökkääjä tuli, mitä hän teki ja milloin se huomattiin? Selkeä aikajana vastaa näihin kysymyksiin ja on ilmoitusten, vakuutuksen ja raportin perusta.
- [CMS-ydintiedostojen vertailu alkuperäiseen](https://phpsos.de/fi/blog/cms-kerndateien-vergleichen/): Vertailu puhtaaseen alkuperäiseen paljastaa jokaisen muuttuneen tiedoston riippumatta siitä, tunteeko skanneri sen. Näin rakennatte vertailun WordPressille, Composer-projekteille ja järjestelmäpaketeille.
- [Tietokannan tarkistus sisäänajetun koodin varalta](https://phpsos.de/fi/blog/datenbank-auf-schadcode-pruefen/): Joka tarkistaa vain tiedostot, ohittaa puolet. Näin käytte läpi tietokannan sisällöt, asetukset, triggerit ja tilit sisäänajetun koodin varalta, lukien ja kopiolla.
- [Verkkosivustojen haittaohjelmaskannerit: mitä ne löytävät ja mitä eivät](https://phpsos.de/fi/blog/grenzen-von-malware-scannern/): Skanneri ei ilmoita mitään, joten kaikki on hyvin? Ei välttämättä. Millaisia verkkosivuskannereita on, mitä kukin näkee ja mitä se ei voi periaatteessa nähdä.
- [PHP-FPM-poolien eristys sivustoittain](https://phpsos.de/fi/blog/php-fpm-pools-isolieren/): Oma pooli jokaiselle sivustolle on alku, ei loppu. Näin tarkistatte nykyiset poolit ja koventatte socketit, päätteet, tilasivut, resurssit ja lokit.
- [memory_limit-asetuksen määrittäminen oikein](https://phpsos.de/fi/blog/memory-limit-richtig-setzen/): memory_limit rajaa muistin PHP-pyyntöä kohden. PHP2Shellin jälkeen php.net suosittelee tilapäisesti päinvastaista. Mikä on voimassa normaalikäytössä, siirtymäaikana ja päivityksen jälkeen.
- [post_max_size- ja upload_max_filesize-rajojen järkevä asettaminen](https://phpsos.de/fi/blog/post-max-size-upload-limits/): Upload-rajat vaikuttavat kolmessa paikassa: verkkopalvelimessa, PHP:ssä ja sovelluksessa. Näin asetatte arvot yhteensopiviksi, myös php.netin PHP2Shellin siirtymäarvojen kanssa.
- [session.upload_progress pois käytöstä: oikein ja pysyvästi](https://phpsos.de/fi/blog/session-upload-progress-abschalten/): Keino aukkoa CVE-2026-115560 vastaan ja yksi PHP2Shellin siirtymäajan toimenpiteistä asetetaan nopeasti. Jotta se pitää, sen on oltava oikeassa paikassa, lukittuna ja tarkistettava jokaisen päivityksen jälkeen.
- [expose_php ja Server-otsakkeet: versiotietojen piilotus](https://phpsos.de/fi/blog/expose-php-versionsangaben/): PHP, Nginx ja Apache kertovat versionumeronsa oletuksena jokaisessa vastauksessa. Se ei suojaa hyökkäyksiltä, mutta antaa skannereille kätevän osumalistan. Näin estätte sen ja säilytätte silti yleiskuvan.
- [display_errors off: virhetulosteiden poisto tuotannosta](https://phpsos.de/fi/blog/display-errors-produktion/): Näkyvät PHP-virheilmoitukset paljastavat polkuja, tietokantojen nimiä ja versioita. Näin kytkette ne pois PHP:ssä, kehyksessä ja verkkopalvelimessa menettämättä virheitä näkyvistä.
- [php_admin_value: asetusten lukitseminen ylikirjoitukselta](https://phpsos.de/fi/blog/php-admin-value-sperren/): Tietoturva-asetuksesta on vähän hyötyä, jos sovellus muuttaa sen takaisin yhdellä koodirivillä. Komennoilla php_admin_value ja php_admin_flag määritätte arvot sitovasti PHP-FPM:lle ja Apachelle.
- [Muistirajojen asettaminen systemd:llä ja cgroupeilla](https://phpsos.de/fi/blog/speichergrenzen-systemd-cgroups/): php.net suosittelee PHP2Shellin siirtymäajan toimenpiteenä asetusta memory_limit=-1 ja PHP:n ulkopuolista muistirajaa. Näin asetatte rajan systemd:llä ja cgroupeilla niin, ettei yksittäinen worker vedä koko palvelua mukanaan.
- [Nginxin turvallinen asetus PHP:lle](https://phpsos.de/fi/blog/nginx-fuer-php-absichern/): Useimmat Nginx-PHP-asennusten heikkoudet eivät ole Nginxissä vaan PHP-locationin muutamalla rivillä. Näin asetatte PHP-FPM:lle välityksen niin, että vain halutut skriptit suoritetaan.
- [Apachen turvallinen asetus PHP:lle](https://phpsos.de/fi/blog/apache-fuer-php-absichern/): Apache on joustava, ja juuri se tekee siitä alttiin virhekonfiguraatiolle. Näin liitätte PHP:n PHP-FPM:n kautta, suljette .htaccess-takaoven ja asetatte tärkeimmät ydinvalinnat turvallisiksi.
- [PHP:n suorituksen kielto upload-kansioissa](https://phpsos.de/fi/blog/php-in-uploads-verbieten/): Web shell tarvitsee kaksi asiaa: kansion, johon se voidaan kirjoittaa, ja palvelimen, joka suorittaa sen. Näin viette siltä jälkimmäisen, ja jokaisessa kirjoitettavassa kansiossa, ei vain uploads-kansiossa.
- [Upload-pyyntöjen suodatus reunalla: mahdollisuudet ja riskit](https://phpsos.de/fi/blog/upload-anfragen-am-rand-filtern/): Asiantuntijakirjoittajat ehdottavat, että upload-pyynnöt todellisten upload-polkujen ulkopuolella estetään välityspalvelimessa, kunnes PHP on päivitetty. Se voi auttaa, mutta myös lamauttaa lomakkeet ja tilaukset. Näin etenette hallitusti.
- [ModSecurityn ja OWASP Core Rule Setin käyttöönotto](https://phpsos.de/fi/blog/modsecurity-owasp-crs/): Oma Web Application Firewall ModSecurityllä ja OWASP Core Rule Setillä on ilmainen ja tehokas, mutta ei itsestään toimiva. Näin valitsette moottorin, aloitatte ilman katkoksia ja hienosäädätte säännöt.
- [Fail2banin käyttöönotto verkkopalvelimille](https://phpsos.de/fi/blog/fail2ban-fuer-webserver/): Fail2ban estää osoitteet, jotka herättävät lokeissa toistuvasti huomiota. Verkkopalvelimille se tuo valmiit suodattimet, ja muutamalla rivillä lisäätte omia. Näin otatte sen käyttöön sulkematta ulos itseänne tai asiakkaitanne.
- [Palomuuri verkkopalvelimelle: avatkaa vain tarvittavat portit](https://phpsos.de/fi/blog/firewall-fuer-webserver/): Verkkopalvelin tarvitsee ulospäin yleensä vain kaksi porttia. Silti monella palvelimella tietokannat, PHP-FPM tai hallintakäyttöliittymät kuuntelevat internetissä. Näin löydätte avoimet palvelut ja suljette sen, mitä ei tarvita.
- [Automaattiset tietoturvapäivitykset Linux-palvelimilla](https://phpsos.de/fi/blog/automatische-sicherheitsupdates/): Raporttien mukaan jakelut toimittivat PHP-backportteja osin jo 21. lokakuuta 2026, korjausten julkaisupäivänä. Joka käyttää automaattisia tietoturvapäivityksiä, sai ne nopeasti palvelimelleen. Jotta ne tehoavat, tarvitaan uudelleenkäynnistyksiä, kolmannen osapuolen lähteitä ja valvontaa.
- [Vähimmän oikeuden periaate: verkkopalvelinkäyttäjän oikeudet](https://phpsos.de/fi/blog/rechte-des-webserver-benutzers/): Ujutettu koodi toimii verkkopalvelinkäyttäjän oikeuksilla. Se, mitä tämä tili saa tehdä, ratkaisee, kuinka pitkälle hyökkääjä pääsee. Näin rajaatte shellin, sudon, cronin, tietokannan ja tiedostojärjestelmän vain välttämättömään.
- [Hallintaosien suojaus IP-osoitteella, VPN:llä tai lisäsuojalla](https://phpsos.de/fi/blog/admin-bereiche-abschirmen/): Miksi verkkosivuston hallintaosan ei tarvitse olla koko maailman saavutettavissa ja miten suojaatte sen IP-rajauksella, VPN:llä tai ennakkotunnistautumisella lukitsematta itseänne ulos.
- [TLS ja HTTPS oikein asetettuna](https://phpsos.de/fi/blog/tls-https-richtig-konfigurieren/): Mitä TLS-versioita ja salausjoukkoja (cipher suites) verkkopalvelimen tulisi nykyään tarjota, mihin suositukset perustuvat ja miten tarkistatte Nginxin, Apachen ja PHP:n lähtevät yhteydet.
- [CIS-benchmarkit ja BSI-moduulit verkkopalvelimille](https://phpsos.de/fi/blog/cis-benchmarks-bsi-bausteine/): Mitä koventamisstandardeja Linux-verkkopalvelimille on, miten CIS-benchmarkit ja IT-Grundschutz-moduulit eroavat toisistaan ja miten niistä tehdään tarkistettava vaatimus PHP-palvelimillenne.
- [Salasanojen turvallinen tallennus PHP:ssä: password_hashin oikea käyttö](https://phpsos.de/fi/blog/passwoerter-in-php-speichern/): Miten kehittäjät tallentavat salasanat PHP:ssä password_hashilla ja password_verifylla, valitsevat sopivan menetelmän ja korvaavat vanhat MD5- tai SHA-1-tiivisteet ilman, että kaikkien käyttäjien salasana nollataan.
- [CSRF-suoja PHP-sovelluksissa](https://phpsos.de/fi/blog/csrf-schutz-php/): Miten kehittäjät estävät Cross-Site Request Forgeryn PHP-sovelluksissa: token jokaiselle muuttavalle pyynnölle, alkuperän tarkistus otsikosta ja SameSite-evästeet lisäkerroksena.
- [Syötteiden validointi ja suodatus PHP:ssä filter_varilla](https://phpsos.de/fi/blog/eingaben-validieren-php/): Miten kehittäjät tarkistavat syötteet PHP:ssä filter_varilla, filter_input_arraylla ja sallittujen luetteloilla, mitkä suodattimet ovat vanhentuneita ja miksi validointi ei korvaa valmisteltuja lauseita eikä tulosteen koodausta.
- [Command Injectionin estäminen PHP:ssä](https://phpsos.de/fi/blog/command-injection-php/): Miten kehittäjät välttävät Command Injectionin PHP:ssä: järjestelmäkomentojen korvaaminen PHP-funktioilla, proc_openin käyttö ilman shelliä, argumenttien tarkistus ja vaarallisten kohtien löytäminen vanhasta koodista.
- [Server-Side Request Forgeryn (SSRF) estäminen PHP:ssä](https://phpsos.de/fi/blog/ssrf-in-php/): Miten kehittäjät estävät PHP-sovellusta kysymästä sisäisiä järjestelmiä vieraiden puolesta: sallittujen luettelot, protokollarajoitus, ratkaistun osoitteen tarkistus ja verkon rajat.
- [XML External Entitiesin (XXE) estäminen PHP:ssä](https://phpsos.de/fi/blog/xxe-in-php/): Miten kehittäjät käsittelevät XML:ää PHP:ssä turvallisesti: libxmlin oletuskäyttäytyminen, riskialttiit asetukset kuten LIBXML_NOENT, suoja entity-loaderilla ja LIBXML_NO_XXE:lla sekä tyypilliset piilotetut XML-syötteet.
- [Type Juggling PHP:ssä: löyhät vertailut tietoturvariskinä](https://phpsos.de/fi/blog/type-juggling-php/): Miksi löyhät vertailut operaattorilla == voivat PHP:ssä johtaa tietoturva-aukkoihin, mitä PHP 8.0 muutti ja miten kirjoitatte vertailut kirjautumisissa, tokeneissa ja käyttöoikeuksissa kestävästi.
- [Turvalliset satunnaisluvut ja tokenit PHP:ssä random_bytesilla](https://phpsos.de/fi/blog/sichere-tokens-php/): Miten kehittäjät luovat PHP:ssä tokeneita salasanalinkeille, API-avaimille ja kertakoodeille: kryptografisesti turvalliset lähteet, riittävä pituus, tallennus tiivisteenä ja rajattu voimassaolo.
- [Tunnusten ja .env-tiedostojen oikea suojaus](https://phpsos.de/fi/blog/env-dateien-schuetzen/): Miten suojaatte tietokannan salasanat, API-avaimet ja muut salaisuudet PHP-projekteissa: .env-tiedostot verkkojuuren ulkopuolella, verkkopalvelimen estot, tiukat oikeudet ja hallittu vaihto tapahtuman jälkeen.
- [Julkinen .git-kansio: aliarvioitu tietovuoto](https://phpsos.de/fi/blog/git-ordner-oeffentlich/): Miksi Gitillä toimitettu verkkojuuri voi paljastaa koko lähdekoodin historioineen, miten tarkistatte asian, estätte pääsyn heti ja rakennatte käyttöönoton pysyvästi ilman .git-kansiota.
- [Varmuuskopiotiedostot verkkojuuressa: .zip, .sql ja .bak](https://phpsos.de/fi/blog/backup-dateien-im-webroot/): Miksi tietokantavedokset, arkistot ja varmuuskopiot julkisessa hakemistossa kuuluvat yleisimpiin tietovuotoihin, miten ne löydetään ja estetään ja miten selvitetään, onko niitä haettu.
- [phpinfo()-tiedostot: miksi niiden on poistuttava](https://phpsos.de/fi/blog/phpinfo-dateien-entfernen/): PHP2Shellin jälkeen moni ylläpitäjä luo nopeasti tiedoston info.php. Miksi tällaiset tiedostot ovat tietovuoto, miten ne löydetään ja mitkä tarkistustavat ovat parempia.
- [Riippuvuudet ajan tasalla: Composer, npm ja laajennukset](https://phpsos.de/fi/blog/abhaengigkeiten-aktuell-halten/): Projekti koostuu kolmesta pakettimaailmasta: Composer, npm ja CMS-laajennukset. Miten pidätte kaikki kolme ajan tasalla kiinteällä rytmillä, selkeällä vastuulla ja testeillä.
- [Tietoturvakoodikatselmointi PHP-projekteille](https://phpsos.de/fi/blog/sicherheits-code-review-php/): Miten tiimit käyvät omaa PHP-koodiaan läpi kohdennetusti tietoturva-aukkojen varalta: katselmointityypit, kriittiset funktiot, järkevät työkalut ja tarkistuslista.
- [Turvallinen lokitus: virheiden kirjaus ilman tietovuotoa](https://phpsos.de/fi/blog/sicher-loggen-php/): Lokit auttavat vianhaussa ja forensiikassa, mutta niistä tulee helposti itse tietovuoto. Mitä PHP-sovellusten tulisi kirjata, mitä ei koskaan ja miten lokit suojataan.
- [REST-API:iden suojaus PHP:ssä](https://phpsos.de/fi/blog/rest-api-php-absichern/): Rajapinnat on usein suojattu huonommin kuin niiden edessä oleva verkkosivusto. Tärkeimmät säännöt PHP:n REST-API:ille olion käyttöoikeudesta nopeusrajoitukseen.
- [IT-palveluntarjoajasopimukset: tietoturvavelvoitteet selkeiksi](https://phpsos.de/fi/blog/dienstleistervertrag-sicherheit/): PHP2Shell osoitti, kuinka usein on epäselvää, kenen pitää päivittää. Mitkä tietoturvavelvoitteet kuuluvat sopimuksiin toimiston, hosting-palveluntarjoajan ja IT-palveluntarjoajan kanssa.
- [Henkilötietojen käsittely, kun palveluntarjoajat pääsevät palvelimelle](https://phpsos.de/fi/blog/auftragsverarbeitung-serverzugriff/): Joka päästää ulkopuoliset asiakastietoja sisältäville palvelimille, tarvitsee yleensä käsittelijäsopimuksen (DPA). Mitä GDPR:n 28 artikla edellyttää ja miten järjestätte pääsyt hätätilanteessa tietosuojan mukaisesti.
- [Haavoittuvuuksien hallinta pk-yrityksessä](https://phpsos.de/fi/blog/schwachstellenmanagement-mittelstand/): Yksikään keskisuuri yritys ei voi käsitellä jokaista tiedotetta heti. Kevyt kierto, jossa haavoittuvuudet kirjataan, arvioidaan, ratkaistaan ja todennetaan, varmistaa, että tärkein hoidetaan ensin.
- [Tietäkää, mitä käytössä on: kaikkien verkkosivustojen ja palvelinten luettelo](https://phpsos.de/fi/blog/inventar-websites-server/): PHP2Shellin kohdalla monet eivät kompastuneet korjaukseen vaan kysymykseen, missä PHP ylipäätään toimii. Näin rakennatte luettelon kaikista verkkosivustoista ja palvelimista.
- [Päivitysten hallinta prosessina palokunta-toiminnan sijaan](https://phpsos.de/fi/blog/patch-management-prozess/): Joka päivittää vasta kun palaa, menettää aikaa hätätilanteessa. Miten päivitysten hallinnan prosessi, jossa on kiinteät luokat, ikkunat ja todisteet, yhdistää rutiinin ja hätätilanteen.
- [Hätäyhteystiedot: kenelle ilmoitetaan ja milloin?](https://phpsos.de/fi/blog/notfallkontakte-liste/): Hätätilanteessa ratkaisee, ketkä tavoitetaan ja milloin. Näin rakennatte IT-hätäyhteystietojen listan, jossa on laukaisevat tilanteet, sijaiset ja tiedot, joita jokainen puhelu tarvitsee.
- [Mitä murrettu palvelin maksaa: kuluerät](https://phpsos.de/fi/blog/kostenposten-eines-hacks/): Murrettu verkkopalvelin aiheuttaa enemmän kuluja kuin korjaus. Mitä kulueriä syntyy ja miten perustelette ennaltaehkäisyn budjetin omilla luvuillanne.
- [Asiakkaiden tiedottaminen häiriön jälkeen](https://phpsos.de/fi/blog/kunden-nach-vorfall-informieren/): Velvollisuus tai vapaaehtoinen: miten päätätte häiriön jälkeen, ketä tiedotatte, mitkä kanavat ovat turvallisia ja miten asiakaspalvelunne on valmisteltu.
- [Verkon toimitusketju: toimisto, hosting-yritys, lisäosien toimittaja](https://phpsos.de/fi/blog/lieferkette-agentur-hoster/): PHP2Shell osoitti, kuinka monta lenkkiä korjauksen ja verkkosivustonne välissä on. Näin tunnette verkkosivustonne toimitusketjun, turvaatte sen ja pehmennätte yksittäisten lenkkien vikaantumista.
- [Tietoturvatietoisuus ylläpitäjille ja toimittajille: tietoturvatietoisuus verkkotiimissä](https://phpsos.de/fi/blog/sicherheitsbewusstsein-redaktion/): Joka ylläpitää verkkosivustoja, päättää päivittäin tietoturvasta, usein huomaamattaan. Näin koulutatte ylläpitäjät ja toimittajat rooleittain ja ilman kalvosulkeisia.
- [Hätäharjoitus pöydän ääressä: verkkopalvelinhäiriön läpikäynti](https://phpsos.de/fi/blog/notfalluebung-am-tisch/): Pöytäharjoitus vie iltapäivän ja osoittaa, kantaako hätäsuunnitelmanne. Tästä löydätte valmiin käsikirjoituksen PHP-verkkopalvelimen häiriölle.
- [ISO 27001 ja TISAX: mitä verkkopalvelimet koskee](https://phpsos.de/fi/blog/iso-27001-tisax-webserver/): Joka ylläpitää ISO 27001 -mukaista tietoturvajohtamisjärjestelmää tai omistaa TISAX-tunnuksen, joutuu ottamaan verkkopalvelimet huomioon. Tässä kerrotaan, mitä vaatimuksia ne koskettavat ja mitkä todisteet merkitsevät PHP2Shellin jälkeen.
- [VdS 10000: tietoturva pienille ja keskisuurille yrityksille](https://phpsos.de/fi/blog/vds-10000-kmu/): VdS 10000 on kevyt kehys keskisuurten yritysten tietoturvalle. Mitä se vaatii, mikä tuli uutena 2025 ja mitä se tarkoittaa verkkosivustoille ja verkkopalvelimille.
- [Lessons Learned: paremmaksi häiriön jälkeen](https://phpsos.de/fi/blog/lessons-learned-nach-vorfall/): Häiriön jälkeen on ennen seuraavaa. Jäsennelty jälkipuinti ilman syyllistämistä muuttaa huonon viikon mitattavaksi edistykseksi.
- [Päivitys, sulkeminen vai odottaminen? Päätöksentekoapu PHP-aukossa](https://phpsos.de/fi/blog/patchen-abschalten-abwarten/): Kriittisen PHP-aukon kohdalla vastuuhenkilöiden on päätettävä nopeasti. Tämä apu jäsentää kolme vaihtoehtoa, nimeää perusteet ja näyttää, milloin odottaminen on perusteltua.
- [WAF vai päivitys: miksi tarvitsette molempia](https://phpsos.de/fi/blog/waf-oder-update/): Web Application Firewall voi torjua hyökkäyksiä mutta ei sulje aukkoa PHP-tulkissa. Milloin WAF auttaa, mihin sen teho päättyy ja miten yhdistätte molemmat järkevästi.
- [Palvelimen uudelleenasennus vai puhdistus? Päätös tartunnan jälkeen](https://phpsos.de/fi/blog/neu-aufsetzen-oder-bereinigen/): Tunkeutumisen jälkeen on kaksi tietä: palvelin puhdistetaan tai rakennetaan uudelleen. Mitkä perusteet ratkaisevat, ja miksi järjestys on tärkeämpi kuin valinta.
- [Korjaatteko itse vai kutsutteko palveluntarjoajan? Rehellinen punninta](https://phpsos.de/fi/blog/selbst-beheben-oder-dienstleister/): Kaikki tietoturvatilanteet eivät vaadi ulkopuolista apua. Näillä perusteilla ja lyhyellä itsearvioinnilla ratkaisette, selviääkö tiiminne PHP2Shellistä yksin vai tarvitsetteko tukea.
- [IT-tietoturvapalveluntarjoajan valinta: 12 kysymystä ennen toimeksiantoa](https://phpsos.de/fi/blog/sicherheitsdienstleister-auswaehlen/): Hyvän tietoturvapalveluntarjoajan löytäminen aikapaineessa on vaikeaa. Nämä kaksitoista kysymystä auttavat vertailemaan tarjouksia asiallisesti lankeamatta markkinointilupauksiin.
- [Hallinnoitu hosting vai oma palvelin? Tietoturvavertailu](https://phpsos.de/fi/blog/managed-oder-eigener-server/): PHP2Shell oli stressitesti jokaiselle toimintamallille. Vertailu näyttää, milloin hallinnoitu hosting on turvallisempi, milloin oma palvelin ja mitkä sekamuodot ovat osoittautuneet hyviksi.
- [PHP-päivitys vai backport? Päätös vanhoille järjestelmille](https://phpsos.de/fi/blog/php-upgrade-oder-backport/): Vanhoille PHP-versioille on PHP2Shellin jälkeen useita teitä: jakelun backport, kolmannen osapuolen lähde, lähdekoodikorjaus, pitkäaikainen tuki tai päivitys. Mihin kukin tie kelpaa ja kuinka kauan se kantaa.
- [Vaihdetaanko CMS hakkeroinnin jälkeen? Milloin se auttaa ja milloin ei](https://phpsos.de/fi/blog/cms-wechsel-nach-hack/): Tunkeutumisen jälkeen luottamus CMS:ään on usein mennyt. Uusi järjestelmä ratkaisee kuitenkin harvoin varsinaisen syyn. Milloin vaihto on järkevä ja miten se onnistuu siististi.
- [Staattiset verkkosivustot: vähemmän PHP:tä, vähemmän hyökkäyspinta-alaa](https://phpsos.de/fi/blog/statische-website-alternative/): Staattinen verkkosivusto toimittaa valmiita HTML-tiedostoja eikä tarvitse PHP:tä palvelimella. Se pienentää hyökkäyspinta-alaa selvästi, mutta tuo mukanaan omat rajansa ja velvoitteensa.
- [Tunkeutumistesti, Bug Bounty vai haavoittuvuusskannaus? Valitkaa sopiva tarkastusmenetelmä](https://phpsos.de/fi/blog/pentest-bugbounty-scan/): Skannaus, tunkeutumistesti ja Bug Bounty tarkastavat verkkosivustoja aivan eri tavoin. Mitä kukin menetelmä tekee, missä se epäonnistuu ja mikä järjestys sopii yrityksellenne.