Состояние сетевой безопасности в 2016 году, подробный отчёт Qrator Labs и Wallarm

[z3apa3a]

Для нейтрализации же потребуется канал шириной от 20 Гбит/с, возможность обрабатывать трафик прикладного уровня на полной пропускной способности соединения и расшифровывать все TLS-соединения в реальном времени

Атака со статических адресов и для блокировки должно быть достаточно блеклиста, а для построения блеклиста должно быть достаточно зарулить/дешифровать какой-нибудь небольшой процент соединений. Есть какая-то причина дешифровать весь трафик?
На самом деле, все еще интересней, в большинстве случаев можно обнаружить подозрительные узлы даже пассивно по используемому cypher suite, отличие от популярных браузеров будет весьма значительное.

[flx]

Владимир, в случае если ботовод с ярко выраженным синдромом дауна — можно еще и до SSL хэндшейка «отшить». А если нет?

И что именно с рандомными соединениями делать?
Полнота наблюдений определяет Качество фильтрации;
Рандомное покрытие — > рандомный результат.

[ximaera]

Есть какая-то причина дешифровать весь трафик?

Да. Проблема в том, что мы говорим не о защите какого-то одного конкретного сервиса, а о построении полноценной системы комплексной защиты, предоставляющей услуги фильтрации тем, кто к ней обратился. Это всё меняет.

Во-первых, какому-то одному конкретному сайту, вполне вероятно, достаточно настроить себе простую фильтрацию по cipher suite, плюс обезопасить себя от самых простых угроз (amplification, pingback) — то есть, от ковровых бомбардировщиков-вымогателей — и жить себе дальше. Но к системам по защите от атак обычно обращаются клиенты, у которых проблема не эпизодическая, она постоянная и носит характер, прошу прощения, advanced persistent threat.

Здесь уже нельзя ограничиться защитой от 80% популярных угроз (что, в полном соответствии с принципом Парето, займёт 20% сил), нужно быть готовым защитить клиента от всего, что может быть использовано целеустремлённым злоумышленником.

Это, кстати, как раз та стена, о которую, по моему опыту, разбиваются те же 80% попыток построить свой бизнес в защите от DDoS-атак (и у меня есть стойкое подозрение, что это можно экстраполировать на весь остальной ИБ-бизнес). Выглядит это обычно примерно следующим образом:

1. Вначале администратор некого хостинга сталкивается с пресловутой «ковровой бомбардировкой» в виде письма с угрозами одному из клиентов и «детской» атакой типа NTP Amplification мощностью 40 Гбит/с.
   
   Администратор решает эту проблему (в сотрудничестве с провайдером Интернет-доступа) оперативно и эффективно, после чего решает, что может теперь предоставлять услуги по защите от DDoS-атак всем желающим.
   
   
2. На сайте хостинга вывешивается реклама новой услуги по защите от DDoS-атак. Эта же реклама появляется в поисковой выдаче.
   
   
3. Спустя полгода-год эту рекламу находит в выдаче всерьёз страдающий от постоянных атак сайт, на который сделали дорогостоящий «заказ» конкуренты.
   
   
4. Сайт приходит, покупает услугу, через полдня на него привычно стартует вся королевская конница, с троекратной сменой используемого ботнета, модификацией тактик и прицельным ударом по вычислительно сложным компонентам сайта. От атак на одного клиента хостинга страдают все остальные клиенты, ряд из них уходит к конкурентам.
   
   
5. Через двое суток без сна, под неослабевающим давлением клиентского отдела, администратор не выдерживает, отказывает сайту в услугах и удаляет рекламу с сайта.

Во-вторых, и это не менее важно, система фильтрации атак должна быть готова не только к существующим методикам, но и к появлению новых. Уязвимые Wordpress-серверы, в основном, все переписаны и учтены, и, в самом деле, можно предзагрузить их список, но что будет делать система фильтрации, если аналогичная проблема появится в Joomla? А что делать с эволюцией IoT-ботнетов? Или с Android-ботнетами — не фильтровать же любую Android-ОС по cipher suite, да и IP-адреса мобильных телефонов никак не фиксированы.

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

[z3apa3a]

но что будет делать система фильтрации, если аналогичная проблема появится в Joomla?

Притворюсь, что не понял, что это риторический вопрос :)
Давайте я еще чтобы продемонстрировать мысль усложню задачу, и представим, что атака пошла сразу с миллиона джумл, чтобы дешифровать весь трафик не хватит никаких ресурсов и надо срочно спасать клиента. Именно в этом случае, я бы сделал примерно так: разграничил трафик от браузеров и от хостинговых сетей, можно по имеющимся IP-классификаторам, можно по сигнатурам TLS-хэндшейка, одного коннекта с одного IP хватает для классификации. В атаке участвует 1,000,000 джумл — для «грубой» классификации пропустим миллион коннектов от джумл прежде чем их грубо отфильтруем. Дальше трафик гарантированно не от джумл пропустил бы обычным путем, % грубо отфильтрованных коннектов на который хватает мощности пустил бы на дешифровку и анализ и состсавил черный список (с джумлами) / белый список (с false positive'ами «грубого» классификатора), остальные коннекты, на которые не хватает ресурсов просто пустил бы в блекхол. Да, зарежем на время людей с проксями на хостингах или возможно какие-то поисковики — и фик с ними. И так пока большая часть атаки не будет отфильтрована блеклистом. По мере роста блеклиста мощность атаки и процент коннектов, уходящих в блекхол будет снижаться, не думаю что потребуется больше нескольких минут, чтобы митигировать ее блеклистами до уровня, когда можно обработать весь трафик. Так что джумлы с вордпрессами не очень пугают, потому что можно быстро сделать грубый фильтр на пассивный трафик.
А вот IoT с Андроидами это очень страшно, да, потому что такое не прокатит.

[ximaera]

Именно в этом случае, я бы сделал примерно так: разграничил трафик от браузеров и от хостинговых сетей

… что тут же уничтожит бизнес B2B-клиентов: платёжные системы, СДБО, банкоматы, биржи, торги, бронирование билетов, регистрация на авиарейсы, облачная бухгалтерия, государственные электронные системы доступа к информации…

Всё остальное, написанное вами, в принципе, имеет смысл, но, если вы будете делать это вручную, это займёт очень много времени.

Вначале вам нужно будет проснуться, или дойти до офиса от метро, или приземлиться на самолёте, если вы в отпуске. Так как вы заранее не знаете, что нужно ловить именно Joomla, вам нужно будет вначале построить кластеры запросов и понять, на какой именно параметр запроса смотреть и что именно искать в User-Agent. И это в предположении, что гипотетическая уязвимость в Joomla, как и уязвимость в Wordpress, не позволяет формировать этот заголовок произвольным образом — а такое предположение чересчур оптимистично, поскольку все уязвимости разные. Таким образом, пропустить придётся куда больше миллиона соединений — в предположении, что у нас миллионный ботнет, это будет порядка 300 миллионов соединений в минуту. 300 миллионов пропущенных одновременных коннектов сами по себе отделают любой Windows Server, как Бог черепаху. Для восстановления работы потребуется перезагрузка.

А если строить автоматическую фильтрацию, то куда дешевле и эффективнее не размениваться на все частные случаи, а строить сразу общее решение проблемы.