Сигурност на структурата на папките на WordPress: Как да забраните достъпа до папката "wp-includes"

Сигурност на структурата на папките на WordPress се постига най-сигурно чрез забрана на директния достъп до папката "wp-includes", вместо да блокирате цялата папка наслеп. Това означава да забраните изпълнението на PHP файловете в тази папка и списъка на директории, а не да затворите цялата папка. Причината е, че wp-includes съдържа необходимите JavaScript, CSS и някои статични файлове за функционирането на ядрото на WordPress; блокирането на достъпа до цялата папка може да наруши дизайна на сайта, редактора или функционалностите на плъгините. Правилният подход е да забраните директния достъп до PHP, като използвате правила в .htaccess, ако ползвате Apache, или в правило за location в server block, ако ползвате Nginx, и след това да валидирате сайта чрез тестове с 403/404 отговори и критични страници.

Една от най-често срещаните грешки в сигурността на WordPress е да се разчита само на силна парола или на плъгин за сигурност. Често нападателите сканират директории, където се намират основните файлове, стари плъгини, неправилни разрешения на файловете и открито списъка на директории. Папката wp-includes е една от целите на тези сканирания. В това ръководство ще намерите приложими стъпки за ограничаване на достъпа до wp-includes в реална хостинг среда, кои правила могат да повредят сайта, примерни конфигурации за Apache и Nginx, методи за тестване и списък за поддръжка. Можете също така да разгледате опциите за WordPress хостинг и общи защитни мерки с SSL сертификат.

Какво е wp-includes и защо трябва да бъде защитен?

wp-includes е основна директория, съдържаща основните библиотеки на ядрото на WordPress. Тематичната система, блоковия редактор, компонентите на REST API, обработка на медии, класове, функции и различни JavaScript файлове са част от тази структура. С други думи, wp-includes е един от моторите на WordPress; не е зона, която потребителите трябва да посещават директно.

Обикновен посетител не трябва да отваря адрес като site.com/wp-includes/. Въпреки това, в изходния код на страницата могат да се видят някои статични ресурси под wp-includes. Например, стандартните скриптови файлове на WordPress, скриптове за емоджи или компоненти на редактора могат да се зареждат от тази директория. Следователно, при вземането на мерки за сигурност е важно да се определи правилната цел: да се забрани директния уеб достъп до PHP файловете, без да се блокира изпълнението на статичните файлове.

Тази разлика е основата на професионалния подход към сигурността на структурата на папките на WordPress. Блокирането на папките произволно може да изглежда безопасно в краткосрочен план, но може да доведе до проблеми като бяла страница, повреден администраторски панел, неработещ блоков редактор или неправилен вид на темата на живия сайт. Целта е да се защитят файловете, от които WordPress се нуждае, като се намали повърхността на атаката.

Какви предимства носи забраната на достъпа до wp-includes?

Забраната на директното изпълнение на PHP в папката wp-includes не спира всички атаки, но значително намалява повърхността на атаката. Особено на сайтове, заразени с вреден софтуер, нападателите опитват да качат вредни PHP файлове в достъпни директории или да извикат съществуващи файлове. Забраната на директното изпълнение на PHP файловете под wp-includes създава допълнителна бариера в този сценарий.

Тази мярка осигурява следните ползи:

• Ограничаване на директното извикване на основните PHP файлове чрез URL.
• Помага да се предотврати показването на съдържанието на папката, ако списъкът на директории е включен.
• Намалява ненужното изтичане на информация при автоматични бот сканирания.
• Осигурява защита на ниво уеб сървър, дори без плъгин за сигурност.
• Укрепва многослойната защита в комбинация с WAF, SSL, актуален PHP и разрешения на файловете.

Важно е да се отбележи, че тази операция е един слой от сигурността. Ако имате остарял плъгин, слаба парола на администратора или компрометирана FTP сметка, правилото за wp-includes не е достатъчно само по себе си. Сигурността е комбинация от хостинг инфраструктура, приложение, управление на потребителите и редовна поддръжка. За сигурна основа можете да се свържете с Сигурен уеб хостинг и допълнителна защита в управлението на домейни с Сигурност на домейна.

Най-често срещаните грешки при затваряне на wp-includes

Блокиране на цялата папка

Най-честата грешка е блокирането на всички HTTP заявки към папката wp-includes с 403. Този метод изглежда логичен на пръв поглед, но тъй като WordPress зарежда някои статични ресурси от тази директория, могат да възникнат неочаквани проблеми. Например, блоковият редактор може да не се отваря, някои JavaScript файлове може да не се зареждат или на фронта могат да се появят малки, но критични проблеми с дизайна.

Прилагане на правилото без тест

Дори един символ грешка в конфигурацията на .htaccess или Nginx може да генерира 500 Internal Server Error. Особено на сайтове с интензивен трафик, прилагането на правилото директно на живо е рисковано. Първо, трябва да направите резервно копие на файла, след което, ако е възможно, да тествате в staging среда и след това да преминете на живо контролирано. Ако се използват опции за staging или резервно копие в инфраструктурата на Hostragons, Резервно копиране на уеб хостинг може да бъде добавено като естествена вътрешна връзка.

Напълно разчитане на плъгини за сигурност

Плъгините за сигурност са полезни; обаче правилата на ниво уеб сървър влизат в действие по-рано. Ако заявката бъде блокирана от Apache или Nginx преди да достигне PHP, консумацията на ресурси също намалява. Затова дори да се ползва плъгин, основните правила на сървъра не трябва да се игнорират.

Контролен списък преди приложение

Кратка подготовка преди ограничаване на достъпа до wp-includes значително намалява риска от прекъсвания. Следният контролен списък е особено препоръчителен за живи WordPress сайтове:

• Направете резервно копие на текущата конфигурация на .htaccess или Nginx.
• Актуализирайте ядрото на WordPress, темите и плъгините.
• Убедете се, че версията на PHP е поддържана и безопасна.
• Проверете разрешенията на файловете: папките обикновено трябва да са 755, а файловете 644.
• Не оставяйте ненужно отворени разрешения за запис на критични файлове като wp-config.php и .htaccess.
• Ако използвате кеш, CDN или плъгин за сигурност, планирайте почистване на кеша след промяната.
• Създайте списък, който да тествате за критични области като администраторски панел, начална страница, страница с публикации, форма за контакт и страница за плащане.

Тези подготовки отнемат около 10-15 минути; обаче предотвратяват прекъсвания, които могат да продължат часове, причинени от грешно правило. На корпоративни сайтове е по-безопасно да се правят промени в часове с нисък трафик.

Забрана на достъпа до PHP в wp-includes с .htaccess на Apache сървър

Най-често използваният метод в споделени хостинги, използващи Apache, е файлът .htaccess. Правилата, добавени в .htaccess файла, намиращ се в основната директория на WordPress, могат да блокират определени PHP повиквания в wp-includes. Преди да започнете, изтеглете копие на файла на компютъра си или създайте резервно копие чрез файловия мениджър в хостинг панела.

Препоръчано правило за .htaccess

Следният подход се фокусира върху забраната на директния достъп до PHP в wp-includes и запазва изпълнението на статичните файлове:

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

Логиката на това правило е проста: ако URL-то започва с wp-includes и завършва с .php, заявката е забранена. Така PHP файловете в wp-includes не могат да бъдат извиквани от браузъра. От друга страна, достъпът до статични файлове като .js, .css, .png, .svg остава разрешен. Това е по-сигурен баланс за предния интерфейс на WordPress и администраторския панел.

Забрана на списъка на директории

Друга критична настройка е да се забрани списъкът на директории. Ако списъкът на директории е разрешен на сървъра, потребителите могат да видят съдържанието на някои папки. Добавянето на следния ред в основния ви .htaccess файл обикновено е достатъчно:

Options -Indexes

Този ред предотвратява показването на списъка на файловете в папките без индекс файл. На съвременни хостинги обикновено е зададено по подразбиране на "изключено"; обаче е добра практика да се провери.

Тест след промяната

След добавянето на правилото, направете следните тестове:

• Отворете адрес siteadresiniz.com/wp-includes/; списък на директории не трябва да се вижда.
• Опитайте да извикате известен PHP файл под wp-includes директно; трябва да получите 403 или 404.
• Проверете началната страница, публикацията в блога и администраторския панел.
• Проверете в инструментите за разработчици на браузъра в разделите Console и Network за наличие на 404/403 грешки.
• Ако използвате плъгин за кеш или CDN, изчистете кеша.

Ако всички тестове са успешни, правилото може безопасно да остане в продуктивната среда. Ако получите 500 грешка, най-бързото решение е да премахнете добавените редове и да възстановите резервното .htaccess.

Забрана на достъпа до PHP в wp-includes на Nginx сървър

На VPS, dedicated или управляеми сървъри, работещи с Nginx, .htaccess не работи. Правилото трябва да бъде добавено в конфигурационния файл на сайта на Nginx, обикновено в блока на сървъра. За тази операция е необходим достъп до SSH и разрешение за редактиране на конфигурационните файлове. Ако не сте сигурни, по-безопасно е да поискате помощ от екипа за поддръжка на хостинга.

Препоръчано правило за location в Nginx

Основното правило може да бъде приложено с следната логика:

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

Това правило блокира заявките към PHP файлове под wp-includes. След промяната е важно да тествате конфигурацията:

nginx -t

Ако тестът е успешен, Nginx ще бъде презареден:

systemctl reload nginx

Командата reload е по-контролирана в сравнение с restart; тя обновява конфигурацията без да прекъсва активните връзки. Въпреки това, е препоръчително да направите промените в периоди с нисък трафик на критични сайтове.

Неща, на които да се обърне внимание при използване на Nginx

• Убедете се, че добавяте правилото в правилния блок на сървъра; може да има множество сайтове на същия сървър.
• Ако използвате CDN или обратен прокси, направете реални тестове след изчистване на кеша на CDN.
• Проверете дали конфигурацията на PHP-FPM обработва само необходимите файлове.
• Проверявайте лог файловете: access.log и error.log бързо показват неправилното правило.

Неправилната подредба на location в Nginx може да доведе до неочаквани резултати. Затова уверете се, че правилото не конфликтира с permalink и PHP обработващите блокове на WordPress.

Сравнение на методите

Следната таблица обобщава основните методи, използвани за ограничаване на достъпа до wp-includes:

В практиката най-добрият резултат се постига с комбинирането на тези методи. Например, правилото за .htaccess в Apache хостинг, правилните разрешения на файловете, актуалното ядро на WordPress, SSL и редовното резервиране образуват многослойна защита. Поради значението на защитната стена и изолацията в хостинг инфраструктурата, изборът на Корпоративен хостинг може да направи разлика за критични сайтове.

Разрешения на файловете и настройки на собствеността

Забраната на достъпа до wp-includes остава непълна, ако разрешенията на файловете са неправилни. Общоприетите разрешения в WordPress са 755 за папки и 644 за файлове. Тези стойности позволяват на уеб сървъра да чете файловете, докато намаляват ненужните права за запис. В някои специализирани хостинг среди могат да съществуват различни конфигурации на потребителите и групите; следователно, трябва да се вземат предвид и препоръките на панела ви.

Особено разрешение 777 е сериозен риск за сигурността. Позволявайки на всеки да пише в папка, това улеснява сценарии за качване на вредни файлове. Дори в директории, които трябва да бъдат записваеми, като wp-content/uploads, трябва да се забрани изпълнението на PHP. Под нормални обстоятелства, wp-includes не трябва да бъде записваем от потребители, освен при актуализации на WordPress.

При одит на сигурността могат да се проверят следните стойности:

• Папка wp-includes: обикновено 755
• PHP файлове в wp-includes: обикновено 644
• wp-config.php: ако е възможно 600 или по-строги разрешения, съобразени с хостинг структурата
• .htaccess: обикновено 644, без ненужни права за запис след редакция

Тези настройки може да не функционират по един и същи начин на всеки сървър. Неправилните разрешения могат да доведат до невъзможност за актуализиране на сайта или за четене на файловете. След промените, здравословната проверка на WordPress и логовете за грешки трябва да се прегледат.

Правят ли плъгините за сигурност това?

Плъгини за сигурност като Wordfence и iThemes Security могат автоматично да предложат някои правила за затягане. Тези плъгини са полезни в области като защита от brute force, наблюдение на промени в файловете, сканиране за вреден софтуер и сигурност на входа. Обаче, относно забраната на достъпа до wp-includes, трябва да проверите какво точно прави плъгинът.

Някои плъгини автоматично добавят правило в .htaccess файла. Други предлагат защита само на ниво приложение. Защитата на ниво приложение влиза в действие след като заявката достигне WordPress, така че не е толкова ранна, колкото блокирането на ниво сървър. Затова професионалният подход е да оцените плъгина и конфигурацията на сървъра заедно.

Ако използвате плъгин за сигурност, направете следните проверки:

• Проверете дали плъгинът добавя правило за .htaccess или Nginx.
• Уверете се, че две различни правила, които правят същото, не си противоречат.
• Потвърдете, че настройките за сигурност не са се променили след актуализация на плъгина.
• Наблюдавайте влиянието върху производителността, като проверявате кеша и използването на ресурси на сървъра.

Използването на множество плъгини за сигурност едновременно често не е добра идея. Противоречиви правила за защитна стена, вход и пренаписване могат да понижат производителността или да причинят неправилни блокировки.

Тест на защитата на wp-includes: Практически сценарий

За да разберете дали приложението е успешно, не е достатъчно само сайтът да се зареди. Следният 7-стъпков практически тест може да се приложи на повечето WordPress инсталации, от сайтове на малки бизнеси до електронни търговски проекти:

• 1. Отворете началната страница в инкогнито режим и проверете за визуални повреди.
• 2. Посетете страница с публикация, категория и страница с резултати от търсене.
• 3. Влезте в wp-admin панела; отворете блоковия редактор и библиотеката с медии.
• 4. Проверете раздела Console в инструментите за разработчици на браузъра.
• 5. Потвърдете, че статичните файлове под wp-includes не са неправомерно блокирани в раздела Network.
• 6. Опитайте да извикате директно PHP файл под wp-includes; очаквайте 403 или 404 отговор.
• 7. Прегледайте логовете за грешки на сървъра за нови и повтарящи се грешки.

Тестът отнема около 5 минути и бързо улавя неправилни конфигурации. Особено за сайтове с процеси на плащане, като WooCommerce, страниците за количка, плащане и потребителски акаунти също трябва да бъдат тествани. Дори малко блокиране на JavaScript на живи приходи може да повлияе на процентите на конверсия.

Допълнителни мерки за сигурност на структурата на папките на WordPress

Защитата на wp-includes е добро начало; обаче е важно да се мисли цялостно за сигурността на WordPress. Следните допълнителни мерки допълнително намаляват повърхността на атаката:

• Дръжте ядрото актуално, вместо да се опитвате да скриете версията на WordPress.
• Изтрийте напълно неизползваните теми и плъгини.
• Направете името на администраторския потребител трудно за познаване.
• Използвайте двуфакторна автентикация.
• Ограничете достъпа до XML-RPC, ако не го използвате.
• Прилагайте лимит на заявките или допълнителна автентикация за wp-login.php.
• Извършвайте автоматични резервни копия и тестове за възстановяване.
• Използвайте HTTPS на целия сайт; без SSL, входните данни са рискови.

SSL не забранява директно достъпа до wp-includes; обаче осигурява основна защита за потребителски сесии, формуляри и трафик на административния панел. Поради това SSL винаги е един от първите слоеве в ръководствата за сигурност на WordPress. В тази връзка, закупи SSL сертификат и Инсталация на безплатен SSL могат да бъдат интегрирани естествено в съдържанието.

Кога да потърсите професионална помощ?

Добавянето на правило за .htaccess в обикновен Apache хостинг е управляемо за повечето потребители. Въпреки това, ако става въпрос за специална конфигурация на Nginx, мрежа от множество сайтове, магазин WooCommerce, новинарски сайт с висок трафик или корпоративен портал, може да бъде по-добре да получите професионална помощ. Защото правилото за сигурност трябва да бъде приложено не само технически правилно, но и безопасно за бизнес непрекъснатост.

Препоръчва се експертна помощ в следните ситуации:

• Ако хоствате множество WordPress сайтове на сървъра.
• Ако използвате Nginx, Varnish, CDN и WAF заедно.
• Ако след последните промени, 403, 404 или 500 грешките нарастват.
• Ако сайтът е имал предишни инфекции от вреден софтуер.
• Ако управлявате система, която обработва плащания, членства или лични данни.

Сигурната хостинг инфраструктура, правилната изолация, редовните резервни копия и експертната помощ са невидимите, но критични части от сигурността на WordPress. При избора на инфраструктура не се фокусирайте само на дисковото пространство; разгледайте и резервното копие, защитната стена, поддръжката на версията на PHP, управлението на SSL и качеството на техническата поддръжка. В този контекст, Hostragons пакети за хостинг и Прехвърляне на WordPress сайт могат да бъдат полезни за читателя.

Заключение

Правилният начин за забрана на достъпа до папката wp-includes в контекста на сигурността на структурата на папките на WordPress не е да блокирате цялата папка, а да забраните директния уеб достъп до PHP файловете в wp-includes и да деактивирате списъка на директории. Тази операция може да бъде бързо приложена с .htaccess за Apache и правила за location за Nginx. Въпреки това, преди всяка промяна е необходимо да се направи резервно копие, след което да се проведат тестове на администраторския панел и предния интерфейс.

Кратко резюме: не нарушавайте статичните файлове, ограничете достъпа до PHP, забранете списъка на директории, проверявайте разрешенията на файловете и правете редовни актуализации. За по-сигурна и управляема инфраструктура на WordPress можете да разгледате хостинг, домейн и SSL решенията на Hostragons и да получите помощ за конфигурация, която отговаря на вашите нужди.

Често задавани въпроси

Безопасно ли е напълно да затворите папката wp-includes?

Обикновено не се препоръчва. В wp-includes могат да се намерят JavaScript, CSS и статични файлове, от които WordPress се нуждае. Пълното блокиране може да повреди изгледа на сайта или администраторския панел. По-сигурният подход е да се забрани директният достъп до PHP файловете в тази папка.

Какво да направя, ако получа 500 грешка след добавяне на правило за .htaccess?

Първо премахнете последните добавени правила или възстановете резервното копие на .htaccess. След това проверете правилото за синтактични грешки. Ако проблемът продължава, прегледайте логовете за грешки на хостинга или поискайте помощ от техническата поддръжка.

Работи ли .htaccess на Nginx сървър?

Не. .htaccess се използва в Apache и LiteSpeed среди. На Nginx ограниченията се прилагат с правила за location в блока на сървъра и конфигурацията трябва да бъде тествана след промяната с nginx -t.

Тази операция ли прави WordPress сайта ми напълно безопасен?

Не. Забраната на достъпа до PHP в wp-includes е важен слой от сигурността, но сама по себе си не е достатъчна. Актуализациите, силните пароли, двуфакторната автентикация, SSL, резервните копия, защитната стена и правилните разрешения на файловете трябва да се прилагат заедно.

Ако използвам плъгин за сигурност, трябва ли да добавя правило за wp-includes?

Зависи от това какви правила прилага плъгинът. Някои плъгини добавят правило в .htaccess, докато други предлагат само защита на ниво приложение. Обикновено е по-силно решение да се ограничи достъпът до PHP на ниво сървър, без да се създават конфликти.