Почему сервер доступен из локальной сети, но недоступен из интернета?

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

Поможет ли блокировка IP-адресов, если канал уже перегружен?

Обычно нет. Правило блокировки на сервере отбросит пакет только после того, как он занял часть канала и прошёл сетевое оборудование до хоста. Блокировка IP полезна лишь при небольшом числе стабильных источников, если поток не насыщает канал и правило срабатывает до перегрузки нужного ресурса. Массовые блокировки могут затронуть клиентов и усложнить диагностику.

Защитит ли CDN или WAF сервер с прямым IP-адресом?

Зависит от схемы публикации и возможностей конкретного сервиса. CDN, reverse proxy и WAF могут принимать запросы до origin-сервера, фильтровать их и снижать прикладную нагрузку, но обычно это относится к поддерживаемым веб-протоколам и настроенным точкам входа. Они не становятся автоматической защитой любого сервиса на сервере. Если атакующий может обращаться к origin по прямому IP-адресу, он способен обойти CDN или WAF. Поэтому для веб-сервиса важно ограничить прямой доступ к origin в соответствии с используемой схемой публикации. Нестандартные TCP-сервисы, UDP-потоки и другие службы, доступные по прямому IP, могут требовать защиты у оператора связи или специализированного поставщика фильтрации. До внедрения следует подтвердить в документации и поддержке поставщика, какие IP-адреса, домены, порты и протоколы входят в защиту, где находится фильтрация и как будет ограничен незащищённый прямой доступ.

Что передать провайдеру при подозрении на DDoS?

Сначала зафиксируйте, что именно наблюдается: время начала либо интервал, атакуемые IP-адреса, домены, порты, регионы затронутых пользователей и симптомы — тайм-ауты, ошибки приложения, потери пакетов, недоступность SSH или RDP. Это поможет поддержке сопоставить обращение со своими сетевыми метриками. Подготовьте доступные данные до, во время и после ухудшения: загрузку входящего и исходящего канала, CPU, памяти и диска, число новых и активных соединений, ошибки сервиса, журналы reverse proxy, приложения и firewall. Если есть образцы пакетов или сведения о распределении трафика по адресам и протоколам, их также можно передать. Используйте заранее согласованный канал эскалации. Если основной канал связи недоступен из-за перегрузки, примените независимый путь, предусмотренный процедурой. Результатом обращения должны быть номер заявки, подтверждение её принятия и согласованное действие: включение фильтрации, проверка защищаемого IP, порта или протокола либо другой шаг со стороны поставщика.

Стоит ли перезагружать сервер во время атаки?

Нет, не без оценки причины перегрузки. Перезагрузка не освобождает насыщенный входящий канал, может продлить простой и уничтожить полезный контекст диагностики. Сначала сохраните доступные метрики и журналы, определите вероятно перегруженный ресурс и обратитесь к провайдеру или сервису фильтрации. Локальные изменения применяйте только точечно и с подготовленным откатом.

Как не спутать DDoS с ошибкой приложения или базы данных?

Нельзя надёжно назвать событие DDoS по одному признаку, например по высокой загрузке CPU или увеличению входящего трафика. Сопоставьте метрики канала с потерями, задержками, числом новых и активных соединений, очередями и ошибками сервиса. Для гипотезы о внешнем потоке проверьте данные провайдера, журналы firewall и reverse proxy, распределение по адресам, портам и протоколам. Если рост запросов совпал с рекламной кампанией, публикацией, рассылкой или другим событием, проверьте аналитику приложения, успешные пользовательские сессии, бизнес-события и кэш-попадания: это может быть легитимный спрос. Когда CPU и задержки растут без пропорционального сетевого трафика, исследуйте журналы приложения и базы данных, длительность операций, очереди, пул соединений и недавние изменения. Потери и тайм-ауты без аномального входящего потока требуют также проверить сеть, DNS, балансировщик, зависимые сервисы и сообщения провайдера. Подозрительные процессы, изменения учётных записей или файлов и необычный исходящий трафик могут указывать на компрометацию, а не на DDoS.

Защита сервера от DDoS: firewall, провайдер и действия при атаке

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

Где трафик можно остановить

Упрощённый путь входящего запроса выглядит так: клиент → сеть и канал провайдера → сеть площадки и порт сервера → сетевой интерфейс сервера → сетевой стек операционной системы, включая firewall и при необходимости отслеживание соединений → сервис и приложение. Чем дальше по этому пути находится защита, тем больше ресурсов уже могло быть потрачено на обработку трафика.

Это определяет границу локального firewall: он принимает решение только о пакетах, которые дошли до хоста. Правило DROP не отправляет ответ и не передаёт пакет приложению, но сам пакет уже занял часть внешней полосы, прошёл сетевое оборудование и был принят интерфейсом сервера.

Ресурс, который исчерпывает атака, определяет подходящий уровень защиты

Сценарий	Что исчерпывается	Типичные признаки	Где защита эффективнее
Объёмный поток пакетов или трафика	Пропускная способность канала, порт, сеть площадки	Высокая загрузка канала, потери и задержки; сервер может быть недоступен даже по SSH	У провайдера, хостинга или внешнего сервиса фильтрации до канала сервера
Большое число новых TCP- или иных соединений	Очереди, таблицы состояний, ресурсы ядра или балансировщика	Рост числа новых подключений и ошибок соединения, даже если канал не заполнен	На сервере, балансировщике и у провайдера — в зависимости от места перегрузки
Протокольное злоупотребление	Обработка пакетов, состояния соединений, CPU сетевого стека	Необычная структура пакетов, много неполных или недопустимых потоков	Фильтрация пакетов на хосте и выше по сети
Прикладная атака	CPU, память, пул процессов, база данных, внешние API	Нормально выглядящие HTTP-запросы вызывают медленные ответы и рост нагрузки приложения	Обратный прокси-сервер (reverse proxy), межсетевой экран веб-приложений (WAF), сеть доставки контента (CDN), ограничения приложения и масштабирование сервиса

Эти категории могут сочетаться. Например, HTTP-запросы от множества адресов способны одновременно занять канал, исчерпать соединения и нагрузить базу данных. По одному симптому — например, высокой загрузке CPU или росту входящего трафика — нельзя надёжно назвать событие DDoS.

Что реально ограничивает firewall на сервере

Локальная фильтрация пакетов полезна как часть обычной политики межсетевого экрана, а не только как реакция на атаку. Она сокращает поверхность входа: сервер принимает только необходимые протоколы, порты и направления трафика.

Блокировка пакетов к неиспользуемым портам, протоколам и адресам назначения.
Разрешение доступа к административным или внутренним службам только из известной сети либо через allowlist.
Ограничение частоты новых пакетов или соединений для конкретного сервиса с помощью ограничения частоты запросов.
Отбрасывание части некорректных, неожиданных или не относящихся к разрешённому потоку пакетов.
Обработка ответного трафика с учётом состояния соединения в stateful firewall.
Временное добавление конкретных источников в список блокировки, если источник стабилен, а блокировка подтверждённо не затрагивает нужных клиентов.

В Linux эти возможности обычно реализуются средствами Netfilter и правилами nftables либо iptables; в Windows — правилами Windows Defender Firewall. Точная семантика лимитов, поддерживаемые параметры, порядок обработки и влияние на ресурсы зависят от стека, версии ядра, firewall-менеджера и конфигурации. Пошаговая настройка вынесена в статьи о политике firewall, nftables, iptables, UFW и firewalld и Windows Defender Firewall.

Ограничение тоже расходует ресурсы

Stateful-фильтрация хранит записи о потоках в таблице состояний. При большом числе новых или специально сформированных потоков эта таблица и её обработка сами могут стать узким местом. Лимиты также требуют учёта пакетов или событий. Не следует считать connection tracking и rate limiting бесплатной либо универсальной DDoS-защитой.

Почему DROP, rate limit и блокировка IP не спасают переполненный канал

Если атака заполнила входящую полосу до сервера, легитимные пакеты конкурируют с атакующим трафиком ещё до firewall. Локальное правило может отбросить вредоносный пакет после получения, но не может вернуть полосу, уже занятую этим пакетом. По той же причине сервер может быть доступен из локальной сети, но недоступен пользователям из интернета.

Блокировка адресов помогает только в узком сценарии: адресов немного, они не меняются, правило обрабатывается до перегрузки нужного ресурса, а объём потока не насыщает канал. В реальных атаках источников может быть много, они могут быстро меняться, а часть адресов — быть подменённой. Массовые блокировки увеличивают ruleset, усложняют диагностику и способны закрыть доступ реальным клиентам.

Географические ограничения, репутационные списки, IDS/IPS и временные блокировки — это компенсирующие контроли для определённых моделей угроз. Они могут снизить нагрузку на сервис, но не заменяют сетевую фильтрацию при насыщении канала. О границах IDS и IPS см. «IDS и IPS для сервера: Suricata и OSSEC без ложной уверенности».

Когда достаточно локальных правил, а когда нужна внешняя защита

Наблюдаемая ситуация	Приоритетная мера	Почему
Открыты ненужные порты или сервис получает обращения из заведомо неразрешённых сетей	Локальная политика firewall, allowlist, закрытие лишних точек входа	Трафик можно отсечь до передачи приложению; канал при этом не обязательно перегружен
Умеренный всплеск новых подключений к одному сервису, канал свободен, сервер доступен	Осторожный лимит новых соединений и проверка приложения	Можно снизить нагрузку на конкретную службу, но порог требуется проверять на нормальной нагрузке
HTTP-нагрузка вызывает дорогие операции приложения, а сеть не насыщена	Ограничения и кэширование на reverse proxy, CDN или WAF; исправление приложения	Проблема находится на прикладном уровне, где firewall L3/L4 не видит смысл запроса
Входящий канал, порт или сеть хостинга насыщены; растут потери и задержки	Обращение к хостингу, оператору или сервису DDoS-фильтрации	Фильтрация должна происходить до узкого канала и инфраструктуры сервера
Публичный веб-сервис можно публиковать через поддерживаемую точку входа CDN	CDN или reverse proxy с включённой защитой приложения	Запросы завершаются и фильтруются до origin-сервера; прямой доступ к origin должен быть отдельно ограничен
Нестандартный TCP-сервис, UDP-поток или прямой IP остаются доступными извне	Уточнение защиты у оператора или специализированного поставщика	Не каждый CDN, WAF или reverse proxy принимает такие протоколы и защищает прямой IP-адрес

CDN и WAF защищают не всё

CDN, reverse proxy и WAF обычно работают для протоколов и точек публикации, которые сервис принимает у этого поставщика. Они не автоматически защищают произвольный UDP-трафик, нестандартные сервисы или origin-сервер, доступный по прямому IP. До внедрения нужно проверить в официальной документации конкретного сервиса поддерживаемые протоколы, схему маршрутизации и способ ограничения прямого доступа к origin.

Что согласовать с провайдером до инцидента

Внешнюю защиту нельзя планировать по общим описаниям услуги. Название продукта, доступные протоколы, условия включения, лимиты, порядок эскалации и договорные обязательства зависят от конкретного провайдера, тарифа и договора. Их следует подтвердить по официальной документации и в поддержке поставщика.

Какие виды защиты доступны: постоянная фильтрация, включение по запросу, BGP-маршрутизация через scrubbing-центр, защита веб-точки через CDN или иной вариант.
Какие IP-адреса, домены, порты, TCP-, UDP- и прикладные протоколы входят в защиту, а какие исключены.
Где именно расположена фильтрация относительно канала сервера и сети площадки.
Как активировать защиту: кто уполномочен подать заявку, какой канал использовать, какие данные предоставить и как подтверждается включение.
Есть ли экстренный канал связи, время реакции, условия SLA и ограничения на работу во время атаки.
Какие метрики и сведения нужны поддержке: атакуемые IP и порты, время начала, графики трафика, затронутые сервисы, образцы пакетов или журналы.
Как проверить, что фильтрация включилась, и как согласовать её отключение после инцидента.
Какие действия может выполнить сам провайдер: фильтрация, ограничение отдельного сервиса, смена маршрута или временное отключение адреса как крайняя мера.

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

Первые минуты при перегрузке

Первичный триаж перегрузки сервера

Цель первых действий — сохранить данные для анализа, определить узкое место и включить подходящий заранее подготовленный уровень защиты. Это триаж инцидента, а не попытка немедленно переписать все правила firewall.

1
Зафиксируйте время и влияние
Запишите время начала, затронутые IP-адреса, домены, порты, регионы пользователей и симптомы: ошибки приложения, тайм-ауты, потери пакетов, недоступность SSH или RDP. Ожидаемый результат — короткая временная шкала, с которой можно сопоставить метрики и журналы. Если точное начало неизвестно, зафиксируйте интервал и отметьте источник наблюдения.
2
Сохраните метрики и журналы
Сохраните графики загрузки канала, CPU, памяти, диска, числа соединений и ошибок сервиса, а также журналы reverse proxy, приложения и firewall. Ожидаемый результат — данные до, во время и после ухудшения, а не только текущая картина. При наличии централизованного журналирования проверьте, что события продолжают поступать; если нет — сохраните доступные локальные данные без очистки.
3
Определите перегруженный ресурс
Сопоставьте загрузку входящего и исходящего канала с потерями, использованием CPU и памяти, числом новых и активных соединений, очередями и задержками приложения. Ожидаемый результат — рабочая гипотеза: насыщен канал, исчерпывается таблица состояний, перегружен процесс сервиса или зависима внешняя система. Если метрики противоречат друг другу, не объявляйте событие DDoS до проверки альтернативных причин.
4
Уведомьте провайдера или защитный сервис
Обратитесь по заранее согласованному каналу и передайте время, атакуемые адреса и порты, симптомы, наблюдаемую нагрузку и влияние на пользователей. Ожидаемый результат — номер обращения, подтверждение принятия и согласованный следующий шаг. Если канал уже насыщен, используйте независимый путь связи, предусмотренный процедурой.
5
Включите предусмотренную внешнюю схему
Активируйте заранее согласованную фильтрацию у поставщика, защиту веб-точки через CDN или другой утверждённый механизм. Ожидаемый результат — изменение маршрута или статуса защиты и измеримое снижение нежелательного трафика до сервера. Если эффект отсутствует, передайте провайдеру новые метрики: возможно, защищается не тот IP, порт или протокол.
6
Меняйте локальные правила только точечно
Если сервер остаётся управляемым и причина понятна, применяйте только заранее подготовленные, обратимые меры для конкретного потока: ограничение нового соединения к одному сервису, временное закрытие несущественной точки входа или ограничение подтверждённого источника. Ожидаемый результат — счётчики и метрики показывают снижение нагрузки без потери административного доступа. При ухудшении немедленно используйте подготовленный откат и передайте проблему на внешний уровень фильтрации.
7
Контролируйте восстановление
Сравнивайте доступность снаружи, загрузку канала, ошибки сервиса и данные провайдера после каждого изменения. Ожидаемый результат — не только снижение трафика, но и восстановление доступа легитимных пользователей. Снимайте временные ограничения лишь после подтверждения стабильности и документируйте, что сработало и что нет.

Не потеряйте управление сервером во время атаки

Не очищайте удалённо весь ruleset, не применяйте массовые блокировки без проверки, не меняйте одновременно маршрутизацию и firewall и не перезагружайте сервер «для очистки» без оценки причины. Такие действия могут закрыть SSH или RDP, уничтожить полезный контекст диагностики и продлить простой. До инцидента подготовьте аварийный доступ и порядок отката; правила безопасного изменения описаны в статье о политике firewall.

Как отличить DDoS от похожих проблем

Гипотеза	Что может указывать на неё	Что проверить до вывода
DDoS или иной внешний сетевой поток	Резкий рост трафика, новых соединений, потерь или однотипных запросов	Метрики канала, данные провайдера, журналы firewall и reverse proxy, распределение по адресам, портам и протоколам
Всплеск легитимного спроса	Рост запросов совпал с рекламной кампанией, публикацией, рассылкой или событием	Аналитику приложения, характер запросов, успешные пользовательские сессии, бизнес-события и кэш-попадания
Ошибка приложения или базы данных	CPU и задержки растут без пропорционального роста сетевого трафика; видны ошибки приложения	Логи приложения и БД, время выполнения операций, очереди, пул соединений, недавние изменения и релизы
Неисправность сети или зависимого сервиса	Потери, тайм-ауты или недоступность наблюдаются без аномального входящего потока	Статус сети и зависимостей, события провайдера, DNS, балансировщик, мониторинг из нескольких точек
Компрометация сервера	Неожиданные процессы, изменения учётных записей, файлов, задач или подозрительный исходящий трафик	Сохраните артефакты и начните отдельное реагирование, не списывая признаки на DDoS

DDoS может совпасть с другой проблемой: неудачный релиз делает приложение уязвимым к обычному всплеску запросов, а компрометированный сервер может создавать исходящий трафик. Если перегрузка сопровождается подозрительными процессами, изменениями учётных записей или файлов, следуйте процедуре из статьи «Сервер взломали: изоляция, артефакты и первые действия».

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

Рабочая схема строится как многоуровневая защита: у каждого уровня есть собственный ресурс и зона ответственности. Сервер ограничивает доступ к службам и отсеивает часть трафика; reverse proxy, CDN или WAF защищают опубликованную веб-точку; сеть площадки и оператор принимают меры до канала сервера; внешний сервис фильтрации обрабатывает объёмные и распределённые потоки; мониторинг и процедура эскалации связывают технические меры с действиями людей.

Для сервера: известный набор открытых служб, проверенная политика firewall, сохранённая конфигурация и аварийный административный доступ.
Для приложения: метрики запросов, ошибок, задержек и зависимостей; меры защиты от дорогих запросов на уровне приложения или reverse proxy.
Для публикации веб-сервиса: подтверждённая схема CDN, WAF или reverse proxy и отсутствие незащищённого прямого доступа к origin там, где это требуется.
Для сети и поставщика: документированная возможность фильтрации, перечень защищаемых адресов и протоколов, контакты и условия активации.
Для эксплуатации: оповещения о загрузке канала и сервиса, хранение журналов, роли ответственных и проверенный порядок эскалации.

Термины в статье

Allowlist: Allowlist — перечень разрешающих записей или правил: система допускает только те субъекты, объекты, действия или значения, которые им соответствуют.
Компенсирующий контроль: Компенсирующий контроль — защитная мера, заменяющая недоступный основной контроль и снижающая тот же риск до приемлемого уровня при документированном обосновании.
Межсетевой экран: Межсетевой экран — средство контроля сетевого трафика, разрешающее или блокирующее его по правилам на границе или между сегментами сети.
Межсетевой экран с отслеживанием состояния: Межсетевой экран с отслеживанием состояния — межсетевой экран, который сопоставляет пакеты с состоянием отслеживаемых соединений и потоков и применяет правила с учётом их контекста.
Многоуровневая защита: Многоуровневая защита — стратегия построения нескольких независимых или взаимодополняющих защитных рубежей, чтобы отказ одного контроля не приводил к компрометации актива.
Ограничение частоты запросов: Ограничение частоты запросов — механизм контроля нагрузки, ограничивающий число запросов от клиента или другого субъекта за заданный интервал.
Отслеживание соединений: Отслеживание соединений в Linux — механизм Netfilter, ведущий записи о потоках и их состояниях для фильтрации с учётом состояния, NAT и правил, зависящих от направления трафика.
Политика межсетевого экрана: Политика межсетевого экрана — набор правил обработки сетевого трафика, определяющий разрешённые и запрещённые взаимодействия между зонами, узлами, сервисами и интерфейсами.
Правило межсетевого экрана: Правило межсетевого экрана — элемент политики фильтрации, задающий условия сопоставления трафика и действие над пакетами или соединениями.
Состояние соединения: Состояние соединения — классификация пакета подсистемой отслеживания соединений: NEW, ESTABLISHED, RELATED, INVALID или UNTRACKED.
Список блокировки: Список блокировки — набор идентификаторов, адресов или признаков, для которых политика явно запрещает действие, например подключение, доставку сообщения или доступ к ресурсу.
Триаж инцидента: Триаж инцидента — первичная оценка события безопасности для подтверждения инцидента, определения его приоритета, масштаба, потенциального ущерба и необходимых действий реагирования.
Фильтрация пакетов: Фильтрация пакетов — способ контроля сетевого трафика по полям пакета и правилам, при необходимости дополненный отслеживанием состояния соединений.
Централизованное журналирование: Централизованное журналирование — сбор и хранение журналов разных систем в общем сервисе для унифицированного поиска, контроля целостности и анализа.