А почему не используется хотя бы netflow для определения цели атаки?
И какой у вас будет алгоритм действий, если это будет не простой TCP/HTTP флуд в адрес, а какой-нибудь UDP volumetric/DNS amplification и прочие разновидности? А если уже не на одного клиента, а целенаправленно на вашу инфраструктуру?
Думаю, что на ваших масштабах минимальная автоматика для diversion/RTBH необходима. В конце-концов, есть gatekeeper.
На тему .arpa странно написано про доступность из паблика.
Владея ASN и адресами вполне можно делегировать на любой NS свои зоны in-addr.arpa и ip6.arpa (с помощью объектов типа domain в RIPE DB, например) и резолвить их публично, так и делают для PTR.
И так же можно держать их на внутренних NS, для любых адресов. Первое, что приходит в голову - зоны для RFC1918.
При более-менее серьезном DDoS conntrack на одном сервере вытечет очень быстро, отреагировать не успеете, т.к. там PPS - сотни тысяч.
И если у оператора нет инструментов митигации типа Arbor/gatekeeper и подобных - как-то значительно повлиять на атаку будет сложно.
В последнее несколько лет часто вижу целенаправленные атаки на саму инфраструктуру операторов и ЦОД, а не их клиентов прицельно Часто они к этому не готовы, т.к. привыкли решать проблему блэкхолингом проблемных адресов (а в этом случае - это все адреса).
А как вы предлагаете использовать PodDisruptionBudget для координации обновления хостов? Он не помешает вам отправить весь кластер в ребут одновременно.
Помимо подмены ответа, вылезают ещё проблемы в виде overhead на такие DNS запросы, зависимости от регистраторов и наверняка ещё много других подводных камней.
Хотя идея DANE в этом плане интересная, но скорее перекладывает проблему на другой слой.
И будто бы кроме централизованных CA остаётся только TOFU, но он видится нежизнеспособным в вебе.
Касаемо протоколов не уверен, что есть потребность в реализации SCEP, кажется, он изжил себя, но, возможно, я неправ, буду рад выслушать реальный кейс и боль от отсутствия такового
Он действительно устарел, но все ещё используется. Например, на сетевом оборудовании для управления PKI VPN.
Болью скорее было отсутствие EST на серверной стороне и необходимость использовать этот самый SCEP.
Если платформа не совсем на коленке собрана, то в том или ином виде в ней будет какой-то SDN для организации сети VM.
BGP в таких системах используется для доставки трафика на VM.
Собирать сети на растянутых L2 доменах в масштабах хостинга/облака - это собирать огромный домен отказа, бороться со штормами и прочими приколами L2.
А почему не используется хотя бы netflow для определения цели атаки?
И какой у вас будет алгоритм действий, если это будет не простой TCP/HTTP флуд в адрес, а какой-нибудь UDP volumetric/DNS amplification и прочие разновидности? А если уже не на одного клиента, а целенаправленно на вашу инфраструктуру?
Думаю, что на ваших масштабах минимальная автоматика для diversion/RTBH необходима. В конце-концов, есть gatekeeper.
DNS - он такой, очень много особенностей и легаси, так что время от времени подкидывает головоломки и опять узнаешь что-то новое :)
В почте для этого есть SMTP Banner Check, для проверки PTR. Вероятно, речь об этом.
Спасибо, очень интересный материал.
Если честно, удивило, что в архитектуру сразу не заложили шардинг, хотя профиль нагрузки явно напрашивается на это. Почему так?
И интересны причины, почему выбрали Postgres, а не ваш же YDB под эти данные?
На тему .arpa странно написано про доступность из паблика.
Владея ASN и адресами вполне можно делегировать на любой NS свои зоны in-addr.arpa и ip6.arpa (с помощью объектов типа domain в RIPE DB, например) и резолвить их публично, так и делают для PTR.
И так же можно держать их на внутренних NS, для любых адресов. Первое, что приходит в голову - зоны для RFC1918.
А как же неискоренимый .local и mDNS? :)
При более-менее серьезном DDoS conntrack на одном сервере вытечет очень быстро, отреагировать не успеете, т.к. там PPS - сотни тысяч.
И если у оператора нет инструментов митигации типа Arbor/gatekeeper и подобных - как-то значительно повлиять на атаку будет сложно.
В последнее несколько лет часто вижу целенаправленные атаки на саму инфраструктуру операторов и ЦОД, а не их клиентов прицельно Часто они к этому не готовы, т.к. привыкли решать проблему блэкхолингом проблемных адресов (а в этом случае - это все адреса).
А как вы предлагаете использовать PodDisruptionBudget для координации обновления хостов? Он не помешает вам отправить весь кластер в ребут одновременно.
Про миграцию и инструменты, которые предлагает этот стек, хотелось бы подробнее узнать.
Как/чем вендор рекомендует массово переносить VM из других платформ?
Помимо подмены ответа, вылезают ещё проблемы в виде overhead на такие DNS запросы, зависимости от регистраторов и наверняка ещё много других подводных камней.
Хотя идея DANE в этом плане интересная, но скорее перекладывает проблему на другой слой.
И будто бы кроме централизованных CA остаётся только TOFU, но он видится нежизнеспособным в вебе.
Скорее, что-нибудь вроде DKIM.
Текущий формат PKI в целом давно уже пора пересматривать и уходить от централизации, в т.ч. из-за таких рисков.
Непонятно только, как обеспечивать валидацю.
Поддерживаю, тоже им пользуюсь уже давно на нескольких устройствах - отлично работает.
Спасибо за детальный тест.
Интересно было бы сравнить на таких моделях, как сильно деградирует производительность при работе через PCI, без NVlink. Не пробовали?
Кластер из двух участников выглядит не очень надёжно.
Как вы решаете проблему split brain? Как обеспечивается кворум?
Он действительно устарел, но все ещё используется. Например, на сетевом оборудовании для управления PKI VPN.
Болью скорее было отсутствие EST на серверной стороне и необходимость использовать этот самый SCEP.
Спасибо за статью, интересный проект.
А не смотрели ejbca или step-ca? Интересно, чем не подошли в вашем случае.
Есть ли возможность не хранить private key в базе и передавать CSR на подпись?
Планируете добавить поддержку ACME, EST и SCEP?
Есть ZFS, можно собрать в установщике или webui.
Это всегда было, независимо от зрелости и стабильности направления. Тем более, если сейчас это модно, как AI, который все пытаются внедрить везде.