Безпека сайту: як захистити його від зламу

Чому атакують навіть невеликі сайти

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

Річ у тім, що вас ніхто не обирав. Переважна більшість атак на малий і середній бізнес не є персональними. Працюють програми: беруть списки доменів та IP-адрес, обходять їх поспіль і перевіряють десятки відомих вразливостей. Бот не знає, що ви стоматологія з Полтави чи майстерня кераміки. Він бачить рядок у відповіді сервера, впізнає версію популярної CMS, звіряється зі своїм переліком і йде далі, якщо не збіглося. Збіглося — починає працювати.

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

Навіщо взагалі ламати сайт-візитівку

Зловмисник рідко має на меті нашкодити саме вам. Зламаний сайт має ринкову вартість, і вона складається з кількох речей одночасно:

• Посилальна вага. На ваші сторінки тихо додають посилання або цілі приховані розділи про казино, позики, аптеки. Ви цього не бачите — а пошуковик бачить.
• Трафік. Ваших відвідувачів починають переспрямовувати на чужі сторінки, але не всіх: часто лише мобільних, лише тих, хто прийшов із пошуку, і лише раз на добу на людину. Саме тому ви можете місяцями заходити на власний сайт зі свого комп'ютера й нічого не помічати.
• Ресурси сервера. Ваш хостинг перетворюється на вузол для розсилання спаму, майнінгу чи атак на інші сайти.
• Дані. База із заявками, телефонами, адресами та поштою — це готовий товар. Навіть якщо у вас «просто форма зворотного зв'язку».
• Вимагання. Файли шифрують або видаляють, а вам пропонують заплатити за повернення.

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

Що зазвичай помічають першим

Симптоми зламу приходять радше ззовні, ніж від вас. Хостинг надсилає лист про підозрілу активність. Google Search Console показує попередження. Клієнт телефонує й каже, що браузер лається на сайт. Пошта компанії раптом починає потрапляти в спам геть у всіх. Трафік із пошуку падає без видимої причини. Якщо щось із цього сталося — вважайте, що ви дізналися пізно, але не безнадійно пізно.

Як сайти ламають насправді

Забудьте кіно. У реальності майже всі зломи малого бізнесу вкладаються в короткий і напрочуд нудний перелік причин. Ми розбирали десятки заражених сайтів, і точка входу майже завжди була однією з цих.

Застаріла CMS і передусім плагіни

Це чемпіон із величезним відривом. WordPress, Joomla, OpenCart, будь-яка популярна система — самі собою не діряві. Проблема в екосистемі: плагін для галереї, який не оновлювався з 2021 року, тема, куплена колись на маркетплейсі та покинута автором, модуль форми, який поставив підрядник і забув.

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

Слабкі й, що гірше, повторювані паролі

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

Викрадені дані з комп'ютера працівника

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

Незахищені форми та відкриті точки входу

Будь-яке місце, де сайт приймає дані ззовні — форма заявки, пошук, завантаження файлу, API-ендпоінт, — це двері. Якщо дані приймаються без перевірки типу, розміру та вмісту, двері працюють в обидва боки. Особливо небезпечним є завантаження файлів: можливість покласти на сервер щось, що сервер потім виконає, — це, по суті, передання ключів.

Зайві файли в корені сайту

Тихий убивця, якого ми знаходимо постійно. У кореневій теці живуть: backup.zip від попереднього підрядника, dump.sql із повною базою, тека .git з усією історією проєкту та паролями у старих комітах, файли test.php, info.php, копія конфігу з назвою config.php.bak. Усе це доступне за прямим посиланням кожному, хто його вгадає. А боти не вгадують — вони мають списки типових назв і перевіряють їх за секунди.

Окремо про .bak та .old: сервер не виконує такі файли як код, а віддає їх текстом. Тобто віддає вміст конфігу з паролем до бази даних просто в браузер.

Забуті та покинуті проєкти

Старий лендинг акції на піддомені. Тестова копія сайту, яку зробили два роки тому й не видалили. Форум, яким ніхто не користується. Їх не оновлюють, бо про них не пам'ятають. При цьому вони часто лежать на тому самому акаунті хостингу — і злам покинутого лендингу дає доступ до файлів основного сайту. Ми завжди починаємо аудит із питання «а що ще висить на цьому акаунті?», і відповідь регулярно дивує самого власника.

HTTPS і SSL сертифікат: це вже не обговорюється

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

Що робить SSL сертифікат простими словами

Без HTTPS дані між браузером відвідувача та вашим сервером ідуть відкритим текстом. Їх бачить і може змінити будь-хто, хто перебуває на шляху: власник Wi-Fi у кав'ярні, провайдер, обладнання в проміжній мережі. Бачить — отже, читає паролі та вміст форм. Може змінити — отже, здатен підмінити вміст вашої сторінки або вставити в неї чужу рекламу, і відвідувач буде впевнений, що це ви.

SSL сертифікат розв'язує два завдання водночас. Він шифрує канал і підтверджує, що домен належить тому, хто його обслуговує. Друге не менш важливе за перше: без підтвердження справжності шифрування марне, бо ви можете шифрувати канал із шахраєм.

Речі, які важливіші за сам сертифікат

Сертифікат сьогодні отримати безкоштовно й автоматично — Let's Encrypt закрив це питання для всіх. Тому помилки давно не в площині «є чи немає», а в деталях налаштування:

• Перенаправлення. Усі запити через HTTP мають постійним редиректом іти на HTTPS. Інакше стара версія просто працює паралельно.
• Змішаний вміст. Сторінка вантажиться через HTTPS, але підтягує зображення, шрифт чи скрипт через HTTP. Браузер лається, а замок в адресному рядку зникає. Найчастіше винні старі скрипти аналітики та віджети.
• Автопродовження. Сертифікат живе недовго й продовжується роботом. Якщо робот зламався, ви дізнаєтеся про це від клієнтів у найгірший день. Моніторинг терміну — обов'язковий.
• Канонічні адреси. Після переходу на HTTPS простежте, щоб одна сторінка була доступна за однією адресою, а не за чотирма варіантами з www і без.

Чого HTTPS не робить

Тут живе небезпечна омана. Замочок у браузері не означає, що сайт безпечний. Він означає рівно одне: канал до сервера зашифровано. Зламаний сайт із вірусом у коді чудово працює через HTTPS, і замочок на місці. Шахрайський фішинговий сайт теж має сертифікат — їх видають безкоштовно й автоматично всім. HTTPS — це фундамент, а не дах.

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

Заголовки безпеки: тихий захист, який майже ніхто не вмикає

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

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

Content-Security-Policy (CSP)

Найпотужніший і найвередливіший. Це білий список: звідки сторінці дозволено вантажити скрипти, стилі, зображення та шрифти. Якщо зловмисник зумів вставити у вашу сторінку чужий скрипт, браузер просто відмовиться його виконувати, бо джерела немає в переліку. По суті, CSP перетворює успішний злам на невдалий.

Чесне попередження: похапцем увімкнений CSP легко зламає сайт. Правильний шлях — спершу режим лише звітів, збирання порушень, потім посилення. На сайті з десятком сторонніх віджетів це робота на кілька днів, а не на десять хвилин.

Strict-Transport-Security (HSTS)

Каже браузеру: «цей домен завжди лише через HTTPS, запам'ятай на рік уперед». Закриває шпарину між моментом, коли людина набрала адресу без префікса, і моментом спрацювання редиректу. Саме в цій шпарині й відбувається перехоплення. Вмикати варто лише тоді, коли ви впевнені, що HTTPS працює всюди й назавжди, — швидко відкотити рішення не вийде.

X-Frame-Options

Забороняє вбудовувати ваш сайт у рамку на чужій сторінці. Захищає від простого й підлого прийому: поверх вашої справжньої кнопки кладуть невидимий шар, і клік користувача йде не туди, куди він думає. Для сайту з особистим кабінетом або оплатою це обов'язковий заголовок.

X-Content-Type-Options

Один рядок, жодних налаштувань. Забороняє браузеру «здогадуватися» про тип файлу всупереч тому, що сказав сервер. Без нього завантажене зображення за певних умов може бути витлумачене браузером як скрипт і виконане.

Referrer-Policy

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

Permissions-Policy

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

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

Оновлення та чужий код: дисципліна замість героїзму

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

Чому оновлення відкладають

Не через лінощі. Через страх. Одного разу оновлення зламало верстку або відвалився кошик — і відтоді кнопку «оновити» обходять десятою дорогою. Страх обґрунтований: оновлення справді може щось зламати, надто якщо сайт зібрано з плагінів, які правили напилком просто в коді.

Але арифметика невблаганна. Ризик зламати верстку — це година роботи. Ризик зламу — це відновлення з бекапу, чистка, пояснення з клієнтами та місяці повернення позицій у пошуку. Другий ризик дорожчий за перший на порядок.

Як оновлюватися без паніки

1. Зробіть бекап до, а не після. Повний: файли й база. Без цього кроку далі не йдемо ніколи.
2. Заведіть тестову копію. Окремий майданчик, закритий від індексації та від сторонніх, де оновлення перевіряють до бою. Для серйозного проєкту це обов'язковий елемент.
3. Розділіть критичне й рутинне. Оновлення безпеки ставлять одразу, мінорні — за розкладом, великі версії — як окремий проєкт із планом.
4. Перевірте головне після. Надсилання форми, оплата, вхід у кабінет, вигляд на телефоні. Три хвилини ручної перевірки заощаджують тижні.

Ревізія чужого коду

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

Друге питання: чи живий автор? Якщо останнє оновлення було три роки тому, а в описі написано «сумісний із версією, яка давно застаріла», — це покинутий код. Він не стане безпечнішим сам собою. Шукайте заміну заздалегідь, спокійно, а не в ніч після зламу.

І головне правило, яке варто повісити в рамці: що менше стороннього коду на сайті, то менша поверхня атаки. Кожен плагін — це чужий розробник, якому ви мовчки видали доступ до свого сервера.

Доступи й хостинг: гігієна, яка важить більше за код

Найчастіша реальна причина зламу — не хитра вразливість, а розкидані доступи. Тут лад наводиться швидко й майже без грошей.

Принцип найменших привілеїв

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

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

Окремі акаунти для окремих людей

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

Двофакторна автентифікація

Якщо впроваджувати лише один пункт із усієї статті — впроваджуйте цей. 2FA знецінює вкрадений пароль. Усі атаки добору й усі витоки чужих баз перестають працювати проти вас, бо пароля недостатньо. Увімкніть її всюди, де вона є: панель хостингу, реєстратор домену, адмінка сайту, пошта, Cloudflare, GitHub.

Окремо про реєстратора домену. Це найбільш недооцінена точка. Втрата контролю над доменом гірша за втрату сайту: сайт відновлюється з бекапу за годину, а домен повертається місяцями через листування з підтримкою, якщо повертається взагалі.

SSH-ключі замість паролів і жодного FTP

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

І окремо: відмовтеся від звичайного FTP. Він передає логін і пароль відкритим текстом, як у дев'яностих. Лише SFTP або SSH. Якщо хостинг пропонує вам FTP як основний спосіб — це сигнал про якість хостингу.

Менеджер паролів замість пам'яті

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

Форми, спам і обмеження частоти запитів

Форма зворотного зв'язку — найдоступніше місце вашого сайту. Вона відкрита всім, працює без авторизації та чекає на дані. Логічно, що саме її навантажують найчастіше.

Чому CAPTCHA — не повне розв'язання

Капча ловить примітивні скрипти й дратує живих людей. Сучасний спам-трафік обходить її або технічно, або через сервіси розпізнавання, де живі люди розв'язують капчі за копійки. При цьому капча помітно знижує конверсію: частина реальних клієнтів просто йде, не розібравши спотворених літер.

Робочий підхід — багатошаровий і невидимий для відвідувача:

• Honeypot. Приховане поле, якого людина не бачить і не заповнює, а бот заповнює автоматично. Заповнено — відкидаємо. Просто, безкоштовно, ефективно проти маси.
• Перевірка часу. Форма, надіслана через півсекунди після завантаження сторінки, заповнена не людиною.
• Обмеження частоти (rate limiting). З однієї адреси — не більше кількох надсилань за проміжок часу. Це ключовий механізм, і він же захищає сторінку входу від добору паролів.
• Невидимі перевірки. Сучасні системи оцінюють поведінку й показують завдання лише підозрілим запитам. Живий клієнт не бачить нічого.

Валідація на сервері не обговорюється

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

Завантаження файлів — окрема історія

Якщо відвідувач може завантажити файл, дійте так, ніби він завантажує щось небезпечне. Перевіряйте справжній тип вмісту, а не розширення в назві. Перейменовуйте файл самі. Обмежуйте розмір. І найголовніше — зберігайте завантажене там, де сервер фізично не виконує код, в ідеалі взагалі в окремому сховищі.

Rate limiting ширший за форми

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

Бекапи: єдина страховка, яка працює завжди

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

Правило 3-2-1

Класика, придумана задовго до нас і досі непобита:

• 3 копії даних: бойова та дві резервні.
• 2 різні носії або платформи — не все в одному місці.
• 1 копія поза основним майданчиком, фізично й адміністративно окремо від сервера.

Останній пункт — саме той, на якому руйнується більшість схем. Бекап, що лежить на тому самому сервері або в тому самому акаунті хостингу, — це не бекап. Зловмисник, який отримав доступ, видалить його першим ділом, бо це стандартний крок. Шифрувальник зашифрує його разом з усім іншим. Хостинг помре разом із ним.

Бекап, який не перевіряли, — це не бекап

Тут починається найнеприємніше. Ми регулярно бачимо ту саму сцену: бекапи справно робилися два роки, а в годину «ікс» з'ясовується, що архіви побиті. Або в них лише файли без бази даних. Або база є, але копіювання ламало кодування, і замість українського тексту в архіві знаки питання. Або архів важить 40 кілобайтів, бо скрипт падав на першій же теці, а повідомлення про помилку йшло на пошту, яку ніхто не читає.

Висновок: відновлення треба репетирувати. Раз на квартал розгорніть копію на тестовому майданчику й подивіться: сайт відкривається, база на місці, зображення є, замовлення відображаються. Це єдиний спосіб дізнатися правду про свої бекапи заздалегідь, а не в момент катастрофи.

Глибина зберігання важливіша за частоту

Щоденний бекап зі зберіганням трьох днів марний проти тихого зараження. Шкідливий код часто сидить місяцями й не проявляє себе. Коли ви його виявите, усі три копії будуть уже заражені. Тримайте глибину: щоденні за два тижні, щотижневі за пару місяців, щомісячні за рік. Місце на диску коштує незрівнянно дешевше, ніж сайт, який немає з чого відновити.

Що саме бекапити

Файли й база — це очевидно. Забувають зазвичай про решту: конфігурацію сервера, правила вебсервера, завдання планувальника, налаштування DNS, листи. Добрий орієнтир — питання «якщо завтра хостинг зникне цілком, скільки часу забере повне піднімання з нуля на новому місці?». Якщо відповіді немає, отже, бекап неповний.

Моніторинг і логи: побачити проблему раніше за клієнта

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

Мінімальний набір

• Моніторинг доступності. Перевірка щохвилини зі сповіщенням. Базові сервіси безкоштовні, ставляться за десять хвилин.
• Контроль цілісності файлів. Система запам'ятовує стан файлів і повідомляє, коли щось змінилося. Ніхто не правив код, а два файли змінилися вночі — це вже розмова.
• Термін дії SSL і домену. Сповіщення заздалегідь, а не постфактум. Забуте продовження домену б'є болючіше за будь-який злам.
• Google Search Console. Безкоштовно й обов'язково. Пошуковик часто дізнається про зараження раніше за власника й чесно пише про це в розділі безпеки.
• Зовнішня перевірка на шкідливий код. Регулярне сканування ззовні ловить те, що видно лише відвідувачу: редиректи, чужі скрипти, підмінений вміст.

Логи: нудно, але саме там правда

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

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

На що дивитися в логах

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

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

WAF і CDN: що Cloudflare робить, а чого не робить

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

Що це таке

CDN ставить між відвідувачем і вашим сервером мережу вузлів по всьому світу. Статику віддають із найближчого вузла — сайт швидший, сервер розвантажений. WAF (фаєрвол рівня застосунку) — фільтр, який дивиться на вхідні запити й відкидає схожі на атаку до того, як вони дійдуть до вашого коду.

Реальна користь

• Поглинання DDoS. Сміттєвий трафік розбивається об мережу провайдера, а не об ваш сервер. Самотужки малий бізнес такої атаки не переживе.
• Приховування справжньої IP-адреси сервера. Атакувати напряму стає складніше, бо ціль не видно.
• Фільтрація ботів. Значна частина сканувального сміття відсіюється автоматично, і логи одразу стають читабельними.
• Віртуальне латання. Правило WAF може закрити свіжу вразливість на час, поки ви готуєте нормальне оновлення. Це виграш часу, а не розв'язання.
• Швидкість. Приємний побічний ефект, помітний і відвідувачам, і пошуковику.

Чого він не зробить

А тепер незручна частина. WAF не врятує, якщо:

• У вас украли пароль. Вхід із правильним логіном і паролем — легальний запит. Фільтр пропустить його й матиме рацію.
• Ваша справжня IP-адреса вже відома й сервер приймає з'єднання напряму, оминаючи фільтр. Це дуже часта помилка налаштування: сервер зобов'язаний приймати трафік лише від мережі провайдера.
• Вразливість у вашій власній бізнес-логіці. Якщо ваш код дозволяє одному користувачеві запросити чуже замовлення за номером, для WAF це звичайний коректний запит.
• Шкідливий код уже всередині. Фільтр дивиться на вхід, а не на те, що відбувається на сервері.
• Налаштовано «гнучкий» режим шифрування. Тоді ділянка від Cloudflare до вашого сервера йде відкритим текстом, а відвідувач бачить замочок і впевнений, що все гаразд. Це небезпечна імітація безпеки — використовуйте суворий режим із перевіркою сертифіката.

Підсумок: WAF і CDN — це чудовий зовнішній паркан. Паркан марний, якщо ключ від дверей лежить під килимком, а на першому поверсі відчинене вікно. Він доповнює гігієну, а не замінює її.

Що робити, якщо сайт уже зламали

Спокійно. Паніка тут коштує дорожче за злам: у паніці видаляють те, що знадобиться для розслідування. Порядок дій відпрацьований, дотримуйтеся його.

1. Ізолювати

Закрийте сайт заглушкою з кодом 503. Це захищає відвідувачів від зараження й каже пошуковику, що роботи тимчасові, а не що сайт помер. Не видаляйте поки нічого.

2. Зберегти докази

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

3. Змінити всі доступи

Усі, без винятків і без «цей точно не міг витекти». Хостинг, SSH, база даних, усі користувачі адмінки, FTP, реєстратор домену, пошта, під'єднані сервіси. Водночас увімкніть 2FA скрізь, де її не було. Важливо: робіть це з чистого комп'ютера — якщо заражений ноутбук, нові паролі витечуть так само, як старі.

4. Знайти точку входу

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

5. Відновитися

Найкращий шлях — чиста переустановка: свіжа CMS, свіжі плагіни з офіційних джерел, а з бекапу беруть лише вміст і базу, яку треба попередньо перевірити (у базу теж вставляють код, зазвичай у шаблони й налаштування). Ручна чистка заражених файлів — це лотерея: пропустили один-єдиний файл, і все повертається.

6. Закрити дірку й повернути репутацію

Усуньте знайдену причину — інакше ви просто перезапустили таймер. Далі: запросіть перегляд у Google Search Console, перевірте поштові записи домену (зламаний сайт часто розсилав спам, і домен уже міг потрапити до чорних списків), переконайтеся, що в базі немає чужих адміністраторів.

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

Практичний чек-лист безпеки

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

Сьогодні, за один вечір

1. Увімкнути 2FA на хостингу, у реєстратора домену, в пошті та в адмінці сайту.
2. Перевірити, що HTTPS працює всюди й весь HTTP іде редиректом.
3. Відкрити список користувачів адмінки й видалити всіх зайвих: колишніх працівників, старих підрядників, незрозумілі акаунти.
4. Перевірити корінь сайту на зайві файли: архіви, дампи бази, теку .git, копії конфігів, тестові скрипти.
5. Переконатися, що бекапи існують і лежать не на тому самому сервері.
6. Під'єднати сайт до Google Search Console й переглянути розділ безпеки.

Цього тижня

1. Завести менеджер паролів і змінити всі повторювані паролі на унікальні.
2. Оновити CMS і всі плагіни, попередньо зробивши повний бекап.
3. Видалити невикористовувані плагіни й теми — саме видалити, а не вимкнути.
4. Налаштувати заголовки безпеки: почніть з X-Content-Type-Options, X-Frame-Options і Referrer-Policy, вони безпечні й вмикаються одразу.
5. Вимкнути FTP, перейти на SSH-ключі.
6. Поставити моніторинг доступності та сповіщення про завершення терміну SSL і домену.
7. Обмежити частоту спроб входу в адмінку.

Цього місяця

1. Перевірити відновлення з бекапу на тестовому майданчику — реально розгорнути й подивитися.
2. Під'єднати CDN і WAF, обов'язково закривши прямий доступ до сервера в обхід фільтра.
3. Впровадити CSP, починаючи з режиму звітів.
4. Провести ревізію всього, що висить на акаунті: піддомени, тестові копії, забуті лендинги. Зайве — видалити.
5. Налаштувати контроль цілісності файлів.
6. Перевірити права доступу до тек і файлів, прибрати можливість запису там, де вона не потрібна.

Регулярно, щоб не повертатися до цієї статті

• Раз на тиждень: оновлення безпеки, погляд на журнал входів.
• Раз на місяць: перевірка бекапів, ревізія користувачів, побіжний погляд на логи.
• Раз на квартал: тестове відновлення, ревізія плагінів, зміна ключових паролів.
• Раз на рік: повний аудит, перегляд того, кому й навіщо видано доступи.

Остання думка, яку варто забрати із собою. Безпека — це не стан «зробили й забули», а звичка, як замок на дверях офісу. Ніхто не гарантує абсолютного захисту, і будь-хто, хто його обіцяє, вводить вас в оману. Але різниця між сайтом, де цей список виконано, і сайтом, де не виконано нічого, — це різниця між «нас намагалися зламати, і нічого не вийшло» та «ми третій тиждень відновлюємо дані».

Часті запитання