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

Последний рубеж: почему ленточная библиотека — это самый надёжный «холодный кошелёк» для данных

В 2025 году мировые потери от киберпреступности, по оценкам отраслевых аналитиков, превысили один триллион долларов США — «это ж сколько стран можно было прокормить?!». В подавляющем большинстве случаев речь идёт об атаках программ‑вымогателей. И в каждом таком инциденте рано или поздно возникает один и тот же вопрос: существует ли копия данных, до которой злоумышленник не сможет добраться?

Всем привет! Меня зовут Дмитрий Передрий, я старший инженер сопровождения BI.ZONE WAF. В этом году сфокусировался на развитии и модернизации систем мониторинга. В последнем проекте добился хорошего результата и хочу этим поделиться.

Главным врагом систем мониторинга я вижу огромное количество ложноположительных срабатываний. В статье покажу один интересный и эффективный способ борьбы с ними.

Все началось с обычного тикета в Jira, из тех, которые выглядят безобидно и даже немного скучно. «Нужно протестировать новый личный кабинет. Разверни тестовую базу». Через несколько месяцев этот тикет аукнулся сорванным релизом, сгоревшим маркетинговым бюджетом и отложенным запуском важнейшего сервиса. А Олег, как всегда, остался крайним.

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

На прошлой неделе были опубликованы сразу три научные работы, так или иначе предлагающие варианты атаки Rowhammer для видеокарт Nvidia. Подобные атаки часто имеют чисто научный интерес, но не в этом случае: во всех работах показаны методы эксплуатации с реально опасными последствиями вплоть до получения прав суперпользователя на целевой системе. Новые атаки были испытаны на видеокартах с видеопамятью стандарта GDDR6, в частности на GeForce RTX3060 и RTX6000. Именно для RTX6000 и подобных моделей новые атаки наиболее актуальны, так как это промышленный видеоускоритель, часто используемый в облачных решениях с общим доступом к вычислительным ресурсам. Именно там перехват контроля над системой‑хостом со стороны клиента представляет наибольшую опасность.

Самая первая атака Rowhammer была впервые продемонстрирована в 2014 году в отношении модулей памяти DDR3. Возможность изменения данных в ячейках памяти при обращении к соседним рядам ячеек была известна и ранее, но именно 12 лет назад эту особенность применили для целевого изменения данных в оперативной памяти так, чтобы, например, создать условия для выполнения произвольного кода или похитить секретные данные. С тех пор были предложены как методы противодействия подобным атакам, так и способы их обхода. Последним достижением академических исследователей стала демонстрация атаки «класса» Rowhammer на новейшие модули памяти стандарта DDR5.

Современный арсенал средств защиты корпоративных сетей велик и разнообразен: межсетевые экраны нового поколения (NGFW), средства защиты веб-приложений (WAF), системы защиты от DDoS-атак, песочницы (Sandbox) и анализаторы сетевого трафика (NTA). Однако существует целый класс решений, которому, на наш взгляд, уделяется незаслуженно мало внимания, — это системы контроля и управления доступом к сети или NAC (Network Access Control).

Данная статья призвана исправить этот пробел. Мы поговорим не о конкретных продуктах, а о самой идее контроля доступа в сеть: для чего это нужно, как работает и на какие ключевые аспекты стоит обратить внимание при выборе NAC-решения.

Когда я только начинал в ИБ, я часами лазил по сайтам в попытках понять: а что вообще нужно знать новичку? Какими базовыми вещами должен владеть специалист по защите информации — будь то внутри контура организации или за его пределами.

Так я наткнулся на статьи про СЗИ — средства защиты информации. По сути, это тот самый инструментарий, с помощью которого специалист и строит защиту.

Думаю, выпущу несколько материалов, где своими словами разберу разные виды СЗИ. Для тех, кто только вникает в профессию, — чтобы было проще ориентироваться в этих штуках.

СПИСОК СЗИ ПРО КОТОРЫЕ Я РАССКАЗЫВАЮ В ЭТОЙ СТАТЬЕ:

1. Межсетевой экран (МЭ) — он же Firewall (англ.) или Brandmauer (нем.).

2. IDS/IPS — Intrusion Detection System / Intrusion Prevention System

3. DLP — Data Leak Prevention

4. SIEM — Security Information and Event Management

5. Sandbox — «песочница»

Межсетевой экран

Думаю, многие уже слышали о межсетевых экранах. Их называют по-разному: Firewall — с английского «огненная стена», или Brandmauer — с немецкого тоже «огненная стена». В общем как ни назови, он делает одно и то же — не дает нежелательному трафику проникнуть в сеть.

Антифрод — это комплекс мер, технологий и процессов, направленных на предотвращение, выявление и минимизацию ущерба от мошеннических действий. Простыми словами — это система, которая борется со злоумышленниками во всех ипостасях. Коллеги на Хабре недавно делали обзор по теме. Также рекомендуем ещё свежую аналитику за 2025 год.

А наша статья посвящена патентам и свидетельствам на антифрод‑системы в России и мире.

Вскоре после нахождения шпионского модуля в Max я обнаружил критическую уязвимость во всех известных VLESS клиентах.

Эта уязвимость позволяет обходить per-app split tunneling и приватные пространства (Knox/Shelter/Island/etc) и гарантированно обнаруживать выходной ip прокси, который вы используете.

При этом один из клиентов уязвим настолько, что позволяет дампить ваши конфиги и, в худшем случае, расшифровать весь ваш трафик.

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

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

Новый пост-квантовый гибридный алгоритм шифрования для высоко-нагруженных систем с реализацией на TypeScript. Ring-LWE, работа с ключами с использованием MAC и SHAKE-256, защита от основных видов атак и другие мысли в реализации протокола QuarkDash.

Расскажем, как нам удалось повысить качество определения истинных секретов в результатах сканирования кода с 0.70 до 0.90 PR AUC с помощью LLM.

AIVPN — это VPN-протокол на Rust, который не только шифрует трафик, но и маскирует его под реальные приложения. Внутри: короткие криптотеги вместо открытого идентификатора сессии, малозаметный старт соединения, профили масок для мимикрии трафика и легковесный модуль нейросетевого резонанса, который отслеживает деградацию маски и позволяет автоматически переключаться на резервный профиль. Сейчас проекту нужна поддержка для развития протокола и выпуска iOS-версии с оплатой Apple Developer Program и размещением в App Store.

Пока мы ждём, что в Telegram наконец раскатится обновлённая реализация Fake-TLS, хочу рассказать о своей реализации MTProto-прокси 2018 года, которая снова становится актуальной, и об одной из её уникальных возможностей.

MTProto-прокси — решение для обхода блокировок Telegram в странах с интернет-цензурой (мы говорим про Иран конечно же 😄). Типичная схема выглядит так: оператор поднимает прокси с одним секретным ключем на всех, публикует одну ссылку, и тысячи людей ей пользуются. Просто, но у этой модели есть реальные ограничения:

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

Нет аналитики на пользователя. Видно общее число соединений и IP-адреса, но не понять, кто активен, кто раздал свою ссылку полусотне друзей и кто потребляет весь ваш трафик.

Ограниченная монетизация. Да, есть “спонсорские каналы”, но если хотите продавать доступ — не за что зацепиться: секрет один на всех, привязать подписку не к чему.

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

Хабр, привет!

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

31 марта 2026 года один из самых популярных npm-пакетов в мире превратился в оружие. Разбираем, как устроена атака на цепочку поставок через axios, почему классические средства защиты могут не выручить на этапе заражения – и как DNS-уровень оказался барьером, который предотвратил крупнейший инцидент.

Мгновенная атака

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

Все еще хорошо – информационная система сети отелей работает исправно, заселяя больше 500 гостей в минуту.

Вы открываете дверь такси и выходите. До стойки ресепшн рукой подать, идти чуть больше минуты - 89 секунд. Но дойдя до нее вы видите, как меняется лицо администратора. Глядя в экран, она видит сообщение о сбое всех систем.

Именно столько – 89 секунд прошло между публикацией вредоносной версии axios и первым заражением. Горизонтальное же продвижение злоумышленников, вооруженных мощью автономных AI-агентов может быть мгновенным. Получив доступ к переменным окружения, токенам CI/CD, ключам доступа к облакам, БД, API платёжных шлюзов, секретам Kubernetes с компьютеров разработчиков – дальнейшее дело техники.

И это реальное описание того, что могло бы случиться, если бы клиент не использовал сервис DNS-фильтрации.

«Где мои логи — в /var/log/messages, /var/log/syslog или только в journalctl?» — этот вопрос рано или поздно задает себе каждый инженер, который вынужден переключаться между разными дистрибутивами: Ubuntu, CentOS, Alpine, корпоративные Unix системы. 

Типичный сценарий: вы заходите на сервер, ищете /var/log/messages, а его или нет, или он есть, но journalctl показывает гораздо больше событий, чем файл. 

Иногда сервер внезапно начинает сильно использовать CPU, и в итоге причиной оказывается агрессивное логирование. 

Если к этому добавить разнородный парк, где рядом с Ubuntu живут динозавры на AIX и Solaris, путаница приобретает глобальный характер. 

Сейчас мы живем в эпоху «двоевластия»: systemd‑journald уже стал стандартом де‑факто, но rsyslog все еще присутствует во многих дистрибутивах по инерции или ради совместимости. Эта статья для инженеров, которые хотят понимать, кто именно пишет логи в Linux, почему они дублируются, где теряются CPU и I/O, и как настроить логирование так, чтобы диск не превращался в помойку. 

Мы пройдем путь от бинарных логов AIX до journald, а в конце разберемся, как практически использовать journalctl с популярными инфраструктурными службами. 

Привет! Меня зовут Леонид Плетнев, я бизнес-партнер по информационной безопасности в 1С-Битрикс. 

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

Вы уверены, что ваш “случайный” пароль действительно случайный?

Я тоже так думал — пока не полез разбираться, как Python на самом деле генерирует случайные значения. Оказалось, что привычный random — это не про безопасность вообще. Это генератор, который только выглядит случайным, но при определённых условиях может быть воспроизведён. Что даст нам возможность предсказать все будущие пароли и прошлые.

В статье я последовательно разбираю:

• почему классическая “энтропия пароля” часто вводит в заблуждение;

• как устроен Mersenne Twister и в чём его фундаментальная проблема;

• почему даже хороший seed (через os.urandom) не делает random безопасным;

• и что на практике можно (и нельзя) восстановить, имея время генерации, код и несколько паролей.

Я попытался воспроизвести реальную атаку: восстановить seed по временной метке и набору сгенерированных паролей. Спойлер — всё оказалось сложнее, чем кажется.

Отдельно показываю, где проходит граница между «кажется надёжным» и «действительно криптостойким», и почему secrets — это не просто «рекомендованный модуль», а принципиально другой класс генерации.

LLM-агенты отлично решают алгоритмические задачи. Но что произойдет, если поместить их в реальную инфраструктуру – с CI/CD, branch protection и security-политиками?

Я провел эксперимент: дал агентам простую задачу – внести изменение в репозиторий и замерджить его в main, соблюдая все правила. При этом у них был доступ к тем же инструментам, что и у разработчика, включая GitHub CLI и админский токен.

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

Мы привыкли, что повтор r в ECDSA — это случайный сбой: плохой генератор, ошибка реализации, повтор nonce. Но что, если за одним repeated-r скрывается целое семейство дефектов (defect-family), которое можно не только обнаружить, но и перенести на другие закрытые ключи?

Представляем закрытую исследовательскую систему — стратификационный анализ ECDSA-подписей на secp256k1. Вместо точечных аномалий мы смотрим на фазовые корпуса подписей, используем торическую геометрию, kNN и перестановочные тесты. Результат:

· Во внешнем корпусе из 30 адресных контекстов и 6257 подписей repeated-r найден только в 1 контексте, межадресных коллизий r — 0. · 58 из 58 контролируемых переносов defect-family с реального адреса-донора на панель реальных адресных целей прошли с полной ECDSA-валидацией реконструированных подписей. · Встроенный publication-safety audit заблокировал открытый bundle, обнаружив 498 проблем (30 критических) — от raw (r,s,z) до восстановленных синтетических k и фрагментов закрытых ключей.

В публичной версии отчёта — только математика, агрегаты и безопасные листинги. Никаких инструкций по эксплуатации. Это продолжение методологии AuditCore, но уже на уровне стратифицированного анализа.

Плотность WiFi-точек в городах достигло такой величины, что позволяет развернуть систему массовой слежки за населением с идентификацией всех граждан, кто проходит возле точки доступа, даже если у них нет с собой мобильного телефона. Исследователи из Технического университета Карлсруэ (KIT) опубликовали научную статью с техническим описанием такой системы.