DDoS: как я защищаю свои проекты на Ubuntu + Nginx (и вам советую)

[CyberSec RuTOR]

Привет, коллеги. CyberSec RuTOR на связи.

5 лет назад я арендовал небольшой VPS для своего первого проекта. Всё работало, клиенты были довольны. А потом в один «прекрасный» день сайт просто лёг. Страницы грузились по минуте, а потом и вовсе перестали открываться. Я зашёл в терминал, набрал top и увидел, как мой маленький сервер задыхается. Тысячи одновременных соединений, процессор на 100%, память забита. Это была моя первая DDoS-атака.
Тогда я не знал, что делать. Сидел, смотрел на экран и понимал: клиенты уходят, деньги теряются, а я бессилен. Потом, конечно, я разобрался. Поменял провайдера на того, у кого была базовая защита, настроил Nginx, накрутил лимиты. Но осадок остался.


С тех пор DDoS-защита — это не «опция», а обязательная часть запуска любого проекта. В этой статье я расскажу, как защищаю свои серверы на Ubuntu с Nginx. Без воды, только практика, которую я проверял на себе.

1. Что такое DDoS и почему вам не плевать


DDoS (Distributed Denial of Service) — это когда другая сторона перегружает ваш сервер или канал связи огромным количеством ложных запросов, так что нормальные пользователи не могут пройти. Представьте, что в ваш магазин вваливается тысяча ботов, они ничего не покупают, просто стоят в дверях. Реальные клиенты не могут войти.

Количество DDoS-атак выросло настолько, что Cloudflare зафиксировал за первые месяцы года столько же атак, сколько за весь предыдущий год . Здравая конкуренция, а не «страшилки».
Если ваш проект зарабатывает деньги или хотя бы имеет репутацию — вы потенциальная цель. DDoS-атака может длиться от нескольких часов до суток . И каждый час простоя — это потерянные клиенты и деньги.

2. Виды атак: что нам угрожает

Прежде чем защищаться, надо понять, от чего. Я выделяю три основных типа, которые чаще всего встречаются на практике :
1. Объёмные атаки (L3/L4).
Атакуют канал связи. Пример — UDP-флуд, когда ботнет забивает ваш канал мусором. Канал переполняется, легитимный трафик не проходит. Это как если бы кто-то забетонировал дорогу к вашему дому.
2. Протокольные атаки (L4).
Атакуют на механизмы установки соединения. Самый известный пример — SYN-flood. Атакующий отправляет множество SYN-пакетов (запросов на соединение), но не отвечает на SYN-ACK (подтверждение). Сервер держит эти соединения открытыми, ждёт ответа, пока не исчерпает все ресурсы. И тогда он перестаёт отвечать даже на легитимные запросы .
3. Прикладные атаки (L7).
Это самые опасные атаки. Они маскируются под обычных пользователей. Шлёт тысячи запросов к тяжёлым страницам (поиск, каталог, оформление заказа). Сервер честно пытается их обработать, но ресурсов не хватает. Отличить такого «пользователя» от реального сложно, потому что запросы выглядят как обычные HTTP-запросы .

3. Слоёная защита: как я строю оборону

Главный принцип, который я усвоил: нельзя положиться на одно решение. Защита должна быть слоёной .
Схема моей обороны:

1. На уровне провайдера / сети — фильтрация крупного мусора.
2. На уровне сервера (Linux) — настройка ядра и базового файрвола.
3. На уровне веб-сервера (Nginx) — лимиты и ограничения для прикладных атак.
4. Мониторинг и автоматизация — чтобы я узнал об атаке до того, как сервер упадёт.

Расскажу о каждом слое подробно.


4. Слой 1: что делает провайдер и что делаю я сам

Идеальный вариант — если ваш хостинг-провайдер или VDS-хост имеет встроенную DDoS-защиту. Многие крупные игроки (например, Radware, Cloudflare) предлагают автоматическую фильтрацию трафика на своих мощностях .
Но если у вас простой VPS без защиты (или она платная и дорогая), вы можете настроить базовые вещи самостоятельно.


Настройка ядра Linux для защиты от SYN-flood

Это первое, что я делаю на новом сервере. Атаки SYN-flood — одни из самых частых .
Редактирую файл /etc/sysctl.conf и добавляю:

# Включаем SYN Cookies (защита от переполнения очереди полуоткрытых соединений)
net.ipv4.tcp_syncookies = 1
# Увеличиваем размер очереди полуоткрытых соединений
net.ipv4.tcp_max_syn_backlog = 524288
# Уменьшаем количество попыток повторной отправки SYN-ACK
net.ipv4.tcp_synack_retries = 2
# Уменьшаем таймауты для keepalive (быстрее освобождаем соединения)
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 5
net.ipv4.tcp_keepalive_probes = 6
# Включаем переиспользование TIME-WAIT соединений
net.ipv4.tcp_tw_reuse = 1

После этого применяю настройки:

sudo sysctl -p

Что это даёт: SYN Cookies — это механизм, при котором сервер не хранит информацию о полуоткрытом соединении, а «шифрует» её в ответном пакете. Если клиент настоящий, он вернёт эту информацию, и соединение установится. Если нет — сервер просто забудет о нём. Это сильно снижает нагрузку при SYN-flood .


Базовый файрвол (UFW или nftables)
Я использую ufw (Uncomplicated Firewall) на Ubuntu — он простой и понятный .

# Включаем ufw
sudo ufw enable
# Разрешаем только нужные порты
sudo ufw allow 22/tcp      # SSH (лучше сменить порт!)
sudo ufw allow 80/tcp      # HTTP
sudo ufw allow 443/tcp     # HTTPS

# Все остальные порты закрыты по умолчанию

Но ufw не умеет сам блокировать DDoS. Для продвинутых правил используют nftables (замена iptables). Например, ограничение количества новых соединений с одного IP:

# Разрешаем не более 10 новых соединений в минуту с одного IP на 80 порт
nft add rule ip filter input tcp dport 80 ct state new limit rate 10/minute accept
nft add rule ip filter input tcp dport 80 ct state new drop

Это отсекает самых наглых ботов .

5. Слой 2: настройка Nginx (самое важное)
Nginx стоит перед вашим приложением и принимает все запросы. Если он ляжет — бэкенд не получит ни одного запроса. Поэтому его настройка — ключевая .

5.1. Лимиты на количество соединений и запросов
Это моя основная защита от прикладных атак (L7). Я ограничиваю, сколько запросов может сделать один IP.

В файле /etc/nginx/nginx.conf (в блоке http { }) добавляю:

# Зона для ограничения запросов: 10 мегабайт памяти, 10 запросов в секунду с одного IP
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
# Зона для ограничения количества соединений с одного IP
limit_conn_zone $binary_remote_addr zone=addr:10m;

В конфигурации конкретного сайта (/etc/nginx/sites-available/ваш_сайт) применяю эти зоны:

server {
    listen 80;
    server_name example.com;
    # Ограничиваем количество одновременных соединений с одного IP до 10
    limit_conn addr 10;
    # Ограничиваем скорость запросов: 10 в секунду, при превышении — очередь до 20, остальные — 503
    location / {
        limit_req zone=one burst=20 nodelay;
        proxy_pass http://localhost:8080;
    }

    # Для тяжёлых страниц (например, поиск или каталог) — более жёсткие лимиты

    location /search {
        limit_req zone=one burst=5 nodelay;
        proxy_pass http://localhost:8080;
    }
}

Если IP превышает лимит, Nginx возвращает ошибку 503 Service Temporarily Unavailable. Легитимные пользователи могут ненадолго задержаться, но боты отсекаются .


5.2. Ограничение размера буфера и тела запроса

Это защита от атак, которые пытаются перегрузить сервер огромными запросами.

# Ограничиваем размер тела запроса (например, 1 МБ для обычных форм)
client_max_body_size 1M;
# Ограничиваем буферы
client_body_buffer_size 1M;
client_header_buffer_size 1k;
large_client_header_buffers 2 1k;

5.3. Таймауты — чтобы не держать соединения вечно

# Таймаут для чтения тела запроса
client_body_timeout 10s;
# Таймаут для чтения заголовка запроса
client_header_timeout 10s;
# Таймаут для отправки ответа
send_timeout 10s;
# Таймаут keepalive-соединения
keepalive_timeout 15s;

Короткие таймауты помогают быстрее освобождать ресурсы от «ленивых» или вредоносных клиентов.


6. Слой 3: fail2ban для автоматической блокировки


Nginx ограничивает запросы, но не банит IP. Этим занимается fail2ban. Он читает логи Nginx и при обнаружении подозрительной активности блокирует IP через файрвол.

Устанавливаю fail2ban:

sudo apt install fail2ban -y

Создаю фильтр для обнаружения превышения лимитов Nginx. Файл /etc/fail2ban/filter.d/nginx-req-limit.conf:

[Definition]
failregex = limiting requests, excess:.* zone.*client: <HOST>
ignoreregex =

Добавляю правило в /etc/fail2ban/jail.local:

[nginx-req-limit]
enabled = true
filter = nginx-req-limit
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]
logpath = /var/log/nginx/error.log
findtime = 600
bantime = 7200
maxretry = 10

• findtime = 600 — смотрю логи за последние 10 минут.
• maxretry = 10 — если 10 превышений лимита, то блокирую.
• bantime = 7200 — блокирую на 2 часа.

Перезапускаю fail2ban:

sudo systemctl restart fail2ban

Теперь если какой-то IP слишком активно долбится в сайт, он автоматически уходит в бан на 2 часа .
7. Слой 4: Cloudflare и аналоги — когда своих сил мало
Для крупных проектов я подключаю Cloudflare (бесплатный тариф уже даёт базовую защиту) или платные сервисы типа DDoS-Guard, Qrator, Radware.
Что даёт Cloudflare :

• Фильтрация трафика на своей сети (огромные мощности).
• Автоматическое включение защиты при атаке.
• Режим «I’m Under Attack» — включает капчу и JS-челленджи для всех посетителей.
• Правила rate limiting на грани.

Для российских проектов часто используют DDoS-Guard — он лучше «понимает» трафик из РФ и СНГ.
8. Мониторинг: как я узнаю об атаке до того, как сервер ляжет
Защита — это хорошо, но я должен знать, что происходит с сервером. Я настроил несколько простых инструментов :
1. Наблюдаю за логами Nginx в реальном времени:

sudo tail -f /var/log/nginx/access.log | cut -d' ' -f1 | sort | uniq -c | sort -nr

Эта команда показывает, какие IP чаще всего стучатся. Если вижу тысячи запросов с одного IP — что-то не так.
2. Использую netstat для контроля соединений:

sudo netstat -an | grep :80 | wc -l

Если количество соединений резко выросло и не падает — возможно, атака.
3. Установил простой скрипт для мониторинга: Он проверяет загрузку CPU, количество соединений и отправляет мне уведомление в Telegram, если что-то идёт не так .
4. Смотрю на графики трафика у провайдера. Если вижу резкий скачок входящего трафика — включаю «ручной режим» и усиливаю защиту.
9. Короткий чек-лист для быстрого старта
Если вы только начинаете и хотите защитить свой проект прямо сейчас, вот что я советую сделать:

1. Настройте ядро Linux (SYN Cookies, таймауты). Это 5 минут, но закрывает много дыр.
2. Настройте UFW или nftables — закройте всё, кроме 22, 80, 443.
3. В Nginx включите limit_req_zone и limit_conn_zone. Это ваша главная защита от прикладных атак.
4. Настройте fail2ban — пусть автоматически банит нарушителей.
5. Подключите Cloudflare (бесплатно) или DDoS-Guard, если проект публичный.
6. Смените SSH-порт с 22 на что-то другое и отключите вход по паролю, оставьте только ключи.
7. Сделайте бэкапы. Сервер может лечь полностью, и иногда проще поднять новый, чем отбиваться.

10. Что я понял за это время
DDoS — это не «страшилка для новичков». Это инструмент конкурентной борьбы, который используют регулярно. Если ваш проект начинает приносить деньги, вы становитесь мишенью.
Я перестал надеяться на «авось пронесёт». Теперь каждый новый сервер я настраиваю по этому чек-листу. Это занимает полчаса, но потом я сплю спокойно.
А вы сталкивались с DDoS-атаками? Как защищались? Есть свои лайфхаки? Делитесь в комментариях — я тоже учусь у вас.

CyberSec RuTOR

 

[Cyber Fantom]

Спасибо за интересную статью. Хотелось бы еще увидеть лайфхаки и фишки опытных сисадминов