ДИСКЛЕЙМЕР:
Автор не призывает к игре с сторонним ПО. Вся информация, приведенная в статье - приведена лишь в образовательных и ознакомительных целях. Информация была взята из открытых источников и ни к чему не призывает.
СОДЕРЖАНИЕ:
Всем привет! Меня зовут Александр Барыков, я руковожу платформенной командой DevOps и являюсь лидером DevOps-комьюнити в нашей компании.
Сегодня хочу поделиться опытом, который мы накопили за последние четыре года. Речь пойдет о достаточно специфической, но знакомой многим теме – организации процесса скачивания и проверки внешних артефактов для размещения во внутреннем закрытом контуре. Эта статья будет полезна разработчикам, DevOps-инженерам и архитекторам, которые сталкиваются с необходимостью соблюдения строгих требований безопасности без потери темпа разработки, особенно в финансовом секторе, где есть регуляторные требования.
Классическая архитектура сетевой безопасности строилась вокруг одной предпосылки: существует чёткая граница между «внутри» и «снаружи». Межсетевой экран нового поколения (NGFW) стоит на этой границе и инспектирует трафик. Модель работала, пока сотрудники сидели в офисе, приложения - в корпоративном ДЦ, а удалённый доступ оставался исключением из правил.
Сегодня, особенно в эпоху «после ковида» и во времена рассвета облаков, это уже не так. Мы в Айдеко сами живем «гибридной» реальности с 2021-го года: работая полностью распределенной по всей России командой 300+ сотрудников в гибридной цифровой среде (где множество сервисов в облаках, но есть и локальные устройства и серверы связанные с необходимостью работы с «железом» ПАК-ми, стендами для нагрузочного тестирования NGFW и т.п.).
Наша цель – предоставить корпорациям решение для организации безопасной работы с современной ИТ-инфраструктурой где бы не находились сотрудники: на удаленке, в командировке, в офисе или других странах.
Классический NGFW в таких условиях остается необходимым - но его одного уже недостаточно.
Ответом индустрии стала архитектура SASE (Secure Access Service Edge), предложенная Gartner в 2019 году. SASE объединяет сетевые и security-функции в единую облачную платформу. Глобальные вендоры уже перестроили свои продуктовые линейки: Palo Alto Networks развивает Prisma SASE, Fortinet - FortiSASE, Zscaler выстраивает cloud-native SSE-платформу. По данным Gartner, к 2028 году 50% SASE-развёртываний будут базироваться на решении одного вендора - с 30% в 2025 году. Консолидация ускоряется.
В первой статье цикла мы рассказали о том, что несет в себе понятие сетевых скрытых каналов. Во второй статье мы поговорим о том, как строятся сетевые скрытые каналы в реальных сетях пакетной передачи на примере протоколов IPv4, ICMP и HTTP.
Привет, Хабр! Меня зовут Иван Костыря, и я работаю в команде SOC UserGate.
Сегодня хочу поделиться с вами мыслями о том, как правильно оформлять и доносить информацию об инцидентах информационной безопасности. Кроме очевидных моментов, что надо обнаружить, сдержать, нейтрализовать и восстановиться, есть ещё и весьма сложная задача — составить грамотный и информативный отчёт. Каждый аналитик, администратор и инженер по-разному видит нужный уровень информирования и по-разному относится к глубине и детальности описания происходящего. В рамках данной статьи постараюсь озвучить некоторые важные пункты, на которых стоит заострить внимание, чтобы сформировать более профессиональный отчёт о случившемся. Эта тема кажется простой только на первый взгляд, но на практике именно качество коммуникации нередко определяет успех или провал в реагировании на инциденты.
Первое, о чём стоит сказать, — информационная безопасность строится на фактах. Факты нужно не только собирать, но и правильно доносить до разных аудиторий — от команды реагирования до топ-менеджмента. Неправильно оформленный отчёт может привести к неверным решениям, потере времени и ресурсов, а в худшем случае — к эскалации инцидента.
Прежде чем говорить о коммуникации, определимся с терминами:
Привет, Хабр!
Это Михаил Кулаков. Я ведущий инженер-аналитик в Диасофт, занимаюсь развитием платформы распределенных реестров Digital Q.BlockChain.
Помните, как в начале 2000-х каждый банк строил свою собственную систему онлайн-банкинга? Одни использовали Java, другие – .NET, третьи – что-то свое. Клиенты мучились: чтобы перевести деньги из одного банка в другой, приходилось распечатывать платежки и ехать в отделение. Сегодня рынок ЦФА в России переживает похожий этап. 19 операторов – 19 изолированных крепостей. Инвестор у «Оператора А» не может купить актив у «Оператора Б», даже если оба используют блокчейн. И проблема совсем не в технологиях.
Всем привет. Сегодня поговорим про доверие в ИБ. Но не про сертификаты и «мировых лидеров», а про физику, математику и алгоритмы. Разберём, почему квантовый ПАК надёжнее межсетевого экрана, как оценить реальную защищённость и можно ли управлять «поверхностью атаки» как выключателем света.
На рынке ИБ для технологических объектов (АСУ ТП, промышленность) сейчас модно создавать «вербально-визуальные конструкции» — красивые слайды, умные слова, обещания доверия. Но доверие бывает разное:
В марте 2026 года экосистема Trivy пережила supply chain-инцидент. Согласно официальному advisory компании Aqua Security, злоумышленник использовал скомпрометированные учетные данные для публикации вредоносного релиза Trivy v0.69.4, перепривязки большинства тегов trivy-action к credential-stealing malware и замены тегов setup-trivy. Позднее были опубликованы и вредоносные Docker Hub образы v0.69.5 и v0.69.6.
Практический смысл этого кейса заключается в том, что компрометация затронула не один контейнерный образ, а сразу несколько официальных каналов доставки. Для команды разработки из этого следует неприятный, но важный вывод: внешний security-инструмент не становится доверенным только потому, что он популярен, официально поддерживается или связан с безопасностью.
Начну немного с вводной, кому неинтересно, можно сразу перейти к технической части статьи.
Недавно я пробовал пройти собеседование в Kaspersky. Ну, как пробовал, если честно даже не дошел до технического этапа :) В общем, я получил реджект. Причина отказа: "решили выйти с предложением к кандидату, который прошел все финальные встречи". Не сказать, что у меня не было опыта в реверсе. Я пару раз реверсил прошивки, но в основном тестировал способы обхода лицензий в продуктах компании. Но вот именно анализом malware как таковым не занимался. Поэтому, буду восполнять этот пробел, ну и попутно буду документировать это все в небольших статьях, поскольку когда пробуешь что-то объяснить другим, сам разбираешься в вопросе еще глубже.
VPN шифрует ваш трафик, но не скрывает сам факт использования VPN. Провайдер знает — и вот как именно. Разбираю четыре уровня обнаружения: от проверки IP по базам до DPI-анализа TLS fingerprint’ов и российских ТСПУ с пропускной способностью 132 Тбит/с, которые в марте 2026-го ушли в bypass из-за перегрузки.
Когда мы слышим об очередной крупной утечке данных — клиентских баз, исходных кодов или коммерческой тайны — в отчетах часто фигурируют формулировки «злоумышленник получил доступ» или «был скомпрометирован сервер». Но за этими общими фразами скрывается принципиально важная деталь: утечка редко является разовым событием. Да, не стоит забывать об инсайдерах, выносящих данные на флешках, но как правило это носит разовый характер.
А в подавляющем большинстве случаев системные утечки — это процесс, управляемый извне. И ключ к расследованию, минимизации ущерба и построению защиты лежит в детектировании инфраструктуры Command & Control (C2). Без понимания того, как работает C2, SOC превращается в пожарную команду, тушащую искры, но не видящую самого пожара.
В этой статье мы разберем, почему C2 — это не просто «вирус», а архитектурный принцип современных атак, и как выстроить расследование вокруг этого понятия.
Громкой новостью прошлой недели стал взлом библиотеки LiteLLM, используемой в качестве посредника для коммуникации с большим количеством языковых моделей (сообщение от разработчиков, новость на Хабре). Через другое вредоносное приложение на Python была взломана учетная запись мейнтейнера проекта, после чего сразу две версии LiteLLM (1.82.7 и 1.82.8) с вредоносными модулями были загружены в репозиторий PyPI. Отчет с анализом вредоносного кода опубликовали эксперты «Лаборатории Касперского».
В версии 1.82.7 вредоносный код был встроен в файл proxy_server.py. В версии 1.82.8 дополнительно появился .pth-файл, благодаря которому вредоносный код выполнялся при каждом запуске интерпретатора, даже если зараженная библиотека не использовалась. После запуска зараженный скрипт начинал рекурсивный обход рабочих директорий в системе жертвы. В каждой директории скрипт просматривал содержимое файлов, которое выводил в буфер stdout и сохранял в файл для последующей отправки на командный сервер злоумышленников. Далее скрипт собирал информацию о системе и также сохранял в файл. После этого он переходил к поиску конфиденциальных данных, включая следующие типы:
Недавно я почитал про будущих ИИ-хакеров (ИИ-агенты на базе рассуждающих моделей, натренированные для взлома систем) и понял, что проблема намного больше, чем «станет больше кибератак». Это уже не выглядит фантазией. OpenAI прямо пишет, что готовится к моделям уровня, способного создавать рабочие zero-day-эксплойты против хорошо защищённых систем или существенно помогать в сложных скрытных вторжениях и уже показывает оборонительную версию той же идеи: их agentic security researcher Aardvark ищет уязвимости в кодовых базах, предлагает патчи и уже находил новые CVE. Anthropic и другие лидеры отрасли также ведут работу в этом направлении и уже демонстрируют сильные результаты по части обнаружения уязвимостей в кодовых базах.
Главная проблема тут не в том, что ИИ начнёт взламывать лучше человека. Главная проблема в другом: он почти обнулит стоимость ещё одной попытки атаки.
До сих пор интернет держался на простом, хотя и неявном компромиссе. Да, системы ломали, деньги крали, базы утекали, людей фишили. Но хорошая атака всё ещё стоила дорого. Чтобы реально атаковать сложные системы, нужны были люди, квалификация, время, инфраструктура, терпение. Защитник не обязан был быть идеальным. Ему часто было достаточно сделать атаку слишком сложной, слишком долгой или слишком дорогой.
ИИ меняет именно это.
Он не просто помогает писать код или искать баги. Он удешевляет всю цепочку: поиск поверхности атаки, перебор гипотез, написание и адаптацию эксплойтов, анализ ошибок, обход защит, повторные попытки, смену тактики, масштабирование сработавшего сценария на тысячи целей. Не получилось с первого раза - попробует со второго, с сотого, с тысячного. Без усталости. Без дефицита специалистов. Почти без предельной стоимости каждой новой попытки.
Исследования IBM, ReliaQuest и Resilience показывают, что ИИ сделал киберпреступность гораздо эффективней. У злоумышленников стало меньше барьеров для входа, больше возможностей для масштабирования. При этом главные слабые места остаются прежними: слабые процедуры help desk, плохая видимость устройств, ошибки в управлении доступом, компрометация почты и мошеннические переводы. Искусственный интеллект ускорил старые схемы, удешевил их и масштабировал. Теперь черные страшные хакеры используют генеративные модели для правдоподобного фишинга, социальной инженерии и ускорения вторжений, а окно на реакцию у светлой стороны силы — старых добрых безопасников — резко сжалось до нескольких минут. Попробуй успей…
Разберем основные тезисы отчета Cyber Risk Report 2025, выпущенного компанией Resilience совместно с ее аналитическим подразделением ROC (Resilience Risk Operations Center).
BIP39 вместо номера телефона, ECDH P-256 + AES-256-GCM, non-extractable CryptoKey, трафик неотличимый от HTTPS. Как это устроено, что сломалось в процессе и почему некоторые решения были болезненными.
Представьте, что вы не знаете, какие устройства подключены к вашей сети, как они настроены и что там происходит. Страшно? Ещё бы! Многие компании как раз так и живут — не уделяют внимания аудиту сетевого оборудования. А зря. Без такой инвентаризации невозможно ни нормально управлять ИТ-инфраструктурой, ни защититься от угроз.
Мы наблюдаем в инфраструктуре клиентов это так часто, что поняли – нужно выдать базу. Мы – это руководитель практики развития MaxPatrol Carbon Константин Маньяков и эксперт центра безопасности (PT ESC) Данил Зарипов, и в этой статье мы будем разбираться в ключевых аспектах аудита сетевых устройств, его роли в построении эффективного управления активами и повышении уровня защищенности ИТ-инфраструктуры.
Многие разработчики в последнее время используют облачные LLM для генерации программного кода, в том числе с помощью агентов. Но это вызывает как минимум две проблемы:
Утечка информации: мы не знаем, какие данные LLM передаёт в облако
Бесконтрольный расход токенов, особенно в случае автоматических агентов, которые запускаются в автономную работу на длительный период
Для этого есть специальные инструменты мониторинга. Например, Tokentap (бывший Sherlock) отслеживает использование токенов для LLM CLI в реальном времени на панели в консоли. Такой MitM-прокси полезен для информационной безопасности и просто для учёта расходов.
Я работаю директором по цифровой трансформации. И каждый раз, когда собираю бюджет, вижу одну и ту же картину: на ИТ денег мало, на ИБ — ещё меньше. При этом требования растут, угрозы множатся, а формулировка от бизнеса : «сделай так, чтобы работало удобно, из любого места и без пароля желательно, ну и не ломалось».
Как и многие я ищу идеальную формулу: минимум вложений → максимум защиты. Не «купить всё и сразу», не «внедрить SOC за 10 миллионов в год», а именно базовую базу по ИТ и ИБ, которая закрывает 80% рисков и не требует армии сотрудников для ее поддержания.
Эта статья — про то, как за разумные деньги выстроить защиту основывая на собственных ошибках и опыте. С цифрами, с инструментами, с калькулятором.
ИБ‑гигиена — это не SOC, не «киберщит» и не магический короб. Это несколько приземлённых вещей: MFA, антивирус, бэкапы, ролевая модель и обучение людей. Всё это стоит сильно дешевле одного серьёзного инцидента.
Всё началось с простой задачи: нужно было безопасно передавать файлы на обычных USB-флешках. Существующие решения либо создавали контейнеры (VeraCrypt), что неудобно для быстрого доступа к отдельным файлам на разных ОС, либо работали слишком сложно для конечного пользователя.
Мне нужно было решение уровня «вставил флешку -> ввел пароль -> файлы зашифрованы». Но главное требование — безопасность данных даже при сбое питания. Если выдернуть флешку посередине шифрования, данные не должны превратиться в кашу.
Так появился crypto_engine. Это не попытка изобрести свою криптографию (мы используем стандартные AES-GCM и ChaCha20), а инженерная работа над тем, как безопасно управлять ключами в памяти, обрабатывать гигабайтные файлы без переполнения RAM и гарантировать целостность данных.
Ниже представлен алгоритм построения архитектуры информационной безопасности (ИБ) при использовании технологии виртуализации на основе документа РС БР ИББС-2.8-2015.
Алгоритм построен по принципу разветвляющейся блок-схемы, аналогичной приведённому примеру. Он учитывает ключевые требования: разделение контуров безопасности, изоляцию, сертификацию средств защиты информации (СЗИ) и разграничение ролей.