# Blog: PHP2Shell, szerverbiztonság és vészhelyzeti segítség

> Blog a PHP2Shell-ről és a szerverbiztonságról: helyzet, tárhely, felismerés, megerősítés, biztonságos fejlesztés, vezetés és döntéstámogatás.

Forrás: https://phpsos.de/hu/blog/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

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.

- [PHP2Shell: mi igazolt és mi nem](https://phpsos.de/hu/blog/php2shell-was-belegt-ist/): 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.
- [Miért vált ismertté a PHP-rés a javítás előtt](https://phpsos.de/hu/blog/php-luecke-vorzeitig-bekannt/): 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.
- [A hatóságok leveszik weboldalaikat a hálózatról: mit tanulhatnak ebből a vállalatok](https://phpsos.de/hu/blog/behoerden-webseiten-offline/): 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.
- [BSI narancs riasztási szint: mit jelent a besorolás](https://phpsos.de/hu/blog/bsi-warnstufe-orange-erklaert/): 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.
- [Mit javasol a CERT-EU és a CERT-Bund a PHP2Shellről](https://phpsos.de/hu/blog/cert-eu-empfehlungen-php/): 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.
- [Cloudflare védelmi szabályok a PHP2Shell ellen: mit tudnak és mit nem](https://phpsos.de/hu/blog/cloudflare-waf-php2shell/): 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.
- [22,6 millió kitett példány: így értelmezze helyesen a számokat](https://phpsos.de/hu/blog/exponierte-instanzen-einordnen/): 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.
- [A PHP2Shell öt percben: tájékoztató az ügyvezetésnek](https://phpsos.de/hu/blog/php2shell-briefing-geschaeftsfuehrung/): 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.
- [A PHP biztonsági rés egyszerűen elmagyarázva](https://phpsos.de/hu/blog/php-luecke-einfach-erklaert/): 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.
- [PHP2Shell: 15 kérdés tárhelyügyfelektől](https://phpsos.de/hu/blog/fragen-von-hosting-kunden/): 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.
- [Miért nem segít a WordPress-frissítés a PHP2Shell ellen](https://phpsos.de/hu/blog/warum-wordpress-update-nicht-hilft/): 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.
- [PHP2Shell és Log4Shell: mi a közös a két résben](https://phpsos.de/hu/blog/php2shell-und-log4shell/): 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.
- [Javítatlan PHP tömeges keresése: így zajlanak az automatizált támadások](https://phpsos.de/hu/blog/automatisierte-massenscans/): 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.
- [A javítás és a támadás közötti időablak](https://phpsos.de/hu/blog/zeitfenster-patch-angriff/): 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.
- [A PHP2Shell után: miért valószínűek további közlemények](https://phpsos.de/hu/blog/weitere-php-meldungen/): 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.
- [PHP2Shell: az első hét helyzetképe](https://phpsos.de/hu/blog/lagebild-erste-woche/): 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.
- [Veszélyes téves tippek a PHP2Shellről, amelyek éppen terjednek](https://phpsos.de/hu/blog/gefaehrliche-falschtipps/): 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.
- [PHP-verzió módosítása a tárhely ügyfélterületén](https://phpsos.de/hu/blog/php-version-hosting-aendern/): 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.
- [Debian és Ubuntu: javított a PHP-csomagom?](https://phpsos.de/hu/blog/debian-ubuntu-paket-gepatcht/): 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.
- [RHEL, AlmaLinux és Rocky Linux: PHP-javítás ellenőrzése](https://phpsos.de/hu/blog/rhel-almalinux-rocky-php/): 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.
- [A sury.org-tároló: PHP-csomagok harmadik féltől](https://phpsos.de/hu/blog/sury-repository-php/): 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.
- [A Remi-tároló: PHP naprakészen tartása RHEL-rendszereken](https://phpsos.de/hu/blog/remi-repository-php/): 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.
- [Miért mutatja a php -v a frissítés után ugyanazt a számot](https://phpsos.de/hu/blog/php-v-zeigt-alte-nummer/): 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.
- [CVE-számok igazolása a csomag changelogjában](https://phpsos.de/hu/blog/cve-im-changelog-nachweisen/): 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.
- [Tárhelyszolgáltató cseréje biztonsági incidens után: mire figyeljen?](https://phpsos.de/hu/blog/hoster-wechseln-nach-vorfall/): 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.
- [Több PHP-verzió egy szerveren: mindegyiket külön kell javítani](https://phpsos.de/hu/blog/mehrere-php-versionen-server/): 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.
- [Régi PHP-verziók kikapcsolása a tárhelypanelben](https://phpsos.de/hu/blog/alte-php-versionen-abschalten/): 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.
- [Plesk: a PHP-handlerek megértése (FPM, FastCGI, Apache-modul)](https://phpsos.de/hu/blog/plesk-php-handler/): 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.
- [CloudLinux és alt-php: amit a tárhelyügyfeleknek tudniuk kell](https://phpsos.de/hu/blog/cloudlinux-alt-php/): 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.
- [PHP NAS-on, tűzfalakon és appliance-eken: az elfelejtett rendszerek](https://phpsos.de/hu/blog/php-auf-nas-und-appliances/): 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.
- [PHP felhő- és PaaS-szolgáltatóknál: ki javítja a futtatókörnyezetet?](https://phpsos.de/hu/blog/paas-php-laufzeit/): 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.
- [Hivatalos PHP Docker image-ek: címkék, digestek és újraépítés](https://phpsos.de/hu/blog/offizielle-php-docker-images/): 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.
- [CI/CD: PHP-image-ek automatikus újraépítése](https://phpsos.de/hu/blog/php-images-in-ci-neu-bauen/): 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.
- [Hosszú távú támogatás régi PHP-verziókhoz: lehetőségek és korlátok](https://phpsos.de/hu/blog/langzeitsupport-alte-php-versionen/): 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.
- [PHP frissítése Windowson](https://phpsos.de/hu/blog/php-unter-windows-aktualisieren/): 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.
- [Figyelmeztető jel: a webszerver shellt indít](https://phpsos.de/hu/blog/webserver-startet-shell/): 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.
- [Gyanús folyamatok keresése Linux-szervereken](https://phpsos.de/hu/blog/verdaechtige-prozesse-linux/): 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.
- [Rejtett cron-feladatok felismerése hátsó kapuként](https://phpsos.de/hu/blog/cronjobs-als-hintertuer/): 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.
- [Nemrég módosított fájlok keresése a webszerveren](https://phpsos.de/hu/blog/geaenderte-dateien-finden/): 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.
- [PHP-fájlok a feltöltési mappában: a lelőhelyek helyes értelmezése](https://phpsos.de/hu/blog/php-dateien-im-upload-ordner/): 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.
- [Elrejtett PHP-kód felismerése](https://phpsos.de/hu/blog/verschleierter-php-code/): 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.
- [Egy szerver kimenő kapcsolatainak ellenőrzése](https://phpsos.de/hu/blog/ausgehende-verbindungen-pruefen/): 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.
- [Idegen admin-fiókok keresése a CMS-ben és a szerveren](https://phpsos.de/hu/blog/fremde-admin-konten-finden/): 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.
- [Ismeretlen SSH-kulcsok keresése és eltávolítása](https://phpsos.de/hu/blog/ssh-schluessel-pruefen/): 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.
- [Kriptobányász a webszerveren: jelek és teendők](https://phpsos.de/hu/blog/kryptominer-auf-dem-server/): 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.
- [A szerver spamet küld: az okok megkeresése](https://phpsos.de/hu/blog/server-verschickt-spam/): 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.
- [SEO-spam és idegen oldalak a Google-indexben](https://phpsos.de/hu/blog/seo-spam-im-google-index/): 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.
- [A weboldal idegen oldalakra irányít át](https://phpsos.de/hu/blog/website-leitet-um/): 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.
- [Bizonyítékok mentése a szerver újratelepítése előtt](https://phpsos.de/hu/blog/beweise-sichern-vor-neuinstallation/): 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.
- [Egy incidens idővonalának elkészítése](https://phpsos.de/hu/blog/zeitleiste-eines-vorfalls/): 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.
- [CMS-magfájlok összevetése az eredetivel](https://phpsos.de/hu/blog/cms-kerndateien-vergleichen/): 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.
- [Az adatbázis ellenőrzése bejuttatott kód szempontjából](https://phpsos.de/hu/blog/datenbank-auf-schadcode-pruefen/): 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.
- [Kártevőkeresők weboldalakhoz: mit találnak meg és mit nem](https://phpsos.de/hu/blog/grenzen-von-malware-scannern/): 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.
- [PHP-FPM-poolok elkülönítése weboldalanként](https://phpsos.de/hu/blog/php-fpm-pools-isolieren/): 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.
- [A memory_limit helyes beállítása](https://phpsos.de/hu/blog/memory-limit-richtig-setzen/): 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.
- [A post_max_size és az upload_max_filesize értelmes korlátozása](https://phpsos.de/hu/blog/post-max-size-upload-limits/): 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.
- [A session.upload_progress kikapcsolása: helyesen és tartósan](https://phpsos.de/hu/blog/session-upload-progress-abschalten/): 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.
- [expose_php és Server-fejléc: verziószámok elrejtése](https://phpsos.de/hu/blog/expose-php-versionsangaben/): 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.
- [display_errors off: a hibakimenet kikapcsolása éles üzemben](https://phpsos.de/hu/blog/display-errors-produktion/): 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.
- [php_admin_value: beállítások zárolása a felülírás ellen](https://phpsos.de/hu/blog/php-admin-value-sperren/): 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.
- [Memóriahatárok beállítása systemd-vel és cgroupokkal](https://phpsos.de/hu/blog/speichergrenzen-systemd-cgroups/): 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.
- [Az Nginx biztonságos konfigurálása PHP-hez](https://phpsos.de/hu/blog/nginx-fuer-php-absichern/): 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.
- [Az Apache biztonságos konfigurálása PHP-hez](https://phpsos.de/hu/blog/apache-fuer-php-absichern/): 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.
- [PHP-végrehajtás tiltása a feltöltési mappákban](https://phpsos.de/hu/blog/php-in-uploads-verbieten/): 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.
- [Feltöltési kérések szűrése a peremen: esélyek és kockázatok](https://phpsos.de/hu/blog/upload-anfragen-am-rand-filtern/): 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.
- [A ModSecurity és az OWASP Core Rule Set alkalmazása](https://phpsos.de/hu/blog/modsecurity-owasp-crs/): 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.
- [A Fail2ban beállítása webszerverekhez](https://phpsos.de/hu/blog/fail2ban-fuer-webserver/): 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.
- [Tűzfal webszerverekhez: csak a szükséges portokat nyissa meg](https://phpsos.de/hu/blog/firewall-fuer-webserver/): 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.
- [Automatikus biztonsági frissítések Linux-szervereken](https://phpsos.de/hu/blog/automatische-sicherheitsupdates/): 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á.
- [Least Privilege: a webszerver-felhasználó jogai](https://phpsos.de/hu/blog/rechte-des-webserver-benutzers/): 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.
- [Admin felületek elzárása IP-címmel, VPN-nel vagy kiegészítő védelemmel](https://phpsos.de/hu/blog/admin-bereiche-abschirmen/): 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.
- [TLS és HTTPS helyes konfigurálása](https://phpsos.de/hu/blog/tls-https-richtig-konfigurieren/): 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.
- [CIS-benchmarkok és BSI-modulok webszerverekhez](https://phpsos.de/hu/blog/cis-benchmarks-bsi-bausteine/): 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.
- [Jelszavak biztonságos tárolása PHP-ban: a password_hash helyes használata](https://phpsos.de/hu/blog/passwoerter-in-php-speichern/): 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.
- [CSRF-védelem PHP-alkalmazásokban](https://phpsos.de/hu/blog/csrf-schutz-php/): 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.
- [Bemenetek validálása és szűrése PHP-ban a filter_var-ral](https://phpsos.de/hu/blog/eingaben-validieren-php/): 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.
- [Command injection megelőzése PHP-ban](https://phpsos.de/hu/blog/command-injection-php/): 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.
- [Server-Side Request Forgery (SSRF) megelőzése PHP-ban](https://phpsos.de/hu/blog/ssrf-in-php/): 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.
- [XML External Entities (XXE) megelőzése PHP-ban](https://phpsos.de/hu/blog/xxe-in-php/): 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.
- [Type juggling PHP-ban: laza összehasonlítások mint biztonsági kockázat](https://phpsos.de/hu/blog/type-juggling-php/): 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.
- [Biztonságos véletlenszámok és tokenek PHP-ban a random_bytes-szal](https://phpsos.de/hu/blog/sichere-tokens-php/): 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.
- [Hozzáférési adatok és .env fájlok helyes védelme](https://phpsos.de/hu/blog/env-dateien-schuetzen/): 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.
- [Nyilvános .git mappa: egy alábecsült adatszivárgás](https://phpsos.de/hu/blog/git-ordner-oeffentlich/): 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.
- [Mentésfájlok a webrootban: .zip, .sql és .bak](https://phpsos.de/hu/blog/backup-dateien-im-webroot/): 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.
- [phpinfo()-fájlok: miért kell eltűnniük](https://phpsos.de/hu/blog/phpinfo-dateien-entfernen/): 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.
- [Függőségek naprakészen tartása: Composer, npm és bővítmények](https://phpsos.de/hu/blog/abhaengigkeiten-aktuell-halten/): 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.
- [Biztonsági code review PHP-projektekhez](https://phpsos.de/hu/blog/sicherheits-code-review-php/): 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.
- [Biztonságos naplózás: hibák rögzítése adatszivárgás nélkül](https://phpsos.de/hu/blog/sicher-loggen-php/): 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.
- [REST API-k védelme PHP-ban](https://phpsos.de/hu/blog/rest-api-php-absichern/): 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.
- [IT-szolgáltatói szerződések: a biztonsági kötelezettségek egyértelmű szabályozása](https://phpsos.de/hu/blog/dienstleistervertrag-sicherheit/): 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.
- [Adatfeldolgozás, ha szolgáltatók férnek hozzá a szerverekhez](https://phpsos.de/hu/blog/auftragsverarbeitung-serverzugriff/): 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.
- [Sebezhetőségkezelés a közép- és kisvállalkozásoknál](https://phpsos.de/hu/blog/schwachstellenmanagement-mittelstand/): 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.
- [Tudni, mi fut: az összes weboldal és szerver leltára](https://phpsos.de/hu/blog/inventar-websites-server/): 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.
- [Patchmenedzsment folyamatként, nem tűzoltásként](https://phpsos.de/hu/blog/patch-management-prozess/): 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.
- [Vészhelyzeti kapcsolattartók: kit kell mikor értesíteni?](https://phpsos.de/hu/blog/notfallkontakte-liste/): É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.
- [Mennyibe kerül egy feltört szerver: a költségtételek](https://phpsos.de/hu/blog/kostenposten-eines-hacks/): 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.
- [Ügyfelek értesítése egy incidens után](https://phpsos.de/hu/blog/kunden-nach-vorfall-informieren/): 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.
- [Az ellátási lánc a weben: ügynökség, tárhelyszolgáltató, bővítményszállító](https://phpsos.de/hu/blog/lieferkette-agentur-hoster/): 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.
- [Biztonságtudatosság adminoknak és szerkesztőknek: security awareness a webes csapatban](https://phpsos.de/hu/blog/sicherheitsbewusstsein-redaktion/): 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.
- [Vészhelyzeti gyakorlat az asztalnál: egy webszerver-incidens végigjátszása](https://phpsos.de/hu/blog/notfalluebung-am-tisch/): 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.
- [ISO 27001 és TISAX: mit érintenek a webszerverek](https://phpsos.de/hu/blog/iso-27001-tisax-webserver/): 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.
- [VdS 10000: információbiztonság a kis- és középvállalkozásoknak](https://phpsos.de/hu/blog/vds-10000-kmu/): 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.
- [Lessons learned: jobbá válni az incidens után](https://phpsos.de/hu/blog/lessons-learned-nach-vorfall/): 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.
- [Javítani, lekapcsolni vagy várni? Döntési segédlet a PHP-rés esetén](https://phpsos.de/hu/blog/patchen-abschalten-abwarten/): 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.
- [WAF vagy frissítés: miért kell mindkettő](https://phpsos.de/hu/blog/waf-oder-update/): 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.
- [Szerver újratelepítése vagy tisztítása? A döntés egy fertőzés után](https://phpsos.de/hu/blog/neu-aufsetzen-oder-bereinigen/): 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.
- [Magunk oldjuk meg, vagy szolgáltatót hívunk? Őszinte mérlegelés](https://phpsos.de/hu/blog/selbst-beheben-oder-dienstleister/): 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.
- [IT-biztonsági szolgáltató kiválasztása: 12 kérdés a megbízás előtt](https://phpsos.de/hu/blog/sicherheitsdienstleister-auswaehlen/): 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.
- [Managed hosting vagy saját szerver? A biztonsági összevetés](https://phpsos.de/hu/blog/managed-oder-eigener-server/): 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.
- [PHP-verzióváltás vagy backport? A döntés régi rendszereknél](https://phpsos.de/hu/blog/php-upgrade-oder-backport/): 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.
- [Feltörés után CMS-t váltani? Mikor segít, és mikor nem](https://phpsos.de/hu/blog/cms-wechsel-nach-hack/): 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.
- [Statikus weboldalak: kevesebb PHP, kisebb támadási felület](https://phpsos.de/hu/blog/statische-website-alternative/): 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.
- [Pentest, bug bounty vagy sebezhetőségi szkennelés? A megfelelő vizsgálati eljárás kiválasztása](https://phpsos.de/hu/blog/pentest-bugbounty-scan/): 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.