Modul 7 · 7.4
A weboldal megerősítése: jogosultságok, fejlécek és biztonsági bővítmények
Modul 7: Biztonság · Olvasási idő: 10 perc
Cél: E lecke után Ön képes lesz egy WordPress-weboldalt megerősíteni jogosultságokkal, beállításokkal és biztonsági fejlécekkel, valamint reálisan megítélni a biztonsági bővítmények értékét.
Kulcsfogalmak: megerősítés (hardening), fájljogosultságok (644, 755), DISALLOW_FILE_EDIT, nincs PHP az uploads mappában, mappalista, verzió elrejtése, X-Powered-By, biztonsági fejlécek, biztonsági mentés fájlok és .git a webmappában, WAF a szerveren, WAF egy bővítményben, kártevőkereső (malwarescanner)
Mit jelent a megerősítés
A megerősítés (hardening) azt jelenti: a weboldalt úgy állítjuk be, hogy egy hiba vagy biztonsági rés kevesebb kárt okozhasson. Ez nem helyettesíti a frissítéseket és az erős jelszavakat (7.2 és 7.3 lecke), de kisebbé teszi a következményeket. Gondoljon egy házra: a frissítések a zárak, a megerősítés pedig azt biztosítja, hogy egy betörő, aki mégis bejutott, ne jusson el a páncélszekrényhez.
Fájljogosultságok
Minden fájlnak és mappának a szerveren vannak jogosultságai: ki olvashatja, írhatja és futtathatja. Ezeket három számjegy írja le: a tulajdonos, a csoport és a világ többi része számára. A WordPress dokumentációjának irányelve:
| Mi | Jogosultság | Jelentés |
|---|---|---|
| Mappák | 755 | A tulajdonos mindent megtehet, mások olvashatják és megnyithatják |
| Fájlok | 644 | A tulajdonos olvashatja és írhatja, mások csak olvashatják |
| wp-config.php | szigorúbb, például 600 vagy 640 | Csak a tulajdonos (és esetleg a webszerver csoportja) olvashatja |
Hogy melyik érték működik a wp-config.php esetében, az attól függ, hogyan futtatja a tárhelyszolgáltatója a PHP-t: a legtöbb osztott tárhelynél a PHP az Ön saját felhasználójaként fut, ekkor elég a 600. Próbálja ki, és nézze meg, hogy a weboldal még mindig működik-e.
Soha ne legyen 777. Ez azt jelenti: a szerveren bárki írhat. Egy útmutató, amely azt mondja, hogy „állítsa a mappát 777-re, ha a feltöltés nem működik”, rosszul oldja meg a problémát. Egy jó minőségű tárhelynél erre soha nincs szükség.
Beállítások a wp-config.php fájlban
Néhány sor, amely sokat számít (a „ennyi, itt a vége a szerkesztésnek” sor előtt):
// Fájlok szerkesztésének letiltása a Vezérlőpultról (Megjelenés > Sablonszerkesztő és Bővítmények > Bővítményszerkesztő).
define( 'DISALLOW_FILE_EDIT', true );
// Hibaüzenetek soha ne jelenjenek meg a látogatók képernyőjén (5.4 lecke).
define( 'WP_DEBUG', false );A DISALLOW_FILE_EDIT beállítással eltűnik az a szerkesztő, amellyel a Vezérlőpultról módosíthatók a sablonok és bővítmények PHP-fájljai. Egy betörő, aki átveszi egy adminisztrátori fiókot, ezzel nem tud két kattintással kártékony kódot elhelyezni a sablonban. A bővítmények telepítése továbbra is lehetséges; ha ezt is tiltani szeretné (például egy olyan weboldalnál, amelyet ügyfél számára kezel), van a DISALLOW_FILE_MODS is, de ekkor a Vezérlőpulton keresztüli frissítések sem fognak működni.
Nincs PHP az uploads mappában, nincs mappalista
A wp-content/uploads mappában képek és dokumentumok helye van, PHP-fájloké soha. A betörők, akik egy biztonsági résen keresztül fel tudnak tölteni egy fájlt, éppen egy PHP-fájlt próbálnak ott elhelyezni, majd azt lehívni. Ezt egy .htaccess fájllal blokkolhatja az uploads mappában (LiteSpeed és Apache esetén):
<Files *.php>
Require all denied
</Files>Kapcsolja ki a mappák tartalmának megjelenítését is. Ha egy mappában nincs index.php vagy index.html, egyes webszerverek megjelenítik az összes fájl listáját („Index of /wp-content/uploads/2026/11”). Ez afféle kirakat azoknak, akik biztonsági mentéseket vagy érzékeny dokumentumokat keresnek. A webmappája .htaccess fájljában:
Options -IndexesSok tárhelyszolgáltató ezt már alapértelmezetten kikapcsolja. E lecke feladata ezt ellenőrzi.
Ne maradjanak maradványok a webmappában
Minden, ami a webmappában van, lehívható a weben keresztül, kivéve amit a szerver PHP-ként futtat vagy blokkol. Veszélyesek a következők:
- a wp-config.php másolatai (
wp-config.php.bak,wp-config.old,wp-config.php~egy szövegszerkesztőből): ezek tartalmazzák az adatbázis jelszavát, és szövegként kerülnek elküldésre (1.3 lecke); - biztonsági mentések, mint a
backup.zip,site.tar.gzvagydatabase.sqla webmappában; .gitmappa egy fejlesztőtől, amellyel valaki letöltheti a teljes kódot (és néha a jelszavakat is);- debug.log fájl a wp-content mappában (5.4 lecke);
- telepítési vagy tesztfájlok, mint az
info.phpaphpinfo()függvénnyel.
A biztonsági mentéseket a webmappán kívül vagy a szerveren kívül tárolja, és takarítsa el a maradványokat.
Verzió elrejtése: kis nyereség
A WordPress alapértelmezetten ezt írja a HTML-be:
<meta name="generator" content="WordPress 7.1.4" />és ugyanezt az RSS-hírcsatornába is. A PHP is néha megmutatja magát egy fejlécben: X-Powered-By: PHP/8.3.14. Ezek elrejtése ésszerű, de ne várjon tőle túl sokat: a betörők programjai egyszerűen kipróbálják a biztonsági rést, függetlenül attól, milyen verziót mutat, és a verziók gyakran levezethetők a szkriptek mögötti ?ver= paraméterből is. Az elrejtés takarítás, nem biztonság. Egy olyan weboldal, amely elrejti a verzióját, de nem frissít, ugyanolyan sebezhető.
Így teheti meg, egy saját kis bővítményben vagy a gyermek sablon (child theme) functions.php fájljában:
remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );A PHP-fejlécet pedig az expose_php = Off beállítással a tárhelyszolgáltató PHP-beállításaiban (DirectAdmin esetén a Select PHP version, Options alatt), vagy a .htaccess fájlban a Header unset X-Powered-By paranccsal.
Biztonsági fejlécek
Néhány fejléccel megmondhatja a böngészőnek, hogyan bánjon a weboldalával. A legfontosabbak:
| Fejléc | Mit csinál |
|---|---|
Strict-Transport-Security | Csak https-en keresztül (3.1 lecke) |
X-Content-Type-Options: nosniff | A böngésző nem próbálja kitalálni, milyen típusú fájl valami; megakadályozza, hogy egy feltöltött „kép” szkriptként fusson le |
X-Frame-Options: SAMEORIGIN vagy Content-Security-Policy: frame-ancestors 'self' | Más weboldalak nem jeleníthetik meg az Ön weboldalát egy keretben (frame); megakadályozza a clickjackinget (egy láthatatlan gomb az Ön weboldaláról valaki másénak a tetején) |
Referrer-Policy: strict-origin-when-cross-origin | Egy másik weboldalra mutató kattintásnál csak a domainneve kerül továbbításra, nem a teljes cím |
Permissions-Policy | Kikapcsolja azokat a böngészőfunkciókat, amelyeket a weboldala nem használ (kamera, mikrofon, helymeghatározás) |
Content-Security-Policy | Pontosan meghatározza, milyen forrásokból érkezhetnek szkriptek és stílusok. Erőteljes, de WordPress és bővítmények mellett nehéz jól beállítani; kezdje a Report-Only módban |
A .htaccess fájlban (LiteSpeed és Apache esetén):
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>Ezután tesztelje, hogy minden működik-e: beágyazott tartalom, fizetési gombok, egy chat-widget. Külső eszközök, mint a securityheaders.com és az internet.nl, megmutatják, mit küld a weboldala.
Biztonsági bővítmények, őszintén megvizsgálva
Sok biztonsági bővítmény létezik (például Wordfence, Solid Security, All-In-One Security, Sucuri). Ezek gyakran egyesítik a következőket: tűzfal, kártevőkereső, bejelentkezés-védelem, kétlépcsős azonosítás, értesítések és egy megerősítési lista. Hasznosak, de vannak korlátaik:
- Egy bővítményben lévő tűzfal (WAF) csak akkor indul el, amikor a PHP már fut. Egy rosszindulatú kérésnek előbb át kell haladnia a webszerveren és a PHP-n, mielőtt a bővítmény látná. Egy olyan biztonsági rést, amely egy közvetlenül meghívott PHP-fájlban van, vagy egy olyan támadást, amely magát a PHP-t terheli meg erősen, nem mindig állít meg. Egy tűzfal a szerveren (például ModSecurity, Imunify360 vagy a tárhelyszolgáltató tűzfala) korábban helyezkedik el a láncban, és többet állít meg, anélkül hogy az Ön csomagja végezné el a számítási munkát. Kérdezze meg a tárhelyszolgáltatóját, mi fut a szerveren.
- Egy kártevőkereső utólag talál. Egy kártevőkereső megmondja Önnek, hogy valami baj van. Ez értékes, de nem előz meg semmit. Egy kártevőkereső pedig, amely ugyanazon a szerveren fut, mint a feltört weboldal, maga is módosítva lehet a betörő által.
- Nem helyettesítik a frissítéseket. Egy bővítmény, amelyben ismert biztonsági rés van, akkor is sebezhető marad, ha mellette fut egy biztonsági bővítmény is. Egyes biztonsági szolgáltatások „virtuális patcheket” kínálnak, amelyek megállítják az ismert támadásokat, amíg Ön frissít; hasznos áthidaló megoldás, de nem helyettesítés.
- Maguk is bővítmények. Több kód, több frissítendő rész, néha saját biztonsági résük is van. Két biztonsági bővítmény egyszerre gyakran ütközik egymással.
- Számítási kapacitást igényelnek, különösen azok a kártevőkeresők, amelyek az Ön saját szerverén futnak.
Ésszerű választás: nézze meg először, mit tesz már a tárhelyszolgáltatója (tűzfal, kártevőkeresés, bejelentkezési kísérletek blokkolása). Egészítse ki azzal, ami hiányzik, ez leggyakrabban a kétlépcsős azonosítás és a bejelentkezési kísérletek korlátozása. Egy kiterjedt biztonsági bővítmény elsősorban olyan tárhelynél hasznos, amely önmagában keveset tesz.
Összefoglalás
- A megerősítés csökkenti egy hiba vagy biztonsági rés okozta kárt; nem helyettesíti a frissítéseket és a jelszavakat.
- Mappák 755, fájlok 644, a wp-config.php szigorúbb; soha 777.
- Kapcsolja be a DISALLOW_FILE_EDIT beállítást, blokkolja a PHP-t az uploads mappában, kapcsolja ki a mappalistákat, és takarítsa el a biztonsági mentéseket, a .git mappát és a debug.log fájlt a webmappából.
- A verzió elrejtése takarítás, nem biztonság; a biztonsági fejlécek segítenek a böngészőnek megvédeni a látogatóit.
- Egy tűzfal a szerveren többet állít meg, mint egy bővítmény; a biztonsági bővítmények kiegészítők, nem helyettesítők.
Kvíz
Feladat
A7.4 feladat: Mit mutat a weboldala mindenkinek? Adja meg weboldala címét. A program beolvassa a kezdőlapot és az RSS-hírcsatornát (/feed/), és ellenőrzi: nincs WordPress-verzió a HTML és a hírcsatorna generator-tag-jében, az X-Powered-By fejléc nem mutat PHP-verziót, és a weboldala küld-e X-Content-Type-Options: nosniff fejlécet, védelmet a keretek (frame) ellen (X-Frame-Options vagy frame-ancestors) és egy Referrer-Policy fejlécet? A HSTS (3.1 lecke) és a Permissions-Policy hiánya megengedett (narancssárga).
A7.4b feladat: Nincsenek elfelejtett maradványok a webmappában. Igazolja, hogy ez az Ön saját weboldala (TXT-rekord vagy fájl a feladat kódjával). A program ezután egy rövid, állandó listát kér le: a /wp-content/uploads/ mappát (nincs mappalista), a /.git/HEAD fájlt, a /wp-content/debug.log fájlt és néhány gyakori elnevezését a wp-config.php másolatainak. Jó eredmény, ha ezek közül egyik sem ad vissza tartalmat (404 vagy 403). A program semmi mást nem próbál ki, és semmit nem módosít.
Bővebben
Ezek a cikkek a WebOké vezérlőpultjainak lépéseit írják le; más vezérlőpultokon hasonlóan működnek.
- DirectAdmin útmutató 11.5: Fájlok és mappák engedélyei (chmod)
- DirectAdmin útmutató 11.4: Rejtett fájlok, például a .htaccess megjelenítése és módosítása
- DirectAdmin útmutató 15.10: Web Applikációs Tűzfal
- DirectAdmin útmutató 15.11: Imunify360: a weboldal vizsgálata kártevők szempontjából
- Fájlok letiltása .htaccess segítségével, például a plugin-googlemap2-proxy.php
- PHP-biztonság
- WordPress megerősítése (developer.wordpress.org, angol): https://developer.wordpress.org/advanced-administration/security/hardening/
- Biztonsági fejlécek (MDN, angol): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#security
