Szószedet: PHP és IT-biztonság

125 szakkifejezés világos szavakkal, mindegyik a megfelelő szakoldalra mutató hivatkozással.

#A B C D E F G H I J K L M N O P R S T U V W X Z

#

2FA: A 2FA (kétfaktoros hitelesítés) a jelszó mellett a bejelentkezéskor egy második igazolást kér, például egy alkalmazásból származó kódot vagy egy biztonsági kulcsot. Egy ellopott jelszó ekkor már önmagában nem elég. A CMS-ek, a tárhelypanelek és a szerverek minden rendszergazdai hozzáférésénél a 2FA-nak alapértelmezettnek kell lennie. Kétfaktoros hitelesítés beállítása admin hozzáférésekhez →
3-2-1 mentés: A 3-2-1 szabály három adatmásolatot javasol két különböző tárolóeszközön, amelyek közül egy más helyen van. Legalább egy másolatnak a szerverről nem módosíthatónak kell lennie, hogy a támadók ne tudják törölni vagy titkosítani. Egy mentés csak akkor számít, ha a visszaállítást tesztelték. Mentési stratégia szerverhez: mentések a 3-2-1 szabály szerint →

A

Apache: Az Apache HTTP Server az egyik legrégebbi és legelterjedtebb webszerver. A PHP benne vagy modulként (mod_php), vagy PHP-FPM-en keresztül, FastCGI-vel fut. A .htaccess fájlokkal a konfiguráció könyvtáranként módosítható. Apache védelme mod_php esetén →
AVV: Az AVV (Auftragsverarbeitungsvertrag, adatfeldolgozási szerződés) a GDPR 28. cikke szerint akkor szükséges, ha egy szolgáltató megbízásból személyes adatokat dolgoz fel, vagy hozzájuk férhet. Ez gyakran a tárhelyszolgáltatókra, ügynökségekre és szerverhozzáféréssel rendelkező IT-szolgáltatókra is érvényes. A szerződés szabályozza többek között az utasításokat, a védelmi intézkedéseket és a bejelentési útvonalakat. Adatfeldolgozás, ha szolgáltatók férnek hozzá a szerverekhez →

B

Backdoor: A backdoor (hátsó ajtó) egy rejtett hozzáférés, amelyen keresztül a támadók egy feltörés után visszatérhetnek. Lehet fájl, rendszergazdai fiók, cron-feladat vagy SSH-kulcs. Ezért minden tisztításhoz hozzátartozik az összes hozzáférési típus keresése, nem csak a fájloké. WordPress backdoor keresése: a hátsó ajtók módszeres felderítése →
Backport: A backport egy biztonsági javítást visz át egy régebbi programverzióba, anélkül hogy az új verzióra kellene váltani. A Linux-disztribúciók és a tárhelyszolgáltatók gyakran így járnak el; a kijelzett verziószám ilyenkor ugyanaz marad. Hogy egy backport telepítve van-e, azt a csomag változásnaplója (changelog) és a szolgáltató igazolása bizonyítja, nem a szám. PHP-verzióváltás vagy backport? A döntés régi rendszereknél →
Bizonyítékrögzítés: A bizonyítékrögzítés azt jelenti, hogy egy incidens nyomait mentik, mielőtt azok a tisztítás, az újraindítás vagy az újratelepítés során elvesznének. Ide tartoznak a naplófájlok, az adathordozók lemezképei, és esettől függően a memória. A szakmai sajtó a PHP2Shell után azt javasolja, hogy a szervernaplókat 2026. 10. 20-tól őrizzék meg. Bizonyítékok mentése a szerver újratelepítése előtt →
Biztonsági fejlécek: A biztonsági fejlécek olyan HTTP-válaszfejlécek, amelyek védelmi szabályokat adnak a böngészőnek, például Content-Security-Policy, Strict-Transport-Security vagy X-Content-Type-Options. A látogatókat védik bizonyos böngészőbeli támadások ellen. A szerveren lévő rések, például a PHP2Shell ellen nem segítenek. Biztonsági fejlécek weboldalakhoz: security header helyes beállítása →
Brute Force: Brute force támadás esetén a támadó automatizáltan sok jelszót próbál ki egy fiókhoz. A célpont gyakran CMS-ek rendszergazdai bejelentkezése, az SSH vagy az FTP. Védelmet az erős jelszavak, a kétfaktoros bejelentkezés és az olyan automatikus tiltások nyújtanak, mint a Fail2ban. Admin bejelentkezések védelme brute force ellen: brute force védelem minden bejelentkezéshez →
BSI: A BSI (Bundesamt für Sicherheit in der Informationstechnik, a német Szövetségi Információbiztonsági Hivatal) a német szövetségi kiberbiztonsági hatóság. Figyelmeztetéseket, ajánlásokat és szabványokat, például az IT-Grundschutzot adja ki. A PHP2Shell-lel kapcsolatban a BSI 3. riasztási szintet (narancs) hirdetett, és azonnali frissítést javasolt. Mit ajánl a BSI a PHP2Shell esetében →

C

CDN: A CDN (Content Delivery Network) a tartalmakat sok elosztott szerveren keresztül szolgálja ki, és így a tényleges weboldal előtt áll. Sok CDN további WAF-szabályokat kínál, például a Cloudflare a PHP2Shell ellen. A védelem csak a CDN-en keresztüli forgalomra hat, és nem pótolja a PHP-frissítést. Cloudflare védelmi szabályok a PHP2Shell ellen: mit tudnak és mit nem →
CERT-Bund: A CERT-Bund a német szövetségi közigazgatás Computer Emergency Response Teamje a BSI-nál. Figyelmeztető és tájékoztató szolgáltatásokat tesz közzé a sebezhetőségekről, és értesíti a hálózatüzemeltetőket a sebezhető rendszerekről. A PHP2Shell-lel kapcsolatban is figyelmeztetett a CERT-Bund. Mit javasol a CERT-EU és a CERT-Bund a PHP2Shellről →
CERT-EU: A CERT-EU az Európai Unió intézményeinek, szerveinek és ügynökségeinek kiberbiztonsági csapata. A beszámolók szerint a CERT-EU lehetségesnek tartja, hogy a PHP2Shell a PHP 5-től kezdődő verziókat érinti. Azt javasolja, hogy a nyilvánosan elérhető alkalmazásokat el kell szigetelni, ha nem javíthatók időben. Mit javasol a CERT-EU és a CERT-Bund a PHP2Shellről →
CGI: A CGI (Common Gateway Interface) egy régi felület, amelynél a webszerver minden kéréshez elindít egy külső programot, és annak kimenetét adja vissza. Egyszerű, de lassú, és a PHP esetében nagyrészt felváltotta a FastCGI. A régi CGI-beállítások még megtalálhatók egyes tárhely- és Windows-rendszereken. CGI és FastCGI: az alapok →
cgroups: A cgroups (Control Groups) a Linux-kernel egy funkciója, amellyel a memória, a CPU és más erőforrások korlátozhatók folyamatcsoportok számára. A konténerek és a systemd használja őket, például a MemoryMax beállítással. A php.net átmeneti intézkedésként a PHP2Shell ellen az RLIMIT_AS vagy RLIMIT_DATA helyett konténeren vagy cgroup-on keresztüli memóriahatárt javasol. Memóriahatárok beállítása systemd-vel és cgroupokkal →
Chain of Custody: A chain of custody (bizonyítási lánc) hézagmentesen dokumentálja, hogy ki mikor mentett, adott át és dolgozott fel egy bizonyítékot. Ellenőrző összegekkel kiegészítve igazolja, hogy az adatokat nem módosították. E dokumentáció nélkül a nyomok bíróság előtt vagy biztosítókkal szemben elveszítik az értéküket. IT-forenzika webszerver-támadás után →
Changelog: A changelog (változásnapló) felsorolja egy program- vagy csomagverzió változásait, biztonsági javításoknál többnyire CVE-számmal. Debianon és Ubuntun az apt-get changelog a csomag changelogját mutatja, az RHEL-családban az rpm -q --changelog. Így egy backport azonos verziószám mellett is igazolható. CVE-számok igazolása a csomag changelogjában →
CLI: A CLI (Command Line Interface) a PHP a parancssorban, például cron-feladatokhoz, CMS-ek konzolparancsaihoz és a Composerhez. A CLI-s PHP más verzió lehet, mint az, amelyik a weboldalakat kiszolgálja. A php -v parancs ezért csak a parancssori verziót mutatja; mindkét útnak javítottnak kell lennie. A PHP a parancssorban (CLI) →
CloudLinux: A CloudLinux egy megosztott tárhelyre szánt Linux-disztribúció, amely az ügyfeleket korlátozott környezetekbe választja szét. Az alt-php segítségével sok PHP-verziót biztosít egymás mellett, a régebbieket is. E verziók mindegyikét külön kell javítani. CloudLinux és alt-php: amit a tárhelyügyfeleknek tudniuk kell →
Command Injection: Command injection esetén a bevitelek ellenőrzés nélkül jutnak egy rendszerparancsba, amelyet az alkalmazás végrehajt. A támadó így saját parancsokat indíthat a webszerver jogaival. Védelmet nyújt, ha lehetőség szerint lemondanak a shell-hívásokról, és következetesen escapeshellarg()-ot használnak. Command injection megelőzése PHP-ban →
Composer: A Composer a PHP csomagkezelője. A könyvtárakat a composer.json adatai szerint telepíti, és a pontos verziókat a composer.lock fájlban rögzíti. A composer audit paranccsal a telepített csomagok ismert biztonsági rések szempontjából ellenőrizhetők; magában a PHP-ban lévő réseket a parancs nem találja meg. Composer: a PHP csomagkezelője →
cPanel: A cPanel egy webtárhely-kezelőpanel, a WHM pedig a szerver-rendszergazda felülete. A PHP-verziókat ott többnyire saját csomagok (EasyApache) biztosítják. Hogy mely buildek javítottak, azt a csomagállapot és a tárhelyszolgáltató igazolja. cPanel és WHM: a PHP védelme →
Credential Stuffing: Credential stuffing esetén a támadók korábbi adatszivárgásokból származó hozzáférési adatokat próbálnak ki más szolgáltatásoknál. Azért működik, mert sokan többször használják ugyanazt a jelszót. Védelmet a szolgáltatásonként egyedi jelszavak és a kétfaktoros bejelentkezés nyújtanak. Kétfaktoros hitelesítés beállítása admin hozzáférésekhez →
CSP: A CSP (Content Security Policy) egy fejléc, amely meghatározza, mely forrásokból tölthet be egy oldal szkripteket, képeket és más tartalmakat. Megnehezíti az XSS-t és az idegen szkriptek bejuttatását, például skimming esetén. Egy szigorú CSP-t gondosan tesztelni kell, hogy a weboldal tovább működjön. Biztonsági fejlécek weboldalakhoz: security header helyes beállítása →
CSRF: A CSRF (Cross-Site Request Forgery) egy bejelentkezett felhasználó böngészőjét arra készteti, hogy akaratlanul műveletet indítson egy másik weboldalon. Tipikusak a módosítások az adminisztrációs területeken. Védelmet az űrlapokban lévő véletlenszerű tokenek és a SameSite attribútumú cookie-k nyújtanak. CSRF-védelem PHP-alkalmazásokban →
CVE: A CVE (Common Vulnerabilities and Exposures) egy világszerte használt jegyzék, amely minden ismert biztonsági résnek egyedi számot ad, például CVE-2026-109618. A szám összehasonlíthatóvá teszi a gyártók, hatóságok és disztribúciók közleményeit. A CVE-szám alapján a csomag változásnaplójában (changelog) is ellenőrizhető, hogy a javítás telepítve van-e. CVE-számok igazolása a csomag changelogjában →
CVSS: A CVSS (Common Vulnerability Scoring System) egy 0-tól 10-ig terjedő skálán értékeli egy rés súlyosságát. Az értékelés figyelembe veszi például, hogy lehetséges-e a támadás a hálózaton át és bejelentkezés nélkül. A PHP2Shell-rések egyenként CVSS v4.0 9,2 értékűek; az Ön környezetében fennálló konkrét kockázatról az érték önmagában nem mond semmit.

D

DDoS: A DDoS-támadás (Distributed Denial of Service) sok forrásból érkező kérésekkel terhel túl egy szolgáltatást, amíg az elérhetetlenné nem válik. Adatokat ilyenkor általában nem lopnak el. A DDoS-t meg kell különböztetni az exploittól, amely célzottan egy rést használ ki. DDoS vagy hackertámadás? A támadások helyes besorolása →
Defacement: Defacement esetén a támadók láthatóan megváltoztatják egy weboldal nyitóoldalát vagy tartalmait, például üzenetekkel vagy képekkel. Feltűnő, de gyakran csak egy mélyebb feltörés látható jele. A weboldalt a tisztázásig feltörtként kell kezelni. Feltörték a weboldalt, mit tegyek? Távoli vészhelyzeti segítség →
Deszerializáció: A deszerializáció a tárolt adatokat visszaalakítja objektumokká, a PHP-ban például az unserialize() függvénnyel. Ha az adatok felhasználóktól származnak, a támadók úgy építhetnek objektumokat, hogy betöltésükkor nem kívánt kód fusson. Felhasználói adatoknál a JSON a biztonságosabb választás. Nem biztonságos deszerializáció PHP-ban: unserialize és biztonság →
disable_functions: A disable_functions egy php.ini-beállítás, amellyel egyes PHP-függvények kikapcsolhatók, jellemzően a rendszerparancsok futtatására szolgálók. Csak a php.ini-ben állítható be, az alkalmazáskódban nem. Megnehezíti a támadók dolgát, de sem a frissítéseket, sem a rendezett jogosultságokat nem pótolja. A PHP disable_functions helyes használata →
display_errors: A display_errors azt határozza meg, hogy a PHP a hibaüzeneteket közvetlenül a böngészőben jeleníti-e meg. Éles üzemben az értéknek Off-nak kell lennie, a hibák helyette a log_errors beállítással egy naplóba íródnak. A látható üzenetek különben elárulják az útvonalakat, a verziókat és a kódrészleteket. display_errors off: a hibakimenet kikapcsolása éles üzemben →

E

EDR: Az EDR (Endpoint Detection and Response) szervereken és munkaállomásokon futó szoftver, amely megfigyeli a folyamatokat, a fájlhozzáféréseket és a hálózati kapcsolatokat, és jelenti vagy leállítja a gyanús viselkedést. Webszervereken például felismerheti, hogy a PHP-FPM shellt indít. Mivel a PHP2Shell-hez nincsenek megerősített IOC-k, az ilyen viselkedéselemzés különösen fontos. Figyelmeztető jel: a webszerver shellt indít →
Embargo: Az embargó az a megállapodott határidő, amíg egy rés részletei bizalmasak maradnak, míg a javítások rendelkezésre nem állnak. Így a gyártók és a disztribúciók előkészíthetik a frissítéseket. A PHP2Shell esetében több beszámoló szerint a részletek az embargó lejárta előtt nyilvánosak lettek; a php.net ezért 2026. 10. 20-án jelentette be a javításokat. Miért vált ismertté a PHP-rés a javítás előtt →
End of Life: Az End of Life (EOL) azt jelenti, hogy egy szoftververzió a gyártótól már nem kap frissítéseket, biztonsági javításokat sem. A PHP 8.1 és régebbi verziói a PHP-projekttől már nem kapnak hivatalos frissítéseket; a 7.4, 8.0 és 8.1 esetében csak minimális forráskód-backportok vannak. Az EOL-szoftveres rendszerekhez frissítési terv kell. PHP End of Life: az elavult verziók kockázatai →
Exploit: Az exploit olyan kód vagy eljárás, amely egy konkrét rést ténylegesen kihasznál. Amint megjelenik egy javítás, a támadók elemezhetik, és exploitokat vezethetnek le belőle. Ezért a javítás közzététele után a támadásokig eltelt idő gyakran jelentősen lerövidül. A javítás és a támadás közötti időablak →
expose_php: Az expose_php azt szabályozza, hogy a PHP elárulja-e a verzióját az X-Powered-By HTTP-fejlécben. Éles üzemben a beállításnak Off értéken kell állnia, hogy a támadók ne lássák azonnal, melyik PHP-verzió fut. Ez információvédelem, nem pótolja a frissítést. expose_php és Server-fejléc: verziószámok elrejtése →
Extension: Az Extension (bővítmény) olyan funkciókkal egészíti ki a PHP-t, mint az adatbázisok, a képek vagy a titkosítás. A bővítmények ugyanabban a folyamatban futnak, mint a PHP, és ugyanazokkal a jogokkal rendelkeznek. A nem szükséges bővítmények kikapcsolása csökkenti a támadási felületet. A PHP-bővítmények (extensions) megértése →

F

Fail2ban: A Fail2ban naplófájlokat olvas, és ismételt sikertelen kísérletek után átmenetileg tiltja az IP-címeket a tűzfalban. Tipikus alkalmazási területei az SSH, a levelezés és a weboldalak rendszergazdai bejelentkezései. Sok címről érkező elosztott támadások ellen csak korlátozottan segít. A Fail2ban beállítása webszerverekhez →
FastCGI: A FastCGI egy protokoll, amellyel a webszerver a kéréseket tartósan futó programfolyamatoknak adja tovább, például a PHP-FPM-nek. A klasszikus CGI-val ellentétben nem indul új folyamat minden kéréshez. Mivel a folyamatok több kérést dolgoznak fel egymás után, frissítések után fontos a rendezett újraindítás. CGI és FastCGI: az alapok →
Forenzika: Az IT-forenzika egy incidens után módszeresen kivizsgálja, mi történt: hogyan jutott be a támadó, mit tett, és mely adatok érintettek. Alapja az adathordozók, a memória és a naplók mentett másolata. Az eredmények fontosak a bejelentési kötelezettségekhez, a biztosításhoz és a feljelentéshez. IT-forenzika webszerver-támadás után →
FPM-pool: A pool PHP-FPM-folyamatok csoportja saját konfigurációval, saját sockettel és ideális esetben saját rendszerfelhasználóval. A weboldalankénti külön pool elválasztja egymástól a weboldalakat, így az egyik oldal feltörése nem éri el közvetlenül a többi fájljait. A poolban a beállítások php_admin_value-val rögzíthetők. PHP-FPM-poolok elkülönítése weboldalanként →
FrankenPHP: A FrankenPHP egy modern alkalmazásszerver PHP-hoz, a Caddy webszerverre építve. A PHP ott közvetlenül be van ágyazva, worker módban az alkalmazás a kérések között a memóriában marad. A FrankenPHP a PHP-csapat szerint az érintett üzemmódok közé tartozik; a frissítés után a szervert az új PHP-val újra kell indítani. FrankenPHP védelme →

G

GDPR 33. cikk: A GDPR 33. cikke kötelezi az adatkezelőket, hogy a személyes adatok védelmének megsértését lehetőleg a tudomásszerzéstől számított 72 órán belül jelentsék az illetékes felügyeleti hatóságnak. A kötelezettség csak akkor szűnik meg, ha az érintettekre nézve valószínűleg nincs kockázat. Az egyedi esetben az adatvédelmi felelősök vagy ügyvédek adnak tanácsot. GDPR-bejelentési kötelezettség: 72 óra az incidens után →
GDPR 34. cikk: A GDPR 34. cikke az érintett személyek értesítését szabályozza. Akkor szükséges, ha egy adatvédelmi incidens valószínűleg magas kockázattal jár a jogaikra és szabadságaikra nézve. Hogy ez fennáll-e, azt adatvédelmi felelősökkel vagy ügyvédekkel érdemes értékeltetni. GDPR-bejelentési kötelezettség: 72 óra az incidens után →
GHSA: A GHSA egy GitHub Security Advisory azonosítója, vagyis a GitHub adatbázisában lévő biztonsági közleményé. Sok nyílt forráskódú projekt, köztük a PHP is, a CVE-szám mellett ott is közzéteszi a közleményeit. A PHP2Shell esetében ezek a GHSA-w8hw-w9fx-j79w és a GHSA-6wmf-4rv5-p3rp.

H

HSTS: A HSTS (HTTP Strict Transport Security) egy fejléc, amellyel egy weboldal közli a böngészővel, hogy egy meghatározott ideig csak HTTPS-en keresztül hívható meg. Ez megakadályozza, hogy a kapcsolatokat titkosítatlan HTTP-re fokozzák le. Bekapcsolása előtt a HTTPS-nek megbízhatóan működnie kell az összes érintett domainen. Biztonsági fejlécek weboldalakhoz: security header helyes beállítása →
.htaccess: A .htaccess fájlok könyvtárankénti konfigurációs fájlok az Apache-hoz és a kompatibilis szerverekhez, például a LiteSpeedhez. A CMS-ek átirányításokhoz és hozzáférés-védelemhez használják, a támadók rejtett átirányításokhoz. Az Nginx nem értékeli ki a .htaccess-t; a védelmi szabályokat ott a szerverkonfigurációba kell tenni. Az Apache biztonságos konfigurálása PHP-hez →

I

Idővonal: Az idővonal (timeline) időrendbe rendezi egy incidens összes nyomát: naplóbejegyzéseket, fájlváltozásokat, bejelentkezéseket, folyamatokat. Megmutatja, mikor kezdődött a támadás, és mi történt milyen sorrendben. Fontos az egységes időzóna, lehetőleg az UTC. Egy incidens idővonalának elkészítése →
Image-digest: Az image-digest egy hash-érték (sha256), amely egyértelműen meghatározza egy konténer-image tartalmát. Az olyan címkével (tag) ellentétben, mint a php:8.3-fpm, amelyet új buildekre át lehet helyezni, a digest soha nem változik. Aki az image-eket digesttel rögzíti, annak biztonsági frissítés után tudatosan frissítenie kell. Hivatalos PHP Docker image-ek: címkék, digestek és újraépítés →
Incident Response: Az incident response egy biztonsági incidens rendezett kezelése: felismerés, megfékezés, nyomok mentése, tisztítás, helyreállítás és utólagos feldolgozás. A rögzített folyamat megakadályozza, hogy a sietségben bizonyítékok semmisüljenek meg vagy hátsó ajtók maradjanak észrevétlenül. Fontosak az egyértelmű felelősségek és a hézagmentes dokumentáció. Incident response szerver elleni támadásoknál →
ini_set(): Az ini_set() egy PHP-függvény, amellyel egy szkript futásidőben módosít beállításokat. Hogy egy szkript mit módosíthat, a beállítás módosítási módjától függ. Mivel a kártékony kód is meghívhatja az ini_set()-et, a védelmi beállítások a szerver- vagy poolkonfigurációba tartoznak, nem az alkalmazáskódba. A php.ini elmagyarázva: felépítés, szintek és elsőbbség →
Integritás-ellenőrzés: Az integritás-ellenőrzés során a fájlokat egy ismert eredeti állapottal vetik össze, többnyire ellenőrző összegek alapján. Sok CMS saját parancsokat kínál ehhez, például a WordPress, a Nextcloud vagy a Matomo. A módosított fájlokat, a feltöltéseket és az adatbázis-tartalmakat egy ilyen összehasonlítás nem fedi le. CMS-magfájlok összevetése az eredetivel →
IOC: Az IOC (Indicator of Compromise) egy támadás konkrét nyomai, például fájlnevek, hash-értékek, IP-címek vagy domainek. Velük a rendszerek célzottan ellenőrizhetők egy ismert támadás szempontjából. A PHP2Shell-hez nincsenek közzétett, megerősített IOC-k; a felismerés viselkedéselemzésen alapul. Már feltörték a rendszeremet? Jelek a PHP2Shell után →
ISO 27001: Az ISO/IEC 27001 az információbiztonsági irányítási rendszerek (ISMS) nemzetközi szabványa. Rendezett kockázatkezelést, intézkedéseket és fejlesztéseket követel meg, a sebezhetőség- és incidenskezelést is beleértve. A vállalkozások e szerint tanúsíttathatják magukat. ISO 27001 és TISAX: mit érintenek a webszerverek →
IT-Grundschutz: A BSI IT-Grundschutz egy módszertan modulokkal és követelményekkel a vállalkozások és hatóságok információbiztonságához. Külön modulok vannak például a webszerverekre és a webalkalmazásokra. Alapként használható egy ISMS-hez vagy egy tanúsításhoz. CIS-benchmarkok és BSI-modulok webszerverekhez →

J

Javítás (patch): A javítás (patch) a gyártó korrekciója, amely lezár egy rést a programkódban. Csak akkor hat, ha telepítették, és az összes futó folyamatot újraindították. A javítás nem távolítja el a már bejuttatott kártékony szoftvert, és nem bizonyítja, hogy korábban nem történt semmi. PHP-javítási szolgáltatás: frissítés telepíttetése, újraindítással és igazolással →
JIT: A JIT (Just-in-Time compiler) a gyakran végrehajtott PHP-kódot futásidőben gépi kóddá fordítja. A PHP 8.0-val jelent meg, és az OPcache része. Tipikus weboldalaknál a teljesítménynövekedés többnyire csekély, számításigényes feladatoknál nagyobb. JIT és teljesítmény a PHP 8-ban →

K

Kiadási ciklus: Minden PHP-verzió először hibajavításokat kap, majd egy ideig már csak biztonsági javításokat. Hogy melyik verzió mikor ér véget, azt a PHP-projekt a php.net-en, a támogatott verziók alatt teszi közzé. A PHP 8.2 a php.net szerint 2026. 12. 31-én éri el a támogatás végét. PHP-verziók és kiadási ciklus →
Kiberbiztosítás: A kiberbiztosítás a szerződéstől függően átvállalja egy támadás utáni költségeket, például a forenzikát, a helyreállítást vagy az üzemszünetet. Sok szerződés tartalmaz együttműködési kötelezettségeket, például az időben végzett frissítéseket és a kár azonnali bejelentését. Hogy az egyedi esetben mi érvényes, azt a biztosítójával tisztázza. Kiberbiztosítás: mi számít káresetben →
Konténer: A konténer egy elszigetelt futtatókörnyezet, amely egy alkalmazást az összes függőségével együtt egy image-ből indít el, például Dockerrel. A konténerben lévő PHP az image-ből származik, nem a gazdarendszerből. A hoszton végzett frissítés ezért nem javítja; az image-et újra kell építeni, és a konténert újra kell indítani. PHP üzemeltetése konténerekben →
Kriptominer: A kriptominer olyan kártékony szoftver, amely idegen szervereken számol ki kriptovalutát. Tipikus jelei a tartósan magas CPU-terhelés és az ismeretlen folyamatok. Egy miner azt mutatja, hogy a támadó kódot tud futtatni; a szervert ilyenkor feltörtnek kell tekinteni. Kriptobányász a webszerveren: jelek és teendők →

L

Least Privilege: A Least Privilege (a minimális jogosultság elve) azt jelenti, hogy minden felhasználó és minden folyamat csak azokat a jogokat kapja, amelyekre valóban szüksége van. Ha a PHP szűk jogokkal fut, a támadó egy feltörés után kevesebb kárt okozhat. Ez érinti a rendszerfelhasználókat, a fájljogosultságokat, az adatbázis-fiókokat és a rendszergazdai hozzáféréseket. Least Privilege: a webszerver-felhasználó jogai →
Lessons Learned: A lessons learned egy incidens utólagos feldolgozása: mi történt, mi ment jól, min kell változtatni? A cél konkrét intézkedések felelősökkel és határidőkkel, nem a felelősök keresése. Az eredmények beépülnek a vészhelyzeti tervbe, a javítási folyamatba és a képzésekbe. Lessons learned: jobbá válni az incidens után →
LFI: LFI-ről (Local File Inclusion) akkor van szó, ha egy alkalmazás olyan helyi fájlt von be, amelynek útvonalát a támadó befolyásolhatja. Így konfigurációs fájlok olvashatók, vagy bizonyos körülmények között bejuttatott kód futtatható. Védelmet a felhasználói bevitelből származó fájlnevek helyett a rögzített engedélylisták nyújtanak. Local File Inclusion megelőzése PHP-ban: LFI és RFI →
LiteSpeed: A LiteSpeed egy webszerver, amely nagyrészt kompatibilis az Apache-konfigurációkkal, például a .htaccess-szel, és a PHP-t a saját LSAPI felületén keresztül köti be. A tárhelyszolgáltatóknál elterjedt; az OpenLiteSpeed a szabad változat. A LiteSpeed a PHP-csapat szerint a PHP2Shell által érintett üzemmódok közé tartozik. LiteSpeed és LSAPI: a PHP frissítése →

M

Megosztott tárhely (shared hosting): Megosztott tárhelynél sok ügyfél osztozik egy szerveren, amelyet a tárhelyszolgáltató üzemeltet. A tárhelyszolgáltató felel a PHP-ért, az operációs rendszerért és a webszerverért, az ügyfél az alkalmazásáért. A PHP2Shell esetében ez azt jelenti: kérdezze meg a tárhelyszolgáltatótól a javítási állapotot, és ellenőriztesse a saját weboldalát nyomok szempontjából. Megosztott tárhely: mit tesz a szolgáltató, és mit kell Önnek tennie →
memory_limit: A memory_limit azt korlátozza, mennyi memóriát foglalhat egy PHP-szkript; az alapértelmezés 128 MB. Ha a határt elérik, a PHP Out-of-Memory hibával megszakad. A CVE-2026-109618 ellen a php.net átmenetileg memory_limit=-1 rögzített beállítást javasol, valamint a konténeren vagy cgroup-on keresztüli memóriahatárt. A memory_limit helyes beállítása →
Menedzselt szerver: Menedzselt szervernél a szolgáltató saját szervert bocsát rendelkezésre, és szerződésben rögzített részét átveszi az üzemeltetésnek, gyakran az operációs rendszer és a PHP frissítéseit. Hogy pontosan mi tartozik bele, az a szerződésben áll, és a szolgáltatók között nagyon eltérő. Kétség esetén a javításokért való felelősséget írásban kell megerősíttetni. Menedzselt szerver: a felelősség tisztázása →
mod_php: A mod_php az Apache webszerver PHP-modulja. A PHP ilyenkor közvetlenül az Apache-folyamatban fut, többnyire annak felhasználói jogaival. A PHP-csapat a PHP2Shell kockázatát a mod_php esetében értékeli a legmagasabbra; ott már azelőtt bemutattak egy exploitot, hogy az alkalmazáskód egyáltalán futna. mod_php elmagyarázva: a PHP az Apache-folyamatban →
ModSecurity: A ModSecurity egy elterjedt nyílt forráskódú WAF, amely modulként fut az Apache-ban, az Nginxben vagy más webszerverekben. Szabályok alapján értékeli a kéréseket, és naplózhatja vagy blokkolhatja őket. Többnyire az OWASP Core Rule Settel együtt használják. A ModSecurity és az OWASP Core Rule Set alkalmazása →
Monitoring: A monitoring a rendszerek folyamatos felügyelete, például az elérhetőségé, a terhelésé, a naplófájloké és a fájlváltozásoké. A biztonsági monitoring célzottan keres rendellenességeket, például új PHP-fájlokat vagy a webszerver által indított shelleket. Csak akkor segít, ha valaki időben ki is értékeli a jelzéseket. Biztonsági monitoring webszerverekhez →

N

Nginx: Az Nginx egy elterjedt webszerver és reverse proxy. A PHP-t nem maga futtatja, hanem a kéréseket FastCGI-n keresztül a PHP-FPM-nek adja tovább. Fontos egy olyan konfiguráció, amely csak valódi PHP-fájlokat ad át a PHP-nak, és kihagyja a feltöltési mappákat. Nginx védelme PHP-FPM-mel →
NIS2: A NIS2 egy uniós irányelv, amely sok vállalkozásra és intézményre kockázatkezelési és biztonsági incidensek bejelentésére vonatkozó kötelezettségeket állapít meg. Lényegesen több ágazatot és vállalkozásméretet érint, mint az előző szabályozás. Hogy az Ön vállalkozása hatálya alá tartozik-e, azt a nemzeti átültetés alapján és jogi tanácsadással érdemes tisztázni. NIS2 és a webszerverek biztonsága →

O

OPcache: Az OPcache a PHP mellé szállított bájtkód-gyorsítótár. A már lefordított kódot a közös memóriában tárolja, hogy a PHP-fájlokat ne kelljen minden kérésnél újra lefordítani. Frissítés vagy tisztítás után a gyorsítótárat ki kell üríteni, illetve a PHP-t újra kell indítani, különben a régi kód tovább futhat. Az OPcache elmagyarázva: a PHP bájtkód-gyorsítótára →
open_basedir: Az open_basedir korlátozza, mely könyvtárakhoz férhetnek hozzá a PHP-szkriptek fájlfüggvényekkel. Több weboldalt kiszolgáló szervereken ez megakadályozza, hogy az egyik oldal egyszerűen olvassa egy másik fájljait. Teljes elkülönítést nem jelent; ide tartoznak a különálló rendszerfelhasználók és FPM-poolok is. open_basedir és weboldalankénti elkülönítés →
Origin szerver: Az origin szerver a tényleges webszerver egy CDN vagy reverse proxy mögött. Ha az IP-címén keresztül közvetlenül is elérhető, a támadók megkerülhetik az előtte álló védelmet. Ezért az origin csak a CDN-ről vagy a proxytól fogadhat kapcsolatokat. Cloudflare védelmi szabályok a PHP2Shell ellen: mit tudnak és mit nem →
Out of Memory: Az Out of Memory az az állapot, amikor egy program nem kap több memóriát, és le kell állnia. A PHP-ban ez akkor történik, ha túllépik a memory_limit értékét. A CVE-2026-109618 esetében egy ilyen megszakadás úgy szakíthatja félbe a PHP-t, hogy a kéréseket leíró adatok csak részben vannak inicializálva. memory_limit és Out-of-Memory: mi történik belül →
OWASP CRS: Az OWASP Core Rule Set (CRS) egy szabadon elérhető szabálykészlet a ModSecurityhez és a kompatibilis WAF-okhoz. Felismeri a tipikus támadási osztályokat, például az SQL-injectiont vagy a command injectiont. A szabályokat az alkalmazáshoz kell igazítani, különben a jogos kéréseket is blokkolják. A ModSecurity és az OWASP Core Rule Set alkalmazása →
OWASP Top 10: Az OWASP Top 10 a webalkalmazások legfontosabb kockázatainak rendszeresen frissített listája, amelyet a nonprofit OWASP Foundation ad ki. A fejlesztés, az ellenőrzések és a képzések alapjául szolgál. Kiegészítésként az OWASP a Cheat Sheeteket kínálja konkrét ellenintézkedésekkel.

P

PECL: A PECL (PHP Extension Community Library) a C-ben írt, nem a standard terjedelemhez tartozó PHP-bővítmények jegyzéke. Az ilyen bővítményeknek illeszkedniük kell a telepített PHP-verzióhoz. A PHP főverziójának váltása után gyakran újra kell építeni vagy le kell cserélni őket. A PHP-bővítmények (extensions) megértése →
PHP: A PHP egy szkriptnyelv, amely főként webszervereken fut, és ott weboldalakat állít elő. Sok elterjedt CMS és webshoprendszer, például a WordPress, a TYPO3 vagy a Shopware PHP-ban íródott. A PHP-értelmezőben lévő rés ezért minden rajta futó alkalmazást érint, függetlenül azok saját frissítési állapotától. Mi a PHP? A programozási nyelv elmagyarázva →
php-cgi: A php-cgi a PHP CGI-n vagy FastCGI-n keresztüli üzemeltetésre szolgáló programja. A PHP-csapat szerint a PHP2Shell által érintett üzemmódok közé tartozik. Ahol a php-cgi még használatban van, érdemes megvizsgálni, lehetséges-e az átállás PHP-FPM-re. php-cgi: kockázatos régi örökség →
PHP-FPM: A PHP-FPM (FastCGI Process Manager) egy külön szolgáltatás, amely a PHP-folyamatokat poolokban kezeli, és FastCGI-n keresztül fogadja a webszerver kéréseit. Ma ez a szokásos üzemmód Nginx mellett és sok Apache-szerveren. A PHP-frissítés után a PHP-FPM-et újra kell indítani, hogy ne fussanak tovább régi folyamatok. PHP-FPM elmagyarázva: folyamatkezelő, poolok és workerek →
php.ini: A php.ini a PHP központi konfigurációs fájlja. Korlátokat, biztonsági és hibabeállításokat határoz meg, például a memory_limit vagy a display_errors értékét. Gyakran minden SAPI-hoz (FPM, CLI, Apache) külön php.ini tartozik, amelyeket külön kell gondozni. A php.ini elmagyarázva: felépítés, szintek és elsőbbség →
PHP2Shell: A PHP2Shell a magában a PHP-ban lévő két kritikus rés, a CVE-2026-109618 és a CVE-2026-109619 neve, egyenként CVSS v4.0 9,2 értékkel. Lehetővé teszik kártékony kód távoli futtatását bejelentkezés nélkül. A PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzióban javították őket, 2026. 10. 21-én kiadva. Mi az a PHP2Shell? A rés egyszerűen elmagyarázva →
php_admin_value: A php_admin_value egy PHP-beállítást úgy rögzít az FPM-poolban vagy az Apache-konfigurációban, hogy az alkalmazások ini_set()-tel vagy .htaccess-szel ne tudják felülírni. A kapcsolókhoz php_admin_flag létezik. A php.net ezt az utat ajánlja a PHP2Shell elleni átmeneti intézkedésekhez, például a memory_limit esetében. php_admin_value: beállítások zárolása a felülírás ellen →
Plesk: A Plesk egy elterjedt webszerver-kezelőpanel, amellyel domainek, PHP-verziók és weboldalankénti kezelők állíthatók be. Saját PHP-csomagokat hoz, de a disztribúció PHP-csomagjait is használhatja. Backportok esetén a Plesk továbbra is régebbi számot, például 8.2.34-et mutathat, noha a javítás megtörtént. Plesk-szerver: PHP-verziók ellenőrzése és javítása →
post_max_size: A post_max_size azt határozza meg, mekkora lehet egy POST-kérés teljes tartalma; az alapértelmezés 8 MB. A PHP2Shell elleni átmeneti intézkedésként a php.net 8M értéket nevez meg feltöltés nélküli weboldalakra, és 32M-t feltöltésekkel. Az upload_max_filesize-nak ez alatt kell lennie. A post_max_size és az upload_max_filesize értelmes korlátozása →
Proof of Concept: A Proof of Concept (PoC) annak bizonyítéka, hogy egy rés kihasználható, gyakran egyszerű demonstrációs kód formájában. A gyártóknak és kutatóknak az értékelést szolgálja, a támadóknak azonban mintául is szolgálhat. Egy közzétett PoC ezért általában növeli a javítás sürgősségét.

R

Ransomware: A ransomware titkosítja az adatokat, és a feloldásért váltságdíjat követel, gyakran az ellopott adatok közzétételével való fenyegetéssel együtt. Egy feltört webszerver erre belépési pont lehet. A leghatékonyabb védelem a különálló, tesztelt mentések és egy vészhelyzeti terv. Mentési stratégia szerverhez: mentések a 3-2-1 szabály szerint →
RCE: Az RCE (Remote Code Execution) azt jelenti, hogy egy támadó távolról saját kódot futtathat egy idegen rendszeren. Ha ehhez nincs szükség bejelentkezésre, unauthenticated RCE-ről beszélünk, amely a webszerver-rések legsúlyosabb osztálya. RCE-vel a támadó adatokat olvashat, hátsó ajtókat hozhat létre, és tovább visszaélhet a szerverrel. Mi az a PHP2Shell? A rés egyszerűen elmagyarázva →
Rendszerkeményítés (hardening): A keményítés (hardening) azt jelenti, hogy egy rendszert úgy állítanak be, hogy a lehető legkisebb támadási felületet nyújtsa: csak a szükséges szolgáltatások, szűk jogok, biztonságos alapbeállítások. PHP-s szervereknél ide tartoznak például a különálló poolok, a tiltott függvények, és a PHP-végrehajtás tiltása a feltöltési mappákban. A keményítés korlátozza a károkat, de nem pótolja a frissítéseket. Szerverkeményítés PHP-webszerverekhez →
Reverse Proxy: A reverse proxy fogadja az internetről érkező kéréseket, és továbbítja őket egy vagy több mögötte lévő szervernek. Átveheti a TLS-t, elosztja a terhelést, és a szűrőszabályok vagy egy WAF helyeként szolgálhat. Védelmet csak akkor nyújt, ha a mögötte lévő szerverek közvetlenül nem is elérhetők. Feltöltési kérések szűrése a peremen: esélyek és kockázatok →
RFI: Az RFI (Remote File Inclusion) az a változat, amelynél egy alkalmazás idegen címről tölt be és futtat kódot. A PHP-ban az allow_url_include=Off beállítás, amely régóta alapértelmezett, megakadályozza távoli fájlok beillesztését. A régi alkalmazásokat és konfigurációkat érdemes erre ellenőrizni. Local File Inclusion megelőzése PHP-ban: LFI és RFI →
Riasztási szint: A BSI a fenyegetettségi helyzetet a biztonsági figyelmeztetéseknél szintekbe sorolja, amelyeket színekkel is jelölnek. A 3. szint (narancs) üzletkritikus helyzetet jelent, amely a szokásos működést jelentősen megzavarhatja. A PHP2Shell esetében a 3. riasztási szint / narancs érvényes. BSI narancs riasztási szint: mit jelent a besorolás →
Root szerver: A root szerver egy bérelt szerver, amelyen az ügyfél teljes rendszergazdai jogokkal rendelkezik. Ezzel a frissítésekért, a keményítésért és a felügyeletért való teljes felelősség is az ügyfélnél van. A szolgáltató csak a hardvert és a hálózatot biztosítja. Root szerver és vServer saját védelme →

S

SAPI: A SAPI (Server Application Programming Interface) az a felület, amelyen keresztül a PHP a környezetével kommunikál, például az Apache-csal, a PHP-FPM-mel vagy a parancssorral. Hogy melyik SAPI van használatban, az határozza meg, hogyan indulnak, használódnak újra és indulnak újra a PHP-folyamatok. A PHP2Shell esetében a PHP-csapat szerint több üzemmód érintett, a mod_php a legmagasabb kockázattal. A SAPI elmagyarázva: hogyan beszél a PHP a webszerverrel →
SEO-spam: A SEO-spam bejuttatott oldalak, linkek vagy átirányítások, amelyekkel a támadók idegen ajánlatokat helyeznek el a keresőmotorokban. Gyakran csak a keresőmotorok vagy a Google felől érkező látogatók látják a manipulált tartalmakat. A tisztítás mellett ezután a Google Search Console-ban is ellenőrzésre van szükség. SEO-spam és idegen oldalak a Google-indexben →
serialize_handler: A session.serialize_handler határozza meg, milyen formátumban tárolja a PHP a munkamenet-adatokat, például php, php_binary vagy php_serialize. A CVE-2026-115560-ra vonatkozó tudnivaló csak egy szokatlan konfigurációt érint, amelyben ezt a formátumot futásidőben átállítják, és a session upload progress aktív. A következő hibajavító kiadásig megoldás a session.upload_progress.enabled=0. CVE-2026-115560: a session upload progress tudnivalója →
Session: A session (munkamenet) összekapcsolja ugyanannak a látogatónak több kérését, például a bejelentkezéshez vagy a kosárhoz. A PHP az adatokat a szerver oldalán tárolja, és a böngészőnek munkamenet-azonosítót ad, alapértelmezetten a PHPSESSID cookie-ban. Aki ismer egy idegen munkamenet-azonosítót, bizonyos körülmények között e felhasználóként léphet fel. Munkamenetek és cookie-k a PHP-ban →
session.upload_progress: A session upload progress egy PHP-funkció, amely a folyamatban lévő fájlfeltöltések előrehaladását a munkamenetben (session) tárolja; alapértelmezetten be van kapcsolva. A php.net átmenetileg session.upload_progress.enabled=0 beállítást javasol a php.ini-ben, az FPM-poolban vagy a szerverkonfigurációban, majd az összes worker újraindítását. A beállítás önmagában a szakmai beszámolók szerint nem zárja le mindkét PHP2Shell-rést; a frissítés kötelező marad. A session.upload_progress kikapcsolása: helyesen és tartósan →
SIEM: A SIEM (Security Information and Event Management) sok rendszer naplóadatait gyűjti központilag, és biztonsági események szempontjából értékeli. Így felismerhetők olyan összefüggések, amelyek az egyes naplókban elvesznek. A SIEM-nek gondozott szabályokra és a jelzéseket feldolgozó emberekre van szüksége. Biztonsági monitoring webszerverekhez →
Skimming: Webshopokban a skimming során a támadók JavaScriptet csempésznek a fizetési folyamatba, amely kiolvassa és elküldi a fizetési és ügyféladatokat. A kód gyakran téma-fájlokban, követőszkriptekben vagy adatbázis-bejegyzésekben rejlik. Az ügyfelek ebből semmit sem vesznek észre, a kereskedő pedig gyakran csak a fizetési szolgáltatók jelzéseiből. Feltört webshop? IT-biztonság kereskedőknek →
SQL-injection: SQL-injection esetén a támadó bevitelen keresztül saját adatbázis-parancsokat csempész egy alkalmazásba. Így adatok olvashatók ki vagy módosíthatók. Védelmet az összeállított SQL-szövegek helyett a helyőrzőkkel ellátott előkészített utasítások (prepared statements) nyújtanak. SQL-injection megelőzése PHP-ban →
SSRF: Az SSRF (Server-Side Request Forgery) egy alkalmazást arra késztet, hogy a támadó megbízásából kéréseket küldjön más címekre, belső rendszerekre is. Így elérhetővé válnak olyan szolgáltatások, amelyek kívülről valójában le vannak árnyékolva. Védelmet a célpontokra vonatkozó engedélylisták és a belső címtartományok tiltása nyújt. Server-Side Request Forgery (SSRF) megelőzése PHP-ban →
Superglobals: A superglobalok olyan változók, amelyeket a PHP minden szkriptben rendelkezésre bocsát, például a $_GET, $_POST, $_COOKIE, $_FILES, $_SERVER és $_SESSION. Az aktuális kérés adatait tartalmazzák, amelyek nagyrészt a látogatótól származnak. Minden bennük lévő adatot megbízhatatlanként kell kezelni és ellenőrizni. Szuperglobálisok: $_GET, $_POST, $_FILES és társaik →
sury.org: A sury.org Ondřej Surý csomagtára aktuális és régebbi PHP-verziókkal Debianhoz és Ubuntuhoz. Harmadik fél ajánlata, nem a Debian biztonsági archívuma. A beszámolók szerint ott az 5.6-tól a 8.5-ig minden ághoz biztosítottak buildeket. A sury.org-tároló: PHP-csomagok harmadik féltől →

T

Threat Hunting: A threat hunting a támadók aktív keresése a saját hálózatban, anélkül hogy figyelmeztetés lenne. A kiindulópont hipotézis, például: indított-e egy webszerver-folyamat shellt 10. 20. óta? Így olyan feltörések találhatók meg, amelyeket az automatikus eszközök átnéznek. Figyelmeztető jel: a webszerver shellt indít →
TISAX: A TISAX az autóiparban használt vizsgálati és információcsere-eljárás az információbiztonságra. Az Autóipari Szövetség (VDA, Verband der Automobilindustrie) követelménykatalógusán alapul, és az ENX Association üzemelteti. A beszállítóknak ezzel kell igazolniuk a biztonsági szintjüket a gyártók felé. ISO 27001 és TISAX: mit érintenek a webszerverek →
TLS: A TLS (Transport Layer Security) titkosítja a böngésző és a szerver közötti kapcsolatot; a HTTPS-ről ismerhető fel. Jelenleg a TLS 1.2 és az 1.3 ajánlott, a régebbi protokollverziókat ki kell kapcsolni. A TLS az adatokat útközben védi, nem magán a szerveren lévő rések ellen. TLS és HTTPS helyes konfigurálása →
Type Juggling: Type juggling a PHP automatikus típuskonverziója, például a laza összehasonlításnál a == operátorral. Ennek következtében egyenlőnek számíthatnak olyan értékek, amelyek nem azok, ami jelszó- vagy tokenellenőrzéseknél veszélyes. Védelmet a szigorú összehasonlítás === jellel és a hash_equals() titkokhoz nyújt. Type juggling PHP-ban: laza összehasonlítások mint biztonsági kockázat →

U

upload_max_filesize: Az upload_max_filesize egyetlen feltöltött fájl méretét korlátozza; az alapértelmezés 2 MB. Az értéknek kisebbnek kell lennie a post_max_size-nál, mert a fájl a POST-kérés része. A túl nagyvonalú értékek haszon nélkül növelik a támadási felületet. A post_max_size és az upload_max_filesize értelmes korlátozása →
.user.ini: A .user.ini fájlok könyvtárankénti PHP-beállítások, amelyeket a PHP-FPM és a CGI értékel ki. Ezekkel a weboldal-üzemeltetők szerverhozzáférés nélkül módosíthatnak egyes értékeket, de csak olyanokat, amelyeket a PHP erre felad. A biztonsági szempontból lényeges előírásokat, például a PHP2Shell elleni session.upload_progress.enabled=0 értéket a php.net szerint nem a .user.ini-n keresztül kell beállítani. A php.ini elmagyarázva: felépítés, szintek és elsőbbség →

V

VdS 10000: A VdS 10000 a VdS Schadenverhütung irányelve a kis- és középvállalkozások információbiztonságára. Karcsúbb, mint az ISO 27001, és a kkv-k lehetőségeire szabták. E szerint tanúsítás is lehetséges. VdS 10000: információbiztonság a kis- és középvállalkozásoknak →
Virtuális javítás (virtual patching): A virtuális javítás az alkalmazás előtt blokkolja az ismert résre irányuló támadásokat, többnyire WAF-fal, a sebezhető kód módosítása nélkül. Időt nyer a valódi frissítés lehetővé válásáig. A PHP2Shell esetében például a Cloudflare arra figyelmeztet, hogy a kérésadatok alapján felállított szabályok önmagukban nem elegendők; a frissítés kötelező marad. WAF és virtuális javítás PHP-hez →
vServer: A vServer (virtuális szerver) egy megosztott hardveren lévő virtuális gép saját operációs rendszerrel és többnyire root hozzáféréssel. A biztonságra ugyanaz érvényes, mint a root szervernél: a frissítések és a keményítés az ügyfél dolga. Sok vServeren előre telepített panelek, például a Plesk futnak. Root szerver és vServer saját védelme →
Vészhelyzeti terv: Az IT-vészhelyzeti terv rögzíti, hogy ki mit tesz egy incidensnél: kapcsolattartók, döntési utak, első lépések, újraindítás. Offline módon is elérhetőnek kell lennie arra az esetre, ha a rendszerek kiesnek. A rendszeres gyakorlatok megmutatják, hogy éles helyzetben működik-e. IT-vészhelyzeti terv készítése webszerverekhez →

W

WAF: A WAF (Web Application Firewall) az alkalmazás előtt ellenőrzi a HTTP-kéréseket, és blokkolja az ismert támadási mintákat. Futhat felhőszolgáltatásként, proxyként vagy webszerver-modulként. Időt nyer, de nem pótolja a frissítést, és megkerülhető, ha a szerver közvetlenül is elérhető. WAF és virtuális javítás PHP-hez →
Webshell: A webshell egy szkript, amelyet a támadók egy webszerveren helyeznek el, hogy a böngészőn keresztül távirányítsák. Gyakran kicsi, elfedett, és feltöltési vagy gyorsítótár-mappákban van elrejtve. A webshell egy PHP- vagy CMS-frissítés után is megmarad, és célzottan keresni kell. Webshell felismerése és eltávolítása →

X

XSS: Az XSS (Cross-Site Scripting) azt jelenti, hogy idegen JavaScript fut egy weboldalon keresztül mások böngészőjében. Ezzel munkamenetek vehetők át, vagy űrlapbevitelek olvashatók le. Védelmet a kimenetek következetes kódolása és a Content Security Policy nyújt. XSS megelőzése PHP-ban: a Cross-Site Scripting biztonságos kivédése →
XXE: Az XXE (XML External Entities) azt használja ki, hogy az XML-elemzők külső hivatkozásokat tölthetnek be a dokumentumokban. Ezáltal bizonyos körülmények között fájlok olvashatók a szerverről, vagy belső kérések indíthatók. Védelmet az nyújt, ha a nem megbízható XML-adatok feldolgozásakor kikapcsolják a külső entitások betöltését. XML External Entities (XXE) megelőzése PHP-ban →

Z

ZAC: A rendőrség Zentrale Ansprechstellen Cybercrime (ZAC), azaz a kiberbűnözés központi kapcsolattartó pontjai olyan szakosodott kapcsolattartó helyek, amelyek kibertámadás áldozatává vált vállalkozásoknak és hatóságoknak szólnak. Minden német tartományban és a BKA-nál (a német szövetségi bűnügyi hivatalnál) megtalálhatók. Feljelentéseket vesznek fel, és tanácsot adnak a további eljáráshoz. Feljelentés tétele: Zentrale Ansprechstellen Cybercrime →
Zend Engine: A Zend Engine a PHP-értelmező magja. A PHP-kódot belső utasításokká (opcode-okká) fordítja, végrehajtja őket, és kezeli a memóriát. A Zend Engine hibái minden PHP-alkalmazást érintenek, és csak PHP-frissítéssel háríthatók el. A Zend Engine: a PHP szíve →
Zero-Day: A zero-day olyan rés, amelyet kihasználnak vagy nyilvánosan ismert, mielőtt a gyártó javítást bocsátana rendelkezésre. Az üzemeltetőknek ilyenkor nulla napjuk van a felkészülésre. A javításig csak átmeneti intézkedések, elszigetelés és felügyelet segít. A javítás és a támadás közötti időablak →

Azonnali kapcsolat

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.

WhatsApp-vészhívás Hívás