Типовий злам сайту малого бізнесу виглядає зовсім не так, як уявляють власники. Ніхто не підбирає ваш пароль вручну і не цікавиться саме вашим прайсом. Бот обходить мільйони доменів поспіль, перевіряє десяток відомих дір і йде далі — а ваш сайт стає майданчиком для фішингу, розсилки спаму або чужих посилань у футері. Нижче — чекліст із п’яти блоків, який закриває переважну більшість автоматичних сценаріїв, приклад конфігурації сервера та порядок дій, якщо ви вже всередині інциденту.

Як насправді ламають сайти малого бізнесу

Логіка «та кому я потрібен» — головна причина, чому сайти падають. Ботам байдуже, чим ви торгуєте: вони шукають не вас, а конкретну версію плагіна, відкриту адмінку чи забутий піддомен. Власник зазвичай дізнається про злам не від хостера, а від Google — коли в результатах пошуку замість опису компанії з’являється попередження про шкідливий сайт, а органічний трафік падає до нуля за одну добу.

• Відомі уразливості в плагінах і темах — найпоширеніший вхід. Між публікацією уразливості й масовим скануванням минає одна-дві доби, а середній сайт оновлюють раз на пів року.
• Слабкі й повторно використані паролі адмінки — без обмеження спроб входу бот перебирає десять тисяч найпопулярніших паролів за кілька годин.
• Форми без валідації та ліміту запитів — від банального спаму до завантаження виконуваного файлу під виглядом картинки.
• Забуті доступи — тестовий піддомен, стара копія сайту в теці /old, відкритий phpMyAdmin, ключ доступу, який випадково потрапив у публічний репозиторій.
• Скомпрометований комп’ютер підрядника — паролі, збережені у FTP-клієнті, крадуть трояни, і в логах це виглядає як цілком легітимний вхід.

Спільне в усіх п’яти векторах — жоден із них не потребує кваліфікації. Це конвеєр. Саме тому базова гігієна дає непропорційно великий ефект: вам не треба бути невразливим, достатньо бути дорожчим за сусідній домен у списку бота. Якщо є підозра, що чуже вже всередині, це найпростіше виявити під час технічного аудиту сайту — сторонні скрипти й підмінені мета-теги випливають першими.

Транспорт: HTTPS і заголовки, які має віддавати сервер

Сертифікат сьогодні безкоштовний і автоматично поновлюється, тож питання не в тому, чи вмикати HTTPS, а в тому, чи вимкнено HTTP повністю. Дуже часто робоча копія сайту віддається і по http://, і по версії з www, без жодного редиректу — це водночас і дірка, і дублювання сторінок для пошуку. Наступний шар — заголовки: сервер має явно повідомляти браузеру, що йому дозволено робити з вашою сторінкою.

# Базовий набір заголовків безпеки для nginx
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'self'" always;

Найважчий рядок тут — Content-Security-Policy, і він же дає найбільше. Коректно налаштована політика робить безглуздою більшість XSS-атак: навіть якщо чужий скрипт потрапив у сторінку, браузер відмовиться його виконувати. Той самий заголовок найчастіше ламає аналітику, чат-віджети й вбудовані відео, якщо увімкнути його наосліп у п’ятницю ввечері.

Оновлення, доступи й принцип мінімальних прав

Другий за частотою вхід після плагінів — облікові записи. Технічно тут немає нічого складного, зате потрібна організаційна дисципліна, якої зазвичай і бракує. П’ять правил нижче ми прописуємо в регламенті підтримки кожного проєкту.

1. 1

   Оновлюйте за розкладом, а не «коли зламається»

   Раз на місяць — ядро, плагіни й залежності, спершу на копії сайту, потім на бойовому. Критичні патчі безпеки — протягом 48 годин. Це одна-дві години на місяць, які закривають найбільший клас ризиків.

2. 2

   Приберіть усе, чим не користуєтесь

   Кожен неактивний плагін, стара тема, тестовий піддомен і копія сайту в теці /backup — це діюча уразливість, яку ніхто не оновлює. Видаляйте, а не деактивуйте: деактивований плагін лишається на диску й часто доступний ззовні.

3. 3

   Двофакторна автентифікація для всіх адміністраторів

   Без винятків, включно з підрядниками й вами. Це єдиний захід зі списку, який рятує навіть тоді, коли пароль уже витік, — а витікають паролі частіше, ніж здається.

4. 4

   Окремий обліковий запис на кожну людину

   Спільний логін на п’ятьох означає, що ви не зрозумієте, хто вніс зміну, і не відкличете доступ, коли людина піде. Заведіть іменні акаунти й закривайте їх у день звільнення.

5. 5

   Мінімальні права за замовчуванням

   Контент-менеджеру не потрібні права на встановлення плагінів, а зовнішньому копірайтеру — доступ до бази. Роль рівня «Редактор» покриває майже всі реальні задачі й зменшує вартість помилки.

Форми, файли й усе, що надсилає користувач

Будь-яке поле, куди відвідувач може щось ввести, — це офіційний вхід у вашу систему. Пошук, фільтр каталогу, форма зворотного зв’язку, завантаження резюме, коментар. Логіка захисту скрізь однакова: не довіряйте нічому, що прийшло з браузера, і перевіряйте це на сервері.

Резервні копії та план на випадок «уже сталося»

Копія, яку ніколи не відновлювали, — це не бекап, а надія. Половина інцидентів, з якими до нас приходять, супроводжується фразою «бекапи начебто робилися»: файли є, база стара на чотири місяці, або архів узагалі не розпаковується. Перевірка займає годину на квартал.

Якщо сайт уже поводиться дивно — редиректи на чужі домени, невідомі сторінки в індексі, різкий стрибок навантаження на сервер — порядок дій має бути таким, і саме в цій послідовності.

1. 1Зафіксуйте стан: зробіть копію сайту й бази «як є». Це єдиний спосіб потім зрозуміти, як саме зайшли.
2. 2Закрийте сайт заглушкою з кодом 503 і вимкніть публічний доступ до адмінки.
3. 3Змініть усі паролі: хостинг, база даних, SSH і FTP, адмінка, пошта на домені, ключі до зовнішніх сервісів.
4. 4Відновіться з копії, зробленої до дати першої підозрілої зміни, — не з останньої, вона вже може містити бекдор.
5. 5Оновіть усе до актуальних версій до того, як знімати заглушку, інакше вас зламають повторно тим самим вектором за добу.
6. 6Перевірте розділ проблем безпеки в Search Console, відправте запит на повторну перевірку і вручну перегляньте, що саме лишилося в індексі.

Часті питання про безпеку сайту

Коротко

• Майже всі зломи малих сайтів автоматичні, тож ціль — не бути невразливим, а бути дорожчим за сусідній домен у черзі бота.
• Чотири дії дають найбільший ефект: щомісячні оновлення, 2FA для всіх адміністраторів, серверна валідація форм і заголовки безпеки з CSP.
• Бекап без квартальної перевірки відновлення — це не резервна копія, а необґрунтоване припущення.
• План реагування треба написати до інциденту: у момент зламу немає часу вигадувати послідовність дій.