Для малого бизнеса защита от DDoS-атак начинается с разделения сервисов по уровню риска. Публичный сайт, удалённый доступ сотрудников и внутренние системы не стоит оставлять за одним маршрутизатором. В статье разберём, как работают облачные фильтры, когда нужна гибридная схема, какие настройки проверить у провайдера и как провести тест без остановки бизнеса. В результате руководитель сможет составить понятный план защиты без покупки избыточного оборудования.
Что происходит с инфраструктурой во время DDoS-атаки?
DDoS-атака создаёт поток запросов или сетевых пакетов, который занимает канал связи либо перегружает сервер. Сайт перестаёт открываться, сотрудники теряют доступ к облачным системам, а клиент не может отправить заявку. При этом злоумышленнику не нужно получать пароль или доступ к панели управления: достаточно направить на адрес сервиса больше трафика, чем тот способен обработать.
Атаки бывают разными. На сетевом уровне перегружается канал, на транспортном уровне растёт число соединений, а на уровне приложений сервер получает большое количество внешне обычных запросов. Поэтому одного правила в межсетевом экране недостаточно. Фильтр должен учитывать адрес источника, частоту запросов, тип протокола и поведение клиента.
Для бизнеса в Беларуси практический риск зависит от того, что опубликовано в интернете. Если компания использует только сайт-визитку и корпоративную почту, последствия обычно связаны с недоступностью сайта. Если наружу выставлены интернет-магазин, личный кабинет, VPN-шлюз или API, атака затрагивает сразу несколько рабочих процессов.
Когда облачный фильтр подходит малому бизнесу?
Облачный фильтр принимает входящий трафик до того, как он достигает сервера компании. Система анализирует поток, отбрасывает подозрительные запросы и передаёт на сайт только разрешённый трафик. Такой подход особенно полезен, когда у бизнеса нет собственного сетевого инженера и оборудования для обработки большого потока.
Схема обычно строится через изменение маршрута трафика к публичному адресу. Провайдер защиты сначала изучает сетевой профиль, затем задаёт параметры фильтрации. В Anycast-сетях поток распределяется по периферийным узлам, поэтому часть атаки блокируется до попадания в облачную инфраструктуру (ITGLOBAL.COM, «DDoS в облачной инфраструктуре: защита, ответственность и решения»).
Перед подключением нужно получить от провайдера ответы на несколько вопросов:
- какие протоколы и порты можно защищать;
- кто меняет DNS или маршрут при включении защиты;
- как фильтр отличает обычных пользователей от автоматических запросов;
- куда направляются уведомления об атаке;
- как вернуть трафик к обычной схеме после инцидента;
- какие журналы и отчёты доступны администратору.
Облачная защита не отменяет базовую настройку сервера. Нужно ограничить открытые порты, отключить ненужные службы, обновлять веб-сервер и отделить административные интерфейсы от публичной части сайта. Для проверки локального контура полезно заранее выбрать межсетевой экран по задачам офиса, а не по максимальной пропускной способности: как выбрать межсетевой экран для офиса малого бизнеса в 2026 году.
Зачем нужна гибридная схема защиты?
Гибридная схема объединяет облачный фильтр и оборудование на площадке компании. Облако принимает на себя крупный внешний поток, а локальный межсетевой экран контролирует разрешённые соединения, доступ сотрудников и обмен с внутренними системами. Такой вариант подходит бизнесу, где простой сайта уже приводит к остановке заказов, телефонии или удалённой работы.
Внутренние адреса при этом не следует публиковать без необходимости. Публичный сайт размещают в отдельном сегменте, а серверы бухгалтерии, файловые хранилища и рабочие станции оставляют за локальным экраном. Если атакуют сайт, внутренние устройства не должны принимать этот поток и не должны быть доступны через тот же внешний адрес.
| Подход | Когда выбрать | Что остаётся на стороне компании |
|---|---|---|
| Только локальный межсетевой экран | Публичный сервис небольшой, а канал и оборудование имеют запас по нагрузке | Правила доступа, обновления, резервные каналы и наблюдение за загрузкой |
| Облачный фильтр | Главный риск связан с доступностью сайта или другого публичного сервиса | Настройка DNS, сервера, приложений и списка разрешённых соединений |
| Гибридная схема | Нужно защитить внешний сервис и сохранить доступ к внутренней инфраструктуре | Сегментация сети, локальный экран, резервирование и порядок переключения |
Для небольшой компании гибрид не означает обязательную покупку сложного комплекса. Иногда достаточно вынести публичный сервис под облачную фильтрацию, оставить офис за межсетевым экраном и настроить отдельный канал управления. Конкретный состав зависит от числа сервисов, требований к доступности и того, кто будет реагировать на инцидент ночью или в выходной день.
Как подготовить сеть до подключения защиты?
Сначала составьте список внешних сервисов: сайт, почтовый шлюз, VPN, удалённый рабочий стол, телефония, API и панели администрирования. Для каждого укажите доменное имя, IP-адрес, порт и ответственного сотрудника. Такой список помогает не включить фильтрацию вслепую и не заблокировать нужный обмен.
Затем разделите доступы. Панель управления сайтом не должна открываться для всего интернета, если сотрудникам достаточно доступа из VPN. Сервер базы данных не следует публиковать напрямую. Административные порты лучше разрешать только с известных адресов либо через защищённый канал.
Следующий шаг — измерить обычную нагрузку. Зафиксируйте средний и пиковый объём трафика, количество соединений, загрузку процессора и время ответа сайта. Без исходных значений трудно понять, где заканчивается штатный всплеск и начинается атака. Замеры стоит повторить в рабочий день, когда сайт и офисные сервисы работают в обычном режиме.
Сетевые сегменты также влияют на последствия инцидента. IP-телефонию, рабочие станции и серверы можно разделить с помощью VLAN, чтобы широковещательный или ошибочный поток не распространялся по всей локальной сети. Практическая инструкция по этой задаче собрана в материале как настроить VLAN для IP-телефонии и облаков в офисе.
Как проверить, что защита действительно работает?
Проверка начинается с безопасного сценария, согласованного с провайдером защиты. Самостоятельно запускать стресс-тест на рабочем адресе не стоит: он может нарушить работу сайта, попасть под ограничения оператора или повредить соседние сервисы. Вместо этого проверяют переключение маршрута, прохождение разрешённых запросов и реакцию системы на искусственно заданные правила.
В контрольном списке должны быть следующие пункты:
- сайт открывается из разных сетей после включения фильтра;
- администратор сохраняет доступ к панели управления через разрешённый канал;
- сервер не принимает соединения на лишние порты;
- система отправляет уведомление об аномальном потоке;
- в журнале видны время начала, тип события и принятое действие;
- после отключения защиты маршрут возвращается без ручного восстановления всей инфраструктуры.
Проверьте и резервный сценарий. Если основной канал связи недоступен, сотрудники должны понимать, какие сервисы продолжают работать, кто принимает решение о переключении и где лежат контакты провайдера. Для офиса с облачными приложениями особенно важен отдельный способ управления сетевым оборудованием, иначе во время сбоя некому будет изменить настройки.
Какие ошибки чаще всего снижают результат защиты?
- Публикация всех серверов через один внешний адрес без разделения ролей.
- Подмена DDoS-защиты обычным антивирусом или локальным правилом на маршрутизаторе.
- Отсутствие списка разрешённых портов и владельцев сервисов.
- Включение фильтрации в момент атаки без предварительной проверки DNS и маршрутов.
- Хранение единственных контактов провайдера на недоступном корпоративном сервере.
- Отсутствие плана восстановления после инцидента и проверки резервной связи.
Для малого бизнеса разумный порядок такой: сначала описать внешние сервисы и измерить их обычную нагрузку, затем закрыть лишние порты и разделить публичную и внутреннюю сеть, после этого выбрать облачный или гибридный вариант защиты. Если в компании уже используются облачные приложения и удалённый доступ, проект лучше начинать с карты потоков: какие соединения нужны сотрудникам, какие идут к клиентам и какие должны оставаться внутри офиса.
