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

Февраль 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 за 20 минут заблокировал 47 000 таких запросов. Но кое-что всё-таки пробилось — и именно это потом потребовало отдельной работы.

Был ещё один момент, который запомнился отдельно. На третий час атаки директору клиники пришло письмо: «Ваш сайт под нагрузкой, переведите 0,008 BTC на адрес ниже — мы остановим атаку. Иначе продолжим». Ransom-DDoS, классика жанра. Директор молча переслал нам письмо с одной припиской: «не плачу принципиально». Честно — мне это понравилось.

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

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

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

На всю операцию ушло 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. На /api/booking/check-slot/ поставили rate-limit: не более 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. Сам сервер стал максимально «тонким» — он просто отдаёт контент тем, кого уже пропустил Cloudflare.

Перенос с 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 и нормальную аналитику — то, чего в Free-версии просто нет.

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

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

На Cloudflare Pro мы написали 14 кастомных WAF-правил — под конкретные сценарии атак на медицинскую клинику. Не универсальные шаблоны, а точечные: по эндпойнтам, по паттернам запросов, по географии трафика. Правила закрывают то, что стандартный набор CRS не покрывает применительно к WordPress с плагином записи на приём.

# 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-бэкапа — поднимаю изолированную среду и проверяю, что всё реально восстанавливается. Не теорию, не логи — именно restore. Не тестируешь бэкап? Значит, бэкапа у тебя нет.

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

На отдельной виртуалке в Selectel у меня крутится связка: Prometheus, Alertmanager и Grafana. Плюс поднял blackbox-exporter — он пингует сайт одновременно из трёх точек: Москва, Питер, Нидерланды. Если сайт не отвечает больше 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 с защитой — 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 минут атаки на любой IP. Клиенты — подростки, конкуренты, шантажисты. Реальная угроза: за 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С».