«Раньше надо было думать». Эта русская максима применима очень ко многим жизненным ситуациям, но в деле защиты сетевых ресурсов от атак на отказ в обслуживании эти слова верны вдвойне.
Предварительное планирование крайне важно, если вы собираетесь создавать популярный и конкурентный сервис где-то в интернете — внимание на него могут обратить не только злоумышленники, но и конкуренты. В конечном счёте, неожиданный и большой наплыв пользователей по сути ничем не отличается от распределённой атаки.
Если вы не озаботились защитой заранее, условия, в которых вам придётся вернуться к этой теме, могут быть совершенно неоптимальными. Мы решили представить вниманию читателя несколько основных пунктов — сложностей, с которыми столкнётся любой сервис, находящийся под атакой и пытающийся подключиться к системе нейтрализации атак на отказ в обслуживании.
Лирическое отступление: если вы собираетесь ехать в отпуск в тропическую страну на другом континенте, то нелишне, помимо общепринятой туристической страховки, озаботиться и вопросом прививок от наиболее опасных и распространённых заболеваний.
Да, шанс укуса комара мал, если вы носите длинный рукав и закатываете брюки в носки. В крайнем случае вас, конечно, спасут. Но данный процесс может затянуться, вы потратите множество нервов и, вполне возможно, средств на медицинских специалистов и препараты как на месте, так и по возвращении. А ведь стоило всего лишь поставить прививку от опасного заболевания и убедиться в том, что ваша страховка покрывает все случаи.
Каковы плюсы подключения к сети фильтрации трафика до атаки?
Первое и самое важное — это знание о поведении пользователей. Наблюдая трафик целевого ресурса до стресса, мы хорошо представляем себе, каково нормальное поведение пользователей ресурса и какая статистика посещаемости является для ресурса естественной. При нахождении под атакой происходит постепенная (или быстрая, всё зависит от действий атакующих) деградация сервиса, в результате которой поведение нормальных пользователей ресурса существенно меняется. В некоторых случаях действия легитимных пользователей начинают походить на атаку и ухудшают её последствия, как пример — циклическое обновление одной и той же страницы пользователем до получения требуемой страницы в браузере.
Чем сильнее деградация сервиса под атакой — тем сложнее отличить легитимных пользователей от вредоносных ботов. Если мы не видели поведение пользователей в преддверии атаки с нормальным и доказано легитимным поведением — мы не знаем заранее, по каким признакам возможно отличить настоящего пользователя от бота-злоумышленника, отправляющего мусорные запросы на сервер. Помимо этого, объём трафика, сопровождающий нормальный рабочий процесс сервиса, был бы также известен.
В случае, если на начало атаки сеть или фильтрационное оборудование не были включены в процесс её нейтрализации, то в процессе для автоматики и обучающихся моделей все пользователи, нажимающие «Обновить страницу», почти неотличимы от трафика атаки, соответственно, вероятность их блокировки высока. Зная предыдущее поведение пользователей ресурса, можно обезопасить и их, и себя от возникновения подобной ситуации.
Точно так же и с объёмом трафика и статистикой посещаемости в нормальной ситуации — в случае отсутствия такой информации на момент атаки будет очень сложно с уверенностью утверждать, вернулся ли трафик в норму после нейтрализации атаки из-за того, что под блокировку могли попасть настоящие пользователи, просто обладающие чуть отличающимся от медианного поведением во время деградации сервиса под атакой.
Конечно, подобные проблемы встречаются не всегда, но становятся особенно острыми при некоторых сценариях атаки. В зависимости от сложности атакующего бота и хитрости злоумышленника, действительно неприятной может стать атака в корень сервиса — в этом случае при деградации сервиса поведение ботов выглядит почти неотличимо от поведения легитимных пользователей, у которых просто «ничего не открывается». В случае атак другого типа, как правило, остаются значимые отличия в легитимном и вредоносном поведении с точки зрения потоков данных.
Представьте себе банальную бытовую ситуацию — прорыв водопроводной трубы, потоп. Вы не были к нему готовы, под рукой не было заглушек, на трубе — запирающих кранов и так далее, худший сценарий. Вы можете быстро заделать дыру и остановить течь, но по всей квартире уже плавает мебель и детские игрушки, а в дверь стучатся гости. Сможете ли вы их пустить? Вряд ли.
Каковы реальные минусы и возможные последствия при подключении под атакой?
«С больной головы на здоровую» — это про нейтрализацию DDoS. И как ни странно, но даже давно присутствующие на рынке компании с профессиональными сотрудниками и тысячами потребителей по всей стране или даже по всему миру далеко не всегда задумываются о нейтрализации DDoS до момента начала атаки. Нам бы хотелось изменить данную ситуацию с помощью донесения адекватной информации до аудитории, но не будем строить иллюзий — пока гром не грянет, мужик не перекрестится.
Давайте рассмотрим основные трудности и сложности, с которыми приходится справляться ресурсу, находящемуся под атакой, и нам как сервису, осуществляющему нейтрализацию распределённых атак.
Первое, о чём можно с уверенностью утверждать в случае сервиса, подключающегося к системе фильтрации, находясь под атакой, это то, что он с высокой вероятностью испытывает частичную или полную недоступность у пользователей.
Второе — если вас атакуют, то, скорее всего, злоумышленник знает уже не только ваше доменное имя, но и IP-адрес. Вдобавок, обычно IP-адрес атакуемого ресурса принадлежит хостеру, поэтому мы априори считаем, что также известен. То есть злоумышленник владеет достаточной информацией для модификации вектора атаки.
Для того чтобы оперативно переехать либо к другому хостеру (возможно, атакуют не вас), либо сменить провайдера IP-транзита (возможно, вы лишь побочная жертва атакующих более масштабную цель) требуется время.
Конечно, отработка false positive — не единственная трудность. Подключение под атакой не устраняет проблему частичной или полной недоступности, и если атака уже началась и успела причинить некоторый вред, то помимо работ по подключению ресурса к системе защиты нужен «контроль повреждений», то есть работа над последствиями атаки на стороне потребителя и заказчика.
Бывает, что атака «хорошо пошла» и принесла значительный ущерб. Буквально это значит следующее — помимо забивания канала связи, через который далее так или иначе будет необходимо организовывать связность уже с облачным провайдером фильтрации трафика, пока выделенных каналов нет, может «умереть» (отказать в обслуживании) пограничный маршрутизатор или балансировщик. Плохо может быть и другим инфраструктурным составляющим, например, нередко в разрыв соединения с внешним миром смотрит межсетевой экран (файрвол), являющийся нежным устройством и не любящий распределённых атак на отказ в обслуживании. Остановка нормальной работы файрвола грозит дырой в сетевом периметре. Да, это лечится перезагрузкой отказавшего оборудования, но до него ещё необходимо добраться и дождаться возвращения его в консистентное состояние. Всё это время трафик пропускается без фильтрации.
Говоря об атаках на прикладной уровень (L7), то здесь и с каналом всё может быть хорошо, и связность есть, но веб-приложение всё равно болеет, находится в депрессии и может, например, отвалиться от базы, либо упасть вместе с ней. А возвращение его в нормальное консистентное состояние может занимать от нескольких часов до нескольких суток, в зависимости от существующих архитектурных сложностей.
К сетям фильтрации трафика существует два наиболее распространенных способа подключения — с использованием DNS либо BGP. Рассмотрим два этих сценария по отдельности.
DNS
Предположим, что атака ведётся только по доменному имени.
Типичный сценарий подключения сайта под атакой по DNS выглядит следующим образом: владелец сетевого ресурса, представленного доменным именем, в A-записи DNS которого указан текущий IP-адрес атакуемого веб-сервера, обращается к нам за помощью. После соблюдения всех формальностей Qrator Labs выделяет клиенту специальный IP-адрес, на который он заменяет свой текущий адрес.
Как правило, в этот момент приходится учитывать возможный высокий TTL на изменение записи DNS, который может составлять от нескольких часов до суток максимум (предел по RFC: 2147483647 секунд) — в течение этого времени старая А-запись будет существовать в кэше DNS-рекурсоров. Поэтому если вы заранее осознаете, что атака вероятна, необходимо иметь низкий TTL для A-записи DNS.
Но в некоторых случаях даже это может не спасти. Ведь злоумышленники во время атаки проверяют её результативность, и видя, что атака не даёт результата, смышлёный злодей быстро переключится на атаку в тот IP-адрес, который он «помнит», минуя сеть фильтрации.
В таком случае необходим новый IP-адрес, неизвестный злоумышленникам и никак не компрометирующий защищаемое доменное имя, желательно в отличном от старого блоке адресов, а идеально — у другого поставщика услуг. Ведь злоумышленники всегда могут пойти дальше и переключить вектор DDoS-атаки в блок адресов (префикс) поставщика, имея достаточные мощности. Ну а к нам — милости просим. Двигаемся дальше.
BGP
В случае с подключением по протоколу BGP всё выглядит несколько иначе.
Если атакуемый сервис обладает собственными блоками адресов (префиксами) и хочет перевести всю инфраструктуру под защиту целиком, анонсируя собственные префиксы через поставщика услуг нейтрализации DDoS — как выглядит данный процесс?
Автономная система под атакой добавляется в наш AS-SET, для того чтобы иметь возможность анонсировать собственные префиксы, после чего начинаются пресловутые сутки (24 часа) на получение всеми нашими аплинками данной информации и обновления префикс-листов. Естественно, в экстренном случае мы стараемся пойти навстречу такому клиенту, форсируя данный процесс, но это возможно не в каждом случае и делается вручную. В свете вышесказанного, время — ключевой и основной стресс-фактор, ведь защитить ресурс требуется безотлагательно, «обезболить мгновенно».
В случае, когда владелец префикса готовится к атаке заранее, проводя ряд предварительных настроек, он может проаносироваться в сеть фильтрации Qrator почти мгновенно, сэкономив время и нервы технических специалистов во внеурочное время и в авральном режиме. Взаимная интеграция в данном случае не только технический, но и психологический процесс.
Лирическое отступление: ваш поставщик услуг связности покупает IP-транзит, как правило, у больших и надежных операторов связи, не ниже региональных Tier-1 операторов. Они фильтруют префиксы, поступающие к ним от клиентов, на основании некоторого списка (prefix-list), который они берут из открытых баз данных (RIPE, RADB и других). Штатно одни поставщики IP-транзита сервиса по защите от DDoS обновляют эти фильтры циклично раз в сутки, другие делают это только по запросу. У грамотного поставщика услуг нейтрализации DDoS точки присутствия расположены по всему миру, мгновенно не накатишь.
Наиболее сложным случаем подключения под атакой является обращение владельца сложной инфраструктуры, обладающей самым разным оборудованием: маршрутизаторами, межсетевыми экранами, балансировщиками нагрузки и прочими чудесами современных технологий. В подобных сценариях даже штатное подключение к поставщику услуг нейтрализации DDoS — сложный процесс, подходить к которому стоит взвешенно и планомерно. Даже как-то стыдно упоминать, что в случае атаки на такой сервис экстренное его подключение к сети фильтрации съедает кучу усилий и не оставляет времени на тщательное планирование, ведь под атакой каждая минута на счету. Пока данные проблемы не решены, сервис имеет проблемы с доступностью у пользователей и деградирует.
Нередко DDoS-атака комбинируется в некоем порядке с хакерской атакой — на взлом и проникновение, либо до атаки на отказ в обслуживании, либо после. Здесь задействованы риски уже совершенно другого порядка: утечка пользовательских данных, получение полного доступа к системе злоумышленником. Данные проблемы необходимо решать перпендикулярно с нейтрализацией DDoS, что в худшем случае ведёт к ещё более продолжительной недоступности у пользователей, а в лучшем — к увеличенной задержке у тех, кто пытается запросить необходимую страницу.
Постскриптум.
Коллеги, доводим до вашего сведения следующую важную новость: www.ietf.org/mail-archive/web/idr/current/msg18258.htmlИнициатива о внедрении механизма автоматической защиты от возникновения «утечек маршрутов» (route leaks), непосредственное участие в создании которой принимали инженеры Qrator Labs, успешно прошла этап «принятия» (adoption call) и перешла в рабочую группу по Interdomain Routing (IDR).
Следующий этап — доработка документа в рамках IDR и, в дальнейшем, проверка руководящей группой (IESG www.ietf.org/iesg). В случае успешного прохождения этих этапов черновик станет новым сетевым стандартом RFC (https://www.ietf.org/rfc.html).
Авторы: Александр Азимов, Евгений Богомазов, Рэнди Буш (Randy Bush, Internet Initiative Japan), Котикалапуди Шрирам (Kotikalapudi Sriram, US NIST) и Кейур Пател (Keyur Patel, Arrcus Inc.) осознают, что в индустрии есть острый спрос на предлагаемые изменения. Однако спешка в данном процессе также неприемлема, и авторы приложат максимум усилий, чтобы сделать предлагаемый стандарт удобным как для транснациональных операторов, так и небольших домашних сетей.
Мы благодарим технических специалистов, выразившим свою поддержку в рамках adoption call. При этом отдельная благодарность тем, кто не просто выразил свое мнение, но и прислал свои замечания. Мы постараемся учесть их при последующих изменениях данного черновика.
Мы также хотим донести до сведения заинтересованных инженеров, что у вас всё ещё есть возможность выразить собственные пожелания к внесению дополнений и уточнений через рассылку IETF (draft-ymbk-idr-bgp-open-policy@ietf.org) или на через сайт инициатив Qrator Labs.
Важно также отметить, что к моменту принятия финального решения у стандарта должно быть две рабочих реализации. Одна из них уже доступна — это наша разработка на базе раутингового демона Bird, доступная на Github: github.com/QratorLabs/bird. Мы приглашаем вендоров и open source сообщество присоединиться к данному процессу.
Автор: Qrator Labs
