.htaccess fertőzés eltávolítása WordPress oldalon – mit keress a fájlban?

A .htaccess fertőzés eltávolítása ritkán oldható meg azzal, hogy visszamásolod az alap WordPress-szabályokat. A rosszindulatú átirányítás eltűnhet, majd percekkel később visszakerülhet, mert egy PHP backdoor, cron feladat vagy kompromittált plugin újraírja a fájlt. A .htaccess sokszor a payload, nem a támadás forrása.

Milyen tünetet okozhat?

• csak Google-ből érkező látogatók átirányítása;
• mobilon szerencsejátékos vagy felnőtt oldal nyílik meg;
• a wp-admin 403 hibát ad;
• ismeretlen PHP fájl fut kép vagy szövegfájl helyett;
• minden kérés egy támadói loaderhez kerül;
• a webhely időnként 500-as hibával leáll;
• a megtisztított szabályok újra megjelennek.

Ha a fő tünet az átirányítás, előbb olvasd el a WordPress átirányítás okait, mert JavaScript, adatbázis-injektálás és kompromittált külső script is okozhat hasonlót.

Mentsd el az eredetit

Ne szerkeszd rögtön élesben. Mentsd le a fájlt, készíts hash-t, és nézd meg a tulajdonost, jogosultságot, módosítási időt:

cp .htaccess ../evidence-htaccess.txt
sha256sum .htaccess
stat .htaccess

Keresd meg az összes .htaccess fájlt, ne csak a webrootban lévőt:

find public_html -name '.htaccess' -type f -print

Az uploads, cache vagy mély plugin könyvtárban található fájl lehet legitim védelem is, ezért az elhelyezkedés önmagában nem döntő.

Gyanús szabályok

Vizsgáld meg az olyan feltételeket, amelyek user agent, referer, cookie, ország vagy eszköz alapján más célra irányítanak. Tipikus elemek:

RewriteCond %{HTTP_REFERER} google [NC]
RewriteCond %{HTTP_USER_AGENT} "android|iphone" [NC]
RewriteRule ^ https://ismeretlen-pelda.invalid/ [R=302,L]

A fenti minta szemléltetés, nem minden hasonló szabály malware. Egy legitim mobiloldal vagy kampány is használhat átirányítást. Gyanús viszont, ha a domain ismeretlen, a szabály kódolt, a WordPress blokk elé került, vagy csak keresőből érkező látogatókat céloz.

Nézd meg ezeket is:

• AddHandler vagy SetHandler, amely képfájlt PHP-ként futtat;
• auto_prepend_file érték .user.ini vagy PHP konfiguráció mellett;
• ismeretlen ErrorDocument, amely backdoorra mutat;
• hosszú, értelmetlen rewrite-lánc;
• hozzáférés engedélyezése rejtett fájlokra;
• minden kérés átadása egy ismeretlen PHP fájlnak.

Biztonságos helyreállítás

Ha Apache alatt csak a WordPress alap útvonalkezelésére van szükség, az adminban a közvetlen hivatkozások mentése újragenerálhatja a blokkot. Fertőzött oldalon ezt ne tekintsd tisztításnak. Előbb készíts tiszta, minimális konfigurációt, és külön add vissza a bizonyítottan szükséges egyedi szabályokat.

Tesztelj minden módosítás után:

apachectl configtest
curl -I https://example.com/
curl -I -A 'Mozilla/5.0 (iPhone)' -e 'https://www.google.com/' https://example.com/

Megosztott tárhelyen az apachectl nem feltétlenül érhető el. Egy hibás .htaccess azonnal 500-as hibát okozhat, ezért legyen visszaállítható másolat és működő SFTP hozzáférés.

Ha a fájl újraíródik

Ez a legfontosabb nyom. Figyeld meg, pontosan mikor változik, és vesd össze az access loggal, PHP folyamattal és cron eseményekkel. Keress írási műveletet végző kódot:

rg -n "\.htaccess|file_put_contents|fopen\(|fwrite\(" wp-content
wp cron event list

Egy plugin legitim módon is írhat rewrite-szabályt. A kérdés az, hogy melyik kérés vagy ütemezett esemény indította, és mi került a fájlba. A WebShield fájlváltozás–HTTP kérés korrelációja ebben erősebb egy egyszeri scannél.

A .htaccess mellett ellenőrizendő helyek

Apache-környezetben nézd meg a .user.ini, php.ini, virtual host és tárhelypanel beállításokat is. WordPressben vizsgáld a wp-config.php, index.php, mu-plugineket, aktív sablont, adatbázisban tárolt URL-eket és cron eseményeket. Nginx esetén a .htaccess eleve nem irányítja a kiszolgálást; ott más konfiguráció vagy alkalmazáskód okozza a tünetet.

A fertőzött fájlok biztonságos törléséről szóló útmutató segít a kapcsolódó loader karanténba helyezésében. Ha az oldal a javítás után ismét átirányít, perzisztencia maradt, és teljes WordPress tisztításra van szükség.

Mikor kész a javítás?

A szabályok tiszták, a konfiguráció tesztje sikeres, az oldal több user agenttel és refererrel helyesen működik, és a fájl monitorozás mellett sem íródik újra. Emellett a backdoor eltűnt, a belépési pontot lezártad, a jelszavakat és saltokat cserélted. Enélkül csak a látható átirányítást kapcsoltad ki.

• .htaccess fertőzés
• WordPress átirányítás
• malware eltávolítás
• Apache