Как защититься от DDoS – статья нашего инженера.
Автор: Виталий Солдатов
С конца февраля продолжаются ежедневные атаки на публичные российские интернет-ресурсы. Это и госсайты, и службы доставки, и парковки, и просто известные сервисы, которые широко используются в РФ. Причём атаки совершаются не только на сайт компании, но и на всю её доступную инфраструктуру: API, личные кабинеты клиентов, терминальные, почтовые и dns-серверы. Размещая приложение в частном или публичном облаке, инженеры рассчитывают вычислительные ресурсы, исходя из системных требований, текущей и прогнозируемой нагрузки. Спрогнозировать интенсивность DDoS-атаки и её продолжительность, а значит – спланировать вычислительные ресурсы не представляется возможным, поэтому и сбой в работе программного обеспечения во время атаки становится неизбежен.
*
Этап проектирования ИС
На этапе проектирования любой информационной системы, в том числе и защищённой в соответствии с требованиями законодательства уже следует решить вопрос с защитой от DDoS-атак, т.е. обеспечить фильтрацию передаваемых данных от клиентов к вашей информационной системе. Поскольку на информационную систему оформляется документация и на межсетевых экранах прописываются правила, разрешающие межсетевое взаимодействие, смена ip-адреса в будущем становится проблемой. Размещение публичной информационной системы без возможности оперативного подключения услуг по фильтрации трафика из-за невозможности смены ip-адреса несёт огромные риски как для владельцев таких систем, так и для их клиентов.
Подобные изменения кажутся неприемлемыми на первый взгляд, но к ним следует относиться как и к любой другой процедуре, выполняемой в рамках информационной безопасности, например, как к смене пароля или ответственного за информационную безопасность сотрудника. Расскажем, как устроена защита от DDoS-атак.
Начать следует с того, что эффективную защиту может обеспечить только специализирующийся на подобных услугах оператор связи.В рамках такой защиты операторы связи, используя программно-аппаратные комплексы, осуществляют фильтрацию трафика, передаваемого к интернет-сервисам клиента. Современные атаки осуществляются по большей части на веб-сайты по http-протоколу с применением большого арсенала средств автоматизации.
Сейчас любой желающий без опыта работы со специализированным программным обеспечением может использовать свой персональный компьютер и доступ в интернет для участия в спланированных атаках на российские публичные интернет ресурсы. Достаточно следовать простым инструкциям, запускать нужные программы и на этом всё. Отчасти благодаря повторяемости подобных атак, инженеры операторов связи могут проанализировать профили атак и эффективно им противодействовать.
Фильтрация вредоносного трафика
DDoS-атаки нацелены на определённые уровни сетевой модели OSI. Если атаки производятся по протоколу http, то необходима защита на прикладном уровне (уровень 7 модели OSI).Такую защиту L7 (level 7) обеспечивают специализирующиеся на подобных услугах операторы. Услуга по подобной фильтрации называется, например, «защита сайта».
Типовой интернет-провайдер обычно оказывает услуги по фильтрации на уровнях 3-4, блокируя разного рода паразитный трафик, по этой причине его программно-аппаратные комплексы не смогут проанализировать запросы к вашему сайту, а значит и защитить его. У облачных операторов и других собственников автономных систем есть возможность «купить интернет» у специализирующихся на защите операторов. Подобная услуга может называться «защита сети», в рамках которой обеспечивается фильтрация не только на уровнях 3-4, но и дополнительно на 7 уровне. То есть услуга «защита сайта» включается в услугу «защита сети». Итак, «защита сайта» – фильтрация L7 показана на схеме 1, «защита сети» – фильтрация L3, L4, L7 показана на схеме 2.
Рис.1 Схема «Защита сайта»
Рис.2 Схема «Защита сети»
В случае «защиты сайта» защитить можно только публичный интернет-сайт. Услугой может воспользоваться физическое или юридическое лицо, а сам сайт может быть размещен у хостера, в виртуальной машине у облачного оператора или в частном облаке. Услуга оказывается через сеть интернет, как это показано на схеме 1 любым специализированным оператором на ваш выбор. Это может быть и Cloudflare, и DDOS-Guard, и Qrator.
Corpsoft24 в партнёрстве с DDOS-Guard оказывает своим клиентам услугу по защите от DDoS-атак на уровнях L3-L4, L7.
*
Защита от DDoS
Оператор предоставляет вам в рамках услуги ip-адрес собственного reverse-прокси, через который будет доступен ваш сайт. Всё, что необходимо сделать – это поменять NS-записи в соответствии с индивидуальными инструкциями. Входящий трафик на ваш сайт принимается на reverse-прокси оператора и далее через сеть интернет передается на ip-адрес вашего сайта. Красной линией на схеме показан весь трафик из сети интернет, включая вредоносный. Зелёным показана передача отфильтрованных данных от оператора до вашего веб-сервера через сеть Интернет любым доступным путём. Предполагается что ip-адрес вашего сервера никому, кроме вашей службы эксплуатации и оператора связи неизвестен. Убедитесь, что ваш фактический ip-адрес сайта не записан в каких-либо базах в интернете. В противном случае он может быть атакован через ваши существующие интернет-подключения. Проверьте, например, базу на сайте https://myip.ms/. Ограничьте доступ к ip-адресу сайта, разрешив обращения по протоколу http только с reverse-прокси и с ваших доверенных сетей. Об ограничениях услуги и тарифных планах уточните у операторов связи.
В рамках нашей комплексной услуги «защита от DDoS» клиенту выдается ip-адрес из защищаемой сети, которая анонсируется по протоколу BGP в DDOS-Guard, где весь входящий трафик из сети интернет до вашей виртуальной инфраструктуры, как показано на схеме, будет проходить через средства фильтрации. Вы сможете защитить все ваши информационные системы, включая сайт с любым количеством доменов. Весь входящий трафик на ваш сайт будет направлен на reverse-прокси DDOS-Guard, а уже от reverse-прокси сервера на ваш сайт. IP-адреса посетителей в этом случае будут записаны в логах как адреса из сети 186.2.164.0/24
. Если ваш сайт работает на nginx
, то в конфигурацию nginx.conf
необходимо внести изменения в секции http
:
real_ip_header X-Forwarded-For; real_ip_recursive on; set_real_ip_from 0.0.0.0/0;
Публичный доступ к веб-серверу следует ограничить средствами межсетевого экрана, разрешив только доверенные сети и сети reverse-прокси.
Когда требуется защита информационной системы, которые работает по протоколу, отличному от https, пригодится фильтрация L3-L4. Это типовое решение по защите сети имеет ограничения:
-
Возникает ассиметрия при передаче данных, когда входящий трафик передаётся от пользователя из сети интернет к информационной системе через средства фильтрации, а исходящий трафик из ЦОДа маршрутизируется в соответствии с правилами маршрутизации, который определил оператор облачных сервисов;
-
Услуга продаётся с лимитом по полосе очищенного трафика. Необходимо определиться с шириной полосы или выбрать тариф от 100 мбит/с;
-
Возможна ошибочная фильтрация, из-за чего могут не работать корректно, например, туннели ipsec, возможны сбои в синхронизации баз данных. Может потребоваться ведение «белых списков» ip-адресов для частичного отключения фильтрации. Как вариант, не используйте канал защиты для передачи по нему чувствительных к потерям данных, используйте ip-адреса из других сетей и защищайте только то, что доступно из сети интернет;
-
Оператор может пропустить весь трафик в начале атаки, что приведёт к неработоспособности сервисов за короткое время. Такое бывает, к сожалению;
-
Подключение и отключение услуги связано с заменой ip-адреса. В качестве альтернативы, которая исключает необходимость смены ip-адреса, можно рекомендовать арендовать сеть из 256 ip-адресов.
С учётом описанных выше недостатков кратковременные сбои все равно неизбежны. Так регулярные атаки, например, на интернет-регистратора nic.ru, который декларирует у себя высокий процент доступности и защиту от DDoS приводят к следующим последствиям:
-
Сайт не работает, т.к. домен «не существует».
-
Почтовые сервера не могут отправить письма, т.к MX-записей нет.
-
Время ответа ns-сервера на запрос может быть более 10 сек.
В такой ситуации вы можете поступить следующим образом:
-
Увеличить TTL у MX-записи хотя бы до суток, чтобы кэширующие резолверы почтовых серверов хранили записи в своих кэшах и не обращались к ns-серверам регистратора (инструкцию по настройке кэширующих резолверов можно найти в этой статье).
-
Разместить зону на дополнительных серверах у других операторов, не ограничиваясь ns-серверами регистраторов.