Andrii Davinci

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

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

Ще одна поширена проблема — підбір паролів та доступ через бекапи. Хоча Brute Force на WordPress частково обмежений, XML-RPC все ще може бути використаний зловмисниками для різних типів атак. Особливо ризиковано, коли бекап лежить у відкритій папці й будь-хто може його завантажити. У дампі зазвичай містяться хешовані паролі, структура бази та логін адміністратора — і все це значно спрощує подальше проникнення.

Спікер окремо підкреслює, що шкідливі програми можуть ховатися не тільки у PHP-файлах. Деякі бекдори були знайдені всередині звичайного PNG чи JPEG, а окремий loader зчитував дані з зображення і запускав повноцінний шелл. Тому перевірка зараженого сайту — складний процес.

Андрій звертає увагу і на footprint — повторювані елементи, які видають сітку сайтів. Однакові шаблони, ідентична структура HTML або спільні медіафайли полегшують пошук PBN і можуть знизити траст доменів у пошукових системах.

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

Щоб уникнути інцидентів, Андрій рекомендує працювати з інфраструктурою системно. Сайти краще розміщувати на різних серверах або принаймні під різними користувачами всередині одного VPS. Плагіни й теми потрібно оновлювати регулярно — нові вразливості з’являються щодня. Паролі повинні бути довгими й надійними, а REST API та XML-RPC варто закривати, якщо вони не використовуються.

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

• застарілі плагіни або теми;
• нулені збірки з вшитими бекдорами;
• відкриті бекапи в кореневій директорії;
• XML-RPC і REST API, доступ до яких не обмежений належним чином;
• слабкі паролі або їх витік через заражений комп’ютер розробника.

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

Моніторинг теж грає велику роль. Найпростіший варіант — UptimeRobot, але ефективніше використовувати інструменти на кшталт Uptime.Click, які дають глибші сигнали про стан сайту та можуть повідомити про підозрілу активність. Firewаll-рішення, такі як Wordfence, Betawall або Cloudflare, значно підвищують стійкість до атак.

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

Під час блоку запитань Андрій зазначає, що HTML-сайт має менше точок проникнення, але WordPress при правильній конфігурації не є менш безпечним. Сканери весь час перевіряють сайти, тому навантаження нагадує постійний стрес-тест. Якщо сайт у висококонкурентній ніші, то варто бути готовим і до DDoS, і до фейкових абузів — близько 70–80% таких скарг він вважає штучно створеними конкурентами. Абузостійкі хостинги інколи необхідні, але кожен випадок має свої нюанси.