Ugrás a tartalomhoz

Sütibeállítások

Típusonként válassza ki, mely sütiket engedélyezi. Választását bármikor módosíthatja a Sütibeállítások linken, amely minden oldal alján megtalálható. Adatvédelmi nyilatkozat

Szükséges

Mindig bekapcsolva

A bejelentkezéshez, a kosár megőrzéséhez és a választásai megjegyzéséhez szükségesek. Ezek mindig be vannak kapcsolva.

Milyen sütik?
  • weboke_sessie, weboke_klant, weboke_remember: a munkamenet és a bejelentkezve maradás
  • weboke_basket: a kosár
  • wkBtwIncl: az árak megjelenítése ÁFÁ-val vagy anélkül
  • wok_cookies: a sütiválasztás, 12 hónap

Méri, melyik hirdetés vezet látogatáshoz vagy rendeléshez, hogy ne fizessünk hatástalan hirdetésekért.

Milyen sütik?
  • Google Ads a Google Tag Manageren keresztül (_gcl_au, _gcl_aw), legfeljebb 90 napig
  • OpenAI Ads, hirdetések a ChatGPT-ben
  • wok_aff: melyik partnerünk ajánlására érkezett (partnerprogram), 60 nap

4,6

Ország és nyelv

Minden országnak saját oldala van, az adott ország áraival és ÁFA-jával.

Megtekintés

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:

MiJogosultságJelentés
Mappák755A tulajdonos mindent megtehet, mások olvashatják és megnyithatják
Fájlok644A tulajdonos olvashatja és írhatja, mások csak olvashatják
wp-config.phpszigorúbb, például 600 vagy 640Csak 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 -Indexes

Sok 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.gz vagy database.sql a webmappában;
  • .git mappa 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.php a phpinfo() 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écMit csinál
Strict-Transport-SecurityCsak https-en keresztül (3.1 lecke)
X-Content-Type-Options: nosniffA 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-originEgy másik weboldalra mutató kattintásnál csak a domainneve kerül továbbításra, nem a teljes cím
Permissions-PolicyKikapcsolja azokat a böngészőfunkciókat, amelyeket a weboldala nem használ (kamera, mikrofon, helymeghatározás)
Content-Security-PolicyPontosan 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

1. Egy útmutató azt mondja: „állítsa a wp-content mappát 777-re, ha a feltöltés nem sikerül.” Mit gondol erről?



2. Mit csinál a DISALLOW_FILE_EDIT?



3. Miért helyezkedik el egy szerveren lévő tűzfal korábban a láncban, mint egy bővítményben lévő tűzfal?



4. Eltávolította a generator-tag-et. Biztonságban van most a weboldala a régi verziókban lévő biztonsági résekkel szemben?



5. Melyik fejléc akadályozza meg, hogy egy másik weboldal betöltse az Ön weboldalát egy láthatatlan keretben (frame)?



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.4. feladat: Mit mutat a weboldala mindenkinek?


Amit beír, és amit találunk, azt nem tároljuk. A böngészője megjegyzi a válaszait és azt, hogy teljesítette e a feladatot. Ha bejelentkezett, a Fiókomban csak azt tároljuk, hogy a feladat (majdnem) helyes volt; ott ezt is törölheti.

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.

A7.4b. feladat: Nincsenek elfelejtett maradványok a webmappában

Ez az ellenőrzés olyan elérési utakat kér le, amelyeket csak a saját weboldalánál szabad ellenőriztetni. Először kattintson a "Saját kódom megjelenítése" gombra, majd állítsa be azt a kódot TXT rekordként a _weboke-cursus.<az Ön domainje> címen, vagy fájlként a weboldalán (lásd a kódnál található magyarázatot).


Amit beír, és amit találunk, azt nem tároljuk. A böngészője megjegyzi a válaszait és azt, hogy teljesítette e a feladatot. Ha bejelentkezett, a Fiókomban csak azt tároljuk, hogy a feladat (majdnem) helyes volt; ott ezt is törölheti.

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.

Egy pillanat…

Domainek beállítása

Állítsa be domainenként a névszervereket, a tárhelyhez való kapcsolást és azt, hogy ki legyen a tulajdonos.

Domainek betöltése…