Защита с ясни действия.
От проверка до решение.

Преди първата промяна: обхват, архив и аварийна конзола

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

Направете архив на файловете, базите и конфигурацията извън публичната директория. Пазете отделно копие с ограничен достъп. Проверете възстановяване в изолирана среда. Snapshot на доставчика е полезен допълнителен слой, но не заменя проверено копие на данните. Осигурете конзолата на хостинга, преди да променяте SSH, VPN или firewall.

1. Операционна система, работещи услуги и отворени портове

За Linux сървър започнете с версията на системата, активните услуги, слушащите портове и неуспешните системни задачи. Следните примери са за администратор на Ubuntu/Debian и не променят конфигурацията:

cat /etc/os-release
uname -r
systemctl --failed
systemctl list-units --type=service --state=running
sudo ss -lntup

Съпоставете всеки порт с реална нужда. База данни, административен панел и вътрешен API обикновено не трябва да са достъпни за целия интернет. Проверете достъпността и от външна мрежа: локално слушащ порт може вече да е блокиран от firewall. Не спирайте непозната услуга, преди да установите кой я използва.

2. Системни актуализации и реална наличност на поправка

След проверен архив обновете пакетния индекс и прегледайте наличните версии:

sudo apt update
apt list --upgradable
apt-cache policy php8.3-fpm php8.3-cli
 test -f /var/run/reboot-required && cat /var/run/reboot-required

Имената на PHP пакетите са примерни: заменете ги с действително инсталирания клон. Съпоставете пълната версия на пакета и изданието на Ubuntu с официалното известие за сигурност. Дистрибуциите могат да пренасят поправки в пакет с по-стар основен номер; само изходът на php -v не доказва наличие или липса на поправка.

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

Официални Ubuntu Security Notices

3. Всички PHP версии, включително скритите в панели

Проверете отделно PHP в командния ред, PHP-FPM или Apache, cron задачите, контейнерите и софтуера на хостинг панела. Един актуален публичен сайт не означава, че уебпощата или инструментът за базите използват същата версия.

php -v
php --ini
systemctl list-unit-files 'php*-fpm.service'
dpkg-query -W 'php*'

Съпоставете всеки виртуален хост с неговия PHP обработчик. Обновете всички използвани изпълними среди от доверен източник. Старите услуги се спират едва след проверка на зависимостите и успешна миграция. Ако нова версия счупи приложение, поправете съвместимостта в копие; не приемайте връщането към неподдържан PHP като постоянно решение. Не оставяйте публичен phpinfo() файл след проверката.

Проверете актуалния жизнен цикъл на PHP

4. CMS, плъгини, теми и библиотеки

Проверете ядрото и разширенията на WordPress или друга CMS. Премахнете неизползваните компоненти след архив. За Composer проект изпълнете от директорията му с обикновения потребител на приложението:

composer validate --no-check-publish
composer audit --locked --no-dev
composer check-platform-reqs --no-dev

Одитът проверява известни съобщени проблеми в зависимостите; чист резултат не удостоверява целия потребителски код. Прегледайте и изоставените пакети. Изберете съвместими версии, обновете lock файла в тестово копие, проверете миграциите и основните процеси. Не изпълнявайте безразборно composer update в работещата продукция.

Composer: audit и проверки на платформата

5. Панели, доверени устройства и обходни адреси

Направете списък на FASTPANEL, phpMyAdmin, уебпоща, SSH, CMS входове и вътрешни системи. За нуждаещите се от ограничаване услуги изберете VPN с отделен ключ за всяко устройство или подходяща идентификационна защита с MFA. Различни профили в панела не трябва да заобикалят мрежовото ограничение.

Проверете основния домейн, директния IP адрес, IPv6, алтернативните имена, портове и backend адреси. Защитете origin сървъра, а не само входния адрес зад прокси. Изпробвайте достъп от доверено устройство и отказ от външна мрежа. Запишете процедура за отнемане на изгубено устройство и авариен достъп през конзолата на доставчика.

6. SSH ключове и права на администраторите

Използвайте индивидуални профили и ключове, ограничени sudo права и MFA, когато средата го поддържа. Преди изключване на паролите проверете вход с ключ в отделна сесия. Пазете текущата връзка отворена, докато потвърдите новия вход.

sudo sshd -t
sudo sshd -T

Първата команда проверява синтаксиса, а втората показва ефективната конфигурация. Прегледайте и включваните настройки в sshd_config.d; условията Match могат да променят поведението за конкретен потребител. Приложете настройките с подходящо reload действие едва след успешна проверка и осигурена аварийна конзола.

Ubuntu: OpenSSH

7. Firewall, IPv6, WAF и ограничения на заявките

Съгласувайте защитната стена на доставчика с тази на самия сървър. За система с UFW прегледът е:

sudo ufw status verbose
sudo ufw status numbered

Разрешете нужния административен маршрут, преди да ограничавате останалото. Проверете IPv4 и IPv6, пощата, DNS и подновяването на сертификатите. Не копирайте произволни правила и не включвайте firewall дистанционно без план за възстановяване. При Docker проверете действителните мрежови правила и публикуваните портове.

WAF и ограниченията за опити за вход могат да намалят определени атаки. Те не поправят уязвимия код и не заменят актуализациите. Проверете, че правилата не блокират нормални форми, API и качвания.

Ubuntu: firewall

8. Файлови права, изолация, бази и тайни

Разделете независимите приложения по системни потребители и PHP-FPM пулове, когато архитектурата го позволява. Дайте право за запис само на нужните upload, cache и runtime директории. Масово задаване на 777 не е поправка.

Конфигурации с пароли, базови SQL архиви, Git история и резервни копия трябва да са извън публичния корен или изрично недостъпни през уеб сървъра. За всеки сайт използвайте отделен потребител на базата с необходимите права. Проверете дали базата слуша само на нужен интерфейс. При доказано изтичане сменете засегнатите тайни след ограничаване и почистване на средата; изтриването на един подозрителен файл не премахва непременно достъпа на атакуващия.

9. Форми, вход, сесии и качване на файлове

Проверете сървърната валидация, параметризираните SQL заявки, кодирането на изхода, проверките на роли и собствеността на записите. За променящи данни действия използвайте подходящата CSRF защита на рамката. HTTPS и SameSite са допълващи мерки, а не заместител на всички проверки.

При качване използвайте списък с разрешени типове, ограничения на размера, проверка на действителния формат и генерирани имена. Каченото съдържание не трябва да се изпълнява като PHP. Съхранявайте файловете извън изпълнимия корен, когато е възможно. Проверете възстановяването на парола, MFA, прекратяването на сесии и ограниченията за многократни опити за вход.

OWASP: удостоверяване · CSRF · качване на файлове

10. HTTPS, сертификати и HTTP заглавки

Проверете валидността на сертификата, имената, веригата и автоматичното подновяване. Изпробвайте HTTP, HTTPS, www и основния домейн. Заглавки като HSTS, CSP, защита от вграждане и nosniff се въвеждат според приложението и след проверка.

curl -I https://example.com/
sudo nginx -t

example.com е примерен адрес: използвайте собствения си домейн. CSP трябва да разрешава необходимите ресурси, без произволни широки изключения. HSTS с поддомейни може да засегне други услуги; не го активирайте без инвентаризация. След успешен nginx -t приложете промяната чрез reload и проверете сайта отново. При Apache използвайте неговия конфигурационен тест.

Nginx: конфигурация и reload

11. Логове, сигнали, архиви и периодични проверки

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

df -h
systemctl --failed
sudo journalctl -p warning --since today

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

12. Какво да направите при съмнение за пробив

Ограничете засегнатата услуга и запазете логовете, времевата линия и снимка на състоянието, преди почистване. Преценете дали има изтичане на данни, други засегнати приложения и задължения за уведомяване според конкретния случай.

Отстранете първоначалната причина, проверете други акаунти и механизми за постоянен достъп и възстановете от доверен източник. Сменете засегнатите пароли, ключове и сесии от чисто устройство след овладяване на средата. Не приемайте липсата на видими странни файлове за доказателство, че всичко е чисто.

13. Кога промяната може да се приеме за успешна

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

Проверете публичния сайт от телефон и външна мрежа, а административния достъп — от разрешено и неразрешено устройство. Запишете извършеното, неприключените рискове и следващата проверка. Резултатът от автоматичен скенер или Lighthouse е част от доказателствата, не сертификат за пълна сигурност.