Blogi: PHP2Shell, palvelimen tietoturva ja hätäapu
Tilannearviot, ohjeet ylläpitäjille ja päätöksenteon tuki johdolle. Järjestetty aiheittain, jokaisessa artikkelissa on lähteet.
Tilanne ja arviointi
17 artikkelia
PHP2Shell: mikä on todennettu ja mikä ei
PHP2Shellin faktantarkistus: mitkä väitteet tulevat ensisijaisista lähteistä, mitkä mediaraporteista ja mitkä väitteet eivät kestä tarkastelua.
Lue lisää →002Miksi PHP-aukko tuli tietoon ennen korjausta
Raporttien mukaan PHP2Shellin yksityiskohdat tulivat julkisiksi ennen embargon päättymistä. Selitämme tapahtumien kulun ja mitä se tarkoittaa päivityssuunnittelullenne.
Lue lisää →003Viranomaiset ottavat verkkosivuja pois verkosta: mitä yritykset voivat oppia
Mainz, Hessenin osavaltion hallitus ja BKA ottivat verkkosivuja varotoimena pois verkosta. Mitä yritykset voivat oppia omaa päätöstään varten.
Lue lisää →004BSI:n oranssi varoitustaso: mitä luokitus tarkoittaa
BSI luokittelee PHP2Shellin tasolle 3 / oranssi. Mitä asteikko kertoo ja mitä ei, ja miten yritykset muuttavat luokituksen päätöksiksi.
Lue lisää →005Mitä CERT-EU ja CERT-Bund suosittelevat PHP2Shellistä
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ää.
Lue lisää →006Cloudflaren suojasäännöt PHP2Shelliä vastaan: mitä ne tekevät ja mitä eivät
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.
Lue lisää →00722,6 miljoonaa altistunutta instanssia: lukujen oikea tulkinta
Unit 42, CybelAngel ja muut mainitsevat PHP2Shellistä hyvin erilaisia lukuja. Selitämme, mitä on laskettu ja mikä luku merkitsee teille todella.
Lue lisää →008PHP2Shell viidessä minuutissa: tiivistelmä johdolle
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.
Lue lisää →009PHP-tietoturva-aukko selkeästi selitettynä
PHP2Shell ei-teknisille: arkisin vertauksin, pienen sanaston ja kolmen tyypillisen lähtötilanteen avulla, mitä verkkosivuston ylläpitäjän kannattaa tehdä.
Lue lisää →010PHP2Shell: 15 kysymystä hosting-asiakkailta
Verkkosivustonne on hosting-yrityksellä ja haluatte tietää, mitä teidän on itse tehtävä PHP2Shellin vuoksi? Tässä 15 yleisintä kysymystä lyhyin vastauksin.
Lue lisää →011Miksi WordPress-päivitys ei auta PHP2Shelliä vastaan
Moni ylläpitäjä päivitti WordPressin otsikoiden jälkeen ja tuntee olonsa turvalliseksi. Miksi se ei PHP2Shellin kohdalla riitä ja mikä ratkaisee.
Lue lisää →012PHP2Shell ja Log4Shell: mitä aukoilla on yhteistä
Moni vertaa PHP2Shelliä vuoden 2021 Log4Shelliin. Mitä vertailu kestää, missä se ontuu ja mitkä silloiset opit auttavat nyt.
Lue lisää →013Massaskannaukset päivittämättömän PHP:n perässä: näin automaattiset hyökkäykset etenevät
PHP2Shellin jälkeen hyökkääjät etsivät internetistä automaattisesti haavoittuvia palvelimia. Miten se etenee, miksi koolla ei ole merkitystä ja mikä suojaa.
Lue lisää →014Päivityksen ja hyökkäyksen välinen aikaikkuna
PHP2Shellin kohdalla hyökkäysyrityksiä oli jo ennen korjausta. Selitämme aikaikkunan vaiheet, miten mittaatte omanne ja miten lyhennätte sitä.
Lue lisää →015PHP2Shellin jälkeen: miksi lisäilmoitukset ovat todennäköisiä
PHP2Shell ei ole ohi 21. lokakuuta tulleella päivityksellä. Miksi jatkoilmoituksia on odotettavissa ja miten valmistatte tiiminne niihin.
Lue lisää →016PHP2Shell: ensimmäisen viikon tilannekuva
Viikko ensimmäisen havaitun hyökkäysyrityksen jälkeen: päivitysten, viranomaisvaroitusten, hyökkäysten ja sulkemisten tilanne lähteittäin eroteltuna.
Lue lisää →017Vaaralliset vääränlaiset vinkit PHP2Shellistä, jotka kiertävät juuri nyt
Evästeiden estäminen, virheilmoitusten piilottaminen, vain CMS:n päivitys: yhdeksän PHP2Shell-neuvoa, jotka luovat väärää turvallisuutta, ja mikä todella merkitsee.
Lue lisää →Hosting ja jakelut
18 artikkelia
PHP-version vaihtaminen hosting-asiakasalueella
Miten vaihdatte PHP-version hosting-yrityksenne asiakasalueella, minkä version valitsette ja mitä tarkistatte ennen ja jälkeen.
Lue lisää →019Debian ja Ubuntu: onko PHP-pakettini päivitetty?
Mitkä PHP-paketit Debian ja Ubuntu ovat korjanneet PHP2Shelliä vastaan, miten vertaatte asennetun tilan tarkasti ja mihin todistaminen kaatuu.
Lue lisää →020RHEL, AlmaLinux ja Rocky Linux: PHP-päivityksen tarkistaminen
Mitä Red Hat on julkaissut PHP2Shellistä, miten todistatte pakettitilan RHELillä ja sen jäljennöksillä ja miksi uudelleenlataus ei riitä.
Lue lisää →021sury.org-repositorio: PHP-paketit kolmannelta osapuolelta
Monet Debian- ja Ubuntu-palvelimet hankkivat PHP:n sury-repositoriosta. Mitä se tarkoittaa päivityksille, todisteille ja vanhoille PHP-versioille PHP2Shellin jälkeen.
Lue lisää →022Remi-repositorio: PHP ajan tasalla RHEL-järjestelmissä
Remi toimittaa ajantasaisia PHP-versioita RHEL-perheelle, moduulina tai rinnakkain asennettavina. Näin tarkistatte tilan PHP2Shellin jälkeen ja vältätte unohtuneet haarat.
Lue lisää →023Miksi php -v näyttää päivityksen jälkeen saman numeron
Päivitys onnistui, mutta php -v ilmoittaa vanhan version. Yleensä kyse on backportista eikä virheestä. Näin erotatte harmittoman todellisista ongelmista.
Lue lisää →024CVE-numeroiden todistaminen paketin muutoslokista
Jos PHP-korjaus on todistettava johdolle, tarkastajille tai vakuutusyhtiölle, versionumero ei riitä. Näin muutoslokin merkinnästä tulee todiste.
Lue lisää →025Hosting-yrityksen vaihto tietoturvatapauksen jälkeen: mihin kiinnittää huomiota?
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.
Lue lisää →026Useita PHP-versioita yhdellä palvelimella: korjatkaa jokainen erikseen
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.
Lue lisää →027Vanhojen PHP-versioiden poistaminen käytöstä hosting-paneelissa
PHP2Shell on hyvä syy luopua vanhoista PHP-versioista. Näin etenette kolmessa vaiheessa, jotta mikään verkkosivusto tai cron-työ ei lakkaa toimimasta huomaamatta.
Lue lisää →028Plesk: PHP-handlerien ymmärtäminen (FPM, FastCGI, Apache-moduuli)
Se, mitä PHP-handleria Plesk käyttää verkkosivustolle, ratkaisee erottelun, asetukset ja riskin. Vertailu PHP2Shellin näkökulmasta.
Lue lisää →029CloudLinux ja alt-php: mitä hosting-asiakkaiden pitäisi tietää
CloudLinux-palvelimilla verkkosivustot toimivat usein omilla alt-php-paketeillaan. Jokainen versio tarvitsee oman korjauksensa, ja sen voi asentaa vain palvelimen ylläpitäjä.
Lue lisää →030PHP NAS-laitteilla, palomuureilla ja appliance-laitteilla: unohdetut järjestelmät
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.
Lue lisää →031PHP pilvi- ja PaaS-palveluissa: kuka korjaa ajoympäristön?
Alustapalveluissa PHP-korjaus riippuu toimintamallista. Ratkaisevaa on ajoympäristö, joka todella palvelee pyyntöjä, ei paikallinen ympäristö eikä sovelluskoodi.
Lue lisää →032Viralliset PHP Docker -kuvat: tagit, digestit ja uudelleenrakennus
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.
Lue lisää →033CI/CD: PHP-kuvien automaattinen uudelleenrakennus
Kuva vanhenee ilman koodimuutostakin. Ajastetuilla buildeilla, versiotarkistuksella ja digestiin perustuvalla käyttöönotolla PHP-korjaukset pääsevät luotettavasti tuotantoon.
Lue lisää →034Pitkäaikaistuki vanhoille PHP-versioille: vaihtoehdot ja rajat
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.
Lue lisää →035PHP:n päivittäminen Windowsissa
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.
Lue lisää →Havaitseminen ja forensiikka
18 artikkelia
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.
Lue lisää →037Epäilyttävien prosessien löytäminen Linux-palvelimilta
Haitalliset prosessit naamioituvat harmittomilla nimillä, toimivat väliaikaisista kansioista tai poistetuista tiedostoista. Muutamalla lukevalla komennolla löydätte poikkeamat ja arvioitte ne.
Lue lisää →038Piilotettujen cron-töiden tunnistaminen takaovena
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.
Lue lisää →039Äskettäin muuttuneiden tiedostojen etsintä verkkopalvelimelta
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.
Lue lisää →040PHP-tiedostot upload-kansiossa: löytöjen oikea tulkinta
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.
Lue lisää →041Hämärretyn PHP-koodin tunnistaminen
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.
Lue lisää →042Palvelimen lähtevien yhteyksien tarkistus
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ä.
Lue lisää →043Vieraiden ylläpitäjätilien löytäminen CMS:stä ja palvelimelta
Tuntematon ylläpitäjä on usein yksinkertaisin takaovi. Näin etsitte vieraita tilejä tasolta tasolle, myös sellaisia, jotka käyttöliittymä piilottaa.
Lue lisää →044Tuntemattomien SSH-avainten löytäminen ja poistaminen
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.
Lue lisää →045Kryptolouhija verkkopalvelimella: merkit ja toimintatapa
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ä.
Lue lisää →046Palvelin lähettää roskapostia: syiden löytäminen
Toimittamattomia viestejä, estolistoja, valituksia: kun oma palvelin lähettää roskapostia, taustalla on yleensä skripti tai kaapattu postilaatikko. Näin löydätte lähteen.
Lue lisää →047SEO-roska ja vieraat sivut Googlen hakemistossa
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.
Lue lisää →048Verkkosivusto ohjaa kävijät vieraille sivuille
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.
Lue lisää →049Varmistakaa todisteet ennen palvelimen uudelleenasennusta
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.
Lue lisää →050Tapauksen aikajanan laatiminen
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.
Lue lisää →051CMS-ydintiedostojen vertailu alkuperäiseen
Vertailu puhtaaseen alkuperäiseen paljastaa jokaisen muuttuneen tiedoston riippumatta siitä, tunteeko skanneri sen. Näin rakennatte vertailun WordPressille, Composer-projekteille ja järjestelmäpaketeille.
Lue lisää →052Tietokannan tarkistus sisäänajetun koodin varalta
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.
Lue lisää →053Verkkosivustojen haittaohjelmaskannerit: mitä ne löytävät ja mitä eivät
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ä.
Lue lisää →Koventaminen ja asetukset
20 artikkelia
PHP-FPM-poolien eristys sivustoittain
Oma pooli jokaiselle sivustolle on alku, ei loppu. Näin tarkistatte nykyiset poolit ja koventatte socketit, päätteet, tilasivut, resurssit ja lokit.
Lue lisää →055memory_limit-asetuksen määrittäminen oikein
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.
Lue lisää →056post_max_size- ja upload_max_filesize-rajojen järkevä asettaminen
Upload-rajat vaikuttavat kolmessa paikassa: verkkopalvelimessa, PHP:ssä ja sovelluksessa. Näin asetatte arvot yhteensopiviksi, myös php.netin PHP2Shellin siirtymäarvojen kanssa.
Lue lisää →057session.upload_progress pois käytöstä: oikein ja pysyvästi
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.
Lue lisää →058expose_php ja Server-otsakkeet: versiotietojen piilotus
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.
Lue lisää →059display_errors off: virhetulosteiden poisto tuotannosta
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ä.
Lue lisää →060php_admin_value: asetusten lukitseminen ylikirjoitukselta
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.
Lue lisää →061Muistirajojen asettaminen systemd:llä ja cgroupeilla
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.
Lue lisää →062Nginxin turvallinen asetus PHP:lle
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.
Lue lisää →063Apachen turvallinen asetus PHP:lle
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.
Lue lisää →064PHP:n suorituksen kielto upload-kansioissa
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.
Lue lisää →065Upload-pyyntöjen suodatus reunalla: mahdollisuudet ja riskit
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.
Lue lisää →066ModSecurityn ja OWASP Core Rule Setin käyttöönotto
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.
Lue lisää →067Fail2banin käyttöönotto verkkopalvelimille
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.
Lue lisää →068Palomuuri verkkopalvelimelle: avatkaa vain tarvittavat portit
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.
Lue lisää →069Automaattiset tietoturvapäivitykset Linux-palvelimilla
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.
Lue lisää →070Vähimmän oikeuden periaate: verkkopalvelinkäyttäjän oikeudet
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.
Lue lisää →071Hallintaosien suojaus IP-osoitteella, VPN:llä tai lisäsuojalla
Miksi verkkosivuston hallintaosan ei tarvitse olla koko maailman saavutettavissa ja miten suojaatte sen IP-rajauksella, VPN:llä tai ennakkotunnistautumisella lukitsematta itseänne ulos.
Lue lisää →072TLS ja HTTPS oikein asetettuna
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.
Lue lisää →073CIS-benchmarkit ja BSI-moduulit verkkopalvelimille
Mitä koventamisstandardeja Linux-verkkopalvelimille on, miten CIS-benchmarkit ja IT-Grundschutz-moduulit eroavat toisistaan ja miten niistä tehdään tarkistettava vaatimus PHP-palvelimillenne.
Lue lisää →Turvallinen kehitys
16 artikkelia
Salasanojen turvallinen tallennus PHP:ssä: password_hashin oikea käyttö
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.
Lue lisää →075CSRF-suoja PHP-sovelluksissa
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.
Lue lisää →076Syötteiden validointi ja suodatus PHP:ssä filter_varilla
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.
Lue lisää →077Command Injectionin estäminen PHP:ssä
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.
Lue lisää →078Server-Side Request Forgeryn (SSRF) estäminen PHP:ssä
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.
Lue lisää →079XML External Entitiesin (XXE) estäminen PHP:ssä
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.
Lue lisää →080Type Juggling PHP:ssä: löyhät vertailut tietoturvariskinä
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.
Lue lisää →081Turvalliset satunnaisluvut ja tokenit PHP:ssä random_bytesilla
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.
Lue lisää →082Tunnusten ja .env-tiedostojen oikea suojaus
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.
Lue lisää →083Julkinen .git-kansio: aliarvioitu tietovuoto
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.
Lue lisää →084Varmuuskopiotiedostot verkkojuuressa: .zip, .sql ja .bak
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.
Lue lisää →085phpinfo()-tiedostot: miksi niiden on poistuttava
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.
Lue lisää →086Riippuvuudet ajan tasalla: Composer, npm ja laajennukset
Projekti koostuu kolmesta pakettimaailmasta: Composer, npm ja CMS-laajennukset. Miten pidätte kaikki kolme ajan tasalla kiinteällä rytmillä, selkeällä vastuulla ja testeillä.
Lue lisää →087Tietoturvakoodikatselmointi PHP-projekteille
Miten tiimit käyvät omaa PHP-koodiaan läpi kohdennetusti tietoturva-aukkojen varalta: katselmointityypit, kriittiset funktiot, järkevät työkalut ja tarkistuslista.
Lue lisää →088Turvallinen lokitus: virheiden kirjaus ilman tietovuotoa
Lokit auttavat vianhaussa ja forensiikassa, mutta niistä tulee helposti itse tietovuoto. Mitä PHP-sovellusten tulisi kirjata, mitä ei koskaan ja miten lokit suojataan.
Lue lisää →089REST-API:iden suojaus PHP:ssä
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.
Lue lisää →Johtaminen ja lainsäädäntö
14 artikkelia
IT-palveluntarjoajasopimukset: tietoturvavelvoitteet selkeiksi
PHP2Shell osoitti, kuinka usein on epäselvää, kenen pitää päivittää. Mitkä tietoturvavelvoitteet kuuluvat sopimuksiin toimiston, hosting-palveluntarjoajan ja IT-palveluntarjoajan kanssa.
Lue lisää →091Henkilötietojen käsittely, kun palveluntarjoajat pääsevät palvelimelle
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.
Lue lisää →092Haavoittuvuuksien hallinta pk-yrityksessä
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.
Lue lisää →093Tietäkää, mitä käytössä on: kaikkien verkkosivustojen ja palvelinten luettelo
PHP2Shellin kohdalla monet eivät kompastuneet korjaukseen vaan kysymykseen, missä PHP ylipäätään toimii. Näin rakennatte luettelon kaikista verkkosivustoista ja palvelimista.
Lue lisää →094Päivitysten hallinta prosessina palokunta-toiminnan sijaan
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.
Lue lisää →095Hätäyhteystiedot: kenelle ilmoitetaan ja milloin?
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.
Lue lisää →096Mitä murrettu palvelin maksaa: kuluerät
Murrettu verkkopalvelin aiheuttaa enemmän kuluja kuin korjaus. Mitä kulueriä syntyy ja miten perustelette ennaltaehkäisyn budjetin omilla luvuillanne.
Lue lisää →097Asiakkaiden tiedottaminen häiriön jälkeen
Velvollisuus tai vapaaehtoinen: miten päätätte häiriön jälkeen, ketä tiedotatte, mitkä kanavat ovat turvallisia ja miten asiakaspalvelunne on valmisteltu.
Lue lisää →098Verkon toimitusketju: toimisto, hosting-yritys, lisäosien toimittaja
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.
Lue lisää →099Tietoturvatietoisuus ylläpitäjille ja toimittajille: tietoturvatietoisuus verkkotiimissä
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.
Lue lisää →100Hätäharjoitus pöydän ääressä: verkkopalvelinhäiriön läpikäynti
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.
Lue lisää →101ISO 27001 ja TISAX: mitä verkkopalvelimet koskee
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.
Lue lisää →102VdS 10000: tietoturva pienille ja keskisuurille yrityksille
VdS 10000 on kevyt kehys keskisuurten yritysten tietoturvalle. Mitä se vaatii, mikä tuli uutena 2025 ja mitä se tarkoittaa verkkosivustoille ja verkkopalvelimille.
Lue lisää →103Lessons Learned: paremmaksi häiriön jälkeen
Häiriön jälkeen on ennen seuraavaa. Jäsennelty jälkipuinti ilman syyllistämistä muuttaa huonon viikon mitattavaksi edistykseksi.
Lue lisää →Päätöksenteon tuki
10 artikkelia
Päivitys, sulkeminen vai odottaminen? Päätöksentekoapu PHP-aukossa
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.
Lue lisää →105WAF vai päivitys: miksi tarvitsette molempia
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.
Lue lisää →106Palvelimen uudelleenasennus vai puhdistus? Päätös tartunnan jälkeen
Tunkeutumisen jälkeen on kaksi tietä: palvelin puhdistetaan tai rakennetaan uudelleen. Mitkä perusteet ratkaisevat, ja miksi järjestys on tärkeämpi kuin valinta.
Lue lisää →107Korjaatteko itse vai kutsutteko palveluntarjoajan? Rehellinen punninta
Kaikki tietoturvatilanteet eivät vaadi ulkopuolista apua. Näillä perusteilla ja lyhyellä itsearvioinnilla ratkaisette, selviääkö tiiminne PHP2Shellistä yksin vai tarvitsetteko tukea.
Lue lisää →108IT-tietoturvapalveluntarjoajan valinta: 12 kysymystä ennen toimeksiantoa
Hyvän tietoturvapalveluntarjoajan löytäminen aikapaineessa on vaikeaa. Nämä kaksitoista kysymystä auttavat vertailemaan tarjouksia asiallisesti lankeamatta markkinointilupauksiin.
Lue lisää →109Hallinnoitu hosting vai oma palvelin? Tietoturvavertailu
PHP2Shell oli stressitesti jokaiselle toimintamallille. Vertailu näyttää, milloin hallinnoitu hosting on turvallisempi, milloin oma palvelin ja mitkä sekamuodot ovat osoittautuneet hyviksi.
Lue lisää →110PHP-päivitys vai backport? Päätös vanhoille järjestelmille
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.
Lue lisää →111Vaihdetaanko CMS hakkeroinnin jälkeen? Milloin se auttaa ja milloin ei
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.
Lue lisää →112Staattiset verkkosivustot: vähemmän PHP:tä, vähemmän hyökkäyspinta-alaa
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.
Lue lisää →113Tunkeutumistesti, Bug Bounty vai haavoittuvuusskannaus? Valitkaa sopiva tarkastusmenetelmä
Skannaus, tunkeutumistesti ja Bug Bounty tarkastavat verkkosivustoja aivan eri tavoin. Mitä kukin menetelmä tekee, missä se epäonnistuu ja mikä järjestys sopii yrityksellenne.
Lue lisää →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.