# Gyakori kérdések

> Gyakori kérdések és megoldások: kizárás, zárolások, kétfaktoros hitelesítés, IP-észlelés, ütközések más bővítményekkel.

## Kizártam magam a webhelyről

A hozzáférés megakadályozása közben könnyen kizárhatod magad is. Ideiglenesen kikapcsolhatod a bővítmény összes funkcióját: írd be a `wp-config.php` fájlba, az első sor (`<?php`) és a „That's all, stop editing! Happy publishing!” sor közé a következőt.

```php
define('ITSEC_DISABLE_MODULES', true);
```

Gyorsan lépj be, módosítsd a kizárást okozó beállítást, és töröld a sort a fájlból.

## Kikapcsolhatom a kétfaktoros hitelesítést?

Igen. Ha ideiglenesen ki kell kapcsolnod, írd a `wp-config.php` fájlba:

```php
define('ITSEC_DISABLE_TWO_FACTOR', true);
```

Ez csak a kétfaktoros modult kapcsolja ki, az előző sorral szemben, amely az összes modult.

## Nem érkeznek meg a kétfaktoros e-mailek

Előbb nézd meg, működik-e a WordPress levélküldése általában, aztán a bővítményét, végül a kétfaktoros levélét. A legtöbbször az általános levélküldéssel van gond. Segíthet SMTP-bővítmény vagy levelezési szolgáltatás.

## Zárolások feloldása

Beállítás közben a bővítmény túl szigorúan zárolhat téged vagy más jogos felhasználót. A zárolás ideiglenes; a vezérlőpult **Aktív zárolások** kártyáján feloldhatod. Ha a zárolás a te felhasználónevedhez kötődik, használhatod a **Varázslinkek** modult: a bejelentkező képernyőn kérj mágikus linket. Ha nincs bekapcsolva, megvárhatod a zárolás lejártát, vagy ideiglenesen kikapcsolhatod a bővítményt a `ITSEC_DISABLE_MODULES` sorral, feloldhatod a zárolást, majd visszakapcsolhatod. Ilyenkor érdemes bekapcsolni a Varázslinkeket is.

### Fehér képernyő „error” felirattal

A behatolásészlelés az olyan IP-címet zárolja, amely sok hibát (404) okoz egyszerre. Nagy vagy korábban feltört webhelyen sok törött hivatkozás lehet olyan fájlokra, amelyek már nem léteznek, ezért az első telepítés vagy webhelyvizsgálat után szinte azonnal kizárhat. Megoldás:

1. Győződj meg róla, hogy a zárolást a behatolásészlelés okozza: az adatbázisban (phpMyAdmin) nyisd meg a `wp_itsec_lockouts` táblát (a `wp_` helyén a saját előtagod áll), és keresd az IP-címedet.
2. Töröld a rekordot, és nézd meg, be tudsz-e lépni. Ha annyi 404-et kapsz, hogy újra kizár, keresd meg újra az IP-címedet, és térj át a következő lépésre.
3. A **Naplók** oldalon keresd meg az IP-címedhez tartozó bejegyzéseket: minden sor egy olyan fájl, amelyre a webhely hivatkozik, de nem létezik. Ezeket egyenként javítsd, így nem ismétlődik a zárolás, a keresők is kevesebb 404-et látnak.

### Miért tiltja ki a Google robotjait?

Ugyanezért: a Google egyszerre járja végig a webhelyet, és ha túl sok 404-et talál, a behatolásészlelés blokkolja. A törött hivatkozások javítása a keresőoptimalizálásnak is jó.

### Zárolási értesítések a saját felhasználónevemmel

A zárolási értesítés azt jelzi, hogy a védelem működik, de bosszantó, ha valaki (vagy egy bot) a te felhasználónevedet találgatja, és így te is zárolva vagy. Használd a Varázslinkeket (ha előzőleg bekapcsoltad), várd meg a zárolás lejártát, vagy kapcsold ki ideiglenesen a bővítményt a `ITSEC_DISABLE_MODULES` sorral. Ilyenkor kapcsold be a Varázslinkeket is.

### Kitiltott IP-cím kézi eltávolítása

Ha egy IP-címet ki akarsz venni a tiltólistából:

1. Nyisd meg a webhely `.htaccess` fájlját (S)FTP-vel vagy a tárhely panelén.
2. Keresd meg a kitiltott IP-címet.
3. A `# Ban Hosts - Security > Settings > Banned Users` szakaszban töröld a hozzá tartozó három sort (példa IP: 1.145.241.30):

```
SetEnvIF REMOTE_ADDR "^1.145.241.30$" DenyAccess
SetEnvIF X-FORWARD-FOR "^1.145.241.30$" DenyAccess
SetEnvIF X-CLUSTER-CLIENT-IP "^1.145.241.30$" DenyAccess
```

4. Töröld az IP-t tartalmazó sort az `<IfModule mod_authz_core.c>` blokkból:

```
Require not ip 1.145.241.30
```

5. Töröld az IP-t tartalmazó sort az `<IfModule !mod_authz_core.c>` blokkból:

```
Deny from ip 1.145.241.30
```

6. Mentsd a fájlt.

## IP-észlelés

### „Feature unavailable” értesítés az IP-észlelés miatt

Ha a **Global Settings** oldalon az IP-észlelés **Nincs beállítva** (Unconfigured) állapotban van, egyes modulok kikapcsolnak: **Felhasználók kitiltása**, **Helyi brute force**, **Hálózati brute force**. Ilyenkor ezeknél „Feature not available” üzenet látszik. A tűzfal és a CAPTCHA szűkebb funkciókkal működik.

A teljes működés visszaállítása:

1. Nyisd meg a **Biztonság → Beállítások → Global Settings** oldalt, és görgess az **IP-észlelés** részhez.
2. Válaszd a kiszolgálódnak megfelelő **Proxy-észlelést**. A legegyszerűbb a **Biztonsági ellenőrző vizsgálat (ajánlott)**: a webhely a gyártó API-jához csatlakozik, amely kiválasztja a megfelelő módszert, és rendszeresen megismétli. Az alap változatban ehhez előbb a **Biztonság → Beállítások → Features → Utilities** fülön be kell kapcsolni a **Security Check Pro** modult.
3. Ha tudod, hogyan csatlakozik a webhely az internethez: **Letiltva** (közvetlen kapcsolat, nincs proxy) vagy **Kézi** (proxy mögött, ismered a proxy által használt HTTP-fejlécet).

Miért számít? A tiltáshoz és a zároláshoz pontos IP-cím kell. Közvetlen kapcsolatnál ez egyszerű, proxy (például Cloudflare, terheléselosztó, WAF) mögött viszont a proxy fejléceire kell hagyatkozni. Korábban volt egy „Automatikus” beállítás, amely előre meghatározott sorrendben olvasta a fejléceket, de ezeket a támadók hamisíthatják, ezért „nem biztonságos” címkét kapott, és ma a bővítmény nem enged zárolást és tiltást, amíg nincs megfelelően beállítva.

### „Invalid IP returned” hiba a biztonsági ellenőrzésnél

Ez szinte mindig azt jelzi, hogy a webhelyen nem működnek a loopback-kérések (a webhely saját magához küldött belső HTTP-kérései, például WP-Cron, REST API-ellenőrzés). A bővítmény a védelemhez nem használ loopbacket, csak azért ellenőrzi, hogy a Megbízható eszközök modul ne blokkolja. A bővítmény loopback nélkül is működik, csak a webhelyvizsgálatban jelenik meg a hiba. Érdemes a tárhelyszolgáltatóval megvizsgáltatni, mi blokkolja, mert máshol is gondot okozhat (például automatikus frissítések).

### Mennyi forgalom látszik a naplóban?

A nagy forgalom, amit a Cloudflare vagy a tárhely mutat, a bővítmény naplójában nem jelenik meg, mert csak a szabálysértések naplózódnak (lásd [Globális beállítások](https://hub.hellowp.io/hu/plugins/ithemes-security-pro/globalis-beallitasok/)).

### A Cloudflare mögötti forgalom korlátozása

A `.htaccess` fájl elejére a Cloudflare IP-tartományainak engedélyezési listáját beírva elérhető, hogy az eredeti szerver csak a Cloudflare-en (és a szükséges tárhely-IP-ken) keresztül legyen elérhető.

## Hide Backend

### Miért érem el még a szokásos bejelentkezési címet?

Az egyéni címen való belépéskor egy órára süti kerül a böngészőbe, amellyel a `wp-login.php` és a `wp-admin` ugyanabban a böngészőben az egyéni cím nélkül is elérhető marad. Ellenőrzéshez nyisd meg privát ablakban.

### WooCommerce mobilalkalmazás

Ha az **Adminfelület elrejtése** be van kapcsolva, a WooCommerce mobilalkalmazás bejelentkezése sikertelen lehet, mert az alkalmazás nem követi az átirányítást az egyéni címre, így a kétfaktoros kérés sem jelenik meg. Megoldás: a bejelentkezéshez kapcsold ki az Adminfelület elrejtését (a WooCommerce szerint az alkalmazásnak az egyéni bejelentkezési címet kell böngészőben megnyitnia).

## Hozzáférési kulcsok

- **„Passkey registration is not available for new users”:** a felhasználó csoportjában nincs bekapcsolva a **Jelszó nélküli bejelentkezés engedélyezése**. Kapcsold be a **Biztonság → Beállítások → User Groups** oldalon.
- **„Could not save passkey user id”:** a bővítmény nem tudja beírni az adatot az adatbázisba (hiányzó tábla vagy hibás adattípus). Kapcsold ki, majd be a bővítményt, hogy létrejöjjenek a hiányzó táblák. Ha marad a hiba, keresd meg a **Naplók** oldalon a hozzáférési kulcsra vonatkozó bejegyzést.

## Telepítés, indulás, hibák

### Nem tudom befejezni a varázslót, vagy nem menthetők a beállítások

A bővítmény hozzáfér a WordPress REST API-hoz, és ha ez korlátozott, a varázsló és a mentés nem működik. Ellenőrizd a tárhelyszolgáltatónál, hogy a szerver engedi a `GET`, `POST`, `PUT`, `PATCH`, `DELETE` és `OPTIONS` HTTP-metódusokat. Lehet, hogy a tárhely tűzfala blokkolja a mentést: a böngésző fejlesztői eszközei (jobb kattintás, **Vizsgálat**, **Console**) piros hibaüzenetet mutatnak a `/wp-json/ithemes-security/` címre 403-as kóddal. Ilyenkor kérd meg a tárhelyszolgáltatót, hogy a tűzfal, a mod_security vagy a WAF szabályaiban engedélyezze ezt a végpontot.

### Üres oldalak a Biztonság menüben frissítés után

Valószínűleg a böngésző a bővítmény régi JavaScript-fájljait tárolta. Kényszerítsd a böngészőt az oldal teljes újratöltésére: Windows alatt Chrome, Firefox és Edge: **Ctrl + Shift + R** vagy **Ctrl + F5**; macOS alatt Chrome, Firefox, Edge: **Cmd + Shift + R**, Safari: **Option + Cmd + R**.

### Az iconv() függvény hiányzik

A bővítmény használja a PHP `iconv` bővítményét (karakterkódolás-átalakítás). A legtöbb tárhelyen alapból van. Ha hiányzik, kapcsold be a tárhely PHP-választójában (cPanel: jelöld be az `iconv` modult), vagy saját szerveren telepítsd a `php-iconv` csomagot, és indítsd újra a webszervert; ha nem megy, kérd a tárhelyszolgáltatót.

### Firewall oldal hibája a MU Plugin Loader futtatása után

Ha a **Varázslinkek** modul ki volt kapcsolva a **MU Plugin Loader** eszköz futtatásakor, szkripthiba keletkezik, és a Tűzfal oldal nem jelenik meg jól. Javítás:

1. A **Biztonság → Eszközök** oldalon futtasd a **Remove MU Plugin Loader** eszközt.
2. A **Biztonság → Beállítások → Features → Firewall** oldalon kapcsold be a **Varázslinkek** modult.
3. Az Eszközök oldalon futtasd újra a **Create MU Plugin Loader** eszközt.

Ezután a Varázslinkek modulnál „Feature not available” üzenet látszik. Ez normális: a Varázslinkek nem működhetnek, amíg a bővítmény Must-Use bővítményként töltődik be.

## Értesítések, naplók, adatvédelem

### Túl sok e-mail érkezik

A bővítmény szándékosan inkább túl sokat értesít. Az ütemezett webhelyvizsgálat kivétel: csak azokról az új sérülékenységekről szól, amelyek elérik a beállított küszöböt, és az előző vizsgálatnál nem szerepeltek. A **Biztonság → Beállítások → Notifications** oldalon a legtöbb értesítés kikapcsolható. Az a funkció lényegét adó értesítések (például a Varázslink e-mail) nem kapcsolhatók ki külön; ahhoz a funkciót kell kikapcsolni. Gyakran kikapcsolt értesítés az **Inaktív felhasználók** (részletek: [Értesítések](https://hub.hellowp.io/hu/plugins/ithemes-security-pro/ertesitesek/)).

### E-mailek egy olyan webhelyről, amelyet már nem kezelek

Valószínűleg egy másolat (például staging) vagy régi szerver még futtatja a bővítményt, amely ütemezett feladatokkal küldi az e-maileket. Teendők:

- Ha még hozzáférsz a régi webhelyhez, töröld róla a bővítményt.
- Töröld a bővítmény tranziens adatait tranziens-kezelővel, a régi és az új webhelyen is.
- Ha a webhely már nincs meg, de a szerver igen, töröltesd a tárhellyel a bővítményhez tartozó cron-feladatokat.
- Ha a régi szerverhez nincs hozzáférésed, állíts be szűrőszabályt a levelezőben, amely eldobja ezeket.

### Napló exportálása adatbázisból

Az adatbázisnaplók az `itsec_logs` táblában vannak. Beépített exportálás nincs, de beállíthatod, hogy fájlba is írjon (a fájlokat tetszőleges helyre teheted), vagy az adatbázistáblát kézzel is kiexportálhatod.

### Hibakeresési mód

A haladó felhasználóknak van **Debug** képernyő (a **Biztonság → Debug** menüpont, amely hibakereső módban jelenik meg).

### Adatkezelés és sütik az adatvédelmi tájékoztatóhoz

A bővítmény adatkezeléséről és sütijeiről a WordPress Adatvédelmi irányelvek útmutatója ad tájékoztatást: **Beállítások → Adatvédelem → Irányelvekkel kapcsolatos útmutató**.

## Webhelyvizsgálat

### Frissítés után is a régi sérülékeny szoftver értesítés jön

Gyakori ok: gyorsítótárazott adat vagy az ütemező hiba okozza az elavult eredményt, vagy az értesítés egy régi webhelytől (például korábbi tárhelyen lévő staging) érkezik. Teendők:

1. **Kézi webhelyvizsgálat:** a **Biztonság → Webhelyvizsgálatok** oldalon futtass kézi vizsgálatot; ha „Tiszta” az eredmény, de az ütemezett vizsgálat tovább elavult adatot mutat, folytasd.
2. **Minden gyorsítótár ürítése:** a tárhely gyorsítótára, a gyorsítótár-bővítmény, a CDN (például Cloudflare) és a böngésző.
3. **Webhely-tranziensek törlése:** tranziens-kezelővel vagy WP-CLI-vel.
4. **Az ütemező alaphelyzetbe állítása:** kapcsold be a hibakereső módot, nyisd meg a **Biztonság → Debug** oldalt, keresd meg az ütemezőtáblát (**Scheduler**), kattints a **Reset** gombra, és várd meg a következő ütemezett vizsgálatot.

Ha így is hibás értesítést kapsz, nézd meg, nem fut-e még a bővítmény egy régi másolaton (staging, dev) vagy régi szerveren, amelyen cron-feladat maradt.

### Mi a baj egy vizsgálat eredményével?

Ne ess pánikba: a bővítmény hajlamos túlzottan óvatos lenni, és a jelzett probléma nem biztos, hogy komoly. Gyors módja a hibakeresésnek a vizsgálati eredmény nyers részleteinek (**Raw Details**) átnézése.

## Egyéb kérdések

### Működik többhelyes (multisite) hálózaton?

Igen, de **hálózati aktiválással** kell bekapcsolni.

### Segít a spam-regisztrációk ellen?

Igen: a legjobb módszer a bővítmény **CAPTCHA** funkciója.

### Lefordítható a bővítmény?

Igen. Az alap változat szövegeit önkéntesek fordítják a WordPress hivatalos fordítási platformján. A csak a Pro változatban lévő szövegekhez használhatsz Poedit-szerű eszközt vagy fordítóbővítményt a `.po` és `.mo` fájlok előállításához; ezeket a megfelelő nyelvi könyvtárba kell tenni.

### Minden WordPress-webhelyhez jó?

Igen, bármely olyan WordPress-webhelyhez, ahová bővítmény telepíthető, új vagy meglévő webhelyhez is. A bővítmény módosítja az adatbázist és a szerver fájljait, ezért telepítés előtt legyen adatmentési és helyreállítási terved.

### Elronthatja a bővítmény a webhelyet?

Bármely bővítmény okozhat hibát. A bővítménynél a leggyakoribb két ok az adatbázist érintő módosítás:

1. az adatbázis-előtag cseréje a `wp_` alapértékről: ha ez nem kerül be a `wp-config.php` fájlba is, a webhely nem tud csatlakozni az adatbázishoz; az előtagnak egyeznie kell a táblákéval;
2. az 1-es azonosítójú felhasználó törlése: ha éppen ezzel a felhasználóval vagy bejelentkezve, a webhely hibásnak tűnik, amíg új adminisztrátort nem veszel fel más azonosítóval.

Az ilyen funkciókat a felületen címkék jelzik. Csak olyan módosítást végezz, amelyet magabiztosan vissza tudsz vonni.

### Mely funkciók működnek az én tárhelyemen?

A bővítmény a szerver konfigurációs fájljait módosítja: Apache esetén a `.htaccess`, NGINX esetén az `nginx.conf` fájlt. Egyes tárhelyek (például a WP Engine) nem használják a `.htaccess` fájlt, más NGINX-es tárhelyek tiltják a konfigurációs fájlok módosítását. Ilyenkor a következők külön beállítást igényelhetnek, vagy a tárhely már kezeli őket:

- **Biztonság → Beállítások → Features → Firewall → Felhasználók kitiltása → Alapértelmezett tiltólista**
- **Biztonság → Beállítások → Advanced → Rendszer finomhangolása**: **Rendszerfájlok védelme**, **Könyvtárböngészés letiltása**, **PHP letiltása a feltöltések, a bővítmények és a sablonok könyvtárában**
- **Biztonság → Beállítások → Advanced → WordPress finomhangolások → API-hozzáférés → XML-RPC letiltása**

Ha nem működnek, a tárhely vélhetően már kezeli őket, vagy kérned kell tőle a konfiguráció módosításának lehetőségét.

### Milyen IP-címeket kell engedélyeznem a tárhely tűzfalában?

A bővítmény vizsgálójának IP-címe a `207.246.255.60`, a központi kezelőé a `207.246.254.118`. Mindkettőt add hozzá biztonságosként a tárhely tűzfalában vagy más, botokat blokkoló rendszerben.

### Az alap változatról a Pro változatra váltás

Telepítsd és aktiváld a Pro változatot, majd az alap változatot kapcsold ki és töröld.

## Ütközések más bővítményekkel

A bővítmény bizonyos WordPress-funkciókat korlátoz, ezért egyes szoftverek a funkcióik egy részét elveszíthetik. Ha egy másik bővítmény nem a várt módon működik, valószínűleg a bővítmény egyik funkciója blokkolja a szükséges komponenst. Lépések:

1. **REST API alapértelmezett hozzáférése:** **Biztonság → Beállítások → Advanced → WordPress finomhangolások**, a **REST API** beállítás legyen **Alapértelmezett hozzáférés**.
2. **XML-RPC engedélyezése** ugyanott, ha a bővítmény távoli kapcsolatot használ.
3. **A PHP-végrehajtási korlátozások ideiglenes kikapcsolása:** **Advanced → Rendszer finomhangolása**; teszteld egyenként a feltöltéseket, bővítményeket és sablonokat.
4. **Alapértelmezett tiltólista kikapcsolása:** **Features → Firewall → Felhasználók kitiltása**.

### LiteSpeed Cache

A bővítmény a **PHP letiltása a bővítmények könyvtárában** beállítással megakadályozza az olyan PHP-fájlok közvetlen futtatását, amelyeket nem a WordPress tölt be (`ABSPATH` nélkül). A LiteSpeed Cache **Guest Mode** funkciója viszont éppen ilyen fájlokra épül. Kapcsold ki a Guest Mode-ot a LiteSpeed Cache-ben, vagy a **PHP letiltása a bővítmények könyvtárában** beállítást.

### Broken Link Checker

Ha a **Kényszerített SSL** be van kapcsolva, a bővítmény szűrője az `http://` címeket `https://` címekre cseréli, ezért a Broken Link Checker nem húzza át a törött hivatkozásokat. Megoldás: kapcsold ki a **Kényszerített SSL** beállítást a **Biztonság → Beállítások → Features → Utilities** fülön, vagy kapcsold ki, javítsd a régi `http://` hivatkozásokat `https://` címre, majd kapcsold vissza.

### Kadence Query Loop blokk

Ha a REST API **Korlátozott hozzáférés** módban van, a Kadence Query Loop (Advanced) blokk keresési eredményei nem jelennek meg a nyilvános oldalon, mert a blokk a `/wp-json/wp/v2/kadence_query/query` végpontot használja. Megoldás: állítsd a REST API-t **Alapértelmezett hozzáférés** módra, vagy a korlátozás megtartása mellett add hozzá ezt a kódot Must-Use bővítményként vagy kódrészlet-bővítménnyel:

```php
<?php
add_filter( 'rest_dispatch_request', function ( $result, $request, $route_regex, $handler ) {
	$route = strtolower( $request->get_route() );

	if ( $route === '/wp/v2/kadence_query/query' || strpos( $route, '/wp/v2/kadence_query/query' ) === 0 ) {
		if ( is_wp_error( $result ) && $result->get_error_code() === 'itsec_rest_api_access_restricted' ) {
			return null; // a kérés mehet tovább
		}
	}
	return $result;
}, 999, 4 );
```

### BunnyCDN

A `.htaccess` egyes szabályai (például a HackRepair tiltólista vagy IP-tiltások) blokkolhatják a BunnyCDN-t, amikor statikus fájlokat kér le, ami 403-as hibát okoz. Megoldás: a `.htaccess` fájl legelejére tegyél egy rövid szabályrendszert, amely felismeri a Bunny kéréseit, és mindig engedi a statikus fájltípusokat, így a többi védelem nem gyengül. Ez példakód, tesztelés nélkül ne használd éles webhelyen.

### Megbízható robotok kivétele az alapértelmezett tiltólistából

Az **Alapértelmezett tiltólista** automatikusan tiltja a `heritrix` szöveget tartalmazó user agentet, ezért egy megbízható robotot (például a BAnQBot-ot) is blokkolhat. Megoldás: Must-Use bővítmény létrehozása (`wp-content/mu-plugins/allow-banqbot.php`), amely a bővítmény fájlírási folyamatába kapcsolódik, és kiveszi a `.htaccess`-ből a `heritrix` szót tartalmazó szabályt. A bővítmény minden `.htaccess`-újraírásnál lefut; ha frissítést kell kényszeríteni, kapcsold ki és be a **Fájlokba írás** beállítást a **Global Settings** oldalon. Ez példakód: tesztelés nélkül ne használd éles webhelyen.