113 artiklit

Blogi: PHP2Shell, serveri turvalisus ja hädaabi

Olukorra hinnang, juhendid administraatoritele ja otsustusabi juhtkonnale. Teemade kaupa sorteeritud, iga artikkel allikatega.

WhatsApp-hädaabi

Olukord ja hinnang Veebimajutus ja distributsioonid Tuvastamine ja forensika Karastamine ja seadistus Turvaline arendus Juhtimine ja õigus Otsustusabi

Olukord ja hinnang

17 artiklit

001

PHP2Shell: mis on tõendatud ja mis mitte

PHP2Shelli faktikontroll: millised väited pärinevad esmaallikatest, millised meediaaruannetest ja millised väited ei pea paika.

Loe edasi →002

Miks sai PHP turvaauk enne paika teatavaks

Aruannete kohaselt said PHP2Shelli üksikasjad avalikuks enne embargo lõppu. Selgitame käiku ja seda, mida see tähendab teie paikamise planeerimisele.

Loe edasi →003

Ametiasutused võtavad veebisaidid võrgust maha: mida ettevõtted sellest õpivad

Mainz, Hessen liidumaa valitsus ja BKA võtsid veebisaidid ennetavalt võrgust maha. Mida ettevõtted sellest oma otsuse jaoks õppida saavad.

Loe edasi →004

BSI hoiatustase oranž: mida hinnang tähendab

BSI hindab PHP2Shelli tasemele 3 / oranž. Mida skaala ütleb ja mida mitte ning kuidas ettevõtted hinnangu otsusteks tõlgivad.

Loe edasi →005

Mida CERT-EU ja CERT-Bund PHP2Shelli kohta soovitavad

Ametlikud asutused on ühel meelel: paikage kohe, muidu isoleerige. Võrdleme soovitusi ja näitame, kuidas isoleerimine praktikas välja näeb.

Loe edasi →006

Cloudflare'i kaitsereeglid PHP2Shelli vastu: mida need annavad ja mida mitte

Cloudflare võttis kaitsereeglid PHP2Shelli vastu kasutusele vara. Miks see aitab, miks see PHP uuendust siiski ei asenda ja milliseid sätteid peaksite kontrollima.

Loe edasi →007

22,6 miljonit avalikult kättesaadavat instantsi: arvude õige hindamine

Unit 42, CybelAngel ja teised nimetavad PHP2Shelli kohta väga erinevaid arve. Selgitame, mida loendati ja milline arv teie jaoks tegelikult loeb.

Loe edasi →008

PHP2Shell viie minutiga: ülevaade juhtkonnale

PHP turvaauk PHP2Shell ühel leheküljel otsustajatele: olukord, risk, viis küsimust IT-le ja tänased otsused.

Loe edasi →009

PHP turvaauk lihtsalt selgitatud

PHP2Shell mittetehnikutele: igapäevaste võrdluste, väikese sõnastiku ja kolme tüüpilise lähteolukorraga, mida veebisaidi käitajana tegema peaksite.

Loe edasi →010

PHP2Shell: 15 veebimajutuse klientide küsimust

Teie veebisait asub veebimajutajal ja soovite teada, mida PHP2Shelli puhul ise tegema peate? Siin on 15 sagedasemat küsimust lühivastustega.

Loe edasi →011

Miks WordPressi uuendus PHP2Shelli vastu ei aita

Paljud käitajad uuendasid pärast pealkirju WordPressi ja tunnevad end kindlalt. Miks see PHP2Shelli puhul tühja läheb ja mis selle asemel loeb.

Loe edasi →012

PHP2Shell ja Log4Shell: mis on turvaaukudel ühist

Paljud võrdlevad PHP2Shelli 2021. aasta Log4Shelliga. Mida võrdlus kannab, kus see lonkab ja millised toonased õppetunnid täna aitavad.

Loe edasi →013

Massiskaneerimine paigamata PHP järele: nii käivad automatiseeritud rünnakud

Pärast PHP2Shelli otsivad ründajad internetist automatiseeritult haavatavaid servereid. Kuidas see käib, miks suurus rolli ei mängi ja mis kaitseb.

Loe edasi →014

Paiga ja rünnaku vaheline ajaaken

PHP2Shelli puhul oli rünnakukatseid juba enne paika. Selgitame ajaakna faase, kuidas oma akent mõõta ja kuidas seda lühendada.

Loe edasi →015

Pärast PHP2Shelli: miks täiendavad teated on tõenäolised

PHP2Shell ei ole 21. oktoobri paigaga lõppenud. Miks järgnevad teated on oodata ja kuidas oma meeskonda selleks ette valmistada.

Loe edasi →016

PHP2Shell: esimese nädala olukorrapilt

Nädal pärast esimest täheldatud rünnakukatset: seis paikade, ametiasutuste hoiatuste, rünnakute ja väljalülitamiste kohta, selgelt allikate järgi eraldatud.

Loe edasi →017

Ohtlikud valenõuanded PHP2Shelli kohta, mis praegu levivad

Küpsiste blokeerimine, veateadete peitmine, ainult CMS-i uuendamine: üheksa PHP2Shelli nõuannet, mis loovad vale kindlustunde, ja see, mis tegelikult loeb.

Loe edasi →

Veebimajutus ja distributsioonid

18 artiklit

018

PHP versiooni muutmine veebimajutuse kliendialas

Kuidas veebimajutaja kliendialas PHP versiooni ümber lülitada, millise versiooni valida ja mida enne ning pärast kontrollida.

Loe edasi →019

Debian ja Ubuntu: kas minu PHP pakett on paigatud?

Millised PHP paketid Debian ja Ubuntu on PHP2Shelli vastu parandanud, kuidas paigaldatud seisu täpselt võrrelda ja mille taha tõend ebaõnnestub.

Loe edasi →020

RHEL, AlmaLinux ja Rocky Linux: PHP paiga kontroll

Mida Red Hat on PHP2Shelli kohta avaldanud, kuidas RHEL-is ja selle järeltuletistes paketiseisu tõendada ning miks pelgalt uuesti laadimisest ei piisa.

Loe edasi →021

Hoidla sury.org: PHP paketid kolmandast allikast

Paljud Debiani ja Ubuntu serverid hangivad PHP-d sury hoidlast. Mida see tähendab uuenduste, tõendite ja vanade PHP versioonide jaoks pärast PHP2Shelli.

Loe edasi →022

Remi hoidla: PHP ajakohasena hoidmine RHEL-süsteemides

Remi tarnib ajakohaseid PHP versioone RHEL-i perekonnale, moodulina või paralleelselt paigaldatavana. Nii kontrollite seisu pärast PHP2Shelli ja väldite unustatud harusid.

Loe edasi →023

Miks php -v näitab pärast uuendust sama numbrit

Uuendus läks läbi, kuid php -v teatab vana versiooni. Enamasti on see backport ja mitte viga. Nii eristate kahjutut päris probleemidest.

Loe edasi →024

CVE-numbrite tõendamine paketi muudatuslogis

Kes peab PHP paiga tõendama juhtkonnale, auditeerijatele või kindlustajatele, vajab enamat kui versiooninumbrit. Nii saab muudatuslogi kirjest tõend.

Loe edasi →025

Veebimajutaja vahetus pärast turvaintsidenti: mida jälgida?

Pärast intsidenti on soov uue veebimajutaja järele mõistetav. Et ründaja kaasa ei koliks, loevad järjekord ja valik.

Loe edasi →026

Mitu PHP versiooni ühes serveris: paigake igaüks eraldi

Paljudes serverites töötavad kõrvuti kolm, neli või rohkem PHP paigaldust. Pärast PHP2Shelli tuleb iga üks leida, uuendada ja taaskäivitada.

Loe edasi →027

Vanade PHP versioonide väljalülitamine majutuspaneelis

PHP2Shell on hea põhjus vanadest PHP versioonidest lahti saada. Toimige kolmes etapis, et ükski veebisait ega cron-töö märkamatult ei katkeks.

Loe edasi →028

Plesk: PHP-handlerite mõistmine (FPM, FastCGI, Apache moodul)

Millist PHP-handlerit Plesk veebisaidi jaoks kasutab, otsustab eraldatuse, seadistuse ja riski. Võrdlus PHP2Shelli silmas pidades.

Loe edasi →029

CloudLinux ja alt-php: mida peaksid majutuskliendid teadma

CloudLinuxi serverites töötavad veebisaidid sageli oma alt-php pakettidega. Iga selline versioon vajab oma paika ja selle saab paigaldada ainult serveri haldaja.

Loe edasi →030

PHP NAS-is, tulemüürides ja seadmetes: unustatud süsteemid

PHP-d ei kasuta ainult veebiserverid. Mõjutatud võivad olla ka NAS-süsteemid, tulemüürid ja veebiliidesega eriseadmed. Paigata saab seal enamasti ainult tootja, kättesaadavuse reguleerite ise.

Loe edasi →031

PHP pilve- ja PaaS-pakkujatel: kes paikab käituskeskkonna?

Platvormiteenustel sõltub PHP paik töömudelist. Otsustav on käituskeskkond, mis tegelikult vastab, mitte kohalik keskkond ega rakenduse kood.

Loe edasi →032

Ametlikud PHP Dockeri pildid: sildid, digestid ja uuesti ehitamine

Ametliku PHP pildi silt on osuti, mis liigub ajaga uutele seisudele. Kes teab, mida tähendavad silt, variant ja digest, valib õige pildi ja saab paigatud seisu tõendada.

Loe edasi →033

CI/CD: PHP piltide automaatne uuesti ehitamine

Pilt aegub ka ilma koodimuudatuseta. Ajastatud ehituste, versioonikontrolli ja digesti järgi juurutusega jõuavad PHP paigad usaldusväärselt tootmisse.

Loe edasi →034

Vanade PHP versioonide pikaajaline tugi: võimalused ja piirid

Kes ei saa PHP 8.1-lt või vanemalt kohe üle minna, leiab pikaajalist tuge distributsioonidelt, kolmandatelt pakkujatelt ja kommertsteenustelt. Mida need teed pakuvad, mida vajate kirjalikult ja kus on piirid.

Loe edasi →035

PHP uuendamine Windowsis

Windowsis ei ole automaatset PHP uuendust. Kes valib õige variandi, kontrollib allalaadimist ja taaskäivitab kõik protsessid, viib PHP2Shelli paiga puhtalt igasse arvutisse.

Loe edasi →

Tuvastamine ja forensika

18 artiklit

036

Hoiatusmärk: veebiserver käivitab shelli

Kui PHP-FPM-i või veebiserveri protsess käivitab shelli, on see üks tugevamaid sissemurdmise hoiatusmärke. Nii kontrollite protsessipuud, hindate erandeid ja jälgite mustrit püsivalt.

Loe edasi →037

Kahtlaste protsesside leidmine Linuxi serverites

Kahjulikud protsessid maskeerivad end kahjutute nimedega, töötavad ajutistest kaustadest või kustutatud failidest. Mõne lugeva käsuga leiate kõrvalekalded ja hindate neid.

Loe edasi →038

Peidetud cron-tööde tuvastamine tagauksena

Ründajad kasutavad ajastatud ülesandeid, et pärast puhastamist tagasi tulla. Nii kontrollite crontabe, cron-katalooge, systemd taimereid ja at-ülesandeid täielikult ning tuvastate kahtlased kirjed.

Loe edasi →039

Veebiserveris hiljuti muudetud failide leidmine

Pärast võimalikku sissemurdmist loeb, mis serveris on muutunud. Nii otsite ajaakna järgi, kasutate mtime'i ja ctime'i õigesti ning võrdlete pakettide, Giti ja varukoopiatega.

Loe edasi →040

PHP-failid üleslaadimiskaustas: leiukohtade õige tõlgendamine

PHP-fail üleslaadimiskaustas on peaaegu alati häirekell, kuid mitte iga fail ei ole kahjulik kood. Nii hindate leidu jälgi hävitamata ja selgitate, kas keegi on seda kutsunud.

Loe edasi →041

Hägustatud PHP-koodi tuvastamine

Loetamatu PHP kood koos eval ja base64_decode'iga on klassikaline märk sissetoodud kahjulikust koodist. Milliseid mustreid otsida, kuidas neid ohutult leida ja millal hägustamine on legitiimne.

Loe edasi →042

Serveri väljaminevate ühenduste kontroll

Veebiserver vastab eelkõige päringutele. Kui ta ise loob ühendusi tundmatutesse sihtkohtadesse, võib see tähendada ründajate juhtimist või andmevoolu. Nii kontrollite ja piirate väljaminevat liiklust.

Loe edasi →043

Võõraste administraatorikontode leidmine CMS-is ja serveris

Tundmatu administraator on sageli kõige lihtsam tagauks. Nii otsite võõraid kontosid tasand tasandi haaval, ka neid, mida liides peidab.

Loe edasi →044

Tundmatute SSH-võtmete leidmine ja eemaldamine

Sissetoodud SSH-võti avab ründajatele ukse ka siis, kui kõik paroolid on muudetud. Nii leiate iga authorized_keys-faili ja kontrollite iga kirjet.

Loe edasi →045

Krüptokaevur veebiserveris: tunnused ja tegutsemine

Püsivalt täis CPU, ilma et külastajaid oleks rohkem: see võib olla krüptokaevur. Nii kontrollite koormust, leiate protsessi ja selle taaskäivitusmehhanismid ning tegutsete korrapäraselt.

Loe edasi →046

Server saadab spämmi: põhjuste leidmine

Kättetoimetamata kirjad, mustad nimekirjad, kaebused: kui oma server saadab spämmi, on selle taga enamasti skript või kaaperdatud postkast. Nii leiate allika.

Loe edasi →047

SEO-rämps ja võõrad lehed Google'i indeksis

Äkki edetabelis ravimite või margikaupade lehed teie domeeni all. Nii selgitate välja, kust SEO-rämps tuleb, ja saate selle indeksist taas välja.

Loe edasi →048

Veebisait suunab külastajad võõrastele lehtedele

Külastajad jõuavad loosimismängudesse või kahtlastesse poodidesse, kuid ise te midagi ei näe? Nii leiate kihi, kus ümbersuunamine peidus on, ja kõrvaldate selle.

Loe edasi →049

Kindlustage tõendid enne serveri uuesti seadistamist

Uuestiehitus kõrvaldab ründaja, kuid ka kõik jäljed. Kes investeerib enne tunni tõendite kindlustamisse, oskab hiljem öelda, mis juhtus.

Loe edasi →050

Intsidendi ajajoone koostamine

Millal ründaja tuli, mida ta tegi, millal see märgati? Korralik ajajoon vastab neile küsimustele ning on teavituste, kindlustuse ja aruande alus.

Loe edasi →051

CMS-i tuumafailide võrdlemine originaaliga

Võrdlus puhta originaaliga näitab iga muudetud faili, sõltumata sellest, kas skanner seda tunneb. Nii ehitate võrdluse üles WordPressi, Composeri projektide ja süsteemipakettide jaoks.

Loe edasi →052

Andmebaasi kontrollimine sissetoodud koodi suhtes

Kes kontrollib ainult faile, jätab poole märkamata. Nii otsite andmebaasi sisust, sätetest, trigeritest ja kontodest sissetoodud koodi, lugevalt ja koopial.

Loe edasi →053

Veebisaidi pahavaraskannerid: mida nad leiavad ja mida mitte

Skanner ei teata midagi, seega on kõik korras? Mitte tingimata. Millised veebisaidi skannerite liigid on olemas, mida igaüks näeb ja mida põhimõtteliselt näha ei saa.

Loe edasi →

Karastamine ja seadistus

20 artiklit

054

PHP-FPM poolide eraldamine veebisaitide kaupa

Oma pool iga veebisaidi jaoks on algus, mitte lõpp. Nii kontrollite olemasolevaid poole ning karastate sokleid, laiendeid, olekulehti, ressursse ja logisid.

Loe edasi →055

memory_limit õige seadistamine

memory_limit piirab mälu PHP päringu kohta. Pärast PHP2Shelli soovitab php.net ajutiselt vastupidist. Mis kehtib tavatöös, üleminekul ja pärast uuendust.

Loe edasi →056

post_max_size ja upload_max_filesize mõistlik piiramine

Üleslaadimispiirid mõjuvad kolmes kohas: veebiserveris, PHP-s ja rakenduses. Nii seate väärtused kooskõlla, ka php.net'i PHP2Shelli üleminekuväärtustega.

Loe edasi →057

session.upload_progress väljalülitamine: õigesti ja püsivalt

Abinõu CVE-2026-115560 vastu ja üks PHP2Shelli üleminekumeetmetest on kiiresti seatud. Et see püsiks, peab see olema õiges kohas, lukustatud ja pärast iga uuendust uuesti kontrollitud.

Loe edasi →058

expose_php ja Server-päised: versiooniandmete peitmine

PHP, Nginx ja Apache nimetavad oma versiooninumbrit vaikimisi igas vastuses. See ei kaitse rünnakute eest, kuid annab skanneritele mugava tabamusloendi. Nii lülitate selle välja ja säilitate ülevaate siiski.

Loe edasi →059

display_errors off: veaväljundi väljalülitamine tootmiskeskkonnas

Nähtavad PHP veateated reedavad teid, andmebaasinimesid ja versioone. Nii lülitate need välja PHP-s, raamistikus ja veebiserveris, vigu silmist kaotamata.

Loe edasi →060

php_admin_value: sätete kaitsmine ülekirjutamise eest

Turvasäte on vähe väärt, kui rakendus muudab selle ühe koodireaga tagasi. Käskudega php_admin_value ja php_admin_flag määrate väärtused PHP-FPM-ile ja Apache'ile siduvalt.

Loe edasi →061

Mälupiiride seadmine systemd ja cgroup'idega

php.net soovitab PHP2Shelli üleminekumeetmena memory_limit=-1 ja PHP-st väljaspool asuvat mälupiiri. Nii seate selle piiri systemd ja cgroup'idega, ilma et üks töölisprotsess kogu teenuse kaasa tõmbaks.

Loe edasi →062

Nginx PHP jaoks turvaliselt seadistamine

Enamik PHP Nginx-seadistuste nõrkustest ei peitu Nginxis, vaid mõnes reas PHP-location'is. Nii seadistate üleandmise PHP-FPM-ile nii, et käivitatakse ainult soovitud skriptid.

Loe edasi →063

Apache PHP jaoks turvaliselt seadistamine

Apache on paindlik ja just see teeb ta konfiguratsioonivigade suhtes haavatavaks. Nii ühendate PHP PHP-FPM-i kaudu, sulgete .htaccess'i tagauksena ja seate olulisemad põhisuvandid turvaliselt.

Loe edasi →064

PHP käivitamise keelamine üleslaadimiskaustades

Veebishell vajab kahte asja: kausta, kuhu seda saab kirjutada, ja serverit, mis seda käivitab. Nii võtate talt teise, igas kirjutatavas kaustas, mitte ainult uploads'is.

Loe edasi →065

Üleslaadimispäringute filtreerimine serveri serval: võimalused ja riskid

Erialaautorid pakuvad, et blokeerida proxys üleslaadimispäringud väljaspool tegelikke üleslaadimisteid, kuni PHP on paigatud. See võib aidata, kuid ka vorme ja tellimusi halvata. Nii toimite kontrollitult.

Loe edasi →066

ModSecurity ja OWASP Core Rule Set'i kasutamine

Oma Web Application Firewall ModSecurity ja OWASP Core Rule Set'iga on tasuta ja võimas, kuid mitte iseenesest toimiv. Nii valite mootori, alustate tõrgeteta ja häälestate reeglid.

Loe edasi →067

Fail2ban veebiserverite jaoks seadistamine

Fail2ban blokeerib aadressid, mis logides korduvalt silma jäävad. Veebiserverite jaoks on kaasas valmis filtrid ja mõne reaga lisanduvad oma filtrid. Nii seadistate selle, ennast ega oma kliente välja lukustamata.

Loe edasi →068

Veebiserveri tulemüür: avage ainult vajalikud pordid

Veebiserver vajab väljapoole tavaliselt vaid kahte porti. Sellegipoolest kuulavad paljudes serverites internetis andmebaasid, PHP-FPM või haldusliidesed. Nii leiate avatud teenused ja sulgete, mida ei vajata.

Loe edasi →069

Automaatsed turvauuendused Linuxi serverites

Aruannete järgi tarnisid distributsioonid PHP tagasiportimisi osaliselt juba 21. oktoobril 2026, paikade päeval. Kes kasutab automaatseid turvauuendusi, sai need kiiresti serverisse. Et need ka mõjuksid, on vaja taaskäivitusi, kolmandate osapoolte allikaid ja kontrolli.

Loe edasi →070

Vähima õiguse põhimõte: veebiserveri kasutaja õigused

Sissetoodud kood töötab veebiserveri kasutaja õigustega. See, mida see konto tohib, määrab, kui kaugele ründaja jõuab. Nii piirate shelli, sudo, croni, andmebaasi ja failisüsteemi vajalikuga.

Loe edasi →071

Admin-alade varjamine IP, VPN-i või lisakaitsega

Miks veebisaidi taustasüsteem ei pea olema kogu maailmale kättesaadav ja kuidas seda IP-lubamise, VPN-i või eelneva sisselogimisega varjate, ilma end ise välja lukustamata.

Loe edasi →072

TLS-i ja HTTPS-i õige seadistamine

Milliseid TLS-versioone ja šifrikomplekte peaks veebiserver täna pakkuma, millele soovitused tuginevad ning kuidas kontrollida Nginxi, Apache'it ja PHP väljaminevaid ühendusi.

Loe edasi →073

CIS-võrdlusalused ja BSI moodulid veebiserveritele

Millised kõvendusstandardid Linuxi veebiserveritele on olemas, kuidas CIS-võrdlusalused ja IT-Grundschutz moodulid erinevad ja kuidas neist saab kontrollitav nõue teie PHP-serveritele.

Loe edasi →

Turvaline arendus

16 artiklit

074

Paroolide turvaline salvestamine PHP-s: password_hash õigesti kasutada

Kuidas arendajad salvestavad PHP-s paroole funktsioonidega password_hash ja password_verify, valivad sobiva meetodi ning asendavad vanad MD5- või SHA-1-räsid ilma kõigi kasutajate paroolide lähtestamiseta.

Loe edasi →075

CSRF-kaitse PHP-rakendustes

Kuidas arendajad hoiavad PHP-rakendustes ära Cross-Site Request Forgery: tokenid igale muutvale päringule, päritolu kontroll päises ja SameSite-küpsised lisakihina.

Loe edasi →076

Sisendi valideerimine ja filtreerimine PHP-s funktsiooniga filter_var

Kuidas arendajad kontrollivad sisendit PHP-s funktsioonidega filter_var, filter_input_array ja lubatud väärtuste nimekirjadega, millised filtrid on vananenud ja miks valideerimine ei asenda Prepared Statements'e ega väljundi kodeerimist.

Loe edasi →077

Command Injection'i vältimine PHP-s

Kuidas arendajad väldivad PHP-s Command Injection'i: süsteemikäskude asendamine PHP funktsioonidega, proc_open kasutamine ilma shellita, argumentide kontroll ja ohtlike kohtade leidmine olemasolevas koodis.

Loe edasi →078

Server-Side Request Forgery (SSRF) vältimine PHP-s

Kuidas arendajad takistavad, et PHP-rakendus päriks võõraste nimel sisesüsteeme: lubatud väärtuste nimekirjad, protokollipiirang, lahendatud aadressi kontroll ja piirid võrgus.

Loe edasi →079

XML External Entities (XXE) vältimine PHP-s

Kuidas arendajad töötlevad XML-i PHP-s turvaliselt: libxml-i vaikekäitumine, riskantsed valikud nagu LIBXML_NOENT, kaitse Entity-Loaderi ja LIBXML_NO_XXE-ga ning tüüpilised peidetud XML-sisendid.

Loe edasi →080

Type Juggling PHP-s: lõdvad võrdlused turvariskina

Miks võivad lõdvad võrdlused märgiga == PHP-s viia turvaaukudeni, mida PHP 8.0 muutis ja kuidas kirjutada võrdlused sisselogimistes, tokenites ja õigustes töökindlaks.

Loe edasi →081

Turvalised juhuarvud ja tokenid PHP-s funktsiooniga random_bytes

Kuidas arendajad loovad PHP-s tokeneid parooli lähtestamise linkide, API-võtmete ja ühekordsete koodide jaoks: krüptograafiliselt turvalised allikad, piisav pikkus, salvestamine räsina ja piiratud kehtivus.

Loe edasi →082

Ligipääsuandmete ja .env-failide õige kaitsmine

Kuidas kaitsta PHP-projektides andmebaasiparoole, API-võtmeid ja muid saladusi: .env-failid väljaspool veebijuurkataloogi, blokeeringud veebiserveris, kitsad õigused ja korrapärane vahetus pärast intsidenti.

Loe edasi →083

Avalik .git-kaust: alahinnatud andmeleke

Miks võib Giti kaudu välja veeretatud veebijuurkataloog avalikustada kogu lähtekoodi koos ajalooga, kuidas seda kontrollida, kohe blokeerida ja juurutus püsivalt ilma .git-kaustata üles ehitada.

Loe edasi →084

Varundusfailid veebijuurkataloogis: .zip, .sql ja .bak

Miks andmebaasitõmmised, arhiivid ja varukoopiad avalikus kataloogis kuuluvad sagedaseimate andmelekete hulka, kuidas neid leida, blokeerida ja selgitada, kas neid on päritud.

Loe edasi →085

phpinfo()-failid: miks need peavad kaduma

Pärast PHP2Shelli loovad paljud administraatorid kiiresti faili info.php. Miks sellised failid on andmeleke, kuidas neid leida ja millised kontrollteed on paremad.

Loe edasi →086

Sõltuvuste ajakohasena hoidmine: Composer, npm ja pistikprogrammid

Projekt koosneb kolmest paketimaailmast: Composer, npm ja CMS-i pistikprogrammid. Kuidas hoiate kõiki kolme ajakohasena kindla rütmi, selge vastutuse ja testidega.

Loe edasi →087

Turvalisuse koodiülevaatus PHP-projektidele

Kuidas meeskonnad vaatavad oma PHP-koodi sihipäraselt turvaaukude suhtes läbi: ülevaatuste liigid, kriitilised funktsioonid, mõistlikud tööriistad ja kontrollnimekiri.

Loe edasi →088

Turvaline logimine: vigade protokollimine ilma andmelekketa

Logid aitavad vigade otsimisel ja kriminalistikas, kuid muutuvad kiiresti ise andmelekkeks. Mida PHP-rakendused peaksid logima, mida mitte kunagi ja kuidas logisid kaitsta.

Loe edasi →089

REST-API-de kaitsmine PHP-s

Liidesed on sageli halvemini kaitstud kui nende ees olev veebisait. Olulisimad reeglid REST-API-dele PHP-s, alates objektiõigusest kuni päringute piiramiseni.

Loe edasi →

Juhtimine ja õigus

14 artiklit

090

IT-teenusepakkujate lepingud: turvakohustuste selge reguleerimine

PHP2Shell näitas, kui sageli on ebaselge, kes peab paikama. Millised turvakohustused kuuluvad lepingutesse agentuuri, hostingupakkuja ja IT-teenusepakkujaga.

Loe edasi →091

Volitatud töötlemine, kui teenusepakkujad serveritele ligi pääsevad

Kes laseb väliseid isikuid klientide andmetega serveritesse, vajab enamasti volitatud töötleja lepingut (AVV). Mida IKÜM art 28 nõuab ja kuidas korraldate ligipääsud hädaolukorras andmekaitsele vastavalt.

Loe edasi →092

Haavatavuste haldus keskmise suurusega ettevõttes

Ükski keskmise suurusega ettevõte ei jõua kõiki teateid kohe läbi töötada. Lihtne ring „registreerida, hinnata, otsustada, tõendada“ tagab, et oluline saab tehtud esimesena.

Loe edasi →093

Teadke, mis töötab: kõigi veebisaitide ja serverite inventar

PHP2Shelli puhul ei kukkunud paljud läbi paigaga, vaid küsimusega, kus PHP üldse töötab. Nii koostate kõigi veebisaitide ja serverite inventari.

Loe edasi →094

Paigahaldus protsessina, mitte tuletõrjena

Kes paigab ainult siis, kui põleb, kaotab hädaolukorras aega. Kuidas kindlate klasside, akende ja tõenditega paigahalduse protsess ühendab rutiini ja hädaolukorra.

Loe edasi →095

Hädaolukorra kontaktid: kes tuleb millal teavitada?

Hädaolukorras loeb, keda kätte saab ja millal. Kuidas koostada IT-hädaolukorra kontaktide nimekiri, kus on käivitajad, asendajad ja andmed, mida iga kõne vajab.

Loe edasi →096

Mida häkitud server maksab: kuluartiklid

Häkitud veebiserver põhjustab rohkem kulusid kui remont. Millised kuluartiklid tekivad ja kuidas põhjendada ennetuse eelarvet oma arvudega.

Loe edasi →097

Klientide teavitamine pärast intsidenti

Kohustus või vabatahtlik: kuidas otsustate pärast intsidenti, keda teavitada, millised kanalid on turvalised ja kuidas on teie klienditeenindus ette valmistatud.

Loe edasi →098

Veebi tarneahel: agentuur, veebimajutaja, pistikprogrammide pakkuja

PHP2Shell näitas, kui palju lülisid on paiga ja teie veebisaidi vahel. Kuidas tunda oma veebisaidi tarneahelat, seda kaitsta ja üksikute lülide katkestusi ära püüda.

Loe edasi →099

Turvateadlikkus administraatoritele ja toimetajatele: security awareness veebimeeskonnas

Kes veebisaite hooldab, otsustab iga päev turvalisuse üle, sageli ise märkamata. Nii koolitate administraatoreid ja toimetajaid rollipõhiselt ja ilma slaidivõitluseta.

Loe edasi →100

Hädaolukorra harjutus laua taga: veebiserveri intsidendi läbimäng

Laua taga harjutus võtab ühe pärastlõuna ja näitab, kas teie hädaolukorra plaan kannab. Siin on valmis stsenaarium PHP veebiserveri intsidendiks.

Loe edasi →101

ISO 27001 ja TISAX: mida veebiserverid puudutavad

Kes käitab ISO 27001 järgset ISMS-i või omab TISAX-märgist, peab veebiservereid kaasa mõtlema. Siin on, milliseid nõudeid need puudutavad ja millised tõendid loevad pärast PHP2Shelli.

Loe edasi →102

VdS 10000: infoturve väikestele ja keskmise suurusega ettevõtetele

VdS 10000 on kerge raamistik keskmise suurusega ettevõtete infoturbeks. Mida see nõuab, mis tuli 2025. aastal uut ja mida see tähendab veebisaitide ja veebiserverite jaoks.

Loe edasi →103

Lessons learned: pärast intsidenti paremaks saamine

Pärast intsidenti on enne järgmist. Struktureeritud järelarutelu ilma süüdistamiseta teeb halvast nädalast mõõdetava edasimineku.

Loe edasi →

Otsustusabi

10 artiklit

104

Kohene kontakt

Iga tund loeb. Kirjutage meile kohe.

Kirjeldage lühidalt süsteemi, PHP versiooni ja tähelepanekut. Võtame teiega ühendust, selgitame olukorra välja ja töötame kaugtööna, kuni intsident on lõpetatud ja dokumenteeritud.

WhatsApp-hädaabi Helista