Комментарии 13
Можно профильный вопрос - можете озвучить почему вы бессильны переда такими атаками и Ваши клиенты вынуждены страдать.
Отвечу за большинство Банков. Потому что сейчас им предписано использовать отечественные AntiDDoS сервисы. А они обычно справляются только с типовыми атаками. Только крупные банки могут себе позволить строить собственную AntoDDoS защиту без использования сторонних сервисов.
А вообще самое лучшее везде где нет необходимости взаимодействия с вне (с доступом из Интернет) использовать выделенные каналы (что дороже построения AntoDDoS).
Жду туториал как самостоятельно крупному банку построить собственную антидудос систему, без регистрации и смс
За банк сам туториал никто не напишет. В банке есть компетентная команда, которая способна не только выполнять действия по туториалам, а и самим их писать. Есть ресурсы, как материальные, так и человеческие. Есть возможность нанять интеграторов и через несколько итераций достигнуть своей цели.
Ну хотя бы пару паттернов накидайте, а то сами рожей не вышли...
Есть возможность нанять интеграторов
Так всё таки сами или не сами?
Сами. Всякие ПАКи бесполезны. Любая Cisco ASA делает все то же самое, встроенными механизмами и установкой лимитов. Лучше использовать автономные системы, желательно геораспределенные (благо страна позволяет), естественно с разными провайдерами и объединенная выделенными каналами (не через Интеренет). Если клиенты их РФ, то внезапно частисно помогает использование НСДИ. Если зарубежные (в том числе ближние), тот тут можно разгуляться по полной. Тот же 1.1.1.1 в бесплатном тарифе превосходит отчечественные услуги AntiDDoS с лихвой. Ну и изначально закладывать архитектуру защищаемой системы с учетом высокой доступности, уменьшив до минимума точки отказа, где это только возможно.
А универсального рецепта нет. Обычно ИБ нужно подстраиваться под архитектуру защищаемой системы. Но если убытки от DDoS будут больше, чем перестроить систему, то флаг Вам в руки!
А что делать с сервисами, которые должны быть доступны из сети интернет, и когда канал, по которому они предоставляются, заваливают SSL хэндшейками
Самостоятельно силами условной компании K?
Ну если поток трафика больше, чем толщина канала, то просто принять трафик не получится. Потому что мусорный трафик выдавит полезный, качество работы деградирует в любом случае. Вне зависимости от того, tls там, или что-то иное. Этот момент многие забывают почему-то. С другой стороны, если есть понимание, откуда такой мусор идёт (например, понятно, что мусор, и это логируется в виде ip, либо с определённых AS/префиксов), то можно попытаться поговорить со своим провайдером, чтобы он это на своей стороне подропал. Ему, провайдеру, в целом, тоже незачем передавать по своим сетям мусор, да и ёмкости у него больше, чем на канале последней мили. Т.е. дропается там, а к клиенту доходит уже подчищенный трафик. С частью провайдеров о таком договориться можно, даже в моменте.
Если поток мусора всё же помещается в канал, полоса для полезного трафика остаётся достаточной, то тут могут быть варианты. Из первого и очевидного - если есть логи, скармливать проблемные ip фаерволам/fail2ban. Но тут оборудование должно быть достаточной производительности, чтобы вывозить первичные пачки tls мусора. Эта штука по CPU действительно может перегрузить системы. Вторая мысль, что приходит в голову - подключить к своим фаерволам какую-нибудь базу репутации ip. Общая мысль тут - отсечь вредоносные tls хэндшейки и не обрабатывать их в принципе. Так сильно дешевле по ресурсам, если главная задача состоит в том, чтобы всё сделать своими силами. Возможны фолзы в срабатывании/не срабатывании, но разобраться с проблемными единичными юзерами после такого - это сильно проще, чем разбираться с проблемами вообще всех своих клиентов. Но надо помнить, что DDoS-атака в немалой степени - это ещё и про цену её реализации. И цена эта, судя по тому, что вижу прямо сейчас в гугле, дешевле цены гигабитного интернета в офис. Это если атака коммерчески мотивирована. А если не коммерчески - тем более. Так что переутилизация канала для среднестатистической, пусть и крупной, организации - почти гарантирована.
Если ни один из вариантов не реализуем/не подходит, то тут или за денежку переложить проблему на плечи других людей (провайдерам защиты), либо мучаться, если потери от DDoS для компании кажутся допустимыми и более предпочтительными, чем затраты на защиту.
Насчет CF не соглашусь. Сильно зависит от профиля клиентского трафика. Не всегда понимает корректно профиль легитимного трафика и потом не может корректно детектить атаки. Ну и дорого. Очень.
Сделайте систему логирования. Без нее - никуда. На основании логов можно определать baseline и сигнатуры, строить правила защиты и рисовать красивые графики для менеджмента. Ну и алерты потом прикрутите - сами понимать будете когда атака началась и что за атака.
После того как построите сигнатуру своего легитимного трафика, попросите своих ISP настроить ACL с их стороны - таким образом закроете вопрос атак L2-3 (DNS & NTP amplifications etc)
Тут самое интересное: готовьте свою аналитику на основе п.1. Вам нужно детектировать девиации трафика (отклонения от baseline) и решать что с этим делать. Это, конечно самое сложное: с одной стороны вы должны отсечь максимум паразитного трафика, с другой - не допустить false positives. Хорошее решение - не дропать клиента, а загонять его на JS challenge.
Дальше проще: есть detector (п.3), есть периметр сети, где происходит блокировка. Постоянно работает процесс: детектирование атаки -> определяем её вектор -> генерируем action -> применяем его к блокиратору -> goto start. Блокиратор, естественно, должен быть как можно ближе к источнику атаки. Тут возможны варианты с honey pot etc.
Конечно, это очень общее описание. Ситуация зависит от внешних каналов, числа POPs, величины production traffic etc. Ну и вариантов реализации, конечно, великое множество.
А вопрос к банкам или к DDoS-Guard? Если к последнему, то наши клиенты не страдают. А вот за тех, кто не у нас - не скажу. Там каждый сам решает, что же сделать для спасения юзеров.
Мы ваши клиенты, и мы страдали, пользы от вашей услуги как показала практика не было
Можно к нам в поддержку/приват, если удобнее (если это не прямо совсем давно было). Ну потому что каждый кейс обращения в саппорт разбирается, если что-то действительно пошло не так. А вот если что-то пошло не так по мнению пользователя, но при этом не было сделано ничего, чтобы донести до нас инфу о возникшем затруднении, то тут только на какие-то глобальные метрики можно полагаться. Увидели аномалии - хорошо. Пошло в анализ. Аномалий нет, SLA выдержан и пользователь отмолчался в моменте - ну тогда и предмета обсуждения нет, получается.
Как организованы DDoS-атаки на банки. И не только. На пальцах