Защита на сайта: права, хедъри и разширения за сигурност

Модул 7: Сигурност · Време за четене: 10 минути

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

Ключови понятия: защита (hardening), права на файлове (644, 755), DISALLOW_FILE_EDIT, без PHP в uploads, списък на съдържанието на папка, скриване на версията, X-Powered-By, хедъри за сигурност, резервни файлове и .git в уеб папката, WAF на сървъра, WAF в разширение, скенер за злонамерен софтуер

Какво означава защита (hardening)

Защитата (hardening) означава: настройване на сайта така, че грешка или пробив да причинят по-малко щети. Тя не замества актуализациите и силните пароли (урок 7.2 и 7.3), но намалява последствията. Представете си къща: актуализациите са ключалките, а защитата означава да се погрижите крадец, който все пак е влязъл, да не стигне до сейфа.

Права на файлове

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

Коя стойност работи за wp-config.php, зависи от това как Вашият хостинг доставчик изпълнява PHP: при повечето споделени хостинг услуги PHP се изпълнява като Ваш собствен потребител, и тогава 600 е достатъчно. Пробвайте и проверете дали сайтът още работи.

Никога 777. Това означава: всеки на сървъра може да записва. Ръководство, което казва „задайте 777 на папката, ако качването не работи“, решава проблема по грешен начин. При добър хостинг това никога не е необходимо.

Настройки в wp-config.php

Няколко реда, които правят голяма разлика (преди „спрете редактирането“):

// Без редактиране на файлове от администрацията (Appearance > Theme Editor и Plugins > Plugin Editor).
define( 'DISALLOW_FILE_EDIT', true );

// Съобщенията за грешки никога на екрана на посетителите (урок 5.4).
define( 'WP_DEBUG', false );

С DISALLOW_FILE_EDIT изчезва редакторът, с който от администрацията можете да редактирате PHP файловете на теми и разширения. Крадец, който завладее акаунт на администратор, тогава не може с два клика да сложи злонамерен код във Вашата тема. Все още можете да инсталирате разширения; ако искате да забраните и това (например при сайт, който управлявате за клиент), има DISALLOW_FILE_MODS, но тогава и актуализациите чрез администрацията вече няма да работят.

Без PHP в uploads, без списък на съдържанието на папка

В wp-content/uploads трябва да има изображения и документи, никога PHP файлове. Крадци, които чрез пробив могат да качат файл, се опитват именно да поставят PHP файл и да го извикат. Блокирайте това с .htaccess в папката uploads (при LiteSpeed и Apache):

<Files *.php>
Require all denied
</Files>

Изключете също показването на съдържанието на папки. Без index.php или index.html в дадена папка някои уебсървъри показват списък с всички файлове („Index of /wp-content/uploads/2026/11“). Това е витрина за всеки, който търси резервни копия или чувствителни документи. В .htaccess на Вашата уеб папка:

Options -Indexes

Много хостинг доставчици вече имат това изключено по подразбиране. Задачата от този урок го проверява.

Без остатъци в уеб папката

Всичко в уеб папката може да бъде поискано през уеб, освен това, което сървърът изпълнява като PHP или блокира. Опасни са:

• копия на wp-config.php (wp-config.php.bak, wp-config.old, wp-config.php~ от текстов редактор): те съдържат паролата за базата данни и се изпращат като текст (урок 1.3);
• резервни копия като backup.zip, site.tar.gz или database.sql в уеб папката;
• папка .git от разработчик, с която някой може да изтегли целия Ви код (а понякога и пароли);
• debug.log в wp-content (урок 5.4);
• стари файлове за инсталиране или тестване, например info.php с phpinfo().

Съхранявайте резервни копия извън уеб папката или извън сървъра, и почиствайте остатъците.

Скриване на версията: малка полза

WordPress добавя по подразбиране в HTML:

<meta name="generator" content="WordPress 7.1.4" />

и същото в RSS емисията. Също и PHP понякога се обажда в хедър: X-Powered-By: PHP/8.3.14. Скриването на това е разумно, но не очаквайте твърде много от него: програмите на крадците просто пробват пробив, независимо от версията, която показвате, а версиите често могат да се изведат и от ?ver= след скриптовете. Скриването е почистване, не е сигурност. Сайт, който скрива версията си, но не се актуализира, е също толкова уязвим.

Ето как се прави, в собствено малко разширение или във functions.php на Вашата child theme:

remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );

А PHP хедъра с expose_php = Off в PHP настройките на Вашия хостинг доставчик (при DirectAdmin в Select PHP version, Options), или с Header unset X-Powered-By в .htaccess.

Хедъри за сигурност

С няколко хедъра казвате на браузъра как да се отнася към Вашия сайт. Най-важните:

В .htaccess (при LiteSpeed и Apache):

<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

След това проверете дали всичко работи: вградено съдържание, бутони за плащане, джаджа за чат. Външни инструменти като securityheaders.com и internet.nl показват какво изпраща Вашият сайт.

Разширения за сигурност, честно погледнато

Има много разширения за сигурност (например Wordfence, Solid Security, All-In-One Security, Sucuri). Те често обединяват: защитна стена (firewall), скенер за злонамерен софтуер, защита при вход, двуфакторно удостоверяване, известия и списък за защита. Полезни, но с граници:

• Защитна стена в разширение (WAF) стартира едва когато PHP вече работи. Злонамерена заявка трябва първо да премине през уебсървъра и PHP, преди разширението да я види. Пробив в PHP файл, който се извиква директно, или атака, която натоварва тежко самия PHP, не винаги се спира. Защитна стена на сървъра (например ModSecurity, Imunify360 или защитна стена на Вашия хостинг доставчик) се намира по-рано във веригата и спира повече, без Вашето разширение да върши изчисленията. Попитайте Вашия хостинг доставчик какво работи на сървъра.
• Скенер открива впоследствие. Скенер за злонамерен софтуер Ви казва, че нещо не е наред. Това е ценно, но не предотвратява нищо. А скенер на същия сървър като хакнат сайт може и самият той да бъде променен от крадеца.
• Те не заместват актуализациите. Разширение с известен пробив остава уязвимо, дори с разширение за сигурност до него. Някои услуги за сигурност предлагат „виртуални кръпки“, които спират известни атаки, докато не актуализирате; удобно като мост, не като замяна.
• Те самите са разширение. Повече код, повече за актуализиране, понякога самите те съдържат пробив. И две разширения за сигурност едновременно често се сблъскват.
• Те изискват изчислителна мощност, особено скенери, които работят на собствения Ви сървър.

Разумен избор: първо проверете какво вече прави Вашият хостинг доставчик (защитна стена, сканиране за злонамерен софтуер, блокиране на опити за вход). Допълнете липсващото, обикновено двуфакторно удостоверяване и ограничаване на опитите за вход. Разширено разширение за сигурност е особено полезно при хостинг, който сам по себе си прави малко.

Обобщение

• Защитата (hardening) ограничава щетите от грешка или пробив; тя не заменя актуализациите и паролите.
• Папки 755, файлове 644, wp-config.php по-строго; никога 777.
• Включете DISALLOW_FILE_EDIT, блокирайте PHP в uploads, изключете списъците на съдържанието на папки и почистете резервни копия, .git и debug.log от уеб папката.
• Скриването на версията е почистване, не сигурност; хедърите за сигурност помагат на браузъра да защити Вашите посетители.
• Защитна стена на сървъра спира повече от разширение; разширенията за сигурност са допълнение, не замяна.

Тест

Задача

Задача A7.4: Какво показва Вашият сайт на всички? Въведете адреса на Вашия сайт. Програмата прочита началната страница и RSS емисията (/feed/) и проверява: няма версия на WordPress в generator тага на HTML и емисията, хедърът X-Powered-By не показва PHP версия, и дали сайтът Ви изпраща X-Content-Type-Options: nosniff, защита срещу frame (X-Frame-Options или frame-ancestors) и Referrer-Policy? HSTS (урок 3.1) и Permissions-Policy могат да липсват (оранжево).

Задача A7.4b: Без остатъци в уеб папката. Докажете, че сайтът е Ваш (TXT запис или файл с кода от задачата). Програмата след това проверява кратък фиксиран списък: папката /wp-content/uploads/ (без списък на съдържанието), /.git/HEAD, /wp-content/debug.log и няколко често срещани имена на копия на wp-config.php. Добре е, ако никое от тях не връща съдържание (404 или 403). Програмата не пробва нищо друго и нищо не променя.

Допълнително четене

Тези статии описват стъпките в панелите на WebOké; в други панели работят по подобен начин.

• Ръководство за DirectAdmin 11.5: Права на файлове и директории (chmod)
• Ръководство за DirectAdmin 11.4: Показване и редактиране на скрити файлове като .htaccess
• Ръководство за DirectAdmin 15.10: Web Application Firewall
• Ръководство за DirectAdmin 15.11: Imunify360: сканиране на уебсайта Ви за злонамерен софтуер
• Блокиране на файлове чрез .htaccess, например plugin-googlemap2-proxy.php
• Сигурност на PHP
• Защита на WordPress (developer.wordpress.org, на английски): https://developer.wordpress.org/advanced-administration/security/hardening/
• Хедъри за сигурност (MDN, на английски): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#security