[pavel.odintsov]

есть огромный шанс проморгать момент когда атака достигнет 2-4MPPS и все и вся умрет

вариант с парсером интересный, надо посмотреть. какой пакетсайз имеется ввиду при расчете 2-4Мппс кончится сеть ? этот парсер подключается линком в сумму всех внешних линков ? или самплируются пакеты для миррора ?

этой теме такое говорить просто стремно (намекаю про Брянск)

а что там в брянске ? резиновые линки ?

 

А в Брянске находится http://ddos-protection.ru, тем и знаменит :) Конкретно у нас на 2-4 mpps кончались роутеры на 100% загрузке, а не емкости каналов.

 

Парсер мы держим на миррор портах каждого из аплинков (они в свою очередь потом на уровне iptables собираются в одно место через ULOG), то есть несколько 10GE шнурков и несколько mirror групп. Зеркалирование идет 1 в 1, без сэмлирования какого-либо.

[pavel.odintsov]

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

 

Арендовать Дата Центры - задача крайне болезненная и затратная. Строить второй Cloud Flare у меня честно говоря денег нету :) А если атака идет с азии, например, то трафик все равно вольется ровным слоем по всем бордерам и не факт, что они даже при таком раскладе это выдержат.

 

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

[CNick]

нет способа отбиться от ддоса кроме выявление таргета и его блэкхола. т.е. ддос в любом случае будет успешен

Можно через BGP Flow Spec. Не знаю кто его поддерживает из провайдеров, надеюсь что все Tier 1, сейчас вот как раз стоит задача это чудо изучить и по возможности внедрить.

[DimaM]

Попробуйте СКАТ, благо оборудование для него у вас скорее всего уже есть и тест бесплатен.

Flood, DDOS атаки отфильтрует автоматичеки без вмешательства оператора.

[Дятел]

Павел, основная масса дающих советы просто не понимают о чем речь...

[DimaM]

Трудно понять учитывая микроскопическую мощность атак :)

 

>Встала задачка защитить веб-сервисы (http/https) в собственном ДЦ от DoS/DDoS атак довольно приличной мощности (несколько гигабит, до 500 000 pps)

[CNick]

но есть проблемы, что даже если пару гигабит долетит до linux бокса, который не был подготовлен должным образом и имеет гигабит в мир, то ему поплохеет.

Такая проблема есть не только в linux боксах, как показала практика балансировщика нагрузки таким как F5 тоже плохеет, если не от трафика и pps то от количества записей в таблице трансляции или соединений. Иногда даже небольшое количество трафика которое прошло через фильтрацию убивает CPU/RAM на них.

[denis_vid]

А предлагаемые решения позволяют защититься от актуального сегодня ntp DrDOS?

Или решение будет заключаться в "подождите, скоро для ntpd обновление выйдет"?)

Изменено 14 февраля, 2014 пользователем denis_vid

[myst]

А предлагаемые решения позволяют защититься от актуального сегодня ntp DrDOS?

Или решение будет заключаться в "подождите, скоро для ntpd обновление выйдет"?)

Любая анти-дидосилка это украшательства над фаерволом типа syn-proxy, что f5 что брокейд с джуном.

Если при внешнем канале 1 гигабит прилетает 1 гигабит паразитного трафика совершенно любая железка превращается в тыкву.

Хоть ты тресни.

 

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

[pavel.odintsov]

Попробуйте СКАТ, благо оборудование для него у вас скорее всего уже есть и тест бесплатен.

Flood, DDOS атаки отфильтрует автоматичеки без вмешательства оператора.

 

Если оно, то не вижу фичи защиты от DDoS http://vasexperts.ru/vas/index.php/site/products :(

 

но есть проблемы, что даже если пару гигабит долетит до linux бокса, который не был подготовлен должным образом и имеет гигабит в мир, то ему поплохеет.

Такая проблема есть не только в linux боксах, как показала практика балансировщика нагрузки таким как F5 тоже плохеет, если не от трафика и pps то от количества записей в таблице трансляции или соединений. Иногда даже небольшое количество трафика которое прошло через фильтрацию убивает CPU/RAM на них.

 

Еще conntrack из той же серии - отличный киллер любого линукса :( По внутри Дата Центра много и разного и почти любому плохеет даже от малости паразитного трафика, поэтому вот и думаем как отфильтровать лишнее минимальной ценой.

[zxz]

А как посчитали что 500 Kpps вам хватит? Это же и в один гигабит можно запихнуть.

[snark]

задачка защитить веб-сервисы (http/https) в собственном ДЦ от DoS/DDoS атак довольно приличной мощности (несколько гигабит, до 500 000 pps)

 

Запросите у циски SCE на тест (дают через ближайшего интригатора) и во время теста попросите связь с ТАС - сможете с тамошним инженером все обсудить.

Первое что пришло в голову: включаете SCE сабскрибер портом в интернеты (т.е. задом-наперед от оф. включения) и настраиваете анонимных сабскриберов, таким образом каждый уникальный IP в этих ваших интернетах будет вашим сабскрибером которого вы сможете не только по скорости ограничить, если захотите, но и повесить на него ограничение на кол-во сессий + возможно (не помню с какой строны работают) защиту от DDoS атак "изнутри" (если включить наоборот, то инет - это сторона сабскриберов).

 

 

никто так и не отписался толком о том, что защита действительно работает

 

Дык отписываться особо не о чем, т.к. большинство вырубает защиту дабы геймеры смогли спокойно задрачивать.

Из недавнего: внезапно канал примерно на час излишне нагружается, но т.к. все у всех работает (особых жалоб, исключая не печатающий принтер, нет), то замечается это только случаныйм взглядом на графики и разбор полетов показывает, что это не решение кого-то из юзеров выкачать все существующее гейпорно, а ничто иное как легкий DDoS (~3Гбит/с ~350Кппс), о котором SCE сообщила и который SCE благополучно тормознула не смотря на то, что защита от DDoS отключена, правда не полностью, т.к. sanity-checks я не трогал. В принципе все хорошо, но проблема с не печатающим "после того как вы подключили интернет" принтером так и осталась.

[pfexec]

А в Брянске находится http://ddos-protection.ru, тем и знаменит :) Конкретно у нас на 2-4 mpps кончались роутеры на 100% загрузке, а не емкости каналов.

2-4Mpps'а же копейки. я понимаю если речь идет о пакетсайзе, то возможно бэкбон можно забить (2-4Mpps пакетами по 1500 байт >50Gbps) и возможно не только бэкбон. Но насколько я могу судить по своему скромному опыту, 1500 пакетами ддос редок. dns/ntp-amplification на выходе не даст пакетсайз в 1500, а udp spoofing'ом быстро не разогнаться. вобщем реальная опасность - это кончина пропускной способности на мой взгляд.

100% загрузки, я так понимаю в качестве рутиров писюки с тазиком торвальца ? ну там, да, кроме пропускной способности еще и пакетрейт может всё убить.

Парсер мы держим на миррор портах каждого из аплинков (они в свою очередь потом на уровне iptables собираются в одно место через ULOG), то есть несколько 10GE шнурков и несколько mirror групп. Зеркалирование идет 1 в 1, без сэмлирования какого-либо.

мне кажется вот это всё черезчур раздутая инфраструктура. впрочем кто знает, может я не прав.

Можно через BGP Flow Spec. Не знаю кто его поддерживает из провайдеров, надеюсь что все Tier 1, сейчас вот как раз стоит задача это чудо изучить и по возможности внедрить.

тирванам это всё не интересно. им и блэкхолы не интересны. трафик - это бабло, никто не будет жрать трафик, утилизировать транспорт, но не продавать его. обычная политика тирвана: принимать специфики /32 с блэкхол комунити в ограниченом количестве. т.е. загнать в блэкхол /24 уже проблема, надо общаться с саппортом. да и "по-умолчанию", зачастую приём комунитей выклюжчено у них или требуется организовать отдельную сессию. вобщем там не всё так радужно и ни о каком flowspec'е не приходится мечтать.

[darkagent]

вобщем реальная опасность - это кончина пропускной способности на мой взгляд.

Хотя бы пару лет назад - да, а сейчас не очень актуально. У некоторых транспортная труба уже за сотку гигабит переваливает. Другое дело, что при таком pps уже уводит маршрутизаторы в потолок, что в свою очередь чревато отвалом протоколов/сессий, и в итоге труба есть, а использовать ее становится не шибко возможно. Вот для таких случаев и приходится продумывать железный комплекс, через который проключается каждый аплинковый порт, и весь этот комплекс на уровне кластера вырезает паразита по всем фронтам.

[pfexec]

Другое дело, что при таком pps уже уводит маршрутизаторы в потолок, что в свою очередь чревато отвалом протоколов/сессий, и в итоге труба есть, а использовать ее становится не шибко возможно.

ват ? MX80 55Mpps через себя может молотить. А числа у "больших" собратьев гораздо более впечатляющие. DDoS в 50Mpps пакетами по >1000 байт кончит 100 гигабитную трубу не напрягаясь. проблемы пакетрейта заботят лишь мастеров линагз-рутинга. всем остальным надо переживать за бэкбон, - он же не всегда > суммы физической емкости всех внешних линков. не зря тот же клаудфаре пишет именно про емкость атаки, а не про пакетрейт: http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack

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

ванильные фантазии продаванов об идеальном вакууме.

по достижению определенной отметки на дерьмометре никакие комплексы не спасут от атаки. :) а мелоч (syn-flood и т.п.) можно давить чуть ли не средствами фаервола самого сервера.

 

не, желание поставить железку и предоставить клиентам сервис по блокировке вредного synflood'а - это норм идея. но не ставить же это на границе в разрыве между ISP и бордером.

Изменено 15 февраля, 2014 пользователем pfexec

[JoeDoe]

Такое ощущение, что многие написавшие в топик действительно не представляют о чем идет речь.

Другое дело, каков бюджет для решения таких задач?!

Вот проверенное профессиональное решение: Arbor TMS

Основано на эвристическом анализе netflow информации. Может и фильтровать чистый от грязного траффика.

Масштабируется до 4 Tbps mitigation. Есть у них различные коробки для анализа и "очистки" траффика - смотрите по ссылке.

Но вот только лучше чтоб сеть ваша была на Cisco CRS или Alcatel-Lucent 7750 - тогда Arbor занимается анализом, а "очистка" происходит прямо на пограничных рутерах. Решение используют многие Tier 1 операторы.

Изменено 15 февраля, 2014 пользователем JoeDoe

[applx]

Такое ощущение, что многие написавшие в топик действительно не представляют о чем идет речь.

Другое дело, каков бюджет для решения таких задач?!

Вот проверенное профессиональное решение: Arbor TMS

Основано на эвристическом анализе netflow информации. Может и фильтровать чистый от грязного траффика.

Масштабируется до 4 Tbps mitigation. Есть у них различные коробки для анализа и "очистки" траффика - смотрите по ссылке.

Но вот только лучше чтоб сеть ваша была на Cisco CRS или Alcatel-Lucent 7750 - тогда Arbor занимается анализом, а "очистка" происходит прямо на пограничных рутерах. Решение используют многие Tier 1 операторы.

 

это решение работает в больших сетях как вы сами сказали тир 1, у ТС в примере ЦОД, если на него льетца 1Г говяного траффика то никакой ДДоС митигэшн не поможет если апстрим не дропает этот самый траффик или не использует этот же самый Арбор. как только в "трубу" попал траффик он её забивает и смысл от того что вы его дропайте нет так как он уже у вас...

[denis_vid]

это решение работает в больших сетях как вы сами сказали тир 1, у ТС в примере ЦОД, если на него льетца 1Г говяного траффика то никакой ДДоС митигэшн не поможет если апстрим не дропает этот самый траффик или не использует этот же самый Арбор. как только в "трубу" попал траффик он её забивает и смысл от того что вы его дропайте нет так как он уже у вас...

+1

Повторю к "знающим" вопрос, может я чего не понимаю, но как они собираются фильтровать "чудо-железками от ддоса" udp поток шириной в канал, который уже здесь?

[Дятел]

Задачу читать пробовали? Первый пост...

[CNick]

+1

Повторю к "знающим" вопрос, может я чего не понимаю, но как они собираются фильтровать "чудо-железками от ддоса" udp поток шириной в канал, который уже здесь?

Повторю еще раз https://tools.ietf.org/html/rfc5575

[applx]

Pokajite isp kotorui bydet soglasen piritsa sledyya dannomy rfc

[pfexec]

Можно через BGP Flow Spec. Не знаю кто его поддерживает из провайдеров, надеюсь что все Tier 1, сейчас вот как раз стоит задача это чудо изучить и по возможности внедрить.

тирванам это всё не интересно. им и блэкхолы не интересны. трафик - это бабло, никто не будет жрать трафик, утилизировать транспорт, но не продавать его. обычная политика тирвана: принимать специфики /32 с блэкхол комунити в ограниченом количестве. т.е. загнать в блэкхол /24 уже проблема, надо общаться с саппортом. да и "по-умолчанию", зачастую приём комунитей выклюжчено у них или требуется организовать отдельную сессию. вобщем там не всё так радужно и ни о каком flowspec'е не приходится мечтать.

Повторю еще раз https://tools.ietf.org/html/rfc5575

сколько раз еще повторить что тирванам (и любым другим ISP тем более) нет интереса принимать трафик и не получать за него денег ?

Изменено 16 февраля, 2014 пользователем pfexec

[zi_rus]

сколько раз еще повторить что тирванам (и любым другим ISP тем более) нет интереса принимать трафик и не получать за него денег ?

те кто здесь отписались это клиенты, они выразили свое желание, эта возможность это доп услуга и конкурентное преимущество при прочих равных.

 

это так, навскидку. что это может дать самому ISP пока не вижу, надо RFC почитать

[pfexec]

это так, навскидку. что это может дать самому ISP пока не вижу, надо RFC почитать

суть flowspec'а в отправлении по bgp каких-то политик фильтрации или рейтлимита своему соседу. отличная технология, мне нравится. но применительно к сабжекту не интересна для ISP, т.к. внезапно оказывается что ISP занимается "защитой" от DDoS'а. ему за это никто не платит, он загружает трафиком свою сеть или ее границу -> ему это не интересно.

блэкхол - это компромис между ISP и кастомером. дропаем весь трафик на таргет и рассказываем своим апстримам и пир-партнерам делать так же -> отбились от ddos'а малой кровью недоступности лишь таргета атаки, а не всей сети где этот таргет расположен. другого тут не будет.

[CNick]

сколько раз еще повторить что тирванам (и любым другим ISP тем более) нет интереса принимать трафик и не получать за него денег ?

Зато им интересно что бы клиент не ушел к другому провайдеру у которых эта услуга есть. По поводу принимать или нет, во время атаки он в любом случаи принимать его будет, в не зависимости есть у него flowspec или нет, просто если есть он его кастомеру не отправит. Так что для них это просто еще один сервис который выгодно отличает их перед теми операторами у которых его нет.

 

И еще один момент, у тирванов нету трафика который им не выгоден. Даже DOS атака это трафик который идет от операторов ниже за который эти самые операторы им платят.