🔐 Захист сайту від DDoS атак ( ͡° ͜ʖ ͡°)

Мета DDoS-атаки – вдарити по найслабшому місцю вашої системи, щоб усе впало.

Кроки захисту від DDoS

Увімкніть DDoS-захист від хостера або сервісу 😁

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

Але, якщо воно безкоштовне, то чом би й ні. Мене повністю влаштовує така система у хостингу Ukraine.

Cloudflare – ваш найкращий друг.

Реєстрація домену та підключення до Cloudflare – це перше, що потрібно зробити.

Важливо: Якщо домен раніше не був підключений до Cloudflare, ваш IP вже відомий конкурентам. І навіть при підключенні Cloudflare, старий IP можна знайти через історію DNS (є сервіси для цього).

Рішення:

Поміняйте IP у хостера/сервера.
Видаліть записи, що розкривають IP, наприклад, MX.

📜 Більш докладно про це у кінці допису.

Використовуйте nginx. Тільки nginx – ніяких apache2, особливо під високі навантаження.
Відмова від бази даних і движків. Приберіть бази даних – вони перші падають під навантаженням. PHP вам теж не потрібен, використовуйте тільки голий nginx.
Налаштування NGINX Content Caching (це якщо не відмовилися від баз і движка).
Жорсткий кеш:
- Налаштуйте кешування контенту зі спливом через пару тисяч років.
- При зміні посилань просто очистіть кеш, щоб він зібрався заново.
Завантаження сайту і генерація статичного HTML. Завантажте сайт цілком або використовуйте плагін, щоб перетворити його на статичні HTML-файли локально.

Як швидко замінити посилання в сотнях файлів:

На сервері через SSH виконайте:

find /шлях/до/ваших/html-файлів -type f -name «*.html» -exec sed -i ‘s/старий_сайт/новий_сайт/g’ {} +

Не копіюйте не зрозумілі вам команди в консоль вивчіть, або довірте сис.адміну

Offline-режим у Cloudflare.

Активуйте режим, за якого сторінки показуються навіть у разі вимкнення сервера.

Як увімкнути:

Зайдіть у налаштування Cloudflare.
У розділі Caching увімкніть Always Online.
Переконайтеся, що сторінки вашого сайту додані в кеш.

Обмежуємо доступ тільки для IP Cloudflare.

Щоб ніхто не міг звернутися до вашого сервера безпосередньо, крім Cloudflare, потрібно налаштувати доступ за IP-адресами їхньої мережі.

Кроки:

Переконайтеся, що ваш сайт уже під’єднаний до Cloudflare. Якщо ваш сайт не через Cloudflare, цей захист не спрацює.
Налаштування на рівні сервера

Для NGINX додайте в конфігурацію сервера:

# Дозволяємо доступ тільки IP Cloudflare
allow 173.245.48.0/20;
allow 103.21.244.0/22;

і т.д….

# Решті доступ заборонено
deny all;

Після цього перезапустіть NGINX:
sudo systemctl reload nginx

IP-адреси Cloudflare можуть оновлюватися, тому регулярно перевіряйте актуальний список: https://www.cloudflare.com/ips/

Ці поради допоможуть тільки від легких DDoS-атак, але навіть при старті атаки дадуть запас часу перед тим, як проєкт ляже.

Крім того, ці заходи дадуть змогу анти-DDoS сервісам ефективніше захищати ваші проєкти, знижуючи навантаження та мінімізуючи ризики.

Приховуємо свої сітки сайтів від пошуковиків і конкурентів

Почнемо з базових і простих речей 👇

Не май один IP для всіх сайтів. Зазвичай всі сайти зберігають на одному сервері або навіть на одному хостингу. Просте рішення – йдемо в Cloudflare і створюємо окремий кабінет для кожного сайту. Чому? Тому що…
Не використовуй однакові NS для всієї сітки сайтів у Cloudflare. Після створення першого домену в Cloudflare вам автоматично призначаються 2-4 NS, які будуть використовуватися на всіх сайтах у цьому акаунті. Якщо всі сайти мають однакові NS, це легко помітити і зв’язати їх між собою. Щоб цього уникнути – створюйте різні кабінети з різними NS для кожного сайту.
Створюй різні акаунти вебмайстра для кожного сайту. Йдеться про вебмайстер акаунти Бінга, Google або інших пошукових систем. Багато хто вважає це параноєю, але краще перестрахуватися. Так, це ускладнює процес, особливо через вимоги номера телефону для реєстрації.
Слідкуйте за DNS записами. Багато хто паляться через MX-записи для поштовиків, на яких висить справжній IP сервера. Якщо пошта не потрібна, видаляйте зайві DNS-записи, щоб не розкривати інформацію про сервер, а ще це захистить від прямої DDOS атаки.

І ось ми зробили те, що залежало від нас. Тепер йдемо далі – до серверних налаштувань Nginx.

Налаштування Nginx, в топку ваш apache2

Приховуємо версію Nginx

Додаємо в секцію http {} рядок:

server_tokens off;

Ця команда приховує саме версію Nginx, але не сам факт, що сервер працює на Nginx. Можна також використовувати модуль more_clear_headers для підміни відповіді, але не будемо ускладнювати.

Видаляємо заголовок X-Powered-By (версію php)
Якщо у нас використовується fastcgi_pass, додаємо:

# Видаляємо заголовок X-Powered-By, який передає PHP
fastcgi_hide_header X-Powered-By;

Якщо використовується proxy_pass:

# Прибираємо X-Powered-By, що приходить від бекенда
proxy_hide_header X-Powered-By;

Додаємо кастомний заголовок

Для маскування можна додати кастомний заголовок:

add_header X-Powered-By «PHP/5.3.10»;

Приклади версій для підміни:

🟢 PHP 8.x
– PHP/8.0.0 – PHP/8.0.30 (останній реліз 8.0)
– PHP/8.1.0 – PHP/8.1.x (актуальна гілка з підтримкою)
– PHP/8.2.0 – PHP/8.2.x (актуальна гілка з підтримкою)
– PHP/8.3.0 – PHP/8.3.x (новітня гілка)
– PHP/8.3.10 (приклад майбутніх версій)

🟢 PHP 7.x
– PHP/7.1.0 – PHP/7.1.33
– PHP/7.2.0 – PHP/7.2.34
– PHP/7.3.0 – PHP/7.3.33
– PHP/7.4.0 – PHP/7.4.33 (останній реліз 7.x)

🟢 PHP 5.x
– PHP/5.2.0 – PHP/5.2.17
– PHP/5.3.0 – PHP/5.3.29
– PHP/5.4.0 – PHP/5.4.45
– PHP/5.5.0 – PHP/5.5.38
– PHP/5.6.0 – PHP/5.6.40 (останній реліз 5.x)

Додаткові заголовки від CMS. Кожна CMS може додавати свої заголовки, які можна легко засікти. Для перевірки використовуємо сервіс https://securityheaders.com/ і дивимося, які заголовки відсилає ваш сайт.

Після аналізу можна приховати їх через fastcgi_hide_header або proxy_hide_header:

fastcgi_hide_header Custom-Header;
proxy_hide_header Custom-Header;

Коди аналітик і різних сервісів
А ще часто на всі сайти вставляють один і той самий код від сервісів, у яких генерується на акаунт.

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