WordPress структура папак: Як забяспечыць доступ да «wp-includes» і абараніць сайт

Бяспека структуры папак WordPress – гэта не проста заблакаваць доступ да «wp-includes» цалкам, а граматна абмежаваць выкананне PHP-файлаў і выключыць спісванне змесціва каталога. «wp-includes» захоўвае важныя JavaScript, CSS і статычныя файлы ядра WordPress, таму поўнае блакаванне папкі можа парушыць працу дызайну, рэдактара або плагінаў. Правільны падыход: для Apache – праз .htaccess, для Nginx – праз server block з location правілам, забараняючы PHP, а затым правяраць сайт па 403/404 адказах і тэставаць крытычныя старонкі.

Адна з распаўсюджаных памылак бяспекі WordPress – спадзявацца толькі на моцны пароль або плагін. Зламыснікі часта скануюць каталёгі ядра, старыя плагіны, няправільныя правы і адкрытае спісванне. «wp-includes» – часта мэта такіх пошукаў. У гэтым артыкуле вы знойдзеце рэальныя крокі для абмежавання доступу да «wp-includes», тыповыя памылкі, канфігурацыі для Apache і Nginx, метады тэставання і чэк-ліст абслугоўвання. Для больш надзейнай інфраструктуры рэкамендуем хостынг WordPress і для агульнай абароны — Сертыфікат SSL.

Што такое «wp-includes» і чаму яго трэба абараняць?

«wp-includes» — адзін з асноўных каталогаў WordPress, у якім захоўваюцца бібліятэкі ядра, сістэма тэм, блок-рэдактар, REST API, апрацоўка медыя, класы, функцыі і шэраг JavaScript-файлаў. Гэта, фактычна, «матор» WordPress, які не прызначаны для прамога наведвання карыстальнікамі.

Звычайны наведвальнік не павінен адкрываць site.com/wp-includes/. Але ў зыходным кодзе старонкі часта сустракаюцца спасылкі на статычныя рэсурсы з гэтага каталога — напрыклад, скрыпты, emoji або элементы рэдактара. Таму мэта абароны — забараніць выкананне PHP-файлаў без парушэння працы статычных файлаў.

Гэта асноўны прынцып прафесійнай бяспекі структуры папак WordPress. Простае блакаванне каталога можа прывесці да «белых» старонак, непрацуючага рэдактара, праблем з тэмамі і плагінамі. Задача — абараніць файлы, патрэбныя WordPress, і зменшыць паверхню атак.

Якую карысць дае абмежаванне доступу да «wp-includes»?

Забарона выканання PHP у «wp-includes» не спыняе ўсе атакі, але значна зніжае рызыку. Калі сайт заражаны, зламыснікі імкнуцца загрузіць або выклікаць шкодныя PHP у даступных каталогах. Забараняючы выкананне PHP у «wp-includes», вы ствараеце дадатковы бар’ер.

Перавагі гэтага падыходу:

Абмежаванне прамога выкліку PHP-файлаў ядра па URL.
Зніжэнне рызыкі спісвання змесціва каталога.
Меньшая інфармацыйная адкрытасць пры аўтаматычных сканіраваннях.
Абарона на ўзроўні вэб-сервера, нават без плагіна.
Умацаванне бяспекі ў комплексе з WAF, SSL, актуальным PHP і правільнымі правамі.

Гэта толькі адзін з пластоў бяспекі. Калі ў вас стары плагін, слабая адміністратарская пароль або скампраметаваны FTP, абарона «wp-includes» не выратуе ад усіх пагроз. Комплексная бяспека — гэта хостынг, праграмнае забеспячэнне, кіраванне карыстальнікамі і абслугоўванне. Рэкамендуем Бяспечны вэб-хостынг і для дамена — Бяспека дамена.

Самыя частыя памылкі пры абмежаванні доступу

Поўнае блакаванне каталога

Самая распаўсюджаная памылка — блакаваць усе HTTP-запыты да «wp-includes» (403). Гэта здаецца лагічным, але WordPress загружае адтуль статычныя файлы. У выніку можа не працаваць блок-рэдактар, JavaScript, парушыцца дызайн.

Дадаваць правілы без тэставання

Нават адна памылка ў .htaccess або Nginx можа выклікаць 500 Internal Server Error. Не варта ўжываць правілы без тэставання: рабіце рэзервовую копію, лепш спачатку выпрабаваць на staging, а не на «жывым» сайце. Калі ў вас ёсць staging або backup (напрыклад, у Hostragons), натуральна ўключыць Рэзервовае капіраванне вэб-хостынгу.

Спадзявацца толькі на бяспечны плагін

Плагіны карысныя, але серверныя правілы спрацоўваюць раней і эканомяць рэсурсы. Таму нават пры выкарыстанні плагіна не забывайце пра асноўныя правілы сервера.

Чэк-ліст перад ужываннем

Падрыхтоўка перад абмежаваннем доступу зніжае рызыку збояў. Рэкамендуем:

Зрабіце рэзервовую копію вашага .htaccess або Nginx.
Абнавіце ядро WordPress, тэмы і плагіны.
Праверце, што ваша версія PHP актуальная і бяспечная.
Пераканайцеся ў правільнасці правоў: каталёгі 755, файлы 644.
Абмежуйце лішнія правы для wp-config.php і .htaccess.
Плануйце ачыстку кэша пасля зменаў (калі выкарыстоўваеце кэш, CDN або плагін бяспекі).
Складайце спіс крытычных старонак для тэставання: адміні панель, галоўная, блог, форма сувязі, аплата.

Гэта займае 10-15 хвілін, але абараняе ад гадзінных збояў. Для карпаратыўных сайтаў лепш рабіць змены ў перыяд нізкай нагрузкі.

Забараняем PHP у «wp-includes» для Apache праз .htaccess

У Apache (на shared хостынгу) самы просты спосаб — .htaccess. Дадайце правілы ў асноўны .htaccess і абавязкова зрабіце копію для адкату.

Рэкамендаванае правіла для .htaccess

Скарыстайцеся:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-includes/.*[.]php$ - [F,L]
</IfModule>

Гэта значыць: калі URL пачынаецца з wp-includes і заканчваецца на .php — забараніць. Статычныя .js, .css, .png, .svg застаюцца даступнымі. Так забяспечваецца баланс бяспекі і функцыяналу.

Забараняем спісванне каталога

Крытычна выключыць спісванне. Дадайце ў .htaccess:

Options -Indexes

Гэта хавае змесціва каталога без index-файла. Звычайна па змаўчанні на сучасных хостынгах, але праверка не перашкодзіць.

Тэставанне пасля змен

Пасля дадання правіл праверце:

Адрас site.com/wp-includes/ — не павінна быць спісу файлаў.
Прамой выклік PHP-файла ў wp-includes — павінна быць 403 або 404.
Галоўная, блог і адміні панель — працуюць?
Console і Network у браузеры — няма 404/403 для важных рэсурсаў?
Кэшаванне або CDN — ачысціце кэш.

Калі ўсё працуе — правіла можна пакідаць. Пры 500 памылцы — выдаліце даданыя радкі або адкатіце копію .htaccess.

Забараняем PHP для «wp-includes» у Nginx

У Nginx (.htaccess не працуе) — трэба дадаць правіла ў site config (server block). Патрэбен SSH-доступ і права на рэдагаванне канфігурацыі. Калі не ўпэўнены — звярніцеся ў падтрымку.

Рэкамендаванае location-правіла для Nginx

Дадайце:

location ~* ^/wp-includes/.*[.]php$ {
deny all;
}

Гэта забараняе PHP ў wp-includes. Пасля змены праверце:

nginx -t

Калі ўсё OK, перазагрузіце:

systemctl reload nginx

Reload — больш мяккі, не перарывае злучэнні. Для важных сайтаў — лепш рабіць у нізкай нагрузцы.

На што звяртаць увагу для Nginx

Правіла павінна быць у правільным server block (магчыма некалькі сайтаў).
CDN або proxy — ачысціце кэш і праверце.
Праверце PHP-FPM — апрацоўвае толькі патрэбныя файлы.
Журналы доступу і памылак — хутка выявяць праблемы.

Няправільны парадак location можа выклікаць нечаканыя вынікі. Праверце, што правіла не супярэчыць permalink і PHP-блокам.

Параўнанне метадаў

Табліца метадаў абмежавання доступу да «wp-includes»:

Параўнанне метадаў
Метад	Асяроддзе	Плюсы	Мінусы
.htaccess	Apache і LiteSpeed хостынг	Хутка, даступна на shared-хостынгу	Памылка — 500
Nginx location	VPS, dedicated, кіраваны сервер	Моцна і прадуктыўна на ўзроўні сервера	Патрэбны SSH і веды канфігурацыі
Плагін бяспекі	Пачаткоўцы	Лёгка кіраваць праз інтэрфейс	Не ўсе правілы на ўзроўні сервера
WAF/CDN	Высокая нагрузка, частыя атакі	Раняя фільтрацыя bot-аў і злосных запытаў	Магчыма выпадкова блакаваць карыстальнікаў
Правы файлаў	Усе сайты WordPress	Аснова бяспекі	Не абмяжоўвае доступ па URL

Лепшы вынік — камбінацыя метадаў: .htaccess, правільныя правы, актуальны WordPress, SSL, рэгулярны backup. Для ізаляванасці і firewall Карпаратыўны Хостынг — асабліва для важных праектаў.

Правы і ўладальнік файлаў

Без правільных правоў абмежаванне доступу да «wp-includes» не дае поўнай абароны. Папулярныя значэнні — каталёгі 755, файлы 644. Гэта дазваляе серверу чытаць файлы, але абмяжоўвае запіс. У некаторых хостынгах могуць быць свае рэкамендацыі.

Асабліва небяспечна — права 777. Гэта дазваляе любому запісваць у каталог, што адкрывае шлях для шкодных файлаў. Нават для wp-content/uploads лепш забараніць выкананне PHP. «wp-includes» не павінен быць запісвальным для карыстальніка.

Праверце:

Каталог «wp-includes»: 755
PHP-файлы ў «wp-includes»: 644
wp-config.php: 600 (або больш строга)
.htaccess: 644, без залішніх правоў

На розных серверах паводзіны могуць адрознівацца. Няправільныя правы могуць заблакаваць абнаўленні або чытанне файлаў. Пасля змен — праверце здароўе WordPress і логи памылак.

Ці робяць гэта бяспечныя плагіны?

Плагіны накшталт Wordfence, iThemes Security могуць аўтаматычна дадаваць hardening-правілы. Яны абараняюць ад brute force, сачаць за зменамі файлаў, сканіруюць на malware, абараняюць login. Але абмежаванне «wp-includes» залежыць ад канкрэтнага плагіна.

Некаторыя дадаюць правілы ў .htaccess, іншыя — толькі на ўзроўні прыкладання. Серверныя правілы спрацоўваюць раней, таму лепш выкарыстоўваць камбінацыю.

Пры выкарыстанні плагіна праверце:

Ці дадае плагін правілы ў .htaccess або Nginx.
Ці не канфліктуюць некалькі правіл з аднолькавай функцыяй.
Ці захоўваюцца абаронныя налады пасля абнаўлення плагіна.
Назірайце за ўплывам на прадукцыйнасць (cache, рэсурсы сервера).

Звычайна не варта выкарыстоўваць некалькі плагінаў бяспекі адначасова — канфлікт firewall, login і rewrite можа пагоршыць прадукцыйнасць або выклікаць памылкі.

Тэставанне абароны «wp-includes»: практычны сцэнар

Проста адкрыць сайт — недастаткова. Практычны 7-крокавы тэст для WordPress (ад малых бізнесаў да e-commerce):

1. Адкрыйце галоўную ў інкогніта і праверце дызайн.
2. Наведайце блог, катэгорыю і вынікі пошуку.
3. Увайдзіце ў wp-admin, адкрыйце рэдактар і медыя-бібліятэку.
4. Праверце Console у браузеры.
5. Network: статычныя файлы з «wp-includes» не павінны быць заблакаваныя.
6. Паспрабуйце выклікаць PHP-файл у «wp-includes» — павінна быць 403 або 404.
7. Праверце логи сервера на новыя або частыя памылкі.

Тэст займае 5 хвілін, але адразу выяўляе праблемы. Для WooCommerce — дадаткова праверце аплату, кошык, профіль. Нават дробная памылка ў JavaScript можа знізіць канверсію на «жывым» сайце.

Дадатковыя меры бяспекі для структуры папак WordPress

Абмежаванне «wp-includes» — толькі пачатак. Для комплекснай абароны:

Не хавайце версію WordPress — абнаўляйце ядро.
Цалкам выдаляйце неактуальныя тэмы і плагіны.
Складайце складаную адміні-лагін.
Уключайце двухфактарную аўтэнтыфікацыю.
Абмяжоўвайце XML-RPC, калі не выкарыстоўваеце.
Для wp-login.php — rate limit або дадатковая аўтэнтыфікацыя.
Аўтаматычныя backup і тэст аднаўлення.
Уключайце HTTPS для ўсяго сайта — без SSL дадзеныя пад пагрозай.

SSL не блакуе «wp-includes», але абараняе сесіі, формы і адміні панэль. Таму SSL — першы слой любога гайдлайна бяспекі WordPress. Рэкамендуем Купіць сертыфікат SSL і Усталёўка бясплатнага SSL.

Калі патрэбна прафесійная дапамога?

Дадаць .htaccess у Apache — нескладана. Але пры складаных канфігурацыях Nginx, multisite, WooCommerce, навінавых парталах або карпаратыўных праектах, лепш звярнуцца да спецыяліста. Бо важна не толькі тэхнічна, але і для бесперапыннасці бізнесу.

Прафесійная падтрымка патрэбна калі:

На серверы некалькі WordPress-сайтаў.
Ужываецца Nginx, Varnish, CDN, WAF разам.
Пасля змены павялічыліся 403/404/500 памылкі.
Сайт ужо быў заражаны malware.
Сістэма апрацоўвае аплату, рэгістрацыю, персанальныя дадзеныя.

Бяспечная інфраструктура, ізаляванасць, рэгулярны backup і падтрымка — крытычныя для бяспекі WordPress. Выбірайце хостынг не толькі па дыск-прасторы, але і па backup, firewall, падтрымцы PHP, SSL, якасці тэхнічнай падтрымкі. Рэкамендуем Hostragons пакеты хостынгу і Перанос сайта WordPress.

Вынік

Для бяспекі структуры папак WordPress абмежаванне доступу да «wp-includes» — гэта не поўная блакаванне каталога, а забарона PHP і выключэнне спісвання. Для Apache — .htaccess, для Nginx — location. Але перад зменамі робіце backup, пасля — тэстуйце адміні панель і публічныя старонкі.

Каротка: не блакуйце статычныя файлы, абмяжуйце PHP, выключыце спісванне, кантралюйце правы і рэгулярна абнаўляйце. Для бяспечнай і кіраванай WordPress-інфраструктуры скарыстайцеся хостынгам, даменам і SSL Hostragons, а таксама прафесійнай падтрымкай — па патрэбе.

Частыя пытанні

Ці бяспечна цалкам блакаваць «wp-includes»?

Не рэкамендуецца. У «wp-includes» захоўваюцца важныя JavaScript, CSS і статычныя файлы. Поўнае блакаванне парушае дызайн і адміні панэль. Лепшы шлях — забараніць PHP у гэтым каталогу.

Што рабіць, калі пасля .htaccess атрымліваю 500 памылку?

Спачатку выдаліце новыя правілы або вярніце backup. Праверце сінтаксіс. Калі памылка не знікла — праглядзіце логи хостынгу або звярніцеся ў падтрымку.

Ці працуе .htaccess на Nginx?

Не. .htaccess — толькі для Apache/LiteSpeed. У Nginx абмежаванні робяцца ў server block (location), пасля чаго трэба тэставаць nginx -t.

Ці робіць гэта мой WordPress цалкам бяспечным?

Не. Абарона «wp-includes» — важны слой, але не адзіны. Абнаўленні, моцныя паролі, двухфактарная аўтэнтыфікацыя, SSL, backup, firewall і правільныя правы — усё важна.

Калі я выкарыстоўваю плагін бяспекі, ці трэба асобна абмяжоўваць «wp-includes»?

Залежыць ад плагіна. Некаторыя дадаюць .htaccess, іншыя — толькі на ўзроўні прыкладання. Абмежаванне PHP на ўзроўні сервера — больш надзейна і не выклікае канфлікту.