Информационная безопасность

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

Использование машинного обучения — один из эффективных способов автоматизации поиска таких угроз. В этой статье мы рассмотрим, как одну и ту же задачу можно решать разными ML алгоритмами: Isolation Forest, Catboost, Autoncoder. В чём особенности, преимущества и ограничения каждого подхода?

Несколько месяцев назад я делал плановую проверку кодовой базы на одном из проектов и нашёл обфусцированный код в файле vite.config.js. Он был на той же строке что и закрывающий };, но сдвинут вправо на несколько сотен пробелов — туда, куда ни один diff-вьюер не прокрутит и ни один редактор не покажет без горизонтального скролла.

Я пошёл смотреть через git log — какой коммит это принёс. Оказался merge-коммит. Не обычный коммит в ветке — именно merge. И вот тут началось интересное.

К 2026 году в Zscaler нет каких‑то уникальных технологий, которых нельзя встретить в других продуктах. По сути, это просто очень удачно собранный и упакованный набор сервисов, который удобно потреблять как SaaS. Проблема в том, что повторить тот же набор возможностей в собственной инфраструктуре — задача нетривиальная: нужны и компетенции, и ресурсы, и бюджет, который для многих компаний оказывается избыточным.

В какой‑то момент наша команда оказались в ситуации, когда нужно было обеспечить непрерывность сервисов для заказчиков в РФ, у которых уже был Zscaler. Это заставило нас пересобрать подход: выделить действительно критичный функционал и понять, как его можно реализовать альтернативным способом.

В этой статье разберу один из вариантов, к которому мы в итоге пришли. Сразу оговорюсь: полную замены Zscaler мы не делали — но закрыть значимую часть задач оказалось вполне реально.

31 марта 2026 года наружу буквально вывалились исходники Claude Code (через sourcemap в npm‑пакете). История уже сама по себе комичная: продукт, который помогает писать код и в теории должен быть особенно аккуратен с публикацией артефактов, случайно публикует не просто кусок дебажной информации, а почти анатомический атлас самого себя.

Но меня в этой истории интересует не столько сам факт утечки, сколько более приземлённый вопрос: что там внутри? Если убрать обычное для таких случаев «вау, утекло», остаётся более интересная интонация: ну‑ка, посмотрим, что тут у нас (или «там у них»?) и нормально ли там написан код.

Разработчик уволился. Через полгода появился похожий продукт, бывший сотрудник открыл ИП и зарегистрировал программу на себя. Или команда ушла к конкуренту и унесла кодовую базу. Или компания вложила несколько миллионов в разработку, а в суде выяснилось, что доказать принадлежность кода некому.

Такие истории заканчиваются не быстро. Судебные разбирательства по правам на ПО, это от года до трёх лет, экспертизы исходных кодов, пяти- и шестизначные суммы судебных расходов. Итог зависит от того, что компания успела сделать до конфликта, а не после.

Когда мы говорим об атаках через цепочку поставок, обычно всплывает в голове что-то монументальное - SolarWinds, взлом инфраструктуры гигантов. Но правда в том, что сегодня любой бизнес, который нанимает внешних админов или DevOps-инженеров, рискует заполучить зловреда, способного годами сидеть в периметре и сливать базы данных(БД). И вы об этом даже не узнаете…

В этой статье - хочу поделиться реальным случаем из практики. Как взлом ноутбука подрядчика привел к внедрению eBPF-руткита в Linux. Раскрыть атаку помогла… ну, скажем так, случайная оплошность самих злоумышленников.

В начале ноября 2025 года децентрализованный протокол Balancer V2 (composable stable pools) подвергся атаке, суммарные потери по разным сетям превысили 128 млн долларов. Причиной стала не ошибка доступа, не реентерабельность и не баг в проверках прав, а потеря точности при расчете инварианта из-за округления. Формально проблема сводилась к округлению при масштабировании значений и выглядела как допустимый технический компромисс. Экономический эффект, однако, оказался значительным.

Взлом Balancer, как и многие другие инциденты, уже подробно разобран в формате post-mortem — с реконструкцией того, как именно была проведена атака. В этой статье подход другой: мы посмотрим на тот же код глазами аудитора, который задается вопросом «что здесь может пойти не так?».

Всем привет! Меня зовут Егор, я аудитор по информационной безопасности в Selectel. Мы как провайдер IT-инфраструктуры работаем с компаниями из разных отраслей и часто сталкиваемся с одним вопросом, когда речь заходит о безопасности: кто именно отвечает за безопасность в облаке — провайдер или клиент?

Полтора года назад я писал статью «Я тебя найду и позвоню», которая начиналась с кейса угона клиентов, но затрагивала возможность пробива любого абонента. Статья вызвала резонанс, и благодаря этому сервис, показанный в статье, закрыл дыру!

И вот прошло 1,5 года, а что теперь? А теперь мы посмотрим на другие сервисы, но тоже связанные с операторами связи и таргетированной рекламой. Они выводы не сделали. Ведь как оказалось, у них все ГОРАЗДО хуже. Проще пробивать, достаточно звонка или клика по безобидной ссылке, а найти можно гораздо больше. А главное, это по прежнему бесплатно!

Ваши данные доступны всем, бесплатно и в удобной форме. Почему? Читайте ниже!

Внимание, это НЕ шутка на 1 апреля.

Источники называют 1 апреля датой возможной полной блокировки Telegram. Но абсолютная блокировка технически почти невозможна — и вот почему. Разбираю 7 причин: от MTProxy, который перегружает ТСПУ мусорным трафиком, до collateral damage при блокировке CDN и парадокса, при котором более агрессивная фильтрация ломает систему блокировок изнутри.

В апреле мы традиционно отдаем микрофон нашему начальнику отдела безопасности Алексею Дрозду (aka @labyrinth, который каждый год собирает для нас подборку забавных и парадоксальных ИБ-инцидентов. Шеф ИБ допускает утечку, криптокошельки пустеют после фотосессии налоговой, нейросеть собирает армию пылесосов-шпионов – все подробности под катом.

ДИСКЛЕЙМЕР:

Автор не призывает к игре с сторонним ПО. Вся информация, приведенная в статье - приведена лишь в образовательных и ознакомительных целях. Информация была взята из открытых источников и ни к чему не призывает.

СОДЕРЖАНИЕ:

Всем привет! Меня зовут Александр Барыков, я руковожу платформенной командой 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 как таковым не занимался. Поэтому, буду восполнять этот пробел, ну и попутно буду документировать это все в небольших статьях, поскольку когда пробуешь что-то объяснить другим, сам разбираешься в вопросе еще глубже.