Həqiqətən Kömək Edən WordPress .htaccess Təhlükəsizlik Qaydaları

“WordPress .htaccess təhlükəsizliyi” adı altında satılanların çoxu doldurmadan ibarətdir. Hücum səthinizi həqiqətən dəyişən qaydalar qısadır: wp-content/uploads daxilində PHP icrasını bloklayın, wp-config.php-a birbaşa girişi qadağan edin və qovluq indeksləşdirməsini söndürün. Populyar olanlar — “brute force-u dayandırmaq üçün” xmlrpc.php-ı bloklamaq, WordPress versiyanızı gizlətmək, 200 sətirlik pis-bot user-agent siyahısı yapışdırmaq — cüzi faydadan tam teatra qədər dəyişir. Aşağıda hansının hansı olduğunu və nə üçün olduğunu göstəririk.

Əvvəlcə bir məsələni həll edək: .htaccess yalnız Apache-də (və onu da oxuyan LiteSpeed-də) hər hansı bir iş görür. nginx-də isə tamamilə nəzərə alınmır — fayl orada sadəcə durur, siz isə qorunduğunuzu düşünürsünüz. Əgər hostinqiniz nginx işlədirsə, bunların heç biri sizə aid deyil və sizə əvəzində server/location blokları lazımdır. curl -I https://yoursite.com ilə yoxlayın və serverin heç vaxt oxumayacağı bir faylı redaktə edərək bir saat sərf etməzdən əvvəl Server: başlığına baxın.

Həqiqətən əhəmiyyət kəsb edən qayda: /uploads-da PHP olmasın

Bu, görməyə dəyər olanıdır. wp-content/uploads dizayn etibarilə hamı üçün yazıla bilən qovluqdur — hər media yükləməsi, fayl saxlayan hər plagin oraya yazır. Əgər hücumçu bu qovluğa .php faylı yerləşdirə bilsə (zəiflikli yükləmə emalçısı, MIME tipini yoxlamayan şəkil sahəsi və ya sındırılmış plagin vasitəsilə), narahatçılıqla tam uzaqdan-kod-icrası kompromisi arasındakı fərq serverin sorğu gələndə həmin faylı icra edib-etməməsindən asılıdır. İcranı qadağan edin və yüklənmiş yük diskdə sadəcə hərəkətsiz bir fayl olaraq qalır.

Bunu wp-content/uploads/.htaccess faylına əlavə edin (fayl yoxdursa, yaradın):

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

Bu, Apache 2.4 sintaksisidir. Köhnə 2.2-də ekvivalenti Order Deny,Allow / Deny from all-dur. Bir faylda hər iki dialekti qarışdırmaq “hardening”-dən sonra qəflətən 500 Internal Server Error alınmasının ən çox rast gəlinən səbəbidir — əgər saxladığınız anda bütün sayt ölürsə, demək olar ki, həmişə səbəbi budur. Versiyanızı apachectl -v ilə yoxlayın.

wp-config.php-ı qoruyun

wp-config.php verilənlər bazası etimadnamələrinizi və autentifikasiya salt-larını saxlayır. PHP işləyərkən ona birbaşa sorğu boş səhifə qaytarır — PHP faylı çap etmək əvəzinə icra edir. Risk uğursuzluq halındadır: əgər PHP nə vaxtsa çökərsə, miqrasiya zamanı səhv konfiqurasiya edilərsə və ya emalçı söndürülərsə, Apache faylı düz mətn kimi verir və verilənlər bazası parolunuzu soruşan hər kəsə açıqlayır. Girişi qadağan etmək pis beş dəqiqəyə qarşı ucuz sığortadır:

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

Qovluq indeksləşdirməsini söndürün

Əgər kimsə index.php olmayan bir qovluğu ziyarət edirsə və Apache-də Options +Indexes aktivdirsə, o, məzmunu sadalayır — hər ehtiyat nüsxə faylı, unutduğunuz hər ehtiyatsız SQL dump-ı. Bunu bütün sayt üzrə söndürün:

Options -Indexes

Aşağı ciddiyyətdə, amma realdır və heç nəyə başa gəlmir.

Bu, dürüst əsas siyahıdır. Bunları — düzgün 2.4-e-qarşı-2.2 sintaksisi ilə birlikdə, ki saytınızı 500-ə salmayasınız — yanlış Apache versiyası üçün yazılmış bir forum postundan kopyalayıb yapışdırmaq əvəzinə WordPress .htaccess generatoru ilə yığa bilərsiniz.

Nə etməMƏLİ

“Brute-force qorunması üçün” xmlrpc.php-ı bloklamaq. Bu, hamının təkrarladığı böyük məsələdir və deyildiyi kimi səhvdir. Bəli, XML-RPC-nin system.multicall metodu tarixən hücumçuya çoxlu giriş təxminini vahid sorğuda birləşdirməyə imkan verirdi — real gücləndirmə. Amma qat-qat çox rast gəlinən brute-force vektoru wp-login.php-a adi POST sorğularıdır və xmlrpc.php-ı bloklamaq bunun üçün heç nə etmir. Brute force sürət məhdudlaşdırması, güclü parollar və 2FA ilə məğlub edilir — bir endpoint-i öldürməklə deyil. XML-RPC-ni söndürmək üçün legitim bir səbəb var: onun pingback funksiyası DDoS reflection üçün sui-istifadə edilə bilər, ona görə də Jetpack, mobil tətbiq və ya pingback-lərdən istifadə etmirsinizsə, onu bağlamaq hücum səthinizi kiçildir. Sadəcə özünüzə bunun brute-force müdafiəniz olduğunu deməyin, çünki deyil.

WordPress versiyanızı gizlətmək / generator etiketini silmək. readme.html-ı və <meta name="generator"> etiketini çıxarmaq hardening kimi hiss olunur. Hücumçu versiyanızı növbəyə alınmış asset sorğu sətirlərindən, blok-redaktor işarələməsindən və saniyələr ərzində onlarla başqa əlamətdən müəyyən edir. Siz heç nə gizlətmirsiniz; sadəcə özünüzü məşğul hiss etdirirsiniz.

Nəhəng pis-bot user-agent və referrer bloklama siyahıları. User agent-lər tək bir saxta HTTP başlığıdır. Bu siyahılar yapışdırdığınız gün köhnəlmiş olur, səriştəli heç nəyi bloklamır və Apache hər sorğuda hər regex-i qiymətləndirir — sıfır təhlükəsizlik üçün real performans vergisi ödəyirsiniz. Onlardan keçin.

wp-login.php-ı IP-yə kilidləmək. ISP-niz ünvanınızı dəyişdirənə və öz admininizdən özünüzü kilidləyənə qədər əladır. Yalnız həqiqətən statik IP ilə məqsədəuyğundur.

Müəllif sıralamasını yönləndirmə (?author=1). İnsanların bunun üçün yapışdırdığı .htaccess yenidənyazması tək başına natamamdır — /wp-json/wp/v2/users REST endpoint-i hələ də istifadəçi adlarını sadalayır. Bir yolu bloklayıb digərini açıq saxlamaq teatrdır.

Hələ də ilişmisiniz?

Əgər bir qayda saytı 500-ə salırsa, bu sintaksisdir — əlavə etdiyiniz son bloku çıxarın və yenidən yükləyin; bu, onu dərhal təcrid edir. Əgər bir qayda heç nə etmirmiş kimi görünürsə, həqiqətən Apache-də olduğunuzu və qovluq üçün AllowOverride-ın aktiv olduğunu təsdiq edin (bir çox idarə olunan hostinq onu məhdudlaşdırır). Faylı bilinən-yaxşı şablondan .htaccess generatoru ilə yığın, əhəmiyyət kəsb edən üç qaydanı saxlayın və qalanını atın.