Комментарии 57
На какой бюджет рассчитано ваше решение?
И зачем городить BGP? Не проще ли поставить несколько прокси за фаерволом(фаерволами) и за ними (логически) бэкенд?
И что нового в вашей технологии? Или вы предлагаете geo-распределенную защиту?
Пограничный роутер не нужен, достаточно VHRP или даже RR-DNS.
И зачем городить BGP? Не проще ли поставить несколько прокси за фаерволом(фаерволами) и за ними (логически) бэкенд?
И что нового в вашей технологии? Или вы предлагаете geo-распределенную защиту?
Пограничный роутер не нужен, достаточно VHRP или даже RR-DNS.
Да уж, к сожалению, это далеко не всем подойдет — денег просто у многих не хватит на такое… :(
Это решение не для одного сайта, а для хостинг-компании (либо очень крупного сервиса).
Если надо защищать один сайт, то лучше не самостоятельно строить такие решения, а купить как сервис.
К примеру, у нас на stop-ddos.net защита одного сайта будет стоить от 250 до 1000 $ в месяц.
К тому-же, мы, в отличие от зарубежных компаний-хостеров, очень либерально относимся к контенту наших клиентов.
Если надо защищать один сайт, то лучше не самостоятельно строить такие решения, а купить как сервис.
К примеру, у нас на stop-ddos.net защита одного сайта будет стоить от 250 до 1000 $ в месяц.
К тому-же, мы, в отличие от зарубежных компаний-хостеров, очень либерально относимся к контенту наших клиентов.
В данном случае защита териториально находится в одном месте.
BGP выбрана по той причине, что когда один из прокси станет недоступным, на него перестанут поступать запросы. BGP в данном случае используется только всередине кластера и может быть построен на серых адресах и серых ASN.
Прокси нельзя поставить просто за файрволами, так как файрвол, в отличии от роутера, обычно не умеет Per Packet Load Balancing, необходимый для балансировки: грубо говоря, на всех серверах стоит один и тот же адрес (как показано на схеме); именно на этот адрес и направлен атакуемый домен, а если не использовать Per Packet, то могут рваться TCP сессии (да и разделение запросов будет неравномерным).
Балансировка нужна только для того, чтоб равномерно распределить запросы между прокси, так как при серьезной атаке даже самый мощный сервер не справится.
BGP выбрана по той причине, что когда один из прокси станет недоступным, на него перестанут поступать запросы. BGP в данном случае используется только всередине кластера и может быть построен на серых адресах и серых ASN.
Прокси нельзя поставить просто за файрволами, так как файрвол, в отличии от роутера, обычно не умеет Per Packet Load Balancing, необходимый для балансировки: грубо говоря, на всех серверах стоит один и тот же адрес (как показано на схеме); именно на этот адрес и направлен атакуемый домен, а если не использовать Per Packet, то могут рваться TCP сессии (да и разделение запросов будет неравномерным).
Балансировка нужна только для того, чтоб равномерно распределить запросы между прокси, так как при серьезной атаке даже самый мощный сервер не справится.
«BGP выбрана по той причине, что когда один из прокси станет недоступным, на него перестанут поступать запросы.»
Круто! А вы на дачу тоже на БелАЗе ездите?
«так как при серьезной атаке даже самый мощный сервер не справится.»
Серьезная атака это сколько одновременных запросов? И что в вашем понимании «самый мощный сервер»?
Круто! А вы на дачу тоже на БелАЗе ездите?
«так как при серьезной атаке даже самый мощный сервер не справится.»
Серьезная атака это сколько одновременных запросов? И что в вашем понимании «самый мощный сервер»?
Решение сделано для хостинг-компании, которая специализируется на защите от DDoS, и одновременно обслуживает многих клиентов. На некоторых клиентов атаки длятся неделями.
Несколько примеров из личного опыта:
Сайт по продаже авиабилетов, атака длилось 2 недели, 8Gbps обычного флуда.
На другие сайты случалось и 500 000 pps SYN-флуда и 100 000 GET запросов в секунду.
На вопрос о мощном сервере:
Один 8-ядерный ксеон 55-ой серии держит, в среднем, 30 000 GET запросов в секунду.
Использование более дорогих сервером нерационально, так как проще делать балансировку на несколько серверов с оптимальным соотношением производительность/цена.
Несколько примеров из личного опыта:
Сайт по продаже авиабилетов, атака длилось 2 недели, 8Gbps обычного флуда.
На другие сайты случалось и 500 000 pps SYN-флуда и 100 000 GET запросов в секунду.
На вопрос о мощном сервере:
Один 8-ядерный ксеон 55-ой серии держит, в среднем, 30 000 GET запросов в секунду.
Использование более дорогих сервером нерационально, так как проще делать балансировку на несколько серверов с оптимальным соотношением производительность/цена.
За что минус? Что никто не слышал про WCCP, CARP, VHRP и пр.? BGP не для этих целей разрабатывался.
VRRP вместо VHRP.
BGP вполне себе тут оправдан.
CARP и VRRP не получится так легко сделать балансировку. WCCP тут тоже неподходит т.к. им нельзя в этом месте подниматься до прикладного уровня — ресурсов нехватит. да и неудобно это — это же все-таки услуги связи.
BGP вполне себе тут оправдан.
CARP и VRRP не получится так легко сделать балансировку. WCCP тут тоже неподходит т.к. им нельзя в этом месте подниматься до прикладного уровня — ресурсов нехватит. да и неудобно это — это же все-таки услуги связи.
для этих целей его тоже можно применять.
но, зачем забивать гвозди кувалдой, если есть молоток?
но, зачем забивать гвозди кувалдой, если есть молоток?
В этой ситуации разумнее было бы использовать LACP с балансировкой по ip-адесам, или CARP.
как связана аггрегация ethernet и ip?
вы думаете они bsd для маршрутизации используют?
вы думаете они bsd для маршрутизации используют?
LACP (а его в данной ситуациии только для агрегации линков использовать можно, так как при отказе сервера линк скорее всего не погаснет) тут вообще не к месту, одного гигабита вполне хватает, один сервер все-равно не выдержит больше гигабита HTTP флуда (в GET запросах это фантастическая цифра).
CARP тоже не совсем то — мы ведь балансировку делаем, а не failover.
В этой схеме BGP (хоть его и придумали для других целей) самое оптимальное средство.
CARP тоже не совсем то — мы ведь балансировку делаем, а не failover.
В этой схеме BGP (хоть его и придумали для других целей) самое оптимальное средство.
система бестолковая:
есть единая точка отказа
не предусмотрено различные правила для разных регионов
за ддосить могу обойдя защиту
есть единая точка отказа
не предусмотрено различные правила для разных регионов
за ддосить могу обойдя защиту
В идеале несколько роутеров с BGP на границе (разумеется в разных ЦОДах), анонсирующие одну и ту-же сеть + несколько прокси за ними. На выходе получаем защиту от DDoS + CDN =) И можно продавать один и тот-же функционал как две разные услуги. А топик действительно «неочем». Если кто-то использует данную схему защиты в продакшене то мне его жаль.
Смысла рамещения в разных ЦОД нет, если есть канал достаточной ширины в одном ЦОД.
А у вас есть какой-нибудь SLA с вашими клиентами, которых вы от DDoS защищаете?
SLA высылается клиенту вместе со счетом на оплату (PayPal), после того как клиент был удоволетворен бесплатной защиты от первого случая DDoS.
В случае, если downtime превысит 4 часа в квартал, мы компенсируем затраты, из расчета
1 час downtime = 1 сутки бесплатного сервиса.
В случае, если downtime превысит 4 часа в квартал, мы компенсируем затраты, из расчета
1 час downtime = 1 сутки бесплатного сервиса.
не предусмотрено различные правила для разных регионов
Что Вы имеете ввиду?
за ддосить могу обойдя защиту
Каким образом, если Вы не сможете узнать реальный адреса бекенда?
Достаточно положить ваш фаерволл и/или пограничный роутер =)
Заддосить роутер с пропускной способностью 500 000 000 pps (типа Juniper MX 480) нереально :)
По поводу файрволов:
Заддосить один Juniper SRX 5800 возможно, но не кластер из нескольких такий файрволов.
По поводу файрволов:
Заддосить один Juniper SRX 5800 возможно, но не кластер из нескольких такий файрволов.
Вы тут говорите о 20 гигабитных каналах и о кластере из железок по 70к. Но сайт с дешевым дизайном у вас зарегистрирован на часное лицо да и сервер на котором оно крутится стоит в ЦОДе Укртелекома.
Забавно все это =)
Забавно все это =)
Оборудование взято в аренду. Система действительно размещена в датацентре Укртелекома — на текущий момент это провайдер с достаточно широкими аплинками (более 100Gbps) чтобы не быть уязвимым практически перед любой атакой.
Изначально схема разрабатывалась под нескольких крупных клиентов. Сайт был открыть недавно, чтобы начать расширять клиентскую базу.
Мы очень благодарны Вам за грамотные комментарии, вызванные безусловно, Вашим неподдельным интересом к затронутой тематике, видно, что Вы хорошо разбираетесь в сетевых технологиях.
Если Вам интересно, быдем рады пообщаться через ЛС, или по скайпу :)
Изначально схема разрабатывалась под нескольких крупных клиентов. Сайт был открыть недавно, чтобы начать расширять клиентскую базу.
Мы очень благодарны Вам за грамотные комментарии, вызванные безусловно, Вашим неподдельным интересом к затронутой тематике, видно, что Вы хорошо разбираетесь в сетевых технологиях.
Если Вам интересно, быдем рады пообщаться через ЛС, или по скайпу :)
Сегодня был топик про успешные топики. Кажется, там было что-то про доступный язык.
антивирус жалуется на яваскрипт инфекцию на сайте вашего друга и блокирует его
Как я понимаю отсеканием хитроботов занимается реверс-прокси? Тогда мне кажется что при достаточно грамотном ддосе вся нагрузка пойдет на проки, а вот тут уже непонятно сколько их должно быть чтобы выдержать большой поток трафика.
а вы что в качестве statefull firewall используете? SRX5800?
НЛО прилетело и опубликовало эту надпись здесь
Надо бы еще дать возможность анализатору ботов банить их по IP на уровне фаерволла где то снаружи, а то они все равно будут коннектиться (+ надо поддерживать лимит на число коннектов с 1 IP, а то одной машиной все зафлудят).
А вообще, защитой от DDoS должен защищаться хостер, ему проще, всех сразу защищать.
А вообще, защитой от DDoS должен защищаться хостер, ему проще, всех сразу защищать.
Число коннектов режется на statefull файрволе.
Банить ботов снаружи не имеет смысла, так как при ботнете в несколько тысяч хостов мы процессом бана снаружи сильно нагрузим роутер (ведь процессор для апи не такой мощный как процессоры на routing engine и forwarding engine), да и сам процесс бана займет уймы времени.
Проще это делать на файрволе самих прокси.
По поводу хостеров:
Большинство хостеров в наше время так демпингуют ценами, что на защиту у них просто не остается средств. А те что посерьезнее, хоть и защищают, но не будут терпеть клиентов на которых атака валится несколько недель (в таких случаях либо просто отказывают, либо ломят цены повыше чем у нас).
Банить ботов снаружи не имеет смысла, так как при ботнете в несколько тысяч хостов мы процессом бана снаружи сильно нагрузим роутер (ведь процессор для апи не такой мощный как процессоры на routing engine и forwarding engine), да и сам процесс бана займет уймы времени.
Проще это делать на файрволе самих прокси.
По поводу хостеров:
Большинство хостеров в наше время так демпингуют ценами, что на защиту у них просто не остается средств. А те что посерьезнее, хоть и защищают, но не будут терпеть клиентов на которых атака валится несколько недель (в таких случаях либо просто отказывают, либо ломят цены повыше чем у нас).
Мне кажется стоит определиться в том, кого Вы собираетесь защищать таким оборудованием.
Если говорить о себестоимости, то все эти вещи стоят не на одну сотню евро, каждая плата на 10ГБит в тех же Juniper кусается очень существенно.
Если же говорить об уязвимостях, я по личному опыту порекомендую думать об уводе атаки в разные стороны на основе гео-кластеризации, тем самым снимая нагрузку по каналам и с ресурсов серверов. Если говорить о BGP, обычного банального prepend еще никто не отменял. Ставьте в нескольких местах детекторы/директоры нагрузки на дешевых машинах но где много памяти и хорошие перепрошитые сетевые карточки (да, существуют особые прошивки, увеличивающие pps на уровне железа, взять хотя бы опыт компании Crossbeam с их Х-серией), займитесь вопросами синхронизации данных между местами, где стоят «ноды» такого гео-кластера, и потом сядьте и посчитайте — Вы будете удивлены, но по расходам это все будет стоить примерно 1/10 часть того варианта, который описали выше.
Если интересно более подробно, см. профиль и пишите в личку.
Если говорить о себестоимости, то все эти вещи стоят не на одну сотню евро, каждая плата на 10ГБит в тех же Juniper кусается очень существенно.
Если же говорить об уязвимостях, я по личному опыту порекомендую думать об уводе атаки в разные стороны на основе гео-кластеризации, тем самым снимая нагрузку по каналам и с ресурсов серверов. Если говорить о BGP, обычного банального prepend еще никто не отменял. Ставьте в нескольких местах детекторы/директоры нагрузки на дешевых машинах но где много памяти и хорошие перепрошитые сетевые карточки (да, существуют особые прошивки, увеличивающие pps на уровне железа, взять хотя бы опыт компании Crossbeam с их Х-серией), займитесь вопросами синхронизации данных между местами, где стоят «ноды» такого гео-кластера, и потом сядьте и посчитайте — Вы будете удивлены, но по расходам это все будет стоить примерно 1/10 часть того варианта, который описали выше.
Если интересно более подробно, см. профиль и пишите в личку.
Спасибо.
Описанными технологиями мы отлично владеем и Вы тоже правы — при защите одного крупного ресурса, описанная Вами технология действительно дешевле и дает хороший результат, однако такую защиту нужно строить под конкретный ресурс.
Если атака ведется не с кучки хилых зомби-хостов :), а намеренно запущена на мощных серверах, тогда возможен вариант что 200 000 (а то и до 1 000 000, если хостер атакующего закроет глаза) pps SYN флуда пойдут на одну точку геораспределенного кластера, так как будут иметь одинаковую политику маршрутизации.
Есть еще пачка мелких граблей которые вылазят при построении универсальной защиты, и эти грабли потребуют большого количества человекочасов работы и уменьшения качества сервиса.
Описанными технологиями мы отлично владеем и Вы тоже правы — при защите одного крупного ресурса, описанная Вами технология действительно дешевле и дает хороший результат, однако такую защиту нужно строить под конкретный ресурс.
Если атака ведется не с кучки хилых зомби-хостов :), а намеренно запущена на мощных серверах, тогда возможен вариант что 200 000 (а то и до 1 000 000, если хостер атакующего закроет глаза) pps SYN флуда пойдут на одну точку геораспределенного кластера, так как будут иметь одинаковую политику маршрутизации.
Есть еще пачка мелких граблей которые вылазят при построении универсальной защиты, и эти грабли потребуют большого количества человекочасов работы и уменьшения качества сервиса.
SYN flood не пойдет на одну точку геораспределенного трафика, т.к. директор/детектор не даст этого сделать, он отслеживает количество пакетов на ту или иную ноду и сделает равномерную балансировку нагрузки между всеми нодами.
Насчет человекочасов косвенно согласен, но они скорее имеют место быть при создании и тюнинге подобной системы, дальше все происходит полностью автоматически.
Насчет человекочасов косвенно согласен, но они скорее имеют место быть при создании и тюнинге подобной системы, дальше все происходит полностью автоматически.
Не совсем понятно.
К примеру, идет атака с одного сервера. На всех роутерах по пути пакетов не включен мултипас (то есть у них в таблице маршрутизации всего один активный маршрут к вашему адресу), соответственно все пакеты прийдут в одну точку. Этой точкой будет ваш роутер. Далее единственным способом перенаправить часть этих пакетов на территориально отдаленную ноду будет пробрасывать трафик через какой-нибудь GRE, тем самым лишний раз нагружать оборудование и канал. Вы именно это имели ввиду?
К примеру, идет атака с одного сервера. На всех роутерах по пути пакетов не включен мултипас (то есть у них в таблице маршрутизации всего один активный маршрут к вашему адресу), соответственно все пакеты прийдут в одну точку. Этой точкой будет ваш роутер. Далее единственным способом перенаправить часть этих пакетов на территориально отдаленную ноду будет пробрасывать трафик через какой-нибудь GRE, тем самым лишний раз нагружать оборудование и канал. Вы именно это имели ввиду?
Извините за неосведомленность, а «гео-кластеризация» это принцип CDN — Content Delivery Network — когда сервера разнесены в разных точках мира поближе к предполагаемому клиенту?
Такое возможно теоретически, но мы не используем данную методику из-за проблем с рассинхронизацией в базах данных которая произойдет если директор/детектор видит все ноды кластера, но при этом ноды потеряли контакт между собой (т.е. фактически клиент в США записал что-то в ноду, которая ближе к нему, а клиент в России записал в ноду которая ближе к нему, в результате когда линк поднимается мы наступаем на грабли идентичных индексов в базе данных, и критериев какой из них более новый/верный здесь не хватает, особенно если записи сделаны одновременно). Посему вариант с детекцией по ближе-дальше мы отменили, и используем только лишь вариант доступен/недоступен и принудительно делаем распределение трафика исходя из нагрузки на трафик по каждой ноды а также по нагрузке по ресурсам на каждую ноду.
Стандартные инструменты разложии по полочкам с одной точкой входа. Для 90% сайтов самые актуальные аспекты защиты как раз в том сегменте, который автор сочно описал «прокси-сервер, способный отличить бота от настоящего клиента». Как по мне такая централизованная схема помимо высокой стоимости имеет ещё одну проблему — вся нагрузка от атаки концентрируется с точки зрения канала в одной точке, это значит что атакуемый будет либо очень много платить датацентру за канал (было бы весьма интересно услышать почём нынче 10G в приличном ДЦ) либо иметь массу проблем с площадкой. Если уже обсуждать решение с такой стоимостью владения хочется видеть каналы обратной связи — ведь атакующего иногда нельзя определить на фильтре а можно только на бекенде, соответсвенно сервер должен уметь оповещать фильтр о проблемах. Также не хватает на мой взгляд средства связи с канальными операторами — 10G полагаю подразумевает наличие нескольки кериеров и IP идентифицированные как реальные и атакующие нужно как-то им сообщать чтобы блокировть трафик ещё до того как вам за него надо платить. Ну и остаётся открытым вопрос HTTP флуда в режиме эмуляции клиента, когда нету сотен тысяч коннектов а есть скажем 20к ботов который честно лазит по сайту, редкий бекенд (если говорить о простых сайтах а не крупных сервисах) выдержит 20к одновременных клиентов — делает защиту совершенно бесполезной — если модули фильтрации сетей и есть то из схемы этого не видно, а фильтрация по гео- и сервис-кодам всё ещё очень эффективна для скрытых HTTP атак
По поводу флуда с эмуляцией клиента:
Честно говоря, не встречал ни одного бота, который бы умел подгружать куки, js, css и картинки. На данный момент, признаков, по которым фронтенд может отличить бота от небота достаточно, была бы фантазия.
Наши методы распознавания ботов не могу опубликовать, тут уж извините, коммерческая тайна.
Если кто-то сделает ботнет из 20 000 нод, которые смогут полностью эмулировать браузер, то жертве придется создавать собственный кластер для бекенда и оптимизировать код, генерить кучу статики — это будет уже скорее высоконагруженная, нежели DDoS устойчивая система.
Честно говоря, не встречал ни одного бота, который бы умел подгружать куки, js, css и картинки. На данный момент, признаков, по которым фронтенд может отличить бота от небота достаточно, была бы фантазия.
Наши методы распознавания ботов не могу опубликовать, тут уж извините, коммерческая тайна.
Если кто-то сделает ботнет из 20 000 нод, которые смогут полностью эмулировать браузер, то жертве придется создавать собственный кластер для бекенда и оптимизировать код, генерить кучу статики — это будет уже скорее высоконагруженная, нежели DDoS устойчивая система.
Чтобы определять бота через CSS/JS/куки/картинки/невидимые формы/флеш и прочее нужны соответствующие модули на бекенде или Вы предлагаете набор стандартных ловушек которые можно имплементировать на Ваших реверс проксях фильтрующих? Что касается ботов то тут большой проблемы нет, используются настоящие браузеры, они только автоматизируются. Это не проблема антиддос системы, это просто способ атаки от которого она в виду отсутствия ряда интерфейсов не защищает, что жаль для системы с TCO в пару сотен тысяч USD
Я верно понял что рабочая моджель описанной системы у Вас развёрнута и работает на мощностях УкрТелекома?
Я верно понял что рабочая моджель описанной системы у Вас развёрнута и работает на мощностях УкрТелекома?
А это только теория?
Есть ли «история успеха», подтверждающая эти идеи? Описание каких-то подводных камней?
Есть ли «история успеха», подтверждающая эти идеи? Описание каких-то подводных камней?
Система рабочая, выше в комментах уже писал о том, атаки какого уровня она выдерживает.
В самой схеме, если ее четко придерживаться, подводных камней нет. А вот в конфигах фронтендов их куча. Самый большой камень — проблемы с поисковиками. Поисковики — тоже боты (и очень глупые, умеют только посылать GET запрос), полный список их адресов все время обновляется и, практически, нигде не выкладывается (в интернете можно найти много списков, но поверьте, они далеко не полные).
Отличать их по соответствию прямому проеобразованию бекрезолва адреса бота достаточно проблематично, когда на вас приходит 50 000 гуглботов. Приходится для ботов поисковиков вести отдельный набор правил (отличаем потенциальные поисковики по юзераджентам): например, если одновременно на ноде обнаруживаем больше 3 гуглботов, срабатывает правило, которое отменяет исключения для поисковиков и любые боты начинают баниться. Дальше, как только скрипт по крону увидит окончание атаки (из аксеслога на фронтенде), исключение для поисковиков возвращается обратно. Но вместе с данной схемой еще нужно использовать онлайн списки адресов поисковых ботов, и такие адреса сразу пропускать на бэкенд, даже не записывая в аксеслог. Мы сами активно работает над этим вопросом.
В самой схеме, если ее четко придерживаться, подводных камней нет. А вот в конфигах фронтендов их куча. Самый большой камень — проблемы с поисковиками. Поисковики — тоже боты (и очень глупые, умеют только посылать GET запрос), полный список их адресов все время обновляется и, практически, нигде не выкладывается (в интернете можно найти много списков, но поверьте, они далеко не полные).
Отличать их по соответствию прямому проеобразованию бекрезолва адреса бота достаточно проблематично, когда на вас приходит 50 000 гуглботов. Приходится для ботов поисковиков вести отдельный набор правил (отличаем потенциальные поисковики по юзераджентам): например, если одновременно на ноде обнаруживаем больше 3 гуглботов, срабатывает правило, которое отменяет исключения для поисковиков и любые боты начинают баниться. Дальше, как только скрипт по крону увидит окончание атаки (из аксеслога на фронтенде), исключение для поисковиков возвращается обратно. Но вместе с данной схемой еще нужно использовать онлайн списки адресов поисковых ботов, и такие адреса сразу пропускать на бэкенд, даже не записывая в аксеслог. Мы сами активно работает над этим вопросом.
Защита от атак становится серьезной головной болью провайдеров, надеюсь, они и будут предлагать в ближ будущем решения такого уровня
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Строим кластерную систему защиты от DDoS