Защита периметра у российского хостинга: что мы изменили после инцидента у клиента

В феврале 2026 у нашего клиента — частной медицинской клиники из ЮВАО Москвы — лёг сайт с системой записи пациентов. На пятницу, 13:40, в самый пиковый час — пациенты не могут записаться, операторы перезванивают вручную, директор клиники мне в WhatsApp пишет «Семён, у нас ад». Это была классическая атака на инфраструктуру: DDoS L7 на форму записи + одновременный SQL-fuzz на /api/. Через четыре часа мы вывели всё в работу, через две недели — полностью пересобрали защиту периметра. Этот материал — отчёт о том, что мы поменяли, какие выводы сделали о российских хостингах в 2026 и почему теперь рекомендуем нашим клиентам конкретный набор инструментов «без героики». Внутри — конкретные конфиги, ценники, фразы из переписки с хостерами.

Что произошло у клиента 13 февраля 2026

До того, как нас атаковали, инфраструктура клиники была, на мой взгляд, совершенно обычной: сайт работал на WordPress с плагином для записи на приём. Мы использовали VDS от Reg.Ru, который стоил 1 800 ₽ в месяц – это была машина на Ubuntu 22.04 с 4 vCPU и 8 GB RAM. База данных MySQL тоже крутилась на этом же сервере, а хостер делал бэкапы раз в сутки. Что касается защиты, то по умолчанию стоял fail2ban для SSH, базовый ModSecurity в Nginx с правилами CRS, и Cloudflare Free для базового CDN. Ничего особенного, как видите.

В 13:40 мы увидели, как загрузка CPU на виртуалке резко подскочила — с привычных 8% до всех 100%. nginx тут же начал выдавать ошибки 504. Когда я заглянул в логи, там творилось что-то невероятное: десятки тысяч POST-запросов в секунду на /api/booking/check-slot/, причём летели они со множества разных IP-адресов. Cloudflare Free, к сожалению, пропускал большую часть этого трафика. Атака была очень хитроумной: каждый IP делал всего 1-2 запроса за 30 секунд, и это не запускало наш rate-limit. В итоге, на пике сервер обрабатывал около 14 000 RPS, хотя обычно мы видим всего 40-60.

Одновременно с этим мы фиксировали попытки эксплуатации, которые маскировались под поиск врача: это были и SQL-инъекции, и запросы к пути /wp-json/wp/v2/users – классический способ собрать логины, и, конечно, brute-force атаки на /wp-admin. ModSecurity, если верить логам, заблокировал 47 000 таких запросов всего за 20 минут. Но, к сожалению, кое-что всё-таки пробилось.

Помимо всей этой технической суматохи, был и один довольно любопытный момент. Когда атака шла уже третий час, на почту директору клиники приземлилось письмо. В нём было написано: «Ваш сайт под нагрузкой, переведите 0,008 BTC на адрес ниже, мы остановим атаку. Иначе будем продолжать». Ну, вы поняли – типичная ransom-DDoS схема. Директор, ни слова не говоря, просто переслал нам это сообщение, приписав: «не плачу принципиально». Вот такой вот принципиальный человек.

Как мы выводили клинику из атаки за 4 часа

Шаг 1. Перевод трафика на Cloudflare с включённым «I am Under Attack»

Что мы сделали первым делом и, главное, максимально быстро? Перевели DNS A-запись сайта на Cloudflare и сразу же включили режим «Under Attack Mode». Объясню, что это за зверь: в этом режиме каждый, кто пытается зайти на сайт, сначала проходит такой специальный JavaScript-челлендж. Боты, по большей части, его одолеть не могут, а вот реальные пациенты справляются с ним за 5-7 секунд – просто видят страницу с надписью «Checking your browser».

На всю эту операцию у нас ушло 12 минут. А знаете, почему так долго? Потому что DNS у клиента изначально располагался на NS-серверах Reg.Ru, да ещё и с TTL 86400, то есть целые сутки! Пришлось не просто менять записи, но и ждать, пока у всех провайдеров обновится старый кэш. Я вот всегда думаю, как было бы здорово, если бы у каждого нашего клиента TTL по умолчанию был установлен на 300 секунд – это очень помогло бы в подобных экстренных случаях.

# Cloudflare API: включить Under Attack Mode
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/settings/security_level" \
     -H "Authorization: Bearer ${CF_API_TOKEN}" \
     -H "Content-Type: application/json" \
     --data '{"value":"under_attack"}'

# Дополнительно — включить Bot Fight Mode
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/bot_management" \
     -H "Authorization: Bearer ${CF_API_TOKEN}" \
     -H "Content-Type: application/json" \
     --data '{"fight_mode":true,"sbfm_likely_automated":"managed_challenge"}'

Шаг 2. Перенос nginx за тонкий слой защиты

Параллельно мы поменяли конфигурацию nginx: подняли rate-limit на критичный endpoint /api/booking/check-slot/ до 5 запросов в минуту с одного IP, на /wp-admin — 3 запроса в минуту, добавили блокировку по User-Agent для известных стрессеров (curl/wget/python-requests без явных кастомных заголовков).

# /etc/nginx/sites-enabled/clinic.conf — фрагмент
limit_req_zone $binary_remote_addr zone=booking:10m rate=5r/m;
limit_req_zone $binary_remote_addr zone=admin:10m rate=3r/m;
limit_req_zone $binary_remote_addr zone=api_strict:10m rate=10r/m;

# Блок известных стрессер-патернов
map $http_user_agent $bad_agent {
    default                          0;
    "~*python-requests"              1;
    "~*curl/[0-9]"                   1;
    "~*GoHttpClient"                 1;
    "~*okhttp/3"                     1;
    "~*Wget"                         1;
    ""                               1;
}

server {
    server_name clinic.ru;
    listen 443 ssl http2;

    if ($bad_agent) { return 403; }

    location /api/booking/check-slot/ {
        limit_req zone=booking burst=2 nodelay;
        limit_req_status 429;
        proxy_pass http://localhost:8080;
    }

    location /wp-admin/ {
        limit_req zone=admin burst=1 nodelay;
        allow 192.168.10.0/24;     # офис клиники
        allow 51.250.84.211;        # наш VPN-шлюз
        deny  all;
    }

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

Через 25 минут после переключения на Cloudflare и применения rate-limit нагрузка на сервере вернулась к 30%, отказы прекратились, форма записи заработала. Для пациентов это видно как «сайт сначала был медленный, потом нормальный». Для нас — четыре часа адреналина.

Шаг 3. Восстановление пропущенных запросов

Мы, конечно, сразу же проверили БД на предмет успешных SQL-инъекций. ModSecurity, надо отдать должное, заблокировал 99% всех попыток. Но вот на трёх запросах ошибка всё-таки проявилась, и мы увидели её только по логам. Мы успели оперативно почистить кеш wp-options и сменить ключи WP_AUTH в файле wp-config.php. А ещё, чтобы уж наверняка, принудительно сбросили все активные сессии администраторов, очистив поле wp_users.user_activation_key. Это, знаете ли, такая формальная, но очень важная гигиена после любого инцидента.

Что мы изменили в архитектуре после атаки

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

Перенос с Reg.Ru на Selectel + Cloudflare Pro

VDS от Reg.Ru за 1 800 ₽ в месяц, на мой взгляд, отлично подходит для какого-нибудь лендинга, но для клиники, да ещё и с EMR-системой, это, конечно, слишком «тонко». Поэтому мы перевезли всю инфраструктуру в Selectel: теперь у нас VDS «Стандарт» с 4 vCPU, 8 GB RAM и 120 GB SSD за 2 600 ₽ в месяц. Плюс к этому, сделали резервную копию в Я.Облаке (это Object Storage), что обходится примерно в 400 ₽ в месяц. И, конечно, мы обновили Cloudflare с Free до Pro, а это уже около 2 200 ₽ в месяц. Зато Pro даёт нам WAF с возможностью управлять правилами, image optimization и гораздо более глубокую аналитику.

Я, честно говоря, очень уважаю Reg.Ru как регистратора – домены и DNS клиники, кстати, так и остались там. Но вот как хостинг-провайдер для критически важных сервисов – мне там не очень-то нравится. Мой опыт показывает, что у Selectel и Я.Облака сетевая инфраструктура в Москве гораздо надёжнее, это прямо заметно. После того, как мы всё перевезли, uptime клиники, по данным нашего мониторинга UptimeRobot, составил 99,98% за два месяца. Это говорит само за себя.

WAF-правила Cloudflare под бизнес-логику

На Cloudflare Pro мы написали 14 кастомных WAF-правил, которые закрывают типичные сценарии для клиники:

# WAF Custom Rules (Cloudflare Expression Language)

# Правило 1: блок POST на форму записи без валидного X-Source-Token
(http.request.uri.path eq "/api/booking/check-slot/"
  and http.request.method eq "POST"
  and not http.request.headers["x-source-token"][0] in {
    "frontend-prod-2026-01" "ios-app-2025-12"
  })
=> Block

# Правило 2: rate-limit /wp-login.php — 5 попыток в час
(http.request.uri.path eq "/wp-login.php")
=> Managed Challenge (rate: 5r/h per IP)

# Правило 3: блокировка путей-разведчиков
(http.request.uri.path matches "(?i)(/\\.env|/\\.git|/wp-config|/phpmyadmin|/admin\\.php)")
=> Block

# Правило 4: блок known-bad SHODAN/Censys агентов
(http.user_agent contains "Censys" or http.user_agent contains "Shodan"
  or http.user_agent contains "MJ12bot" or http.user_agent contains "AhrefsBot")
=> Block

# Правило 5: только Россия и СНГ для админки
(http.request.uri.path matches "^/wp-admin"
  and not ip.geoip.country in {"RU" "BY" "KZ" "AM"})
=> Block

Бэкапы по схеме 3-2-1 без оптимизма

До атаки у клиента бэкап был один — снимок виртуалки на стороне хостера, делается раз в сутки, хранится 7 дней. Этого катастрофически мало. Я ввёл схему 3-2-1: три копии (продуктив + два бэкапа), на двух разных носителях, одна — оффсайт.

#!/bin/bash
# /usr/local/bin/clinic-backup.sh — запуск через cron каждый час для БД,
# раз в сутки для файлов

set -euo pipefail

BACKUP_DIR=/var/backups/clinic
S3_BUCKET=s3://clinic-backups-itfresh
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
RETENTION_DAYS=14
RETENTION_S3_DAYS=90

# 1. БД — каждый час
mysqldump --single-transaction --quick \
  --triggers --routines --events \
  -u backup -p"${MYSQL_BACKUP_PASS}" \
  clinic_main | gzip -9 > "${BACKUP_DIR}/db-${TIMESTAMP}.sql.gz"

# 2. Файлы и uploads — раз в сутки
if [ "$(date +%H)" = "03" ]; then
    tar czf "${BACKUP_DIR}/files-${TIMESTAMP}.tar.gz" \
        /var/www/clinic/wp-content/uploads \
        /var/www/clinic/wp-config.php \
        /etc/nginx /etc/letsencrypt
fi

# 3. Заливка в Я.Облако Object Storage (S3-совместимый)
aws s3 cp "${BACKUP_DIR}/db-${TIMESTAMP}.sql.gz" "${S3_BUCKET}/db/" \
  --endpoint-url=https://storage.yandexcloud.net \
  --storage-class=STANDARD_IA

# 4. Локальный rotation
find "${BACKUP_DIR}" -name "db-*.sql.gz" -mtime +${RETENTION_DAYS} -delete
find "${BACKUP_DIR}" -name "files-*.tar.gz" -mtime +${RETENTION_DAYS} -delete

# 5. Уведомление в Telegram о статусе
curl -s "https://api.telegram.org/bot${TG_BOT_TOKEN}/sendMessage" \
  -d "chat_id=${TG_CHAT_ID}" \
  -d "text=Backup OK at ${TIMESTAMP} — $(du -sh ${BACKUP_DIR} | cut -f1)"

Раз в две недели я сам тестирую restore из S3-бэкапа в изолированной среде — это единственный способ убедиться, что бэкапы рабочие. Не тестируешь — не имеешь.

Мониторинг 24/7 через Prometheus + Telegram

На отдельной виртуалке в Selectel я поднял целый комплекс: Prometheus, Alertmanager и Grafana. Ещё настроил blackbox-exporter, чтобы проверять доступность сайта сразу с трёх разных точек – из Москвы, Питера и Нидерландов, используя наш VPS. Теперь, если сайт простаивает больше 60 секунд, алерты тут же летят в дежурный Telegram-канал ITfresh. Мы всегда в курсе.

# prometheus.yml — фрагмент
scrape_configs:
  - job_name: 'blackbox-clinic'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
        - https://clinic.ru/
        - https://clinic.ru/api/booking/check-slot/
        - https://clinic.ru/wp-login.php
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: localhost:9115

# alertmanager rules
groups:
  - name: clinic_critical
    rules:
      - alert: ClinicDown
        expr: probe_success{job="blackbox-clinic"} == 0
        for: 60s
        labels:
          severity: critical
        annotations:
          summary: "Сайт клиники недоступен с {{ $labels.instance }}"

      - alert: ClinicSlowResponse
        expr: probe_duration_seconds{job="blackbox-clinic"} > 3
        for: 5m
        labels:
          severity: warning

Что мы поняли про российские хостинги в 2026

За 15 лет в IT-аутсорсе в Москве я видел эволюцию российского хостинга от «один поднял VDS на коленке» до серьёзных облачных провайдеров. К 2026 году расклад такой.

Топ для критичных сервисов

Yandex Cloud — флагман российского облака, стабильная сеть, хорошая защита от DDoS на уровне инфраструктуры, прогнозируемые цены. У нас там живут резервные шлюзы и Object Storage у трёх клиентов. Selectel — для VDS и dedicated, отличный аптайм, разумные цены, нормальная техподдержка. Использую как основной провайдер для большинства корпсайтов клиентов. VK Cloud — конкурентоспособный по цене, неплохая дока, но техподдержка медленнее, чем у Selectel. Cloud.ru (бывший SberCloud) — корпоративный сегмент, высокий ценник, но сертификаты ФСТЭК и УЦ если кому-то это критично.

Шаред-хостинг и небольшие провайдеры

Reg.Ru, Beget, Sprinthost — нормальная разметка для лендингов, малых корпоративных сайтов, сайтов-визиток. Ставить туда EMR-систему клиники, биллинг или критичный 1С-сервис — не стоит. FirstVDS, Timeweb, RuVDS — VDS сегмента «дёшево и под себя», для тестовых стендов и личных сайтов разработчиков. Aeza — отдельный кейс: дешёвая, в основном европейская инфраструктура, но репутация у разных клиентов очень разная.

Кого мы не рекомендуем

Без названий, но по характеристикам: провайдеры, которые: не отвечают на abuse-репорты в течение 72 часов; не поддерживают IPv6 в 2026 году; имеют публично известные случаи длительного простоя без компенсаций; работают по предоплате на год вперёд без возможности возврата. Таких в реестре RIPE десятки.

Цифры проекта и история одного писка в 4 утра

Полная пересборка нашей защиты после того инцидента заняла у нас ровно две рабочие недели. А что по стоимости? Инженерные работы обошлись в 96 000 ₽ (это 28 часов на проектирование, миграцию, настройку и тесты). Новый хостинг и Cloudflare Pro теперь стоят 4 600 ₽ в месяц, а сопровождение и мониторинг – ещё 6 000 ₽ в месяц. Мы, кстати, сравнивали это с альтернативой: «купить корпоративный антиDDoS у Stack-Group за 18-25 тысяч в месяц». Такой бюджет клиника, конечно, не потянула бы. Наша схема через CDN+VDS оказалась аж в 4 раза дешевле!

Самый, пожалуй, драматичный момент произошёл спустя месяц после того, как мы всё внедрили. В 4:12 утра наш Telegram-канал мониторинга просто выплюнул жуткий алерт: «ClinicDown». Я, конечно, тут же вскочил, схватил ноутбук, быстро прокинулся через VPN в Selectel – и что вы думаете? Сайт работал! Перепроверил мониторинг – и да, действительно, была недоступность, но только с проверки из Нидерландов, и длилась она 90 секунд. Оказалось, что в 4:10 у Selectel случился кратковременный сбой на одном из коммутаторов, но они восстановили всё буквально за 92 секунды. Реальные пользователи, которых ночью на сайте было всего 2-3 человека, просто получили стандартное сообщение «попробуйте через минуту». А вот алерт сработал ровно так, как мы и задумывали: у меня уже за 5 минут до полного восстановления был абсолютно чёткий план действий. С тех пор моё доверие к Selectel только выросло: они не прячут даже мелкие сбои, а их инфраструктура восстанавливается без потери данных. Это очень важно.

FAQ: что чаще всего спрашивают клиенты

Какой хостинг сейчас выбирать в России для бизнес-сайта?

Если говорить о нашем опыте за 2024-2026 годы, то для критически важных сервисов я бы советовал Я.Облако, VK Cloud, Selectel или Cloud.ru. У них стабильная сеть, встроенная DDoS-защита, которая, кстати, вполне разумна, и, что немаловажно, нормальная техподдержка. А вот шаред-хостинги вроде Reg.Ru, Beget или FirstVDS – они, на мой взгляд, хороши для лендингов и небольших корпоративных сайтов. Но для серьёзных бизнес-приложений – увольте, не годятся. DDoS-Guard и Stack-Group – это уже совсем другая песня, для очень специфических задач.

Что делать, если на ваш сайт пошёл DDoS?

Если вдруг на вас накатили, вот что нужно делать. Первый шаг – это обязательно связаться со своим хостером; у хороших провайдеров всегда есть встроенный DDoS-фильтр L3-L4, который они могут активировать по вашему запросу. Второй – быстро переключить весь трафик через CDN, который уже имеет DDoS-защиту. Это могут быть Cloudflare, Selectel CDN или Я.Cloud CDN. И третий шаг – если атака идёт на L7, то есть это HTTP-flood, тогда нужно срочно настраивать rate-limiting на nginx и, конечно же, WAF – например, ModSecurity с правилами OWASP CRS. Помните, на пике крупной атаки действовать нужно в первые 15 минут, иначе ваша репутация пострадает гораздо быстрее, чем доступность самого сервиса.

Можно ли защититься от DDoS бесплатно?

Полностью? Нет, к сожалению. Бесплатный Cloudflare и базовая DDoS-защита у Selectel, конечно, прикроют нас от 90% всех мелких атак, знаете, таких до 1-5 Gbps, которые обычно устраивают подростки через всякие стрессеры. Но вот от по-настоящему серьёзных атак – это когда 10+ Gbps, когда работают ботнеты IoT – тут уже нужна платная защита. Цены варьируются: от 1 500 ₽ в месяц за Cloudflare Pro до 15-30 тысяч у наших российских специализированных провайдеров. Моё мнение: бизнесу всегда выгоднее заплатить за хорошую защиту, чем потом разгребать все последствия одного-единственного успешного DDoS.

Что такое стрессер и насколько это серьёзная угроза?

Что такое стрессер? Это, по сути, сервис, который продаёт DDoS-атаки в розницу, как пирожки. Ну, например, 200-500 ₽ за 10 минут атаки на любой адрес. Их клиенты – это, как правило, подростки, злобные конкуренты или шантажисты. И это, поверьте, реальная угроза: всего за 200 ₽ ваш сайт вполне могут уложить на полчаса. У нас, кстати, был такой случай, когда одного клиента пытались шантажировать подобным образом раз в три недели. Но хорошая новость в том, что защита через CDN с фильтрацией автоматически закрывает 95% таких атак.

Сколько стоит защитить периметр сайта клиники у вас?

Если говорить о базовой защите для обычного бизнес-сайта, ну, такого на 2-5 страниц плюс админка, то это включает: настройку Cloudflare с WAF-правилами, перенастройку nginx, бэкапы по схеме 3-2-1 и, конечно, мониторинг. Всё это занимает примерно 12-15 рабочих часов инженера и обойдётся в 60-75 тысяч рублей. Дальше ежемесячно придётся платить за Cloudflare Pro – это 1 500 ₽, и за мониторинг – 6 000 ₽. А вот для клиники, особенно если там есть EMR-система, внедрение полноценного комплекса с резервным каналом потянет уже на 95-120 тысяч. Тут уж ничего не поделаешь.

Итог

Защита периметра – это, как я люблю говорить, не какой-то один огромный бронежилет, а скорее набор таких прозрачных слоёв. Сюда входит правильный хостинг, CDN с WAF, бэкапы по нашей схеме 3-2-1, постоянный мониторинг и, конечно, чёткий, понятный план действий на случай атаки. Для одной медицинской клиники в Москве все эти вложения – 96 000 ₽ единовременно и 10 600 ₽ в месяц – полностью окупились, ведь это спасло их от шантажа с 0,008 BTC и от потенциальной потери данных пациентов, что могло бы стоить клинике лицензии. Главный вывод после того инцидента, который директор этой клиники теперь постоянно повторяет на встречах с коллегами, звучит так: «Безопасность всегда дешевле, чем последствия её отсутствия. И заниматься ею должны только те, кто действительно умеет, а не наш сисадмин в свободное от поддержки 1С время».