Администрирование

Мы расскажем, как настроить безопасность кластеров Kafka и Zookeeper, какие инструменты можно использовать для мониторинга и управления кластером, а также про особенности продукта, с которыми мы столкнулись.

 Почему Apache Kafka?

 Apache Kafka — это унификация. Десятки поставщиков и потребителей, миллионы сообщений в день и огромные массивы данных — для этого нужна надежная, отказоустойчивая и высокопроизводительная шина данных. Существует множество версий дистрибутивов Apache Kafka, например vanilla kafka, oбразы от confluent, bitnami, wurstmeister и т.д. Мы расскажем про решение на базе сборок от Confluent в виде Docker-образов. Оно самое надежное в плане информационной безопасности. Конфигурирование и запуск контейнеров с Kafka в данном случае происходит с помощью docker-compose.

 За время работы с Kafka мы прошли  путь от «коробочного» решения до тонкой настройки безопасности кластера, применения TLS шифрования и разворачивания по рекомендациям вендора по построению геораспределенного кластера. В конфигурации «из коробки» нет первоначальных настроек безопасности. Для контроля доступов, вносимых изменений и безопасного взаимодействия перед нами встала задача настройки на кластере Apache Kafka TLS шифрования, аутентификации и авторизации средствами встроенного ACL.

 TLS шифрование

Обеспечивает шифрование соединения между брокерами Kafka, серверами Zookeeper, клиентами и брокерами. Вся ключевая информация помещается в хранилища — keystore, которые разделяют на два вида:

• keystore, где хранятся ключи и сертификаты стороны, в отношении которой пройдет процедура аутентификации и установления защищенного соединения, например, приватный ключ и ассоциированный с ним и подписанный со стороны центра сертификации (ЦC) сертификат.

В данной статье мы рассказываем о том, как беспроводные сети могут помочь беспилотным машинам справляться с некоторыми “edge case” ситуациями и описываем подход для упрощения операции поиска объектов, влияющие на свойства беспроводных каналов. 

Итак, начнем!

Короткий мануал их 7 шагов о том, как собрать из официальных исходников свой Composer без политических лозунгов авторов или просто внести свои изменения и подписать валидной сигнатурой.

Привет, Хабр! Меня зовут Игнат Нахай и это мой первый пост. Я работаю в команде по внедрению платформы ZIIoT для промышленности. Конкретнее – отвечаю за архитектурные решения при внедрении платформы в информационный слой заказчика.

ZIIoT объединяет все источники промышленных данных на предприятии и через набор MES-сервисов позволяет управлять качеством, отслеживать генеалогию продукции, анализировать производительность, проводить оперативное и детальное планирование, контролировать состояние и распределение ресурсов и много чего еще.  В связи с этим в платформе рождается большой объем информации, которая востребована в других информационных системах предприятия. Здесь я расскажу, как мы решали задачу построения информационных потоков и как нам в этом помог Apache NIFI. 

Я работаю в центре киберзащиты DataLine и в числе прочего занимаюсь межсетевыми экранами нового поколения (NGFW): тестирую новые решения, внедряю, настраиваю, слежу за работоспособностью. 

В прошлый раз коллеги уже рассказывали про аналог западных NGFW на случай санкций и показывали схемы подключения виртуального шлюза безопасности в облаке. Но что если компания имеет на балансе аппаратный межсетевой экран и хочет продолжать использовать именно его, а не облачное решение? Например, если нужна частная инсталляция, а покупать новый аппаратный шлюз пока нет возможности. 

С этой мыслью мы запустили тесты производительности отечественного UTM UserGate в интересном контексте: мы подняли версию UserGate на программно-аппаратном комплексе от зарубежного вендора NGFW. В статье поделюсь сценариями тестирования и покажу результаты на популярном устройстве розового цвета. При желании такие же тесты можно прогнать на любом другом оборудовании.

Есть мнение, что платформа OpenStack теряет актуальность, но с этим утверждением согласны не все. Разберемся, в чем дело и обсудим альтернативы.

В этом году на площадке Positive Hack Days пройдет финал первого Всероссийского конкурса open source проектов школьников и студентов по направлению «Кибербезопасность». Мероприятие организовано Кружковым движением Национальной технологической инициативы при поддержке Минцифры, Минобрнауки, Positive Technologies и других IT-компаний России.

Регистрация открыта, работы принимаются до 10 мая.

С недавних пор SIEM-системы «показаны» не только крупному бизнесу, но и субъектам КИИ, и операторам персданных – то есть почти всем. ФСТЭК и другие регуляторы настоятельно рекомендуют вооружаться SIEM, в некоторых отраслях это прямые требования, которые нельзя игнорировать.

Теперь ситуация и вовсе накалилась. С одной стороны, геополитика умножила в разы количество кибератак на российские компании, так что защититься нужно быстро и качественно. С другой, самые популярные SIEM – зарубежные, они уходят с российского рынка. Возникает вопрос: как внедрить SIEM, чтобы успеть надежно вооружиться против хакеров, выполнить требования импортозамещения и не слить на внедрение все бюджеты?

Мы нечасто приходим на Хабр «торговать лицом», но в нынешних условиях считаем нужным рассказать – у нас есть инструмент, который решает эти проблемы. Представляем вам «СёрчИнформ SIEM».

Мы решили поделиться результатами опроса, проведенного агентством S&P Global в начале 2022 года. Они позволяют узнать, какие поставщики систем хранения данных и какие технологии лидируют в 2022-м, кто готов сменить свою СХД и почему.

Что такое EVM?

EVM — это среда выполнения для блокчейна Ethereum. Позволяет запускать код смарт-контракта путем компиляции в байт-код EVM.

Основы: Solidity → Байт-код → Opcode

Как вы знаете, код Solidity должен быть скомпилирован в байт-код перед развертыванием в сети Ethereum. Этот байт-код соответствует серии инструкций кода операции, которые интерпретирует EVM.

Исходный код: файл, написанный на языке программирования, таком как Java, Solidity.

Байт-код: скомпилирован из исходного кода и запущен на виртуальной машине, такой как JVM, EVM.

Машинный код: код, который может прочитать только операционная система. Байт-код преобразуется в машинный код и, наконец, выполняется.

В этом посте раскрывается эксплойт CVE-2022-27666, уязвимость, позволяющая добиться локального повышения привилегий на последней версии Ubuntu Desktop 21.10. Изначально мы приберегли ее для pwn2own 2022, но она была пропатчена за 2 месяца до начала конкурса. Поэтому было решено обнародовать наш эксплойт и опубликовать PoC в конце поста.

Наше первичное исследование показало, что эта уязвимость затрагивает последние версии Ubuntu, Fedora и Debian. Наш эксплойт был создан для атаки на Ubuntu Desktop 21.10 (последняя версия на момент написания эксплойта).

В этой небольшой заметке я хочу затронуть тему совместных конфиденциальных вычислений и попробовать кратко изложить суть этих подходов и развеять несколько неоднозначностей, сложившихся в трактовке этого термина в современном информационном поле. Надеюсь получиться 🙂

Начну немного издалека, я в целом интересуюсь темой распределенной обработки данных с сохранением конфиденциальности, в частности активно смотрю на развитие такого направления, как Federated Learning. Часто попадаются статьи и материалы на эту тему, в которых наблюдаю некоторую терминологическую путаницу, тк термины Federated Learning и Confidential Computing часто используют как синонимы, но это не совсем так. Может быть я не совсем прав, но набор методов, для "обучения" (learning) и для "вычислений" вообще-то отличаются и не являются подмножеством друг друга. Поэтому в первую очередь хочу высказаться про мое понимание их фундаментальной разницы:

Итак, Вы работаете с Большими Данными:

– Обработка этих данных требует значительного времени (и затрат 💰).

– Исторические данные не меняются (или не должны меняться) - как правило, это свершившиеся факты.

– Если Вам удается не делать повторную обработку исторических данных - Вы экономите время и затраты.

Технологии контейнеризации в последние годы получили широкое распространение и наиболее известным решением по управлению контейнерами по праву считается Kubernetes, или, сокращенно, K8s. Kubernetes это система автоматизации развертывания и масштабирования контейнеризированных приложений и управления ими. Данная система построена на базе программного обеспечения с открытым исходным кодом. Изначально решение разрабатывалось специалистами Google, начиная с 2014 года и предназначалось для решения внутренних задач корпорации. Однако, впоследствии Kubernetes стал решением Open-Source и получили широкое распространение по всему миру.

Kubernetes, как система управления кластерами из контейнеров, является динамическим решением, которое позволяет в режиме реального времени реагировать на события, оживлять “упавшие” сервисы и масштабироваться по запросу. Особенно преимущества Kubernetes  в части живучести оценили разработчики. В качестве примера можно привести историю, когда у помещенного в контейнеры приложения начала “течь” память. Однако, разработчики узнали об этом только через несколько месяцев, когда заинтересовались, логами приложения. А все это время Kubernetes исправно следил за контейнерами с этими приложениями и в случае их “подвисания” тут же рестартовал их. Так что живучесть контейнеризированным приложениям данная система обеспечивает на “отлично”.

В целом, K8s можно назвать стандартом для современных DevOps-сред в организациях различного уровня. Например, Kubernetes используется в таких облачных сервисах, как: AWS, Microsoft Azure или Google Cloud.

Существует великое множество статей об оптимизации PostgreSQL — эта «кроличья нора» весьма глубока. Когда несколько лет назад я начал разрабатывать бэкэнд аналитического сервиса, у меня уже был опыт работы с другими СУБД, такими как MySQL и SQL Server. Тем не менее, раньше мне не приходилось так фокусироваться на производительности. В прошлых проектах, над которыми я работал, либо не было жестких требований к времени обработки (DS/ML), либо не требовалось обрабатывать много строк одновременно (обыкновенные веб-приложения). Однако в этот раз мои запросы:

• состояли из 3-10 JOIN-ов по коррелирующим запросам;

• уielded от 10 до 1,000,000 строк;

• должны были выполняться в течение времени, определенного UX-ом;

• не могли быть hinted — пока Cloud SQL, управляемый PostgreSQL в Google Cloud, не стал поддерживать pg_hint_plan в конце 2021 года;

• запрещали прямой доступ к серверному процессу, чтобы, например, хакнуть некоторые perf — потому что PostgreSQL был managed.

Получение целого миллиона строк в одном API endpoint сигнализирует о проблеме в алгоритме или архитектуре. Конечно, все можно переписать и перепроектировать, но за это нужно платить.

У нас не нашлось «заклинания», которое решило бы все проблемы с производительностью SQL. Тем не менее, я упомяну здесь несколько дельных предложений, которые помогли нам и, надеюсь, смогут помочь читателю. Разумеется, это не какие-то сакральные знания. Но когда мы начинали оптимизацию, я был бы рад их прочитать или услышать.

Прошлой осенью я протестировала программное обеспечение для обхода антивирусов, которое применялось на различных тренировках у нас на киберполигоне. Для исследования я выбрала несколько инструментов обфускации и проверила, смогут ли общедоступные средства антивирусной защиты — Microsoft Defender, Kaspersky Total Security и VirusTotal — обнаружить вредоносную нагрузку в файлах после их обработки обфускаторами.

Исследование проводилось исключительно в образовательных целях для организации киберучений: на Национальном киберполигоне мы помогаем будущим специалистам по кибербезопасности и тем, кто уже работает в отрасли, без риска реального ущерба оттачивать на практике навыки defensive security. Участники учений тренируются на эмулированной инфраструктуре предприятий различных отраслей выявлять цепочки атак, сценарии которых повторяют действия реальных злоумышленников, в том числе и обход антивирусов.

Сегодня я поделюсь результатами моего исследования и заодно кратко опишу другие методы обхода антивирусов. Cтатья может быть полезной пентестерам и другим специалистам по кибербезопасности, желающим убедиться в работоспособности доступных методов обхода антивирусов, которые можно найти в открытых источниках.

Я считаю, что именно агрегаты из Domain-Driven Design лежат в основе поддерживаемых информационных систем. Однако эта концепция малоизвестна за пределами DDD-сообщества и довольно сложна для понимания, поэтому я решил написать очередной пост посвящённый агрегатам. В основном для чтобы структурировать собственное понимание агрегатов и создать "методичку" для своих команд, но и широкой общественности, я надеюсь, этот пост тоже может быть полезен.