Mga .htaccess Security Rule ng WordPress na Talagang Nakakatulong

Karamihan sa ibinebenta bilang “WordPress .htaccess security” ay puro pampalaki lang. Ang mga rule na talagang nagbabago sa iyong attack surface ay maiikli: i-block ang PHP execution sa loob ng wp-content/uploads, i-deny ang direktang access sa wp-config.php, at i-disable ang directory indexing. Ang mga popular — pag-block sa xmlrpc.php “para pigilan ang brute force,” pagtatago ng iyong WordPress version, pag-paste ng 200-line na bad-bot user-agent list — ay mula sa halos walang saysay hanggang purong palabas lang. Nasa ibaba kung alin ang alin, at bakit.

Isang bagay munang linawin: gumagana lang ang .htaccess sa Apache (at LiteSpeed, na nagbabasa rin nito). Sa nginx ay ganap itong hindi pinapansin — nakaupo lang doon ang file habang iniisip mong protektado ka. Kung nginx ang pinapatakbo ng iyong host, wala sa mga ito ang naaangkop at kailangan mo ng server/location blocks sa halip. I-check gamit ang curl -I https://yoursite.com at tingnan ang Server: header bago ka gumugol ng isang oras sa pag-edit ng file na hindi naman binabasa ng server.

Ang rule na talagang mahalaga: walang PHP sa /uploads

Ito ang isang sulit gawin. Ang wp-content/uploads ay world-writable ayon sa disenyo — bawat media upload, bawat plugin na nag-se-save ng file, ay nagsusulat doon. Kung makapaglagay ang isang attacker ng .php file sa direktoryong iyon (sa pamamagitan ng vulnerable na upload handler, isang image field na hindi nagva-validate ng MIME type, o isang compromised na plugin), ang pagkakaiba ng isang abala lang at isang buong remote-code-execution compromise ay kung iexecute ng server ang file na iyon kapag hiniling. I-deny ang execution at ang na-upload na payload ay isang inert na file lang na nakaupo sa disk.

Ilagay ito sa wp-content/uploads/.htaccess (gumawa ng file kung wala pa):

<FilesMatch "\.php$">
    Require all denied
</FilesMatch>

Iyan ay Apache 2.4 syntax. Sa mas lumang 2.2, ang katumbas ay Order Deny,Allow / Deny from all. Ang paghahalo ng dalawang dialect sa iisang file ang pinakakaraniwang dahilan ng biglaang 500 Internal Server Error pagkatapos “mag-hardening” — kung namatay ang buong site sa sandaling i-save mo, halos palaging iyon ang dahilan. I-check ang iyong version gamit ang apachectl -v.

Protektahan ang wp-config.php

Ang wp-config.php ay naglalaman ng iyong database credentials at auth salts. Habang tumatakbo ang PHP, ang direktang request dito ay nagbabalik ng blangkong page — iexecute ng PHP ang file sa halip na i-print ito. Ang panganib ay ang failure case: kung mag-crash ang PHP, ma-misconfigure habang nagma-migrate, o ma-disable ang handler, ise-serve ng Apache ang file bilang plaintext at itatapon ang iyong DB password sa kahit sinong humingi. Ang pag-deny ng access ay murang insurance laban sa isang masamang limang minuto:

<Files wp-config.php>
    Require all denied
</Files>

I-off ang directory indexing

Kung may bumisita sa isang folder na walang index.php at naka-on ang Options +Indexes sa Apache, ililista nito ang mga laman — bawat backup file, bawat naligaw na SQL dump na nakalimutan mo. I-off ito sa buong site:

Options -Indexes

Mababang severity, pero totoo, at libre lang.

Iyan ang matapat na core list. Maaari mong buuin ang mga ito — kasama ang tamang 2.4-vs-2.2 syntax para hindi ma-500 ang iyong site — gamit ang WordPress .htaccess generator sa halip na kopyahin mula sa isang forum post na isinulat para sa maling Apache version.

Ang HINDI dapat gawin

Pag-block sa xmlrpc.php “para sa brute-force protection.” Ito ang malaking bagay na inuulit ng lahat at mali ito gaya ng pagkasabi. Oo, ang system.multicall method ng XML-RPC ay dating nagpapahintulot sa attacker na pagsama-samahin ang maraming login guess sa iisang request — tunay na amplification. Pero ang napakakaraniwang brute-force vector ay ang mga simpleng POST request sa wp-login.php, at ang pag-block sa xmlrpc.php ay walang ginagawa para doon. Ang brute force ay natatalo ng rate limiting, malalakas na password, at 2FA — hindi ng pagpatay sa isang endpoint. May lehitimong dahilan para i-disable ang XML-RPC: ang pingback feature nito ay maaaring abusuhin para sa DDoS reflection, kaya kung hindi mo ginagamit ang Jetpack, ang mobile app, o ang pingbacks, ang pagsara nito ay nagpapaliit sa iyong attack surface. Huwag mo lang sabihin sa sarili mo na ito ang iyong brute-force defense, dahil hindi.

Pagtatago ng iyong WordPress version / pag-alis ng generator tag. Ang pag-alis ng readme.html at ng <meta name="generator"> tag ay parang hardening ang pakiramdam. Nafi-fingerprint ng isang attacker ang iyong version mula sa enqueued asset query strings, block-editor markup, at isang dosenang iba pang palatandaan sa loob ng ilang segundo. Wala kang itinatago; ginagawa mo lang ang sarili mong abala ang pakiramdam.

Malalaking bad-bot user-agent at referrer blocklist. Ang user agents ay iisang spoofed na HTTP header. Ang mga list na ito ay luma na sa araw na i-paste mo, wala silang nbabloke na mahusay, at ini-evaluate ng Apache ang bawat regex sa bawat request — nagbabayad ka ng tunay na performance tax para sa zero na seguridad. Laktawan mo ang mga ito.

IP-locking ng wp-login.php. Mahusay hanggang paikutin ng iyong ISP ang iyong address at nai-lock mo ang sarili mo palabas ng sarili mong admin. Viable lang sa isang tunay na static IP.

Author-enumeration redirects (?author=1). Ang .htaccess rewrite na pino-paste ng mga tao para dito ay hindi kumpleto nang mag-isa — ang REST endpoint na /wp-json/wp/v2/users ay naglilista pa rin ng mga username. Ang pag-block sa isang path habang bukas ang isa pa ay palabas lang.

Nasadlak pa rin?

Kung nag-500 ang site dahil sa isang rule, syntax iyon — tanggalin ang huling block na idinagdag mo at i-reload; agad nitong naihihiwalay iyon. Kung parang walang ginagawa ang isang rule, kumpirmahin na nasa Apache ka nga at naka-enable ang AllowOverride para sa direktoryo (maraming managed host ang nagre-restrict nito). Buuin ang file mula sa isang known-good na template gamit ang .htaccess generator, panatilihin ang tatlong rule na mahalaga, at ibaba ang iba.