Как защитить сервер от DDoS-атак с помощью прокси: настройка за 15 минут

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

В этом руководстве разберём, как настроить прокси для защиты от DDoS, какие типы прокси использовать и как построить многоуровневую систему безопасности. Материал ориентирован на системных администраторов, владельцев веб-сервисов и DevOps-специалистов.

Как работают DDoS-атаки и почему прокси помогают

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

Основные типы DDoS-атак:

• Volumetric attacks (объёмные атаки) — заполняют канал связи огромным количеством трафика (DNS amplification, UDP flood)
• Protocol attacks (протокольные атаки) — эксплуатируют уязвимости в сетевых протоколах (SYN flood, Ping of Death)
• Application layer attacks (атаки на уровне приложений) — имитируют легитимные запросы к веб-приложению (HTTP flood, Slowloris)

Прокси-серверы помогают защититься от DDoS несколькими способами:

• Скрытие реального IP-адреса сервера — атакующие видят только IP прокси, а не вашего основного сервера
• Фильтрация вредоносного трафика — прокси анализирует запросы и блокирует подозрительные
• Распределение нагрузки — несколько прокси-серверов распределяют трафик между backend-серверами
• Rate limiting — ограничение количества запросов с одного IP-адреса
• Кэширование статического контента — снижает нагрузку на основной сервер

Важно понимать, что прокси — это не панацея от всех типов DDoS. Мощные volumetric атаки могут забить канал связи до прокси-сервера. Поэтому прокси эффективны в комбинации с другими методами защиты: CDN, облачными anti-DDoS сервисами (Cloudflare, AWS Shield), файрволами.

Типы прокси для защиты от DDoS: обратные vs прямые

Для защиты от DDoS используются два основных типа прокси-серверов:

Обратные прокси (Reverse Proxy)

Обратный прокси располагается перед вашим веб-сервером и принимает все входящие запросы от клиентов. Клиенты взаимодействуют только с прокси, не зная реального IP-адреса вашего сервера. Это основной инструмент для защиты от DDoS.

Популярные решения для обратных прокси:

• Nginx — быстрый и лёгкий веб-сервер с функциями обратного прокси
• HAProxy — специализированный load balancer с мощными возможностями фильтрации
• Apache mod_proxy — модуль для Apache, менее производительный чем Nginx
• Varnish — HTTP-акселератор с фокусом на кэширование

Прямые прокси (Forward Proxy)

Прямые прокси используются на стороне клиента для исходящих запросов. В контексте защиты от DDoS они применяются реже, но могут быть полезны для:

• Скрытия IP-адресов ваших серверов при обращении к внешним API
• Распределения исходящего трафика через множество IP-адресов
• Обхода блокировок при сборе информации о потенциальных атаках

Для этих задач подходят резидентные прокси — они имеют реальные IP-адреса домашних пользователей и выглядят как обычный трафик, что затрудняет их обнаружение и блокировку.

Настройка обратного прокси на Nginx для защиты сервера

Nginx — один из самых популярных инструментов для создания обратного прокси. Он быстро обрабатывает входящие запросы, поддерживает rate limiting и может фильтровать подозрительный трафик.

Базовая настройка обратного прокси

Установите Nginx на отдельный сервер, который будет принимать весь входящий трафик. Реальный веб-сервер должен быть скрыт за прокси и принимать запросы только от него.

# /etc/nginx/nginx.conf

http {
    # Ограничение количества соединений с одного IP
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
    limit_conn conn_limit 10;

    # Ограничение количества запросов (rate limiting)
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
    limit_req zone=req_limit burst=20 nodelay;

    # Таймауты для защиты от Slowloris
    client_body_timeout 10s;
    client_header_timeout 10s;
    keepalive_timeout 5s 5s;
    send_timeout 10s;

    upstream backend {
        # IP вашего реального веб-сервера
        server 192.168.1.100:80;
        # Можно добавить несколько серверов для балансировки
        # server 192.168.1.101:80;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            # Передача запросов на backend
            proxy_pass http://backend;
            
            # Передача оригинального IP клиента
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;
            
            # Таймауты для прокси
            proxy_connect_timeout 5s;
            proxy_send_timeout 10s;
            proxy_read_timeout 10s;
        }
    }
}

Блокировка подозрительных User-Agent

Многие DDoS-атаки используют ботов с характерными User-Agent. Добавьте правила для их блокировки:

# Блокировка известных ботов
map $http_user_agent $bad_bot {
    default 0;
    ~*bot 1;
    ~*crawler 1;
    ~*spider 1;
    ~*scraper 1;
    "" 1; # Пустой User-Agent
}

server {
    listen 80;
    server_name example.com;

    if ($bad_bot) {
        return 403;
    }

    location / {
        proxy_pass http://backend;
    }
}

Geo-блокировка нежелательных стран

Если ваш сервис работает только для определённых стран, можно заблокировать трафик из других регионов с помощью модуля GeoIP:

# Установка модуля GeoIP
# apt-get install nginx-module-geoip

load_module modules/ngx_http_geoip_module.so;

http {
    geoip_country /usr/share/GeoIP/GeoIP.dat;

    # Разрешаем только трафик из России и Украины
    map $geoip_country_code $allowed_country {
        default no;
        RU yes;
        UA yes;
    }

    server {
        listen 80;
        server_name example.com;

        if ($allowed_country = no) {
            return 403;
        }

        location / {
            proxy_pass http://backend;
        }
    }
}

HAProxy для распределения нагрузки и фильтрации трафика

HAProxy — это мощный load balancer с расширенными возможностями фильтрации трафика. Он поддерживает сложные ACL (Access Control Lists) для блокировки атак на уровне приложений.

Базовая конфигурация HAProxy

# /etc/haproxy/haproxy.cfg

global
    maxconn 50000
    # Логирование
    log /dev/log local0
    log /dev/log local1 notice

defaults
    mode http
    log global
    option httplog
    option dontlognull
    
    # Таймауты
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    
    # Ограничение размера запроса (защита от POST flood)
    maxconn 3000

frontend http_front
    bind *:80
    
    # Rate limiting: максимум 100 запросов за 10 секунд с одного IP
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src
    http-request deny if { sc_http_req_rate(0) gt 100 }
    
    # Блокировка запросов без Host header
    acl has_host hdr(host) -m found
    http-request deny if !has_host
    
    # Блокировка подозрительных User-Agent
    acl bad_bot hdr_sub(User-Agent) -i bot crawler spider scraper
    http-request deny if bad_bot
    
    # Передача на backend
    default_backend web_servers

backend web_servers
    balance roundrobin
    option httpchk GET /health
    
    # Список backend серверов
    server web1 192.168.1.100:80 check
    server web2 192.168.1.101:80 check
    server web3 192.168.1.102:80 check

Защита от HTTP Flood с помощью ACL

HTTP Flood — атака, при которой злоумышленник отправляет множество легитимных HTTP-запросов. HAProxy позволяет создать сложные правила для их обнаружения:

frontend http_front
    bind *:80
    
    # Трекинг количества запросов с одного IP
    stick-table type ip size 100k expire 30s store http_req_rate(10s),conn_cur
    http-request track-sc0 src
    
    # Блокировка при превышении лимитов
    acl too_many_requests sc_http_req_rate(0) gt 50
    acl too_many_connections sc_conn_cur(0) gt 10
    
    http-request deny deny_status 429 if too_many_requests
    http-request deny deny_status 429 if too_many_connections
    
    # Блокировка запросов к несуществующим путям (сканирование)
    acl valid_path path_beg /api /static /login /
    http-request deny if !valid_path
    
    default_backend web_servers

Whitelist доверенных IP-адресов

Создайте whitelist для доверенных IP (например, ваших офисных адресов или партнёров), которые не будут подвергаться rate limiting:

frontend http_front
    bind *:80
    
    # Whitelist доверенных IP
    acl whitelist src 203.0.113.0/24 198.51.100.50
    
    # Rate limiting только для не-whitelist IP
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src if !whitelist
    http-request deny if { sc_http_req_rate(0) gt 100 } !whitelist
    
    default_backend web_servers

Использование резидентных прокси для скрытия инфраструктуры

Помимо обратных прокси перед вашим сервером, можно использовать резидентные прокси для дополнительной защиты инфраструктуры. Это особенно актуально, если вам нужно:

• Скрыть IP-адреса ваших серверов мониторинга — если вы отслеживаете DDoS-атаки или собираете информацию об угрозах, резидентные прокси помогут скрыть ваши действия
• Обращаться к внешним API без раскрытия инфраструктуры — ваши серверы могут делать запросы через резидентные прокси, что затруднит их обнаружение
• Тестировать защиту от DDoS — имитировать атаки с разных IP-адресов для проверки эффективности ваших фильтров

Резидентные прокси имеют IP-адреса реальных домашних пользователей, что делает их неотличимыми от обычного трафика. Это затрудняет их блокировку и позволяет обходить geo-ограничения.

Пример: Мониторинг угроз через резидентные прокси

Предположим, вы хотите отслеживать активность ботнетов, которые могут атаковать ваш сервис. Используя резидентные прокси, вы можете собирать информацию, не раскрывая IP-адреса ваших серверов:

import requests

# Настройка резидентного прокси
proxies = {
    'http': 'http://username:password@residential-proxy.com:8080',
    'https': 'http://username:password@residential-proxy.com:8080'
}

# Сбор информации о потенциальных угрозах
threat_sources = [
    'http://suspicious-site1.com',
    'http://suspicious-site2.com'
]

for source in threat_sources:
    try:
        response = requests.get(source, proxies=proxies, timeout=5)
        # Анализ ответа для выявления паттернов атак
        print(f"Status: {response.status_code}, IP: {response.headers.get('X-Your-IP')}")
    except Exception as e:
        print(f"Error accessing {source}: {e}")

Правила фильтрации: как отличить атаку от легитимного трафика

Главная сложность защиты от DDoS на уровне приложений (L7) — отличить вредоносный трафик от легитимного. Современные атаки имитируют поведение реальных пользователей, что затрудняет их обнаружение.

Признаки DDoS-атаки

• Резкий рост количества запросов — в 2-10 раз больше обычного за короткий период
• Запросы с одинаковым User-Agent — боты часто используют один и тот же User-Agent
• Отсутствие Referer — прямые запросы без перехода с других страниц
• Однотипные запросы — обращения к одному и тому же URL с минимальными вариациями
• Отсутствие JavaScript — боты не выполняют JS-код на странице
• Низкое время на странице — боты сразу закрывают соединение после получения ответа
• Подозрительные IP-диапазоны — массовые запросы из одной подсети

Многоуровневая фильтрация

Эффективная защита использует несколько уровней фильтрации:

Пример: JavaScript Challenge в Nginx

Простой способ отфильтровать ботов — потребовать выполнения JavaScript для установки cookie:

server {
    listen 80;
    server_name example.com;

    # Проверка наличия cookie
    set $has_cookie 0;
    if ($http_cookie ~* "verified=true") {
        set $has_cookie 1;
    }

    # Если cookie нет, показываем JS challenge
    location / {
        if ($has_cookie = 0) {
            return 200 '
                <html>
                <head><title>Verification</title></head>
                <body>
                <script>
                    document.cookie = "verified=true; path=/";
                    window.location.reload();
                </script>
                <noscript>Please enable JavaScript</noscript>
                </body>
                </html>
            ';
        }

        proxy_pass http://backend;
    }
}

Мониторинг и реагирование на DDoS в реальном времени

Эффективная защита от DDoS требует постоянного мониторинга трафика и быстрого реагирования на аномалии. Настройте систему мониторинга, которая будет отслеживать ключевые метрики:

• Количество запросов в секунду — резкий рост может указывать на атаку
• Количество уникальных IP-адресов — DDoS часто приходит с множества IP
• Процент ошибок 4xx/5xx — рост ошибок может быть признаком перегрузки
• Время ответа сервера — увеличение latency указывает на проблемы
• Потребление ресурсов — CPU, память, сетевой трафик

Инструменты мониторинга

Настройка алертов в Prometheus

Создайте правила для автоматического оповещения при обнаружении аномалий:

# prometheus_alerts.yml

groups:
  - name: ddos_detection
    interval: 10s
    rules:
      # Алерт при резком росте запросов
      - alert: HighRequestRate
        expr: rate(nginx_http_requests_total[1m]) > 1000
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "High request rate detected"
          description: "Request rate is {{ $value }} req/s"

      # Алерт при росте ошибок 5xx
      - alert: HighErrorRate
        expr: rate(nginx_http_requests_total{status=~"5.."}[5m]) > 10
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "High 5xx error rate"
          description: "5xx errors: {{ $value }} req/s"

      # Алерт при высоком CPU
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High CPU usage"
          description: "CPU usage is {{ $value }}%"

Автоматическое реагирование с Fail2ban

Fail2ban анализирует логи и автоматически блокирует IP-адреса, которые превышают лимиты запросов:

# /etc/fail2ban/jail.local

[nginx-req-limit]
enabled = true
filter = nginx-req-limit
logpath = /var/log/nginx/access.log
maxretry = 100
findtime = 60
bantime = 3600
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]

# /etc/fail2ban/filter.d/nginx-req-limit.conf
[Definition]
failregex = ^<HOST> -.*"(GET|POST).*HTTP.*"
ignoreregex =

Многоуровневая защита: комбинирование прокси с другими методами

Прокси-серверы — важный элемент защиты от DDoS, но они наиболее эффективны в комбинации с другими методами. Рассмотрим архитектуру многоуровневой защиты:

Уровень 1: Сетевая защита (L3/L4)

• Облачные anti-DDoS сервисы — Cloudflare, AWS Shield, Google Cloud Armor фильтруют трафик до того, как он достигнет ваших серверов
• Аппаратные файрволы — специализированное оборудование для фильтрации сетевого трафика
• BGP blackholing — перенаправление вредоносного трафика в "чёрную дыру" на уровне провайдера

Уровень 2: CDN и кэширование

• CDN (Content Delivery Network) — распределяет статический контент по множеству серверов, снижая нагрузку на origin
• Кэширование на прокси — Varnish, Nginx кэшируют популярные страницы и отдают их без обращения к backend
• Оптимизация контента — минификация CSS/JS, сжатие изображений снижают объём трафика

Уровень 3: Прокси и балансировка (L7)

• Обратные прокси — Nginx, HAProxy фильтруют запросы на уровне приложений
• Load balancing — распределение нагрузки между несколькими backend-серверами
• Rate limiting — ограничение количества запросов с одного IP
• WAF (Web Application Firewall) — ModSecurity, AWS WAF блокируют атаки на веб-приложения

Уровень 4: Backend оптимизация

• Оптимизация базы данных — индексы, кэширование запросов, read replicas
• Асинхронная обработка — тяжёлые задачи выполняются в фоне через очереди (RabbitMQ, Redis)
• Горизонтальное масштабирование — добавление новых серверов при росте нагрузки

Пример архитектуры

Клиент
  ↓
Cloudflare (anti-DDoS L3/L4, CDN)
  ↓
Nginx обратный прокси (rate limiting, фильтрация)
  ↓
HAProxy (балансировка нагрузки)
  ↓
Backend серверы (веб-приложение)
  ↓
База данных (с репликацией)

Такая архитектура обеспечивает защиту на всех уровнях: сетевом, транспортном, прикладном. Даже если атака пройдёт один уровень, следующий её остановит.

Использование прокси дата-центров для дополнительного слоя

В некоторых случаях имеет смысл добавить прокси дата-центров как промежуточный слой между CDN и вашими серверами. Они обеспечивают высокую скорость обработки и могут выполнять дополнительную фильтрацию трафика. Прокси дата-центров дешевле резидентных и мобильных, что делает их экономически выгодным решением для обработки больших объёмов трафика.

Заключение

Защита от DDoS-атак с помощью прокси-серверов — это эффективный метод, который позволяет фильтровать вредоносный трафик, скрывать реальные IP-адреса серверов и распределять нагрузку. Обратные прокси на базе Nginx или HAProxy обеспечивают гибкую настройку правил фильтрации, rate limiting и блокировки подозрительных запросов.

Ключевые моменты, которые мы рассмотрели:

• Обратные прокси (Nginx, HAProxy) — основной инструмент защиты на уровне приложений (L7)
• Rate limiting и фильтрация по User-Agent, IP-репутации помогают отсеять большинство атак
• Резидентные прокси полезны для скрытия инфраструктуры мониторинга и сбора информации об угрозах
• Многоуровневая защита (CDN + прокси + WAF + оптимизация backend) обеспечивает максимальную устойчивость
• Мониторинг и автоматическое реагирование критически важны для быстрого обнаружения и блокировки атак

Помните, что DDoS-атаки постоянно эволюционируют, поэтому система защиты требует регулярного обновления и тестирования. Проводите нагрузочное тестирование, анализируйте логи, обновляйте правила фильтрации и следите за новыми методами атак.

Если вы планируете строить многоуровневую систему защиты с использованием прокси, рекомендуем рассмотреть резидентные прокси для скрытия критичной инфраструктуры и прокси дата-центров для высокоскоростной обработки больших объёмов трафика. Комбинация разных типов прокси обеспечивает оптимальный баланс между безопасностью, производительностью и стоимостью.