Можно к нам в поддержку/приват, если удобнее (если это не прямо совсем давно было). Ну потому что каждый кейс обращения в саппорт разбирается, если что-то действительно пошло не так. А вот если что-то пошло не так по мнению пользователя, но при этом не было сделано ничего, чтобы донести до нас инфу о возникшем затруднении, то тут только на какие-то глобальные метрики можно полагаться. Увидели аномалии - хорошо. Пошло в анализ. Аномалий нет, SLA выдержан и пользователь отмолчался в моменте - ну тогда и предмета обсуждения нет, получается.
Самостоятельно силами условной компании K? Ну если поток трафика больше, чем толщина канала, то просто принять трафик не получится. Потому что мусорный трафик выдавит полезный, качество работы деградирует в любом случае. Вне зависимости от того, tls там, или что-то иное. Этот момент многие забывают почему-то. С другой стороны, если есть понимание, откуда такой мусор идёт (например, понятно, что мусор, и это логируется в виде ip, либо с определённых AS/префиксов), то можно попытаться поговорить со своим провайдером, чтобы он это на своей стороне подропал. Ему, провайдеру, в целом, тоже незачем передавать по своим сетям мусор, да и ёмкости у него больше, чем на канале последней мили. Т.е. дропается там, а к клиенту доходит уже подчищенный трафик. С частью провайдеров о таком договориться можно, даже в моменте.
Если поток мусора всё же помещается в канал, полоса для полезного трафика остаётся достаточной, то тут могут быть варианты. Из первого и очевидного - если есть логи, скармливать проблемные ip фаерволам/fail2ban. Но тут оборудование должно быть достаточной производительности, чтобы вывозить первичные пачки tls мусора. Эта штука по CPU действительно может перегрузить системы. Вторая мысль, что приходит в голову - подключить к своим фаерволам какую-нибудь базу репутации ip. Общая мысль тут - отсечь вредоносные tls хэндшейки и не обрабатывать их в принципе. Так сильно дешевле по ресурсам, если главная задача состоит в том, чтобы всё сделать своими силами. Возможны фолзы в срабатывании/не срабатывании, но разобраться с проблемными единичными юзерами после такого - это сильно проще, чем разбираться с проблемами вообще всех своих клиентов. Но надо помнить, что DDoS-атака в немалой степени - это ещё и про цену её реализации. И цена эта, судя по тому, что вижу прямо сейчас в гугле, дешевле цены гигабитного интернета в офис. Это если атака коммерчески мотивирована. А если не коммерчески - тем более. Так что переутилизация канала для среднестатистической, пусть и крупной, организации - почти гарантирована.
Если ни один из вариантов не реализуем/не подходит, то тут или за денежку переложить проблему на плечи других людей (провайдерам защиты), либо мучаться, если потери от DDoS для компании кажутся допустимыми и более предпочтительными, чем затраты на защиту.
А вопрос к банкам или к DDoS-Guard? Если к последнему, то наши клиенты не страдают. А вот за тех, кто не у нас - не скажу. Там каждый сам решает, что же сделать для спасения юзеров.
Можно к нам в поддержку/приват, если удобнее (если это не прямо совсем давно было). Ну потому что каждый кейс обращения в саппорт разбирается, если что-то действительно пошло не так. А вот если что-то пошло не так по мнению пользователя, но при этом не было сделано ничего, чтобы донести до нас инфу о возникшем затруднении, то тут только на какие-то глобальные метрики можно полагаться. Увидели аномалии - хорошо. Пошло в анализ. Аномалий нет, SLA выдержан и пользователь отмолчался в моменте - ну тогда и предмета обсуждения нет, получается.
Самостоятельно силами условной компании K?
Ну если поток трафика больше, чем толщина канала, то просто принять трафик не получится. Потому что мусорный трафик выдавит полезный, качество работы деградирует в любом случае. Вне зависимости от того, tls там, или что-то иное. Этот момент многие забывают почему-то. С другой стороны, если есть понимание, откуда такой мусор идёт (например, понятно, что мусор, и это логируется в виде ip, либо с определённых AS/префиксов), то можно попытаться поговорить со своим провайдером, чтобы он это на своей стороне подропал. Ему, провайдеру, в целом, тоже незачем передавать по своим сетям мусор, да и ёмкости у него больше, чем на канале последней мили. Т.е. дропается там, а к клиенту доходит уже подчищенный трафик. С частью провайдеров о таком договориться можно, даже в моменте.
Если поток мусора всё же помещается в канал, полоса для полезного трафика остаётся достаточной, то тут могут быть варианты. Из первого и очевидного - если есть логи, скармливать проблемные ip фаерволам/fail2ban. Но тут оборудование должно быть достаточной производительности, чтобы вывозить первичные пачки tls мусора. Эта штука по CPU действительно может перегрузить системы. Вторая мысль, что приходит в голову - подключить к своим фаерволам какую-нибудь базу репутации ip. Общая мысль тут - отсечь вредоносные tls хэндшейки и не обрабатывать их в принципе. Так сильно дешевле по ресурсам, если главная задача состоит в том, чтобы всё сделать своими силами. Возможны фолзы в срабатывании/не срабатывании, но разобраться с проблемными единичными юзерами после такого - это сильно проще, чем разбираться с проблемами вообще всех своих клиентов. Но надо помнить, что DDoS-атака в немалой степени - это ещё и про цену её реализации. И цена эта, судя по тому, что вижу прямо сейчас в гугле, дешевле цены гигабитного интернета в офис. Это если атака коммерчески мотивирована. А если не коммерчески - тем более. Так что переутилизация канала для среднестатистической, пусть и крупной, организации - почти гарантирована.
Если ни один из вариантов не реализуем/не подходит, то тут или за денежку переложить проблему на плечи других людей (провайдерам защиты), либо мучаться, если потери от DDoS для компании кажутся допустимыми и более предпочтительными, чем затраты на защиту.
А вопрос к банкам или к DDoS-Guard? Если к последнему, то наши клиенты не страдают. А вот за тех, кто не у нас - не скажу. Там каждый сам решает, что же сделать для спасения юзеров.