A WordPress megerősítése a bővítményeken túl: 12 szerver- és wp-config-beállítás

A biztonsági bővítmények segítenek, de van egy egyértelmű korlátjuk: a WordPressen belül futnak, vagyis csak azután, hogy a kérés már elérte a PHP-t. A legerősebb intézkedések lejjebb helyezkednek el — a webszervernél és a wp-config.php fájlban, ahová egy bővítmény nem ér el. Ezeket a beállításokat egyszer konfigurálod; utána csendben aktívak maradnak, és nem lassítják az oldalt.

Az alábbiakban 12 konkrét dolgot találsz, amelyeket magad is ellenőrizhetsz, vagy megkérheted a tárhelyszolgáltatódat, hogy alkalmazza őket. Nem helyettesítik a józan észt (jó jelszavak, időben végzett frissítések), de jelentősen megemelik a lécet bárki számára, aki be akar jutni. És egy őszinte figyelmeztetés: ha valaki „feltörhetetlen” oldalt ígér neked, fordulj el — a biztonság rétegekből áll, nem egy pipálandó jelölőnégyzet.

Fájljogosultságok, amelyek nem hagynak nyitva ajtókat

A rossz jogosultságok az egyik leggyakoribb probléma. Az egyszerű szabály:

• könyvtárak: 755
• fájlok: 644
• wp-config.php: 600 (vagy 640), csak a szerver felhasználója számára olvasható

Soha ne legyen 777 semmin — az azt jelenti, hogy „bárki írhat”. Ellenőrizd a tulajdonjogot is: mindennek annak a felhasználónak a tulajdonában kell lennie, amely alatt a PHP fut, nem a rootnak. Jó jel, ha maga a WordPress nem tudja közvetlenül szerkeszteni a sablonfájlokat — ha tudja, akkor egy fiókot feltörő támadó is tudja. A wp-config.php külön kezelést érdemel, mert az adatbázis-hitelesítő adataidat tartalmazza.

wp-config.php — ahol a hangnem eldől

Ez a fájl a telepítés szíve. Néhány sor, amely számít:

• Egyedi kulcsok és sók (salts), a hivatalos WordPress-szolgáltatásból generálva — érvénytelenítik az ellopott munkameneteket.
• define('DISALLOW_FILE_EDIT', true); — eltávolítja a sablon-/bővítményszerkesztőt a felügyeletből, így senki nem tud kódot befecskendezni egy feltört fiókból.
• define('FORCE_SSL_ADMIN', true); — HTTPS-t kényszerít a felügyeleti területen.
• define('WP_DEBUG', false); és a WP_DEBUG_DISPLAY kikapcsolva éles környezetben, hogy a hibák ne fedjék fel a szerver elérési útjait.

Opcionálisan helyezd a wp-config.php fájlt egy szinttel a nyilvános gyökér fölé, és változtasd meg a táblák előtagját wp_-ről a sajátodra. Nem csodaszerek, de csökkentik a támadási felületet.

Webszerver-szabályok (Apache / Nginx)

Itt blokkolod a hozzáférést, még mielőtt a PHP egyáltalán elindulna.

• Tiltsd le a közvetlen hozzáférést az érzékeny fájlokhoz: wp-config.php, .htaccess, readme.html, xmlrpc.php (ha nem használsz XML-RPC-t).
• Kapcsold ki a könyvtárlistázást (Options -Indexes az Apache-on), hogy senki ne böngészhesse a mappáidat.
• A legfontosabb: állítsd le a PHP-végrehajtást a wp-content/uploads mappán belül. Ha egy támadónak sikerül feltöltenie egy álcázott .php fájlt, ott végrehajtás nélkül az ártalmatlan.

Az Nginx-en ezek location blokkok; az Apache-on szabályok a .htaccess-ben vagy a konfigurációban. Megosztott tárhelyen kérd meg a támogatást, hogy alkalmazza őket — ez teljesen normális kérés.

Biztonsági fejlécek — válaszok, amelyek megmondják a böngészőnek a szabályokat

A HTTP-fejlécek nem állítanak meg egy szerveroldali feltörést, de sok böngészőoldali támadást bezárnak (clickjacking, tartalomtípus-találgatás, HTTP-re való visszaminősítés). Érdemes beállítani:

• Strict-Transport-Security (HSTS) — arra kényszeríti a böngészőt, hogy csak HTTPS-t használjon.
• X-Content-Type-Options: nosniff — megállítja a fájltípus-találgatást.
• X-Frame-Options: SAMEORIGIN (vagy CSP frame-ancestors) — clickjacking elleni védelem.
• Referrer-Policy és Permissions-Policy — korlátozzák, mi szivárog ki, és mely böngésző-API-k engedélyezettek.

Állítsd be őket szerverszinten vagy a platformod fejlécszabályain keresztül. Az eredményt bármely ingyenes, nyilvános fejlécellenőrzővel ellenőrizheted.

Adatbázis, fiókok és karbantartás

Az utolsó réteg a higiénia:

• Az adatbázis-felhasználónak csak azokkal a jogokkal kell rendelkeznie, amelyekre a saját adatbázisán szüksége van — nem egy globális root fiókkal.
• Ne legyen „admin” felhasználónév, és legyenek hosszú, egyedi jelszavak; ideális esetben kétfaktoros hitelesítés az admin fiókokon.
• Tartsd a PHP-t és a WordPresst támogatott verzión — sok betörés régi szoftverből ered, nem kifinomult támadásokból.
• Egy automatizált, tesztelt biztonsági mentés, amelyet a szerveren kívül máshol tárolsz.

Így néz ki egy komolyan kezelt telepítés az MPO Web Studiónál: már megerősítve szállítjuk az oldalakat, távolról, országosan, ezekkel a beállításokkal a kezdetektől elvégezve. Ha szeretnél véleményt a jelenlegi oldaladról, írj nekünk WhatsAppon — őszintén megmondjuk, mit érdemes megváltoztatni.