Комментарии 21
Как то сильно "толсто".
Из причин "Почему западные решения не подходят для защиты российских веб‑приложений", только одну и то с натяжкой можно назвать - несоответствие требованиям регулятора (а DS Proxima ГОСТ уже поддерживает?), две других притянуты за уши. Зарубежные балансировщики, тем более те с которыми идет сравнение в статье умеют балансировать все, включая и "особенные" приложения 1С, любой TCP трафик, с любыми критериями балансировки. Разбор TLS на большинстве из них происходит за счет специализированных ASIC процессоров а не за счет x86 core процессоров. Рекламируемое решение DS Proxima, если я верно прочитал их даташиты, сделала это на GPU, но до специализированных ASIC им далеко еще - потому сильная презакладка вычислительных ресурсов присутствует в отличии, как раз от зарубежных решений где есть баланс между мощностями и производительностью.
А схема тестового стенда вообще прекрасна. Говорится о том что зарубежные решения якобы на x86 и им не хватает ресурсов для работы с разбором HTTPS и WAF и что нужно в одном месте после разбора HTTPS проверять трафик на наличие вредоносов, но почему то DS Proxima не разбирает HTTPS трафик а шлет его на отдельную сущность WAF, который как раз и забирает на свои x86 процессора всю нагрузку - разбор TLS, анализ, сбор TLS и отправка уже шифрованного трафика на второй балансировщик. Упс.
Ну и самый сок, львиная доля функционала по защите веб приложений на стороне WAF работать не будет скорее всего (деталей стенда нет), по причине типовой схемы работы балансировщика - двойной NAT, то есть кластер WAF не будет знать реальных source IP того кто подключается, а это минус Geo IP минус черные и белые списки. Можно было бы на балансировщике первым в схеме разобрать HTTPS и добавить XFF\XRI заголовки, но кто так делает:) задача то рекламировать.
Безусловно, в отсутствии легальной, согласно регуляторной практики, схемы использования зарубежных решений балансировки, выбираем из того что есть, точнее вынуждены выбирать...
Ну, не могут же они прямо написать, - а кто не будет брать, тому отключат газ. - делают умное лицо.
А, вообще, просто их девочка из пиара по ошибке опубликовала лекцию для колхозников на ресурсе дачников
Спасибо за ваше мнение. Однако хотелось бы напомнить, что на Хабре приветствуется конструктивный и уважительный диалог без оскорблений и провокаций. Предлагаю сосредоточиться на сути обсуждения и избегать необоснованных обвинений.
Но вы ведь сами задали этот тон начиная с заголовка и последовательно развивали его далее, следовательно для вас приемлема такая провокационная риторика. Либо же вы ошиблись площадкой и выложили лекцию для колхозников доклад для пленума партии на технический ресурс.
Пока что из вашей статьи следует что все западные балансеры обрабатывают трафик на х86 и избегают использовать для этого FPGA, причём, видимо, в силу именно "западности". Сомнительное во всех смыслах заявление. Как и то, что "российские" веб-приложения следует защищать каким-то особым способом.
Уважаемый коллега, благодарим за ваш комментарий — приятно видеть, что дискуссия принимает более предметный характер.
Так как в случае западных решений речь идет о L7-баланасировщиках, то в этом контексте нам действительно не известны модели западных балансировщиков, где бы вся логика обработки на уровне L7 выполнялась аппаратно — на FPGA или ASIC. Как правило, даже при наличии аппаратных ускорителей (например, для SSL/TLS offload), основная логика L7 остаётся программной и исполняется на x86 CPU общего назначения.
Если у вас есть примеры моделей, реализующих полноценную L7-балансировку на FPGA, будем признательны за указание — это действительно важно для понимания архитектурных трендов и эволюции решений.
Что касается защиты веб-приложений: утверждение, что российские приложения не требуют специфического подхода к защите, на наш взгляд, спорно. Ниже — основные причины:
Языковая специфика (обработка вредоносных запросов на русском языке, в том числе с учетом морфологии, кодировок, обходов).
Культурные и социальные особенности фишинга и социальной инженерии, завязанные на российский контекст.
Локальные паттерны атак.
Опыт интеграции с ПО и понимание бизнес-процессов, характерных для российских компаний.
Отсутствие мониторинга российского DarkNet/Telegram-сегмента в западных Threat Intelligence-платформах.
Если у вас есть практические примеры успешной защиты русскоязычных и юридически значимых веб-приложений западными WAF/балансировщиками с учетом вышеуказанных нюансов — будем рады обсудить.
Про аппаратную L7-балансировку. В F5 BIG-IP часть задач по обработке трафика разгружена на специальные чипы (например, SSL ASIC). Это не полный переход на «железо», но шаг в этом направлении. В Cisco ADC и Citrix ADC используются аппаратные ускорители для TCP и шифрования. Это позволяет снизить нагрузку на центральный процессор при работе с HTTP/2, TLS 1.3 и так далее. NVIDIA BlueField DPU позволяет выносить часть сетевых функций из CPU прямо в SmartNIC. Это тоже не полноценная L7-балансировка на железе, но уже гибридное решение.
Про защиту российских веб-приложений. Современные WAF, например Cloudflare, Imperva или Akamai, умеют работать с разными языками. Они используют NLP и машинное обучение, чтобы распознавать атаки даже на русском языке — включая морфологические вариации и кодировки. AWS WAF или Google Cloud Armor позволяют гибко настраивать фильтры под конкретные сценарии, в том числе под российские. Многие платформы интегрируются с локальными аналитиками и экспертами. То есть, если нужно, добавляется знание российского контекста через партнёров.
Уважаемый коллега, благодарим за развернутые комментарии.
Да, вы абсолютно правы — современные западные решения представляют собой гибридную архитектуру, где основная обработка ведётся на CPU, а часть задач (например, шифрование или ускорение TCP/HTTP) разгружается на специализированные чипы. И действительно, речь уже идет не просто о балансировщиках, а о полноценных ADC (Application Delivery Controller), включающих не только L4–L7-балансировку, но и функции безопасности, оптимизации трафика и др. Однако, как показывает практика, реализовать каждую из этих функций в виде отдельного аппаратного ускорителя невозможно. В итоге ключевые компоненты всё равно конкурируют за ресурсы центрального процессора. Отдельно хотелось бы отметить, что, по нашему опыту, многие функции ADC приобретаются "на вырост" или "на всякий случай", но на практике так и остаются неактивными либо не интегрированными в реальную инфраструктуру заказчика. Причин много: сложность внедрения, отсутствие компетенций, избыточность для текущих задач.
Действительно, такие решения, как Cloudflare, Imperva, Akamai, AWS WAF или Google Cloud Armor, обладают развитым функционалом и применяют современные технологии, включая ML/NLP, в том числе для обработки текстов на разных языках. Однако важно подчеркнуть, что вы описываете решения класса Cloud WAAP (Web Application and API Protection) — то есть облачные сервисы, предоставляющие WAF как услугу с функциями защиты L7, DDoS mitigation, rate limiting и т.д. Мы же в статье говорим о внедрении WAF внутри инфраструктуры компании (on-premises или private cloud), то есть о совершенно другом классе решений, отличающемся по архитектуре, требованиям и применимости в российском контексте.
в случае западных решений речь идет о L7-баланасировщиках, то в этом контексте нам действительно не известны модели западных балансировщиков, где бы вся логика обработки на уровне L7 выполнялась аппаратно
Кажется, я понял посыл. Ваше устройство, получается, оптимизировано для DPI. Да, в этом случае, риторика противопоставления "вражеской" технике мало подходящей для цензурирования трафика, действительно оправдана. Для специфической аудитории. Да, наверное, целевой :(
утверждение, что российские приложения не требуют специфического подхода к защите, на наш взгляд, спорно. Ниже — основные причины:
на мой взгляд, это не причины, а общие слова, ничем не подкреплённые. По-прежнему уверен, что "российские уязвимости" ничем не отличаются от "западных уязвимостей".
Отсутствие мониторинга российского DarkNet/Telegram-сегмента в западных Threat Intelligence-платформах.
разве что, вот это интересно и даже хотелось бы узнать подробнеее. Получается, что вы во-первых, мониторите вот это всё, во-вторых, на основе мониторинга добавляете правила, в третьих перепрограммируете свой аппаратный FPGA-based балансер? Удалённо? По подписке? Если можно перепрограммировать эти правила, то, получается, разница с "вражескими" железками только в доп сервисе, а не в преимуществе одной железки над другой? То есть опять этот пункт мимо (а тогда и вышестоящие при всей изначальной спорности, тоже получаются не относящимися к устройству). Да, а вы этот сервис, получается, предоставляете?
Кажется, я понял посыл. Ваше устройство, получается, оптимизировано для DPI. Да, в этом случае, риторика противопоставления "вражеской" технике мало подходящей для цензурирования трафика, действительно оправдана. Для специфической аудитории. Да, наверное, целевой :(
Благодарим за ваш отклик. Хотим уточнить: наше устройство является аппаратным балансировщиком нагрузки и оптимизировано именно под задачи высокопроизводительной балансировки трафика.
Оно не связано с функциями фильтрации, цензурирования или интеграции с системами типа СОРМ. Речь в статье шла о технических аспектах построения решения по защите веб-приложений, а не о контроле контента или передаче данных в сторонние системы наблюдения или цензурирования трафика.
на мой взгляд, это не причины, а общие слова, ничем не подкреплённые. По-прежнему уверен, что "российские уязвимости" ничем не отличаются от "западных уязвимостей".
Согласны, что базовые уязвимости (XSS, SQLi, RCE и др.) универсальны. Мы не утверждаем, что в России есть особые “уникальные” уязвимости. Речь о другом — российские веб-приложения работают в специфической среде: с учётом языка, нормативных требований, инфраструктурных особенностей и источников угроз.
Поэтому, даже при общемировом наборе атак, подход к защите должен учитывать локальный контекст. Это требует постоянной адаптации и аналитики — чем, в частности, и занимаются наши коллеги из SolidWall.
разве что, вот это интересно и даже хотелось бы узнать подробнеее. Получается, что вы во-первых, мониторите вот это всё, во-вторых, на основе мониторинга добавляете правила, в третьих перепрограммируете свой аппаратный FPGA-based балансер? Удалённо? По подписке? Если можно перепрограммировать эти правила, то, получается, разница с "вражескими" железками только в доп сервисе, а не в преимуществе одной железки над другой? То есть опять этот пункт мимо (а тогда и вышестоящие при всей изначальной спорности, тоже получаются не относящимися к устройству). Да, а вы этот сервис, получается, предоставляете?
Мониторингом веб-угроз, анализом специфики атак и регулярным обновлением сигнатур занимаются наши коллеги из SolidWall. Они развивают собственный WAF-продукт, адаптируя его под реалии Рунета. Мы, в свою очередь, отвечаем за аппаратную балансировку трафика на кластеры WAF и backend-серверов обеспечивая отказоустойчивость и высокую производительность всей системы.
Таким образом, мы реализуем подход «best of breed» — когда решение строится из отдельных специализированных компонентов, каждый из которых оптимален в своей области:
аппаратный балансировщик — под производительность и устойчивость;
WAF — под гибкую и актуальную защиту.
В статье мы противопоставляем эту архитектуру классическому западному подходу «best of suite», где все функции (включая балансировку, защиту, ускорение, кеширование и пр.) собраны в одном универсальном устройстве или облачной платформе.
Мониторингом веб-угроз, анализом специфики атак и регулярным обновлением сигнатур занимаются наши коллеги из SolidWall. Они развивают собственный WAF-продукт
То есть и последний тезис об отсутствии мониторинга российских даркнетов оказался несостоятельным. Ведь если этим занимаются отдельные компании с отдельным продуктом, то и заслуги впшей в жтом нет и ваш балансировщик просто лишён части функциональности. Рекламировать это как преимущество - ну, особый дар - на Жигулях вам никогда не разобьёт нос подушка безопасности. Ведь у Жигулей нет этих подушек!
Мы, в свою очередь, отвечаем за аппаратную балансировку трафика на кластеры WAF и backend-серверов
Означает ли это, что вы утверждаете, что с помощью "западных решений" это невозможно сделать?
даже при общемировом наборе атак, подход к защите должен учитывать локальный контекст. Это требует постоянной адаптации и аналитики — чем, в частности, и занимаются наши коллеги из SolidWall.
То есть вашей заслуги в этом нет, а подключить стороннюю подсистему можно при использовании любого балансировшика? В чём же ваше преимущество?
То есть и последний тезис об отсутствии мониторинга российских даркнетов оказался несостоятельным. Ведь если этим занимаются отдельные компании с отдельным продуктом, то и заслуги впшей в жтом нет и ваш балансировщик просто лишён части функциональности. Рекламировать это как преимущество - ну, особый дар - на Жигулях вам никогда не разобьёт нос подушка безопасности. Ведь у Жигулей нет этих подушек!
Позвольте уточнить: в статье речь идёт не об отдельных продуктах, а о предынтегрированном решении, где аппаратный балансировщик и WAF работают как единый комплекс. Именно решение в целом, с учётом всех компонентов и их взаимодействия, обеспечивает заявленную функциональность — включая анализ локальных угроз, устойчивость к отказам и производительность.
Если продолжать автомобильную аналогию — любой современный автомобиль собирается из модулей разных производителей: тормозная система — одного, электроника — другого, шины — третьего. Но потребитель покупает не комплектующие, а целостное транспортное средство, за которое отвечает автопроизводитель. И именно он гарантирует, что все части работают слаженно.
Так и здесь: наша задача — не просто предоставить железо, а собрать и сопровождать надёжную платформу, в которую уже интегрированы балансировка, отказоустойчивость и защита веб-приложений.
Означает ли это, что вы утверждаете, что с помощью "западных решений" это невозможно сделать?
Нет, мы не утверждаем, что западные балансировщики не умеют распределять трафик. Это, безусловно, зрелые решения с широкими возможностями.
Наш тезис в другом: мы предлагаем альтернативный подход, в котором специализированный аппаратный балансировщик и адаптированный под российские реалии WAF работают как единое решение. Такой прединтегрированный формат позволяет быстрее внедрять, проще сопровождать и учитывать локальные особенности — технические, нормативные и организационные.
Речь не о том, что «там не умеют», а о том, что мы по-другому расставили приоритеты и собрали решение под задачи, актуальные для отечественного рынка.
То есть вашей заслуги в этом нет, а подключить стороннюю подсистему можно при использовании любого балансировшика? В чём же ваше преимущество?
Да, теоретически никто не запрещает подключить стороннюю систему защиты к любому балансировщику — как и собрать автомобиль из деталей разных производителей. Но ключевое отличие — в уровне интеграции, зрелости связки и ответственности за конечный результат.
Мы —производитель первого полноценного аппаратного балансировщика нагрузки на российском рынке, и одна из наших ключевых задач — развитие экосистемы прединтегрированных решений совместно с российскими разработчиками ИБ-систем. Это означает:
заранее протестированную и оптимизированную связку,
готовые сценарии внедрения,
совместную техническую поддержку,
развитие функциональности с учётом локальных реалий и обратной связи от клиентов.
То есть строим совместно с партнёрами комплексные решения, в которых каждый компонент усиливает другой. Именно это и даёт конечному заказчику реальное преимущество — в скорости внедрения, удобстве эксплуатации и устойчивости к атакам, актуальным для российских систем.
вы оскорбились на дачников или колхозников? или на правду?
Здравствуйте! Спасибо за ваш развёрнутый комментарий и внимание к деталям. Ниже уточнения:
В решении DS Proxima используется аппаратная обработка трафика на FPGA, а не на GPU (возможно Вы имели ввиду CPU). Это даёт значительные преимущества:
Стабильная производительность до 1 Тбит/с, что с лихвой покрывает потребности в 99.9% реальных сценариев и обеспечивает эффективную обработку трафика любой скорости.
Низкое энергопотребление — порядка 200 Вт, что существенно выгоднее по сравнению с архитектурами на чистом x86.
Высокая надёжность, поскольку аппаратная обработка на FPGA не зависит от операционной системы, уменьшая потенциальные риски и точки отказа.
Когда мы упоминали использование x86 ядер в западных балансировщиках, речь шла именно о функциях, связанных с балансировкой нагрузки и WAF, а не об обработке HTTPS.
Таким образом, архитектура DS Proxima представляет собой сбалансированное решение, сочетающее мощную аппаратную обработку трафика с возможностью менять функциональные возможности, что обеспечивает и высокую производительность, и адаптивность системы.
2. Вопрос касательно TLS мы довольно детально разобрали в нашей предыдущей статье “Нужен ли внешний SSL-офлоадинг, если Intel уже встроила его прямо в CPU?” Там мы показываем, что начиная с серверных процессоров Intel Xeon 4-го поколения TLS-терминацию можно выполнять прямо на сервере — быстро и эффективно. Встроенный в CPU криптоускоритель Intel QAT открывает путь к распределённой обработке HTTPS-трафика без компромиссов по производительности и надёжности. Это подтверждается также тестами программных версий F5 и Citrix NetScaler которые обеспечивают уровень производительности, сопоставимый с аппаратными ASIC-ускорителями.
3. Спешим развеять ваши сомнения касательно архитектуры решения. В нашей схеме используется не двойной NAT (SNAT + DNAT), а только DstNAT (Destination NAT). Как это работает в нашей архитектуре:
Балансировщик выполняет только DNAT, то есть меняет только адрес назначения пакета, перенаправляя трафик на нужный WAF. При этом исходный IP-адрес клиента (source IP) сохраняется неизменным в пакете, так как SNAT не применяется.
Благодаря этому WAF видит реальный source IP клиента, а не IP балансировщика. Поскольку WAF получает корректные исходные IP, все механизмы, завязанные на IP, включая GeoIP-фильтрацию, белые и черные списки, работают корректно и эффективно. Нет необходимости в дополнительной обработке X-Forwarded-For (XFF) или X-Real-IP (XRI) заголовков для восстановления исходного IP, что упрощает архитектуру и повышает надёжность системы.
Спасибо за информацию. Мой посыл не в том что DS Proxima хуже или лучше, это ваш как раз посыл, сравнить и сказать, зарубежное плохое, наше лучше. Я только об этом. Про FPGA вы правы, я ошибся.
По поводу того что вы на тестовом стенде реализовали только SNAT как один из вариантов встраивания балансировщиков в сеть, я и уточнил, что по стенду не понятно как реализовано. Решения балансировки только с SNAT малоприменимы к сожалению в сетях active - active ЦОД без L2 растягивания я писал исходя из этого постулата, для решений в пределах одного L2 домена на соответствующую часть сетевой инфраструктуры вполне да можно и без NAT вообще обойтись.
Благодарим за ваш комментарий и уточнение.
Хотим прояснить, что на нашем тестовом стенде реализован DNAT, а не SNAT. При этом мы поддерживаем варианты интеграции как на уровне L3, так и на L2 — в зависимости от требований конкретной сетевой архитектуры.
Судя по вашему комментарию, у вас, возможно, есть практическая задача или сценарий, который важно корректно учесть с точки зрения совместимости и топологии. Мы будем рады обсудить её детально с нашими техническими специалистами — например, в нашем Telegram-чате по DS Proxima, где можно быстро и напрямую задать вопросы.
В части вашего тестового стенда с DNAT я не про него конкретно выше а про использование только одного NAT, не дописал чутка. К слову у SW WAF есть же кластеризация и выдаваемый наружу VIP по VRRP, разве нет? Под балансировщики DS Proxima задач нет, они сильно избыточны под балансировщики вообще есть конечно задачи, которые решаются более экономически целесообразными решениями.
Но коли затронули сам продукт, явный недостаток его в том что есть только одна модель нет вариативности в отличии от зарубежных решений по производительности. Или что то поменялось?
На данный момент действительно представлена одна модель, однако мы активно работаем над расширением продуктовой линейки, и в течение следующего года планируем представить новые модификации. Чтобы лучше понять актуальные потребности, нам было бы очень полезно узнать вашу точку зрения:
Есть ли интерес к компактным форм-факторам?
Какие типы интерфейсов и портовой ёмкости наиболее востребованы в ваших сценариях?
Да, есть. Текущие способности одной модели балансировщика сильно избыточны, для большинства, я думаю бизнесов, кроме крупного, нет таких потоков трафика. Большой интерес есть к виртуальным апплаенсам на базе специализированных аппаратных платформ аналогичных SDX Citrix, других решений особо как сегментировать сервисы согласно требований регуляторов нет и к 1U железкам обрабатывающим трафика на 50-100 Мбит\сек но с одновременной расшифровкой 10ков тысяч TLS соединений, с базовыми функциями балансировки L4-L7
удалено
Практический опыт построения надежной защиты российских веб-приложений