Blog: PHP2Shell, szerverbiztonság és vészhelyzeti segítség
A helyzet értékelése, útmutatók rendszergazdáknak és döntéstámogatás a vezetőségnek. Téma szerint rendezve, minden cikk forrásokkal.
Helyzet és értékelés
17 cikk
PHP2Shell: mi igazolt és mi nem
Tényellenőrzés a PHP2Shellről: mely állítások származnak elsődleges forrásból, melyek médiabeszámolókból, és mely állítások nem állják meg a helyüket.
Tovább olvasom →002Miért vált ismertté a PHP-rés a javítás előtt
Beszámolók szerint a PHP2Shell részletei az embargó lejárta előtt nyilvánosságra kerültek. Elmagyarázzuk a lefolyást és azt, mit jelent ez az Ön javítástervezésére nézve.
Tovább olvasom →003A hatóságok leveszik weboldalaikat a hálózatról: mit tanulhatnak ebből a vállalatok
Mainz, a hesseni tartományi kormány és a BKA elővigyázatosságból levette weboldalait a hálózatról. Mit tanulhatnak ebből a vállalatok a saját döntésükhöz.
Tovább olvasom →004BSI narancs riasztási szint: mit jelent a besorolás
A BSI a PHP2Shellt 3 / narancs szintre sorolta. Mit mond ki a skála, mit nem, és hogyan fordíthatják le a vállalatok a besorolást döntésekre.
Tovább olvasom →005Mit javasol a CERT-EU és a CERT-Bund a PHP2Shellről
A hivatalos szervek egyetértenek: azonnal javítani, különben izolálni. Összehasonlítjuk az ajánlásokat, és megmutatjuk, hogyan néz ki gyakorlatban az izolálás.
Tovább olvasom →006Cloudflare védelmi szabályok a PHP2Shell ellen: mit tudnak és mit nem
A Cloudflare korán bevezetett védelmi szabályokat a PHP2Shell ellen. Miért segít ez, miért nem helyettesíti mégsem a PHP-frissítést, és mely beállításokat érdemes ellenőriznie.
Tovább olvasom →00722,6 millió kitett példány: így értelmezze helyesen a számokat
A Unit 42, a CybelAngel és mások nagyon különböző számokat közölnek a PHP2Shellről. Elmagyarázzuk, mit számoltak össze, és melyik szám számít valóban az Ön számára.
Tovább olvasom →008A PHP2Shell öt percben: tájékoztató az ügyvezetésnek
A PHP2Shell PHP biztonsági rés egy oldalon döntéshozóknak: helyzet, kockázat, öt kérdés az IT-hez és a mai döntések.
Tovább olvasom →009A PHP biztonsági rés egyszerűen elmagyarázva
A PHP2Shell nem szakembereknek: hétköznapi képekkel, egy kis szószedettel és három tipikus kiindulási helyzettel arról, mit tegyen weboldal-üzemeltetőként.
Tovább olvasom →010PHP2Shell: 15 kérdés tárhelyügyfelektől
A weboldala a tárhelyszolgáltatónál van, és tudni szeretné, mit kell Önnek magának tennie a PHP2Shell esetében? Itt a 15 leggyakoribb kérdés rövid válaszokkal.
Tovább olvasom →011Miért nem segít a WordPress-frissítés a PHP2Shell ellen
Sok üzemeltető a főcímek után frissítette a WordPresst, és biztonságban érzi magát. Miért megy ez a PHP2Shell esetében a levegőbe, és mi számít helyette.
Tovább olvasom →012PHP2Shell és Log4Shell: mi a közös a két résben
Sokan a 2021-es Log4Shellhez hasonlítják a PHP2Shellt. Mit bír az összehasonlítás, hol sántít, és mely akkori tanulságok segítenek ma.
Tovább olvasom →013Javítatlan PHP tömeges keresése: így zajlanak az automatizált támadások
A PHP2Shell után a támadók automatizáltan átfésülik az internetet sebezhető szerverek után. Hogyan zajlik ez, miért nem számít a méret, és mi véd.
Tovább olvasom →014A javítás és a támadás közötti időablak
A PHP2Shellnél már a javítás előtt voltak támadási kísérletek. Elmagyarázzuk az időablak fázisait, hogyan mérheti a sajátját, és hogyan rövidítheti le.
Tovább olvasom →015A PHP2Shell után: miért valószínűek további közlemények
A PHP2Shell nem zárult le az október 21-i javítással. Miért várhatók további közlemények, és hogyan hangolja rá a csapatát.
Tovább olvasom →016PHP2Shell: az első hét helyzetképe
Egy héttel az első megfigyelt támadási kísérlet után: a javítások, a hatósági figyelmeztetések, a támadások és a leállítások állása, forrásonként szétválasztva.
Tovább olvasom →017Veszélyes téves tippek a PHP2Shellről, amelyek éppen terjednek
Sütik blokkolása, hibaüzenetek elrejtése, csak a CMS frissítése: kilenc tanács a PHP2Shellről, amely hamis biztonságot kelt, és ami valóban számít.
Tovább olvasom →Tárhely és disztribúciók
18 cikk
PHP-verzió módosítása a tárhely ügyfélterületén
Hogyan állíthatja át a PHP-verziót a tárhelyszolgáltatója ügyfélterületén, melyik verziót válassza, és mit ellenőrizzen előtte és utána.
Tovább olvasom →019Debian és Ubuntu: javított a PHP-csomagom?
Mely PHP-csomagokat javította a Debian és az Ubuntu a PHP2Shell ellen, hogyan hasonlíthatja össze pontosan a telepített állapotot, és min bukik el az igazolás.
Tovább olvasom →020RHEL, AlmaLinux és Rocky Linux: PHP-javítás ellenőrzése
Mit tett közzé a Red Hat a PHP2Shellről, hogyan igazolja a csomagállapotot RHEL-en és az utánépítéseken, és miért nem elég az újratöltés.
Tovább olvasom →021A sury.org-tároló: PHP-csomagok harmadik féltől
Sok Debian- és Ubuntu-szerver a sury-tárolóból szerzi be a PHP-t. Mit jelent ez a frissítésekre, az igazolásokra és a régi PHP-verziókra a PHP2Shell után.
Tovább olvasom →022A Remi-tároló: PHP naprakészen tartása RHEL-rendszereken
A Remi aktuális PHP-verziókat szállít a RHEL-családhoz, modulként vagy párhuzamosan telepíthetően. Így ellenőrizze az állapotot a PHP2Shell után, és kerülje el az elfelejtett ágakat.
Tovább olvasom →023Miért mutatja a php -v a frissítés után ugyanazt a számot
A frissítés lefutott, de a php -v a régi verziót jelzi. Többnyire backportról van szó, nem hibáról. Így különbözteti meg az ártalmatlant a valódi problémáktól.
Tovább olvasom →024CVE-számok igazolása a csomag changelogjában
Aki a vezetőségnek, ellenőröknek vagy biztosítóknak be kell, hogy bizonyítson egy PHP-javítást, annál többre van szüksége egy verziószámnál. Így lesz a changelog-bejegyzésből igazolás.
Tovább olvasom →025Tárhelyszolgáltató cseréje biztonsági incidens után: mire figyeljen?
Incidens után érthető a vágy egy új tárhelyszolgáltatóra. Hogy a váltás ne vigye magával a támadót is, a sorrenden és a kiválasztáson múlik.
Tovább olvasom →026Több PHP-verzió egy szerveren: mindegyiket külön kell javítani
Sok szerveren három, négy vagy több PHP-telepítés fut egymás mellett. A PHP2Shell után mindegyiket meg kell találni, frissíteni és újraindítani.
Tovább olvasom →027Régi PHP-verziók kikapcsolása a tárhelypanelben
A PHP2Shell jó alkalom, hogy megszabaduljon a régi PHP-verzióktól. Így haladjon három fázisban, hogy egyetlen weboldal és egyetlen cron-feladat se essen ki észrevétlenül.
Tovább olvasom →028Plesk: a PHP-handlerek megértése (FPM, FastCGI, Apache-modul)
Hogy a Plesk melyik PHP-handlert használja egy weboldalhoz, az dönt az izolációról, a konfigurációról és a kockázatról. Összehasonlítás a PHP2Shell szemszögéből.
Tovább olvasom →029CloudLinux és alt-php: amit a tárhelyügyfeleknek tudniuk kell
A CloudLinux-szervereken a weboldalak gyakran saját alt-php csomagokkal futnak. Mindegyik verzió külön javítást igényel, és azt csak a szerver üzemeltetője telepítheti.
Tovább olvasom →030PHP NAS-on, tűzfalakon és appliance-eken: az elfelejtett rendszerek
Nem csak a webszerverek használnak PHP-t. A NAS-rendszerek, tűzfalak és webes felülettel rendelkező célberendezések is érintettek lehetnek. A javítást ott többnyire csak a gyártó adhatja, az elérhetőséget Ön szabályozza.
Tovább olvasom →031PHP felhő- és PaaS-szolgáltatóknál: ki javítja a futtatókörnyezetet?
A platformszolgáltatásokon a PHP-javítás az üzemeltetési modelltől függ. Az számít, melyik futtatókörnyezet szolgál ki ténylegesen, nem a helyi környezet vagy az alkalmazáskód.
Tovább olvasom →032Hivatalos PHP Docker image-ek: címkék, digestek és újraépítés
A hivatalos PHP image egy címkéje olyan mutató, amely idővel új állapotokra vándorol. Aki tudja, mit jelent a címke, a változat és a digest, a megfelelő image-et választja, és igazolni tudja a javítási állapotot.
Tovább olvasom →033CI/CD: PHP-image-ek automatikus újraépítése
Egy image kódmódosítás nélkül is elavul. Időzített buildekkel, verzióellenőrzéssel és digest szerinti kiadással a PHP-javítások megbízhatóan eljutnak az éles rendszerbe.
Tovább olvasom →034Hosszú távú támogatás régi PHP-verziókhoz: lehetőségek és korlátok
Aki nem tud azonnal váltani a PHP 8.1-ről vagy régebbiről, hosszú távú támogatást talál disztribúcióknál, harmadik feleknél és kereskedelmi szolgáltatásoknál. Mit nyújtanak ezek az utak, mi kell írásban, és hol vannak a korlátok.
Tovább olvasom →035PHP frissítése Windowson
Windowson nincs automatikus PHP-frissítés. Aki a megfelelő változatot választja, ellenőrzi a letöltést és újraindítja az összes folyamatot, tisztán juttatja el a PHP2Shell-javítást minden gépre.
Tovább olvasom →Felismerés és forenzika
18 cikk
Figyelmeztető jel: a webszerver shellt indít
Ha egy PHP-FPM- vagy webszerver-folyamat shellt indít, az a behatolás egyik legerősebb figyelmeztető jele. Így ellenőrizze a folyamatfát, értékelje a kivételeket, és figyelje tartósan a mintát.
Tovább olvasom →037Gyanús folyamatok keresése Linux-szervereken
A kártékony folyamatok ártalmatlan nevekkel álcázzák magukat, ideiglenes mappákból vagy törölt fájlokból futnak. Néhány olvasó paranccsal megtalálja és besorolja a feltűnő jeleket.
Tovább olvasom →038Rejtett cron-feladatok felismerése hátsó kapuként
A támadók ütemezett feladatokkal térnek vissza a tisztítás után. Így ellenőrzi teljesen a crontabokat, a cron-könyvtárakat, a systemd-időzítőket és az at-feladatokat, és ismeri fel a gyanús bejegyzéseket.
Tovább olvasom →039Nemrég módosított fájlok keresése a webszerveren
Egy lehetséges behatolás után az számít, mi változott a szerveren. Így keres időablakokban, használja helyesen az mtime-ot és a ctime-ot, és veti össze csomagokkal, Gittel és mentésekkel.
Tovább olvasom →040PHP-fájlok a feltöltési mappában: a lelőhelyek helyes értelmezése
A feltöltési mappában lévő PHP-fájl szinte mindig riasztó jel, de nem minden fájl kártékony kód. Így értékeli a leletet nyomok megsemmisítése nélkül, és tisztázza, hívta-e meg valaki.
Tovább olvasom →041Elrejtett PHP-kód felismerése
Az olvashatatlan, eval-t és base64_decode-ot használó PHP-kód a beszúrt kártékony kód klasszikus jele. Milyen mintákat keressen, hogyan találja meg őket veszélytelenül, és mikor jogos az elrejtés.
Tovább olvasom →042Egy szerver kimenő kapcsolatainak ellenőrzése
A webszerver főként kérésekre válaszol. Ha maga épít kapcsolatot ismeretlen célokhoz, az a támadók irányítását vagy adatszivárgást jelenthet. Így ellenőrzi és korlátozza a kimenő forgalmat.
Tovább olvasom →043Idegen admin-fiókok keresése a CMS-ben és a szerveren
Egy ismeretlen adminisztrátor gyakran a legegyszerűbb hátsó kapu. Így keres szintről szintre idegen fiókokat, azokat is, amelyeket a felület elrejt.
Tovább olvasom →044Ismeretlen SSH-kulcsok keresése és eltávolítása
A beszúrt SSH-kulcs akkor is megnyitja az ajtót a támadók előtt, ha az összes jelszót megváltoztatták. Így találja meg az összes authorized_keys fájlt, és ellenőrzi minden bejegyzésüket.
Tovább olvasom →045Kriptobányász a webszerveren: jelek és teendők
Tartósan teli CPU anélkül, hogy több látogató jönne: ez lehet egy kriptobányász. Így ellenőrzi a terhelést, találja meg a folyamatot és az újraindító mechanizmusait, és jár el rendezetten.
Tovább olvasom →046A szerver spamet küld: az okok megkeresése
Kézbesíthetetlen levelek, tiltólisták, panaszok: ha a saját szerver spamet küld, többnyire egy szkript vagy egy eltérített postafiók áll mögötte. Így találja meg a forrást.
Tovább olvasom →047SEO-spam és idegen oldalak a Google-indexben
Egyszer csak gyógyszerekről vagy márkás árukról szóló oldalak jelennek meg a domainje alatt. Így derítheti ki, honnan származik a SEO-spam, és hogyan tűnik el újra az indexből.
Tovább olvasom →048A weboldal idegen oldalakra irányít át
A látogatók nyereményjátékokra vagy kétes webshopokba kerülnek, Ön viszont semmit sem lát? Így találja meg azt a réteget, amelyben az átirányítás rejlik, és hogyan szünteti meg.
Tovább olvasom →049Bizonyítékok mentése a szerver újratelepítése előtt
Az újjáépítés eltávolítja a támadót, de minden nyomot is. Aki előtte egy órát a bizonyítékrögzítésre fordít, később meg tudja mondani, mi történt.
Tovább olvasom →050Egy incidens idővonalának elkészítése
Mikor érkezett a támadó, mit tett, mikor vették észre? Egy rendezett idővonal megválaszolja ezeket a kérdéseket, és a bejelentések, a biztosítás és a jelentés alapja.
Tovább olvasom →051CMS-magfájlok összevetése az eredetivel
A tiszta eredetivel való összevetés minden módosított fájlt megmutat, függetlenül attól, hogy egy kereső ismeri-e. Így építse fel az összevetést WordPresshez, Composer-projektekhez és rendszercsomagokhoz.
Tovább olvasom →052Az adatbázis ellenőrzése bejuttatott kód szempontjából
Aki csak a fájlokat ellenőrzi, a felét átnézi. Így kutassa át az adatbázis tartalmait, beállításait, triggereit és fiókjait bejuttatott kód után, csak olvasással és egy másolaton.
Tovább olvasom →053Kártevőkeresők weboldalakhoz: mit találnak meg és mit nem
A kereső nem jelez semmit, tehát minden rendben? Nem feltétlenül. Milyen típusú weboldal-keresők léteznek, mit lát mindegyik, és mit nem láthat elvileg.
Tovább olvasom →Keményítés és konfiguráció
20 cikk
PHP-FPM-poolok elkülönítése weboldalanként
Weboldalanként egy saját pool csak a kezdet, nem a vég. Így ellenőrizze a meglévő poolokat, és keményítse a socketeket, végződéseket, státuszoldalakat, erőforrásokat és naplókat.
Tovább olvasom →055A memory_limit helyes beállítása
A memory_limit PHP-kérésenként korlátozza a memóriát. A PHP2Shell után a php.net átmenetileg az ellenkezőjét javasolja. Mi érvényes normál üzemben, az átmenetben és a frissítés után.
Tovább olvasom →056A post_max_size és az upload_max_filesize értelmes korlátozása
A feltöltési határok három helyen hatnak: a webszerverben, a PHP-ban és az alkalmazásban. Így állítsa be egymással összhangban az értékeket, a php.net PHP2Shellhez szóló átmeneti értékeivel is.
Tovább olvasom →057A session.upload_progress kikapcsolása: helyesen és tartósan
A CVE-2026-115560 elleni megoldás és az egyik PHP2Shell-átmeneti intézkedés gyorsan beállítható. Hogy tartson, a megfelelő helyen kell állnia, zárolva kell lennie, és minden frissítés után újra ellenőrizni kell.
Tovább olvasom →058expose_php és Server-fejléc: verziószámok elrejtése
A PHP, az Nginx és az Apache alapértelmezetten minden válaszban megnevezi a verziószámát. Ez nem véd a támadások ellen, de a keresőknek kényelmes találati listát ad. Így kapcsolja ki, és tartsa meg mégis az áttekintést.
Tovább olvasom →059display_errors off: a hibakimenet kikapcsolása éles üzemben
A látható PHP-hibaüzenetek elárulják az útvonalakat, adatbázisneveket és verziókat. Így kapcsolja ki őket a PHP-ban, a keretrendszerben és a webszerverben anélkül, hogy szem elől tévesztené a hibákat.
Tovább olvasom →060php_admin_value: beállítások zárolása a felülírás ellen
Egy biztonsági beállítás keveset ér, ha az alkalmazás egyetlen kódsorral újra megváltoztatja. A php_admin_value és a php_admin_flag segítségével kötelezően rögzítheti az értékeket a PHP-FPM-hez és az Apache-hoz.
Tovább olvasom →061Memóriahatárok beállítása systemd-vel és cgroupokkal
A php.net a PHP2Shell átmeneti intézkedéseként a memory_limit=-1 értéket és a PHP-n kívüli memóriahatárt javasolja. Így állítsa be ezt a határt systemd-vel és cgroupokkal úgy, hogy egyetlen worker se rántsa magával az egész szolgáltatást.
Tovább olvasom →062Az Nginx biztonságos konfigurálása PHP-hez
A PHP-hez készült Nginx-beállítások legtöbb gyengesége nem az Nginxben rejlik, hanem a PHP-location néhány sorában. Így konfigurálja a PHP-FPM-nek való átadást úgy, hogy csak a kívánt szkriptek fussanak le.
Tovább olvasom →063Az Apache biztonságos konfigurálása PHP-hez
Az Apache rugalmas, és éppen ettől hajlamos a hibás konfigurációra. Így kapcsolja be a PHP-t a PHP-FPM-en át, zárja le a .htaccess hátsó ajtót, és állítsa be biztonságosan a legfontosabb alapopciókat.
Tovább olvasom →064PHP-végrehajtás tiltása a feltöltési mappákban
Egy webshellnek két dologra van szüksége: egy mappára, ahová írható, és egy szerverre, amely végrehajtja. Így veszi el tőle a másodikat, és pedig minden írható mappában, nem csak az uploadsban.
Tovább olvasom →065Feltöltési kérések szűrése a peremen: esélyek és kockázatok
Szakírók azt javasolják, hogy a PHP javításáig a proxyn blokkolják a valódi feltöltési útvonalakon kívüli feltöltési kéréseket. Ez segíthet, de űrlapokat és rendeléseket is megbéníthat. Így járjon el ellenőrzötten.
Tovább olvasom →066A ModSecurity és az OWASP Core Rule Set alkalmazása
A ModSecurityvel és az OWASP Core Rule Settel működtetett saját Web Application Firewall ingyenes és hatékony, de nem megy magától. Így válassza ki az engine-t, induljon kiesések nélkül, és hangolja a szabályokat.
Tovább olvasom →067A Fail2ban beállítása webszerverekhez
A Fail2ban tiltja azokat a címeket, amelyek ismétlődően feltűnnek a naplókban. Webszerverekhez kész szűrőket hoz, és néhány sorral sajátokat is hozzáadhat. Így állítsa be anélkül, hogy kizárná magát vagy az ügyfeleit.
Tovább olvasom →068Tűzfal webszerverekhez: csak a szükséges portokat nyissa meg
Egy webszervernek kifelé többnyire csak két portra van szüksége. Mégis sok szerveren adatbázisok, PHP-FPM vagy kezelőfelületek hallgatnak az interneten. Így találja meg a nyitott szolgáltatásokat, és zárja le, amire nincs szükség.
Tovább olvasom →069Automatikus biztonsági frissítések Linux-szervereken
Beszámolók szerint a disztribúciók a PHP-backportokat részben már 2026. október 21-én, a javítások napján kiszállították. Aki automatikus biztonsági frissítéseket használt, gyorsan megkapta őket a szerverén. Hogy hassanak is, újraindítások, külső források és ellenőrzés kell hozzá.
Tovább olvasom →070Least Privilege: a webszerver-felhasználó jogai
A beinjektált kód a webszerver-felhasználó jogaival fut. Az dönti el, meddig jut el a támadó, hogy mit tehet ez a fiók. Így korlátozza a shellt, a sudót, a cront, az adatbázist és a fájlrendszert a szükségesre.
Tovább olvasom →071Admin felületek elzárása IP-címmel, VPN-nel vagy kiegészítő védelemmel
Miért nem kell egy weboldal backendjének az egész világ számára elérhetőnek lennie, és hogyan zárhatja el IP-engedélyezéssel, VPN-nel vagy előtét-bejelentkezéssel úgy, hogy közben magát ne zárja ki.
Tovább olvasom →072TLS és HTTPS helyes konfigurálása
Mely TLS-verziókat és cipher suite-okat érdemes ma egy webszervernek kínálnia, mihez igazodnak az ajánlások, és hogyan ellenőrizheti az Nginxet, az Apache-ot és a kimenő PHP-kapcsolatokat.
Tovább olvasom →073CIS-benchmarkok és BSI-modulok webszerverekhez
Milyen keményítési szabványok léteznek Linux-webszerverekhez, miben különbözik a CIS-benchmark és az IT-Grundschutz-modul, és hogyan lesz belőlük ellenőrizhető előírás a PHP-szervereihez.
Tovább olvasom →Biztonságos fejlesztés
16 cikk
Jelszavak biztonságos tárolása PHP-ban: a password_hash helyes használata
Hogyan tárolják a fejlesztők a jelszavakat PHP-ban a password_hash és a password_verify segítségével, hogyan választják ki a megfelelő eljárást, és hogyan váltják le a régi MD5- vagy SHA-1-hasheket anélkül, hogy minden felhasználónak jelszót kellene visszaállítania.
Tovább olvasom →075CSRF-védelem PHP-alkalmazásokban
Hogyan előzik meg a fejlesztők a Cross-Site Request Forgeryt PHP-alkalmazásokban: tokenek minden módosító kéréshez, eredetellenőrzés a fejlécben és SameSite sütik további rétegként.
Tovább olvasom →076Bemenetek validálása és szűrése PHP-ban a filter_var-ral
Hogyan ellenőrzik a fejlesztők a bemeneteket PHP-ban a filter_var, a filter_input_array és az engedélyezési listák segítségével, mely szűrők elavultak, és miért nem helyettesíti a validálás a prepared statementeket és a kimenet kódolását.
Tovább olvasom →077Command injection megelőzése PHP-ban
Hogyan kerülik el a fejlesztők a command injectiont PHP-ban: a rendszerparancsok kiváltása PHP-függvényekkel, a proc_open használata shell nélkül, az argumentumok ellenőrzése és a veszélyes helyek megtalálása a meglévő kódban.
Tovább olvasom →078Server-Side Request Forgery (SSRF) megelőzése PHP-ban
Hogyan akadályozzák meg a fejlesztők, hogy egy PHP-alkalmazás idegenek megbízásából belső rendszereket kérdezzen le: engedélyezési listák, protokollkorlátozás, a feloldott cím ellenőrzése és hálózati határok.
Tovább olvasom →079XML External Entities (XXE) megelőzése PHP-ban
Hogyan dolgozzák fel a fejlesztők biztonságosan az XML-t PHP-ban: a libxml alapértelmezett viselkedése, kockázatos opciók, mint a LIBXML_NOENT, védelem entity loaderrel és LIBXML_NO_XXE-vel, valamint tipikus rejtett XML-bemenetek.
Tovább olvasom →080Type juggling PHP-ban: laza összehasonlítások mint biztonsági kockázat
Miért vezethetnek a == operátorral végzett laza összehasonlítások biztonsági résekhez PHP-ban, mi változott a PHP 8.0-val, és hogyan írja meg robusztusan az összehasonlításokat bejelentkezésekben, tokenekben és jogosultságokban.
Tovább olvasom →081Biztonságos véletlenszámok és tokenek PHP-ban a random_bytes-szal
Hogyan hoznak létre a fejlesztők PHP-ban tokeneket jelszó-visszaállító linkekhez, API-kulcsokhoz és egyszeri kódokhoz: kriptográfiailag biztonságos források, elegendő hossz, tárolás hashként és korlátozott érvényesség.
Tovább olvasom →082Hozzáférési adatok és .env fájlok helyes védelme
Hogyan védi az adatbázis-jelszavakat, API-kulcsokat és más titkokat PHP-projektekben: .env fájlok a webroton kívül, tiltások a webszerverben, szűk jogok és rendezett csere egy incidens után.
Tovább olvasom →083Nyilvános .git mappa: egy alábecsült adatszivárgás
Miért teheti közzé a Gittel kitelepített webroot a teljes forráskódot az előzményekkel együtt, hogyan ellenőrizze, azonnal tiltsa le, és építse fel tartósan a telepítést .git mappa nélkül.
Tovább olvasom →084Mentésfájlok a webrootban: .zip, .sql és .bak
Miért tartoznak az adatbázis-dumpok, archívumok és biztonsági másolatok a nyilvános könyvtárban a leggyakoribb adatszivárgások közé, hogyan találja meg és tiltsa le őket, és tisztázza, lekérték-e őket.
Tovább olvasom →085phpinfo()-fájlok: miért kell eltűnniük
A PHP2Shell után sok admin gyorsan létrehoz egy info.php fájlt. Miért jelentenek az ilyen fájlok adatszivárgást, hogyan találja meg őket, és melyek a jobb ellenőrzési utak.
Tovább olvasom →086Függőségek naprakészen tartása: Composer, npm és bővítmények
Egy projekt három csomagvilágból áll: Composerből, npm-ből és CMS-bővítményekből. Hogyan tartja mindhármat naprakészen rögzített ritmussal, egyértelmű felelősséggel és tesztekkel.
Tovább olvasom →087Biztonsági code review PHP-projektekhez
Hogyan nézik át a csapatok célzottan a saját PHP-kódjukat biztonsági rések után: a review fajtái, kritikus függvények, értelmes eszközök és egy ellenőrzőlista.
Tovább olvasom →088Biztonságos naplózás: hibák rögzítése adatszivárgás nélkül
A naplók segítenek a hibakeresésben és a forenzikában, de könnyen maguk is adatszivárgássá válnak. Mit naplózzanak a PHP-alkalmazások, mit soha, és hogyan védhetők a naplók.
Tovább olvasom →089REST API-k védelme PHP-ban
Az interfészek gyakran rosszabbul védettek, mint a mögöttük álló weboldal. A REST API-k legfontosabb szabályai PHP-ban, az objektumjogosultságtól a sebességkorlátozásig.
Tovább olvasom →Vezetés és jog
14 cikk
IT-szolgáltatói szerződések: a biztonsági kötelezettségek egyértelmű szabályozása
A PHP2Shell megmutatta, milyen gyakran tisztázatlan, ki patchel. Mely biztonsági kötelezettségek tartoznak az ügynökséggel, tárhelyszolgáltatóval és IT-szolgáltatóval kötött szerződésekbe.
Tovább olvasom →091Adatfeldolgozás, ha szolgáltatók férnek hozzá a szerverekhez
Aki külsősöket enged ügyféladatokat tartalmazó szerverekhez, általában adatfeldolgozói szerződésre (AVV) szorul. Mit követel a GDPR 28. cikke, és hogyan szervezheti a hozzáféréseket vészhelyzetben adatvédelmi szempontból megfelelően.
Tovább olvasom →092Sebezhetőségkezelés a közép- és kisvállalkozásoknál
Egyetlen középvállalkozás sem tud minden közleményt azonnal feldolgozni. A felmérés, értékelés, döntés és igazolás karcsú ciklusa gondoskodik róla, hogy a fontos dolog történjen meg először.
Tovább olvasom →093Tudni, mi fut: az összes weboldal és szerver leltára
A PHP2Shellnél sokan nem a javításon buktak el, hanem azon a kérdésen, hogy egyáltalán hol fut PHP. Így építheti fel az összes weboldal és szerver leltárát.
Tovább olvasom →094Patchmenedzsment folyamatként, nem tűzoltásként
Aki csak akkor javít, ha ég a ház, vészhelyzetben időt veszít. Hogyan köti össze a rutint és a vészhelyzetet egy patchmenedzsment-folyamat rögzített osztályokkal, ablakokkal és igazolásokkal.
Tovább olvasom →095Vészhelyzeti kapcsolattartók: kit kell mikor értesíteni?
Éles helyzetben az számít, kit érnek el, és mikor. Hogyan építheti fel az IT-vészhelyzeti kapcsolattartók listáját kiváltó okokkal, helyettesítésekkel és azokkal az adatokkal, amelyekre minden híváshoz szükség van.
Tovább olvasom →096Mennyibe kerül egy feltört szerver: a költségtételek
Egy feltört webszerver több költséget okoz, mint a javítás. Mely költségtételek merülnek fel, és hogyan indokolhat saját számokkal egy megelőzési költségvetést.
Tovább olvasom →097Ügyfelek értesítése egy incidens után
Kötelező vagy önkéntes: hogyan dönti el egy incidens után, kit értesít, mely csatornák biztonságosak, és hogyan van felkészülve az ügyfélszolgálata.
Tovább olvasom →098Az ellátási lánc a weben: ügynökség, tárhelyszolgáltató, bővítményszállító
A PHP2Shell megmutatta, hány láncszem van egy javítás és az Ön weboldala között. Hogyan ismerheti meg a weboldala ellátási láncát, hogyan biztosíthatja, és hogyan foghatja fel az egyes láncszemek kiesését.
Tovább olvasom →099Biztonságtudatosság adminoknak és szerkesztőknek: security awareness a webes csapatban
Aki weboldalakat gondoz, naponta dönt a biztonságról, gyakran anélkül, hogy észrevenné. Így képezheti az adminokat és a szerkesztőket szerepkör szerint, diacsata nélkül.
Tovább olvasom →100Vészhelyzeti gyakorlat az asztalnál: egy webszerver-incidens végigjátszása
Egy asztalnál tartott gyakorlat egy délutánba kerül, és megmutatja, hogy a vészhelyzeti terve megáll-e. Itt egy kész forgatókönyvet talál egy PHP-webszerveren történt incidenshez.
Tovább olvasom →101ISO 27001 és TISAX: mit érintenek a webszerverek
Aki ISO 27001 szerinti ISMS-t üzemeltet, vagy TISAX-címkével rendelkezik, annak a webszervereket is figyelembe kell vennie. Itt áll, mely követelményeket érintik, és mely igazolások számítanak a PHP2Shell után.
Tovább olvasom →102VdS 10000: információbiztonság a kis- és középvállalkozásoknak
A VdS 10000 az információbiztonság karcsú kerete a közép- és kisvállalkozásoknak. Mit követel, mi jött újonnan 2025-ben, és mit jelent ez a weboldalakra és a webszerverekre.
Tovább olvasom →103Lessons learned: jobbá válni az incidens után
Az incidens után jön a következő incidens előtti idő. Egy strukturált, felelősök keresése nélküli utólagos megbeszélés egy rossz hétből mérhető előrelépést csinál.
Tovább olvasom →Döntéstámogatás
10 cikk
Javítani, lekapcsolni vagy várni? Döntési segédlet a PHP-rés esetén
Egy kritikus PHP-résnél a felelősöknek gyorsan kell dönteniük. Ez a segédlet rendezi a három lehetőséget, szempontokat nevez meg, és megmutatja, mikor védhető a várakozás.
Tovább olvasom →105WAF vagy frissítés: miért kell mindkettő
Egy webalkalmazás-tűzfal el tudja fogni a támadásokat, de nem zár le rést a PHP-értelmezőben. Mikor segít egy WAF, hol ér véget, és hogyan kombinálhatja értelmesen mindkettőt.
Tovább olvasom →106Szerver újratelepítése vagy tisztítása? A döntés egy fertőzés után
Egy behatolás után két út áll nyitva: a szerver megtisztítása vagy újjáépítése. Mely szempontok döntenek, és miért fontosabb a sorrend, mint a választás.
Tovább olvasom →107Magunk oldjuk meg, vagy szolgáltatót hívunk? Őszinte mérlegelés
Nem minden biztonsági helyzethez kell külső segítség. Ezekkel a szempontokkal és egy rövid önteszttel eldöntheti, hogy a csapata egyedül megbirkózik-e a PHP2Shell-lel, vagy támogatásra van szüksége.
Tovább olvasom →108IT-biztonsági szolgáltató kiválasztása: 12 kérdés a megbízás előtt
Időnyomás alatt jó biztonsági szolgáltatót találni nehéz. Ez a tizenkét kérdés segít az ajánlatokat tárgyszerűen összehasonlítani, reklámígéretekbe való beleesés nélkül.
Tovább olvasom →109Managed hosting vagy saját szerver? A biztonsági összevetés
A PHP2Shell minden üzemeltetési modellnek stressztesztje volt. Az összevetés megmutatja, mikor biztonságosabb a managed hosting, mikor a saját szerver, és mely vegyes formák váltak be.
Tovább olvasom →110PHP-verzióváltás vagy backport? A döntés régi rendszereknél
A régi PHP-verziókhoz a PHP2Shell után több út van: disztribúciós backport, harmadik fél forrás, forráskód-javítás, hosszú távú támogatás vagy verzióváltás. Mit ér az egyes út, és meddig hord.
Tovább olvasom →111Feltörés után CMS-t váltani? Mikor segít, és mikor nem
Egy behatolás után a CMS-be vetett bizalom gyakran elvész. Egy új rendszer azonban ritkán oldja meg a tényleges okot. Mikor értelmes a váltás, és hogyan sikerül tisztán.
Tovább olvasom →112Statikus weboldalak: kevesebb PHP, kisebb támadási felület
A statikus weboldal kész HTML-fájlokat szolgál ki, és nem igényel PHP-t a szerveren. Ez jelentősen csökkenti a támadási felületet, de saját korlátokkal és kötelezettségekkel jár.
Tovább olvasom →113Pentest, bug bounty vagy sebezhetőségi szkennelés? A megfelelő vizsgálati eljárás kiválasztása
A szkennelés, a penetrációs teszt és a bug bounty egészen különböző módon vizsgálja a weboldalakat. Mit tud az egyes eljárás, hol csődöt mond, és milyen sorrend illik az Ön vállalkozásához.
Tovább olvasom →Minden óra számít. Írjon nekünk most.
Ismertesse röviden a rendszert, a PHP-verziót és a megfigyelését. Jelentkezünk, tisztázzuk a helyzetet, és távolról dolgozunk, amíg az incidens le nem zárul és dokumentálva nem lesz.