WordPress wp-config.php fájl haladó biztonsági beállításai – Teljes útmutató

A WordPress wp-config.php fájljában elvégezhető haladó biztonsági beállítások közé tartozik az adatbázis-hozzáférés védelme, a munkamenetkulcsok megerősítése, a fájlszerkesztés letiltása, a hibakeresési kimenet biztonságos kezelése, az SSL használatának kikényszerítése és a kritikus könyvtárútvonalak korlátozása. Röviden: a wp-config.php a WordPress webhelyed egyik biztonsági központja; a megfelelő beállításokkal csökkentheted a támadási felületet, mérsékelheted a jogosulatlan hozzáférés kockázatát, és egy esetleges biztonsági incidens során korlátozhatod a károkat.

A legtöbb WordPress-telepítést végző webhelytulajdonos a wp-config.php fájlt csupán egy technikai fájlnak tekinti, amelybe az adatbázis nevét, felhasználónevét és jelszavát kell beírni. Pedig ez a fájl egy éles webhely biztonsági architektúrájának kritikus eleme. Különösen webshopok, tagsági rendszerek, vállalati weboldalak és nagy forgalmú blogok esetében a helyesen konfigurált wp-config.php fájl erős védelmi réteget biztosít az egyszerű bottámadásokkal, az adminfelületen keresztüli fájlmanipulációval, a hibaüzenetek kiszivárgásával és a munkamenet-lopási kísérletekkel szemben.

Ebben az útmutatóban a Hostragons blogja számára lépésről lépésre áttekintjük a WordPress wp-config.php fájlon végrehajtható haladó biztonsági beállításokat. Egyszerűen, de technikai pontossággal elmagyarázzuk, hogy az egyes beállítások mire valók, milyen esetekben javasoljuk a használatukat, és mire kell figyelni a telepítés előtt. Ha még nem rendelkezel biztonságos és naprakész tárhely-infrastruktúrával, a wp-config.php megerősítése mellett a megbízható WordPress tárhely kiválasztása is fontos. Ezen a ponton a WordPress hosting csomagok és a biztonságos webtárhely megoldások oldalak relevánsak lehetnek.

Mi az a wp-config.php fájl, és miért kritikus a biztonság szempontjából?

A wp-config.php a WordPress gyökérkönyvtárában található konfigurációs fájl, amely a webhely alapvető működési paramétereit tartalmazza. A WordPress ezen a fájlon keresztül csatlakozik az adatbázishoz, olvassa be a biztonsági kulcsokat, határozza meg a hibakeresési viselkedést, kezeli a fájlrendszer-műveleteket és futtat néhány haladó konstanst. Ezért a fájl tartalma sokkal érzékenyebb, mint egy átlagos témafájlé.

Ebben a fájlban általában a következő kritikus információk találhatók:

• Adatbázis neve, felhasználónév, jelszó és kiszolgáló adatai
• Authentication Unique Keys és Salts néven ismert munkamenet-biztonsági kulcsok
• Adatbázis tábla előtag
• Hibakeresési és naplózási beállítások
• A fájlszerkesztést, frissítést és SSL viselkedést vezérlő konstansok
• WordPress memóriakorlát és ideiglenes fájlkönyvtár működési beállítások

Ha egy támadó hozzáfér a wp-config.php tartalmához, megszerezheti az adatbázis kapcsolódási adatait. Ebben az esetben nemcsak a WordPress adminfelület, hanem az adatbázisban lévő felhasználói fiókok, rendelési rekordok, űrlapok, tartalmak és privát ügyféladatok is veszélybe kerülnek. Ezért a wp-config.php fájl védelme a WordPress biztonság egyik alapvető lépése.

Mielőtt elkezded: Biztonsági mentés, tesztelés és hozzáférési terv

Egy apró elírás is a wp-config.php fájlban azt okozhatja, hogy a webhelyed fehér képernyő hibát jelez, az adatbázis-kapcsolat megszakad, vagy az adminisztrációs panel elérhetetlenné válik. Ezért a módosítások előtt alkalmazz egy háromlépcsős biztonsági tervet.

1. Készíts teljes biztonsági mentést

Először készíts fájl- és adatbázis-mentést. Nem elegendő csupán a wp-config.php fájlt letölteni a számítógépedre; mivel egy módosítás befolyásolhatja az adatbázis-kapcsolatot, az adatbázis mentése is fontos. Ha a vezérlőpultodon van automatikus mentési funkció, ellenőrizd az utolsó mentés dátumát. Ha szükséges, hozz létre manuális mentést. Ebben a témában a webhely biztonsági mentés útmutató tartalmával haladhatsz tovább.

2. Egyesével alkalmazd a módosításokat

Ahelyett, hogy egyszerre 8 vagy 10 biztonsági beállítást adnál hozzá, minden változtatás után teszteld a webhelyet, az adminpanelt és a kritikus űrlapokat. Például először kapcsold ki a fájlszerkesztést, majd ellenőrizd a webhelyet. Ezután konfiguráld a hibakeresési beállítást. Ez a módszer lehetővé teszi, hogy hiba esetén gyorsan megtaláld, melyik sor okozta a problémát.

3. Legyen kész FTP vagy fájlkezelő hozzáférésed

Ha a wp-config.php hibásan kerül mentésre, előfordulhat, hogy nem tudsz belépni a WordPress adminfelületére. Ezért győződj meg róla, hogy a cPanel fájlkezelő, az SFTP vagy a biztonságos fájlátviteli hozzáférésed működik. Az SFTP használata biztonságosabb, mint az FTP, mert a kapcsolat titkosított. A biztonságos hozzáféréshez hasznos lehet a Mi az SFTP és hogyan kell használni című útmutató.

wp-config.php biztonsági beállítások összefoglalása

Az alábbi táblázat gyakorlatiasan összefoglalja az ebben az útmutatóban ismertetett alapvető és haladó biztonsági beállításokat. Mielőtt éles webhelyen alkalmaznád, minden sort értékelj a webhelyed igényei szerint.

Erősítsd meg a biztonsági kulcsokat és a Salt értékeket

A WordPress munkamenet-biztonságát a wp-config.php fájlban található AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY és ezek salt megfelelői támogatják. Ezek a kulcsok teszik biztonságosabbá a felhasználói sütiket és a munkamenet-ellenőrzési folyamatokat. Ha a kulcsok gyengék, alapértelmezettek vagy hosszú ideje nem változtak, a munkamenet-biztonság gyengülhet.

A javasolt gyakorlat, hogy a WordPress hivatalos titkos kulcs generátorán keresztül hozz létre új, véletlenszerű kulcsokat. Ezek a kulcsok általában 64 karakternél hosszabbak, véletlenszerű szimbólumokat tartalmaznak, és gyakorlatilag lehetetlen kitalálni őket. Egyszerűen cseréld le a meglévő sorokat a wp-config.php fájlban az új kulcsokra.

Ennek a műveletnek a hatása egyértelmű: Minden aktív felhasználói munkamenet megszakad, és a felhasználóknak újra be kell jelentkezniük. Ha gyanítod, hogy egy adminisztrátori fiókot feltörtek, a salt értékek frissítése gyors vészhelyzeti lépés. Különösen félévente vagy biztonsági rés gyanúja esetén jó gyakorlat ezeknek a kulcsoknak a megújítása.

Kapcsold ki a fájlszerkesztést az adminfelületen keresztül

A WordPress adminisztrációs paneljén található egy szerkesztő, amely lehetővé teszi a téma- és bővítményfájlok szerkesztését. Bár ez a funkció fejlesztés közben praktikusnak tűnik, éles webhelyeken komoly kockázatot jelent. Ha egy támadó hozzáfér egy adminisztrátori fiókhoz, a panel fájlszerkesztőjén keresztül kártékony PHP kódot adhat hozzá.

A következő konstans hozzáadásával a wp-config.php fájlhoz kikapcsolhatod a fájlszerkesztést az adminból: define('DISALLOW_FILE_EDIT', true);

Ez a beállítás letiltja a WordPress adminban található téma- és bővítmény fájlszerkesztőt. Napi publikálású blogok, vállalati webhelyek és WooCommerce áruházak esetében javasoljuk az alapértelmezett aktiválását. Ha fájlmódosításokra van szükség, azokat SFTP-n, Git-en vagy biztonságos telepítési folyamatokon keresztül kell elvégezni.

Haladóbb lehetőségként használható a DISALLOW_FILE_MODS konstans, amely a fájlfeltöltési és frissítési műveleteket is korlátozza. Mivel azonban ez a beállítás a bővítmény- és témfrissítéseket is blokkolhatja, csak olyan nagyon érzékeny rendszerekben érdemes előnyben részesíteni, ahol a karbantartási ablakon kívül nem szabad változtatásokat végezni.

Tedd a hibakeresési beállításokat éles webhelyhez alkalmassá

A WordPress fejlesztői környezetben hasznos bekapcsolni a WP_DEBUG értéket; láthatod a hibákat, megtalálhatod az inkompatibilis bővítményeket és diagnosztizálhatod a téma problémákat. Az éles webhelyen azonban a képernyőre írt hibaüzenetek olyan információkat tartalmazhatnak, mint a kiszolgáló útvonala, bővítmény neve, fájl helye, adatbázis-lekérdezési tippek és PHP verzió, amelyek hasznosak lehetnek egy támadó számára.

Éles környezetben a biztonságos megközelítés logikája a következő: Ne mutasd a hibákat a látogatónak, szükség esetén írd egy egyedi naplófájlba. Ehhez a WP_DEBUG értékének false-nak kell lennie; ha a fejlesztési szakaszban naplózásra van szükség, a WP_DEBUG_LOG legyen true, a WP_DEBUG_DISPLAY pedig false. A példa logika így néz ki: define('WP_DEBUG', false); define('WP_DEBUG_DISPLAY', false);

Ha hibakutatást kell végezned, rövid időre kapcsold be a naplózást, oldd meg a problémát, majd kapcsold ki újra. Győződj meg arról is, hogy a naplófájl nem érhető el nyilvános könyvtárból. Mivel a debug.log fájl néha a webhely gyökeréhez közeli helyeken jöhet létre, és rosszul konfigurált kiszolgálókon kívülről olvasható lehet. Az ilyen kockázatok csökkentéséhez kritikus a megfelelő tárhely-konfiguráció. A WordPress hibanaplók kezelése és a biztonságos WordPress tárhely ezen a ponton természetes folytatástartalmak.

Tedd kötelezővé az SSL-t és az adminisztrációs panel biztonságát

Az SSL tanúsítvány titkosítja a felhasználó és a kiszolgáló közötti forgalmat. Mivel a WordPress adminfelületére felhasználónévvel és jelszóval jelentkeznek be, az admin forgalomnak HTTPS-en keresztül kell történnie. Ez a beállítás különösen fontos azoknál a csapatoknál, amelyek nyilvános hálózatokról, irodán kívülről vagy mobilkapcsolatokról érik el az adminisztrációs panelt.

A wp-config.php fájlban a FORCE_SSL_ADMIN konstanssal kötelezővé tehető az SSL az adminisztrációs panelen: define('FORCE_SSL_ADMIN', true);

A beállítás helyes működéséhez a domain neveden érvényes SSL tanúsítványnak kell lennie. Ha még nem használsz SSL-t, először fejezd be a tanúsítvány telepítését. Az SSL nemcsak a biztonság, hanem a felhasználói bizalom és a SEO szempontjából is alapvető követelmény. A Hostragons SSL lehetőségeiért nézd meg a SSL tanúsítvány termékek oldalt, a domain kezeléséhez pedig a domain keresés és domain regisztráció oldalt.

Ha az SSL kikényszerítése után végtelen átirányítási hiba lép fel, általában a proxy, CDN vagy load balancer konfigurációja nem megfelelően érzékelt. Ilyen esetben ellenőrizni kell a kiszolgálóoldali HTTPS fejléceket és a WordPress webhely cím beállításait.

Kezeld biztonságosabban az adatbázis-információkat és a tábla előtagot

A wp-config.php fájlban lévő DB_NAME, DB_USER, DB_PASSWORD és DB_HOST értékek teszik lehetővé a WordPress számára az adatbázishoz való csatlakozást. Ezeknek az információknak erősnek és korlátozott jogosultságokkal kell rendelkezniük. Az egyik leggyakoribb hiba, hogy az adatbázis-felhasználónak a szükségesnél több jogosultságot adnak.

Éles WordPress webhely esetén ajánlott, hogy az adatbázis-felhasználó csak a szükséges engedélyekkel rendelkezzen. Általában a SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER és INDEX engedélyek elegendőek. Kockázatos a WordPress konfigurációjában olyan széles jogkörű felhasználókat használni, amelyek a kiszolgáló szintjén az összes adatbázishoz hozzáférnek.

Helyes megközelítés a tábla előtag kérdésében

A WordPress alapértelmezett tábla előtagja a wp_ érték. Új telepítéseknél, ha ezt egy eltérő és véletlenszerű értékre változtatod, megnehezíted az automatizált támadóeszközök dolgát. Például a wp_ helyett választhatsz egy rövid, de nehezen kitalálható előtagot, mint a hr7x_. Egy meglévő webhelyen azonban a tábla előtag megváltoztatása nem merül ki csupán a wp-config.php fájlban lévő table_prefix érték módosításában; az adatbázisban lévő táblaneveket és néhány usermeta rekordot is frissíteni kell.

Ezért ha meglévő éles webhelyen hajtasz végre tábla előtag változtatást, először készíts teljes biztonsági mentést, lehetőség szerint teszteld a műveletet staging környezetben, majd vidd át élesbe. Új telepítéseknél viszont biztonságosabb és kockázatmentesebb már a kezdetektől eltérő előtagot használni.

A wp-config.php fájl áthelyezése a gyökérkönyvtáron kívülre

A WordPress bizonyos kiszolgáló-konfigurációkban képes a wp-config.php fájlt a gyökérkönyvtár egy szinttel feljebb is olvasni. Például ha a WordPress fájlok a public_html mappában vannak, a wp-config.php fájl áthelyezhető a public_html-en kívülre, egy szülőkönyvtárba. Ez a módszer csökkenti a weben keresztüli közvetlen hozzáférés kockázatát.

Ez a gyakorlat azonban nem feltétlenül működik minden tárhely-környezetben ugyanúgy. Megosztott tárhelyeken a könyvtárjogosultságok, a vezérlőpult felépítése vagy a biztonsági házirendek miatt előfordulhat, hogy a fájl áthelyezése a szülőkönyvtárba nem lehetséges. Ezenkívül a karbantartást végző személyeknek ismerniük kell a fájl helyét; ellenkező esetben a későbbi hibakeresési folyamat elhúzódhat.

A módszer alkalmazása előtt ellenőrizd a tárhelyszolgáltatód fájlstruktúráját. Ha menedzselt WordPress tárhelyet használsz, érdeklődj a támogatási csapattól a javasolt könyvtárstruktúráról. A Hostragons infrastruktúráján a megfelelő könyvtár- és jogosultságkezeléshez a tárhely vezérlőpult útmutató tartalom lehet támogató.

Szigorítsd a fájljogosultságokat és az írási engedélyeket

A wp-config.php biztonsága nemcsak a benne lévő konstansoktól függ, hanem a fájl operációs rendszer szintű jogosultságaitól is. Az általános ajánlás, hogy a wp-config.php fájl ne legyen mindenki által írható. A legtöbb Linux alapú tárhely-környezetben a fájljogosultságok korlátozottabb értékekkel konfigurálhatók, mint például 400, 440 vagy 600. Hogy melyik érték működik, az a kiszolgáló felhasználójától és a PHP futtatási modelljétől függ.

A gyakorlati megközelítés a következő: A fájlt a webhely működését nem zavaró legalacsonyabb jogosultsággal kell tartani. A 777-es, mindenki számára írási engedélyt adó beállítások semmiképpen sem használhatók. A 644 néhány környezetben alapértelmezetten működik, de érzékenyebb telepítéseknél a 600 vagy 440 előnyben részesíthető. A változtatás után tesztelni kell a webhely betöltését, az adminpanelt és a bővítményfrissítési képernyőket.

Emellett fontos a wp-config.php fájlhoz való hozzáférést webszerver szinten is blokkolni. A modern tárhely-infrastruktúrákban a PHP fájlok nem jelennek meg közvetlenül forrásként; azonban rosszul konfigurált kiszolgálókon kockázatot jelenthetnek. Ezért a megbízható tárhely-infrastruktúra ugyanolyan fontos, mint a fájljogosultságok.

Kezeld biztonságközpontúan az automatikus frissítéseket

A WordPress mag, a bővítmények és a témák rendszeresen kapnak biztonsági frissítéseket. A wp-config.php-n keresztül bizonyos mértékig kezelheted az automatikus frissítési viselkedést. Biztonsági szempontból általában ajánlott az alverziós frissítések automatikus végrehajtása. Mivel ezek a frissítések többnyire biztonsági és hibajavítási fókuszúak.

Például a WordPress mag alverziós frissítéseinek bekapcsolva tartása csökkenti a késedelmet az ismert sebezhetőségekkel szemben. A főverzió-átállások azonban tesztelést igényelhetnek a téma- és bővítménykompatibilitás szempontjából. Ezért vállalati webhelyeken a legegészségesebb módszer: az automatikus biztonsági javításokat bekapcsolva tartani, a nagyobb frissítéseket pedig staging környezetben tesztelni, mielőtt élesbe kerülnének.

A frissítési stratégiában három alapszabályt használhatsz: Először biztonsági mentés, aztán tesztelés, végül élesítés. Ez az egyszerű sorrend megteremti a helyes egyensúlyt a biztonság és a folytonosság között.

Tartsd ellenőrzés alatt a PHP memóriakorlátot és az erőforrás-felhasználást

A wp-config.php fájlban a WP_MEMORY_LIMIT és WP_MAX_MEMORY_LIMIT értékekkel meghatározható a WordPress által használható memória mennyisége. Bár ezek a beállítások közvetlenül nem tűnnek biztonsági beállításnak, az erőforrás-felhasználásos támadásoknál, hibás bővítményeknél és intenzív admin műveleteknél fontosak.

Például egy kis blog számára a 128M legtöbbször elegendő, míg WooCommerce áruházak vagy többnyelvű webhelyek esetében 256M-re lehet szükség. A memóriakorlát szükségtelenül magasra emelése azonban azt okozhatja, hogy egy hibás bővítmény több erőforrást fogyaszt, és csökkenti a kiszolgáló teljesítményét. A helyes értéket a webhely forgalma, a bővítmények száma és a tárhelycsomag erőforrásaival együtt kell értékelni.

Ha gyakran kapsz memóriahibát, a korlát emelése helyett inkább keresd meg a probléma forrását. Nehéz bővítmények, optimalizálatlan lekérdezések, elavult PHP verzió vagy elégtelen tárhelycsomag lehet az ok. A teljesítményt és a biztonságot együtt kell kezelni. Ebben a témában a WordPress teljesítményoptimalizálás és a nagy teljesítményű tárhely csomagok tartalmak természetes linkelési lehetőséget kínálnak.

Tartsd biztonságban az ideiglenes fájlkönyvtárat és a feltöltési viselkedéseket

Néhány tárhely-környezetben a WordPress az ideiglenes fájlokat az alapértelmezett rendszerkönyvtárakban tárolja. Ez normális; azonban a hibásan engedélyezett megosztott könyvtárak biztonsági kockázatot jelenthetnek. A wp-config.php-n keresztül a WP_TEMP_DIR meghatározásával kijelölhető az a könyvtár, amelyet a WordPress az ideiglenes fájlokhoz használ.

Ha ezt a módszert használod, ügyelj arra, hogy a könyvtár ne legyen nyilvánosan elérhető, az írási engedély ellenőrzött legyen, és csak az adott webhely felhasználója férhessen hozzá. Különösen a fájlfeltöltési, médiafeldolgozási és bővítményfrissítési folyamatok során használják aktívan az ideiglenes könyvtárakat. Egy rosszul konfigurált ideiglenes könyvtár feltöltési hibákhoz vagy fájlszivárgási kockázathoz vezethet.

Süti domain és többhelyes biztonság

WordPress többhelyes, aldomaines vagy alkönyvtáras struktúrát használó projekteknél a süti domain és a webhely URL értékek érzékenyebbé válnak. A helytelen süti domain meghatározás azt okozhatja, hogy a munkamenetek váratlan aldomaineken lesznek érvényesek, vagy bejelentkezési hurkokhoz vezethet. Biztonsági szempontból minden webhelyarchitektúránál a süti hatókörét a minimálisan szükséges tartományra kell korlátozni.

Például az admin.pelda.hu, shop.pelda.hu és blog.pelda.hu struktúráknál tudatosan kell meghatározni, hogy a sütik az összes aldomainen vagy csak egy adott domainen legyenek érvényesek. A szükségesnél szélesebb süti hatókör növelheti annak az esélyét, hogy egy aldomain sebezhetősége befolyásolja a többi domain munkameneteit.

Ha többhelyes telepítést használsz, értékeld együtt a wp-config.php fájlban lévő multisite konstansokat, a domain mapping beállításokat és az SSL konfigurációt. Az ilyen projekteknél a domain és SSL tervezés is fontos. A többdomaines kezelés és a wildcard SSL tanúsítvány linkek itt relevánsak lehetnek.

Alkalmazható biztonsági ellenőrzőlista a wp-config.php-hoz

Az alábbi listát rendszeresen ellenőrizheted éles WordPress webhelyeden. Különösen új bővítmények telepítése, téma módosítások, kiszolgáló átköltöztetés és gyanús bejelentkezési kísérletek után jó szokás átnézni ezt a listát.

• A wp-config.php fájl naprakész biztonsági mentése biztonságos helyen van tárolva?
• A biztonsági kulcsok és salt értékek egyediek és véletlenszerűek?
• A DISALLOW_FILE_EDIT aktív?
• Éles webhelyen a WP_DEBUG ki van kapcsolva vagy biztonságos naplózási módban van?
• Az adminisztrációs panel kötelezően HTTPS-en keresztül működik?
• Az adatbázis-felhasználó nem rendelkezik szükségtelen jogosultságokkal?
• A tábla előtag új telepítéseknél eltér az alapértelmezett wp_ értéktől?
• A fájljogosultságok nem tartalmaznak veszélyes értékeket, mint a 777?
• Az automatikus biztonsági frissítések ellenőrzött módon be vannak kapcsolva?
• A tárhelyfiókban az SFTP, biztonsági mentés és SSL megfelelően van konfigurálva?

Gyakori hibák és azok elkerülése

A wp-config.php-val kapcsolatban a leggyakoribb hiba, hogy az internetről talált kódrészleteket anélkül adják hozzá, hogy értenék, mire valók. Minden WordPress webhely más kiszolgáló, téma, bővítmény és forgalmi struktúrával rendelkezik. Ezért egy beállítás, amely az egyik webhelyen problémamentesen működik, egy másikon munkamenet-problémát vagy frissítési hibát okozhat.

A második gyakori hiba, hogy éles webhelyen bekapcsolva hagyják a hibakeresési kimenetet. Ez rontja a felhasználói élményt és technikai információszivárgáshoz vezet. A harmadik hiba, hogy a wp-config.php fájl biztonsági mentését a web gyökérkönyvtárában hagyják olyan nevekkel, mint wp-config-backup.php, wp-config-old.php. Ezek a fájlok rossz kiszolgálóbeállítás esetén egyszerű szövegként letölthetők. A biztonsági mentéseket webes hozzáféréstől elzárt területen kell tárolni.

A negyedik hiba, hogy a fájljogosultságokat 777-re állítják a probléma megoldásához, majd nem állítják vissza. Bár rövid távon megoldani látszik a problémát, biztonsági szempontból nagyon veszélyes. Az ötödik hiba, hogy SSL telepítése nélkül aktiválják a FORCE_SSL_ADMIN-t; ez adminisztrációs panel elérési problémákhoz vezethet.

Hogyan építs ki professzionális WordPress biztonsági réteget?

A wp-config.php megerősítése fontos lépés, de önmagában nem nyújt teljes biztonságot. A professzionális biztonsági megközelítésnek rétegzettnek kell lennie. Erős tárhely-izoláció, naprakész PHP verzió, webalkalmazás tűzfal, megbízható SSL, rendszeres biztonsági mentés, korlátozott adminisztrátori fiókok, kétfaktoros hitelesítés és naplókövetés együttesen alkotják a teljes képet.

Például amikor egy támadó megpróbál kihasználni egy bővítmény-sebezhetőséget, a WAF réteg blokkolhatja a kérést. Ha egy felhasználói jelszót feltörnek, a kétfaktoros hitelesítés lép működésbe. Ha fájlmódosítás történik, gyors visszaállítás végezhető a biztonsági mentésből. A wp-config.php pedig ebben a láncban a kritikus konfigurációs és korlátozási pont.

Ha most indítod a WordPress webhelyed, már a kezdetektől haladj biztonságközpontúan: tervezz erős domaint és SSL-t, válassz biztonságos tárhelyet, változtasd meg az alapértelmezett tábla előtagot, generálj egyedi salt kulcsokat, kapcsold ki az admin fájlszerkesztést, és aktiváld a rendszeres biztonsági mentéseket. Ezek az alapvető lépések sok későbbi problémát megelőznek, mielőtt azok elkezdődnének.

Összegzés: Kis beállítások, nagy biztonsági hatás

A WordPress wp-config.php fájljával végrehajtható haladó biztonsági beállítások gyakorlatias és hatékony intézkedéseket kínálnak webhelyed támadási felületének csökkentésére. A salt kulcsok frissítése, a fájlszerkesztés kikapcsolása, a hibakeresési kimenet elrejtése, az SSL kötelezővé tétele, az adatbázis-jogosultságok korlátozása és a fájljogosultságok szigorítása olyan lépések, amelyek a legtöbb WordPress webhely számára magas hasznot biztosítanak.

Ne siess ezeknek a beállításoknak az alkalmazásával: készíts biztonsági mentést, egyesével végezd a módosításokat, és tesztelj minden lépést. A biztonságos konfiguráció, a megfelelő tárhely-infrastruktúrával és rendszeres karbantartással kombinálva, a WordPress webhelyed sokkal ellenállóbbá válik. Ha biztonságosabb és fenntarthatóbb infrastruktúrát tervezel, nézd meg a Hostragons WordPress tárhely, SSL tanúsítvány és domain regisztráció megoldásait, hogy megtaláld az igényeidnek megfelelő kiindulópontot.

Gyakran Ismételt Kérdések

Biztonságos szerkeszteni a wp-config.php fájlt?

Igen, biztonságos, ha megfelelően készítesz biztonsági mentést és ellenőrzötten alkalmazod a módosításokat. Azonban egyetlen elírás is befolyásolhatja a webhely elérését. Ezért először készíts fájl- és adatbázis-mentést, majd a beállításokat egyesével tesztelve alkalmazd.

Mi történik, ha megváltoztatom a salt kulcsokat a wp-config.php fájlban?

Minden aktív felhasználói munkamenet megszakad, és a felhasználóknak újra be kell jelentkezniük. Ez a művelet nem törli a tartalmakat, és nem teszi tönkre az adatbázist. Különösen gyanús bejelentkezés, adminisztrátori fiók kockázata vagy biztonsági rés után javasolt gyors intézkedés.

Éles WordPress webhelyen bekapcsolva kell maradnia a WP_DEBUG-nak?

Nem. Ha éles webhelyen a WP_DEBUG bekapcsolva marad, a hibaüzenetek technikai információkat szivárogtathatnak ki a látogatóknak. A biztonságos megközelítés az, hogy a hibákat nem jelenítjük meg a képernyőn, és csak rövid távú igények esetén használunk ellenőrzött naplózást.

A DISALLOW_FILE_EDIT blokkolja a bővítmény- és témfrissítéseket?

Nem, a DISALLOW_FILE_EDIT csak az adminisztrációs panel fájlszerkesztőjét kapcsolja ki. A bővítmény- és témfrissítések normálisan folytatódnak. A frissítések kikapcsolásához eltérő és korlátozóbb beállítások szükségesek.

Milyen fájljogosultságot kell beállítani a wp-config.php-nak?

Bár a kiszolgáló konfigurációjától függően változik, a cél az, hogy a fájlt a működést nem zavaró legalacsonyabb jogosultsággal tartsuk. A 777 semmiképpen sem használható. A legtöbb környezetben a 600, 440 vagy 644 működhet; a változtatás után tesztelni kell a webhelyet és az adminpanelt.