Обновлён репозиторий untidetect‑tools со списком сервисов для анти‑детекта в сети, включая:
анти‑детект‑браузеры, который меняют цифровой след и позволяют остаться незамеченным;
библиотеки для анонимного сёрфинга, что интегрируются прямо в код;
ПО для эмуляции реального поведения человека на сайтах и платформах;
системы обхода капчи и сервисы для получения e‑mail и СМС;
практические советы по приватному сёрфингу в сети.
Можно ли настроить MFA за 15 минут?
Узнайте на вебинаре Avanpost 17 сентября
Можно ли усилить защиту удаленного доступа сотрудников всего за 15 минут? Эксперты Avanpost утверждают, что да, — и готовы доказать это в прямом эфире.
Avanpost начинает серию вебинаров о простой и быстрой организации Identity Security.
В первом выпуске:
✔️ эксперты расскажут об эталонной архитектуре Avanpost Identity Cloud,
✔️ докажут, что путь к Zero Trust из облака проще, чем кажется
✔️ и главное — покажут, как всего за 15 минут защитить подключение к удаленному рабочему месту сотрудника.
17 сентября в 11:00 мск ведущие запустят таймер и с нуля настроят MFA с помощью Avanpost Identity Cloud. А вы сможете наблюдать за всем процессом.
За эти 15 минут они:
✅ Развернут новый экземпляр Avanpost MFA+ в облаке;
✅ Настроят политику многофакторной аутентификации;
✅ Привяжут Avanpost Authenticator через QR-код;
✅ Включат многофакторную аутентификацию для OpenVPN;
✅ Выполнят вход с подтверждением на смартфоне.
😊Выглядит непросто? Тем интереснее проверить.
Присоединяйтесь и смотрите эфир до конца — участников ждет уникальное предложение от Avanpost, с которым защитить доступ сотрудников можно не только быстро, но и выгодно.
➡️ Зарегистрироваться
Пропустил ИТ-митап, который прошел в офисе КОРУСа 9 сентября? Обязательно ждем тебя в следующий раз! А пока делимся записями докладов 🤩
⬆️ИИ-инструменты для аналитика — что изменилось за 2 года
Спикер: Даниил Иванов, руководитель группы аналитики департамента CRM&BPM
⬆️Автоматизация тестирования с помощью ИИ — идеи, гипотезы и результаты
Спикер: Татьяна Веселова, руководитель направления ELMA департамента CRM&BPM
⬆️Безопасная разработка Android-приложения: уязвимости в вашем коде и как их исправить
Спикер: Арнольд Соболев, младший программист АО «ИнфоТеКС»
Смотри и слушай доклады в ВК Видео и следи за новостями о следующих мероприятиях 👀
#внутри_КОРУСа
Постквантовый TLS на nginx: стоимость рукопожатия
Стоимость рукопожатия в постквантовом TLS на nginx складывается из CPU криптографии, объёма обмена и сети. Результат для ML-KEM TLS на nginx верен только для заданных версий ПО, группы, клиента, RTT, MTU и resumption.
Сколько задержки добавляет гибридный постквантовый TLS?
Гибридный обмен добавляет ML-KEM и увеличивает сообщения TLS, поэтому прибавка зависит от стенда. В локальной сети большую долю задержки может дать CPU, а при высоком RTT и потерях сильнее влияет сеть. Разницу показывают парные cold-прогоны с одной группой, cipher suite, RTT и MTU.
Классический, постквантовый и гибридный обмен без терминологической путаницы
X25519MLKEM768 сочетает X25519 и ML-KEM-768. Подпись и симметричный шифр остаются классическими, и свойства ML-KEM на них не переносятся. Поле negotiated group подтверждает ML-KEM TLS на nginx, а отчёт указывает классическую часть и алгоритм подписи.
Версии, provider и совместимость nginx с клиентами
Набор групп задают TLS-библиотека и provider, поэтому в отчёт идут nginx -V, версия libcrypto и флаги сборки. Бенчмарк постквантового TLS проводят после согласования с целевыми клиентами:
nginx -V openssl list -tls1_3 -tls-groups openssl s_client -connect HOST:443 -servername HOST -groups X25519MLKEM768 -brief
Старые реализации с draft code points идут отдельной серией.
Где появляются дополнительные вычисления и байты
В полном handshake клиент отправляет ML-KEM key share, а сервер инкапсулирует секрет. Для X25519MLKEM768 shares клиента и сервера составляют 1216 и 1120 байт. Задержка гибридного TLS-рукопожатия зависит от MTU и retransmissions.
Убирает ли session resumption основную часть расходов?
Session resumption убирает передачу сертификата, но эфемерный обмен может остаться. В TLS 1.3 psk_dhe_ke снова выполняет эфемерный обмен, psk_ke его пропускает и не добавляет новой прямой секретности. Cold и resumed handshakes проверяют раздельно, фиксируя pcap, negotiated mode, CPU и факт возобновления.
Классика, гибрид, холодный старт и resumption
X25519 и X25519MLKEM768 сравнивают при одинаковых cipher suite, цепочке сертификатов и nginx.conf, разделяя cold и resumed-серии. Производительность PQC на nginx показывают CPU-замеры и pcap, а RFC 10024 задаёт размеры shares для сверки. tc netem меняет RTT, потери проверяют отдельно.
Cycles, насыщение ядер и предел новых соединений
Стоимость ML-KEM в TLS 1.3 считают как разницу cycles и CPU time между гибридом и контролем, делённую на число cold handshakes. Нагрузку поднимают до плато, записывая CPU, %steal, ошибки accept и listen queue.
Размер обмена, RTT и чувствительность к потерям
Pcap даёт байты по направлениям, TLS records, пакеты и retransmissions. Одинаковая certificate chain отделяет цену key share от сертификата. Wall latency сопоставляют с RTT, серию с потерями держат отдельно.
Какие метрики nginx и TLS нужно измерять?
1. CPU cycles и CPU time на успешный cold и resumed handshake.
2. Wall latency p50/p95/p99, negotiation errors и новые соединения в секунду.
3. Байты, TLS records, пакеты, retransmissions и negotiated group.
Reuse, session resumption и защита от handshake-флуда
Keep-alive сокращает число новых соединений. Конфигурация задаёт session cache, а лог и метрики подтверждают PSK и hit rate. Rate limit и CPU-резерв считают по числу новых соединений. Reuse помогает против честного трафика, но атакующий открывает новые соединения, и каждое стоит полного обмена.
Совместимость, canary и наблюдаемые критерии отката
Долю поддерживающих клиентов и поведение fallback проверяют до canary. В мониторинге раздельно видны negotiation errors, p95/p99, CPU и resumption rate. Requests per second для полных рукопожатий считают отдельно от HTTP RPS. Выход за SLO или CPU-бюджет означает откат.
Стоимость рукопожатия в постквантовом TLS на nginx приемлема, если клиенты согласуют стандартную группу, серии укладываются в SLO при заданных RTT и MTU, а CPU сохраняет запас. Иначе canary сужают или остаются на классической группе.
Я написал, что система умеет откатывать действия агента. Потом открыл код
В анонсе своего проекта я написал: «журнал — это последовательность действий, по нему можно пройти назад и честно остановиться на первом шаге, который отменить нельзя». Фраза мне нравилась. Перед публикацией я решил проверить, делает ли это код.
Код откатывал один шаг по идентификатору. Никакого прохода назад, ни остановки на необратимом. До публикации оставалось несколько часов.
Функцию я написал — вместо того чтобы смягчить формулировку. И на первом же запуске поймал две вещи.
Порядок прохода я задал сортировкой по времени — и получил неправильный порядок. Отметки хранятся с точностью до секунды, несколько шагов делят одну и ту же, а стабильная сортировка при равных ключах сохраняет исходный порядок. При reverse=True часть шагов шла вперёд. Порядок графа задаёт последовательность выполнения, а не строка времени; время решает только, попал ли шаг в окно.
Панель разошлась с движком. Она показывает, что произойдёт, до нажатия кнопки: сколько действий отменится и где проход встанет. Превью обещало остановку на «Сборке пакета», а откат отменил все шесть действий. Превью считало отсутствие ключа признаком необратимости, движок для отсутствующего ключа возвращал компенсацию по умолчанию. Два места, одно правило, разная трактовка.
Это ровно то, против чего всё и строится: обещание отката, которое молча не сработало, хуже отсутствия отката — во втором случае человек хотя бы знает, что разбираться придётся руками. Теперь превью спрашивает правило у самой профессии, а не повторяет его своими словами, и есть тест, единственная работа которого — упасть, если эти двое снова разойдутся.
Двумя неделями раньше — ошибка того же рода
Журнал, который проверяет только автор, ничего не доказывает. Поэтому верификатор написан на другом языке: пишет Python, проверяет TypeScript.
На тесте, где JS-верификатор читает журнал, созданный Python, выяснилось, что json.dumps сериализует 0.0 как "0.0", а JSON.stringify то же число — как "0". Строки разные, хеши разные, одна и та же честная запись хешируется по-разному.
Последствие: система объявила бы настоящий журнал поддельным. Не пропустила бы подделку — обвинила бы в подлоге того, кто ничего не подделывал.
def _jcs_numbers(value: Any) -> Any: """Приводит числа к форме, одинаковой в Python и JavaScript.""" if isinstance(value, bool): return value if isinstance(value, float) and value.is_integer(): return int(value)
Проверка на bool не паранойя: в Python True — экземпляр int, без этой ветки булево уехало бы в числовую нормализацию.
Писал бы верификатор я сам, на том же Python, — ошибка дожила бы до первого спора с клиентом.
Функция, которой намеренно нет
Проект отдаёт наружу MCP-сервер, JSON-API и ноду n8n. Все три умеют выполнять шаги, спрашивать разрешение и читать журнал. Ни один не умеет подтверждать.
Если бы модель могла вызвать confirm, человек исчез бы из цепочки: агент сам себе разрешал бы необратимое действие. Поэтому карточка подтверждения уходит человеку, а в списке инструментов MCP такого инструмента нет — и есть тест, который упадёт, если он там появится. По той же причине там нет отката: он пишется в журнал как решение оператора, и агент, отменяющий свои действия, расписывался бы чужим именем.
Что вынес
Проверка на другом языке ловит то, чего не видит ни один тест, написанный в той же голове и в той же экосистеме. Разница между 0.0 и 0 не находится ревью.
И второе, менее приятное: между «я написал это в описании» и «это работает» расстояние больше, чем кажется. Я поймал у себя обещанную и несуществующую функцию за несколько часов до анонса — просто потому, что решил открыть файл и прочитать, что там написано.
Альфа, 115 тестов, ноль зависимостей, AGPL-3.0: github.com/oleg-vdv/kepil. Верификатор отдельно и под MIT: agent-trace.
Программа конференции GoCloud Tech 2026 уже на сайте
Зарегистрировались на конференцию для тех, кто двигает прогресс в эпоху искусственного интеллекта? Самое время выбрать свой трек:
В треке «Инфраструктура»
Расскажем, как устроена облачная инфраструктура и как она меняется с ростом ИИ-нагрузок. Обсудим безопасность, отказоустойчивость и инженерные компромиссы при создании инфраструктурных сервисов.
Ждем: архитекторов, инженеров, DevOps и SRE, системных администраторов, технических лидеров и всех, кто проектирует, развивает или эксплуатирует облачную инфраструктуру и ИИ-платформы.
В треке «Разработка»
Обсудим, как меняется процесс разработки платформ с приходом ИИ. Обсудим безопасность, разработку собственных решений и границы возможностей ИИ-агентов.
Ждем: техлидов, backend-разработчиков, DevOps и SRE, AppSec-специалистов и всех, кто внедряет ИИ в разработку, строит внутренние платформы и отвечает за production-надежность.
В треке «Данные и ML»
Поговорим, как строить платформы данных и ML-системы, готовые к работе с ИИ. Разберем архитектуру Lakehouse, Data Governance, защиту чувствительных данных и инфраструктуру для высоконагруженного доступа к моделям.
Ждем: дата-, ML- и ИИ-инженеров, архитекторов, продуктовых менеджеров и всех, кто работает с корпоративными данными, LLM и ИИ-сервисами.
Треть объема файловых хранилищ российских компаний занимает цифровой мусор. И это только «цветочки»
Цифровой беспорядок ничем не отличается от обычного: пока не начинаешь разбирать, кажется, что всё под контролем. А потом открываешь папку с файлами или галерею телефона — и обнаруживаешь кэш, который давно пора очистить, копии ненужных документов и файлы, о которых уже успел забыть.
В корпоративных ИТ-инфраструктурах и масштаб больше, и последствия серьезнее. И проблема далеко не в том, что в хранилищах годами лежат ненужные файлы. Хуже всего, что среди этого разрозненного массива данных практически неизбежно оказываются файлы, содержащие конфиденциальную информацию. Если не автоматизировать процесс контроля и аудита, это повлечет за собой финансовые и репутационные риски.
За 2025 год мы проаудировали ИТ-инфраструктуру более сотни компаний — от финансового сектора до фармацевтики, проверили свыше 157 ТБ данных и более 511 тыс. учетных записей.
Делимся некоторыми фактами.
Итоги аудита
В среднем около трети объема файловых хранилищ занимает цифровой мусор: устаревшие файлы, которые не открывали несколько лет, копии и дубликаты документов, а также данные, не связанные с рабочими задачами. Например, личные фото, видео и случайные архивы сотрудников.
Проблема эта далеко не новая и сохраняется из года в год. Бороться с ней вручную практически невозможно: объем данных растет, а вместе с ним в геометрической прогрессии увеличивается и количество информации, за которой необходимо следить. Без инструментов класса DCAP здесь не обойтись.
С доступами ситуация тоже далека от идеала. Более 33% учетных записей имеют слабые пароли либо пароли, которые не обновлялись более 90 дней. В случае инсайдерской атаки такие учетные записи могут упростить злоумышленникам доступ к корпоративным данным. Поэтому компаниям важно разработать надежную парольную политику и автоматизировать ее соблюдение.
Еще один риск связан с правами доступа к сетевым хранилищам. На практике учетные записи сотрудников нередко создаются с одинаковым набором прав, а доступ к файловым ресурсам по умолчанию предоставляется всем. В результате в таком хранилище может оказаться конфиденциальная информация, доступ к которой могут получить злоумышленники.
Что осталось за кадром
Это лишь несколько фактов, которые мы регулярно подтверждаем в ходе аудитов. В полной версии отчета вы найдете больше цифр, разбивку данных исследования по отраслям и размеру компаний, а также рекомендации, как навести порядок в работе с данными и доступами, чтобы эффективнее управлять их жизненным циклом.
Пару недель назад прошла CTF от компании Касперский. Задачи, как вы понимаете, были из области классического ИБ: криптография (crypto), реверс инжиниринг (reverse), расследование инцидентов (forensics), внешний (web) и внутренний пентесты (misc), а также pwn (даже не знаю как правильно перевести).
И все бы ничего, но задачи были несравнимо "необычные", не чета таскам в до-ИИшную эпоху. Даже мою любимую форензику я не смог решить... ни одного задания. Давно у меня не было такого гнетущего ощущения как "эффекта самозванца". Но в чем оказался секрет?
Примерно через 20 минут после начала мероприятия наш сокомандник говорит: "Я решил первое задание!" На завидный вопрос коллег, а что там было и как решал, прозвучал ответ: "Я не знаю, я просто закинул архив и задание в ИИ и тот мне сам все решил". Прикольно, но как-то не спортивно мне кажется. Ладно, победителей не судят, а в правилах не было запрета на потусторонние силы.
Через 30 минут тоже самое повторилось и со вторым заданием, потом с третьим и так далее. В итоге, таким образом наша команда (читай ИИ) смогли решить чуть меньше 10 упражнений.
В ходе последующих обсуждений мы все пришли к выводу, что CTF в целом уже не то, и сейчас мероприятия превратились в "борьбу кошельков", то есть у кого больше закуплено агентов. Вместе с тем и организаторы не стоят на месте и свои задания (судя по врайтапам) тоже генерируют через ИИ, потому что решить их руками в установленные сроки просто не реально.
В общем, есть на чем задуматься.
К слову сказать, если сейчас перейти на сайт портала, чтобы посмотреть таски, то у вас ничего не получится: вас встретит заглушка об окончании мероприятия. НО! перед заглушкой на долю секунды мелькают задания... что намекает на скрипт, который проверяет текущую дату и сверяет с датами проведения CTF.
Поэтому, если есть желание попробовать самому, то открываем Burp и ставим Intercept On.
А если будет тяжело, можно посмотреть решения одного из участников - https://github.com/hax1ng/Kaspersky-CTF-2026/
🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
Как встроить практики качества и безопасности в ежедневный цикл разработки?
Обсудили этот вопрос на прошедшем вебинаре "Автоматизация контроля качества и безопасности ПО". Эксперты PVS-Studio и Apsafe рассказали, почему статический анализ и автоматизированные проверки стали доступными инструментами для любой команды и как регулярный контроль безопасности помогает успевать за современным ритмом релизов без перестройки CI/CD.
Посмотреть запись можно тут:
- VK Video
- Rutube
- YouTube
- Наш сайт
Хороший бэкап умеет не только сохранять, но и возвращать нужное
В большой инфраструктуре десятки тысяч машин, БД, контейнеров, платформ. И сценарии восстановления у всех свои: где-то нужно поднять всё с нуля, а где-то – вернуть один объект или несколько атрибутов. Российские вендоры последовательно движутся в сторону точности.
Свежий пример: в «Кибер Бэкапе Облачном» теперь можно выбирать отдельные объекты внутри Kubernetes. Резервируешь и восстанавливаешь только то, что действительно нужно, – не тащишь весь кластер ради одной ошибки.
Не просто «есть копия», а умение достать из неё именно то, что сломалось, и не трогать остальное.
Тот же принцип особенно важен для каталогов. В гетерогенных средах и особенно при миграции с AD на Linux инфраструктура становится сложнее: параллельные среды, скрипты, промежуточные состояния. И тут ошибка часто не убивает каталог целиком. Можно неверно изменить атрибуты пользователей, удалить группу, разорвать связи — система продолжит работать, но доступы поедут.
Восстанавливать весь каталог из полной копии — как из пушки по воробьям.
Нужно найти, что именно сломалось, и вернуть только это — один объект, один атрибут. Это и есть гранулярное восстановление. Оно не отменяет полное восстановление — это разные сценарии. Пожар в дата-центре и кривой скрипт, поменявший одну группу, лечатся по-разному.
Простая логика для каталога: перед миграцией сделал копию, потом сравнил состояния и точечно исправил последствия.
И здесь Kubernetes и каталог оказываются ближе, чем кажется: бэкап ценен не только фактом наличия, но и тем, насколько точно ты можешь им воспользоваться, когда что-то пошло не так.
Источники:
«Киберпротект» расширил возможности «Кибер Бэкапа Облачного» для крупных гетерогенных инфраструктур
Безопасная разработка от кода до прода — новый бесплатный курс Cloud.ru
Кто-то считает безопасность головной болью ИБ-отдела и вспоминает о ней за день до релиза — когда править уже долго и дорого. Кто-то уверен, что контейнер — это просто «легковесная виртуалка», и удивляется, когда изоляция оказывается не такой уж изолированной. Безопасность часто воспринимают как отдельный этап в конце пайплайна, а не как часть жизненного цикла разработки. Чтобы глобально исправить это, мы собрали свой опыт провайдера облачных и ИИ-решений в экспресс-курс «Основы безопасной разработки в облаке» и сделали доступ к нему открытым.
⏳За один кофе-брейк (около 20 минут) вы можете узнать:
Как безопасность распределяется между этапами разработки, сборки, развертывания и эксплуатации приложения.
За счет чего контейнеры дают скорость и гибкость, какую цену за это платит изоляция и как эту цену скомпенсировать.
Какие практики чаще всего приводят к инцидентам, и как их избежать с самого начала.
Какие готовые сервисы безопасности закрывают типовые задачи защиты быстрее самостоятельной разработки.
Кому подойдет курс?
ИТ-специалистам и DevOps-инженерам. Поможет встроить проверки безопасности в существующий CI/CD-конвейер и автоматизировать их без потери скорости релизов.
Специалистам по ИБ и облачной безопасности. Структурирует модель угроз для облачных приложений и позволит говорить с разработкой на одном языке.
Всем, кто интересуется кибербезопасностью. Систематизирует разрозненные знания об облаке в единую картину жизненного цикла.
Курс открывается сразу после регистрации на платформе, заниматься можно в любой момент в комфортном темпе. Все уроки и прогресс отражаются в личном кабинете, доступ к материалам остается с вами навсегда. После финального теста вы получаете сертификат о прохождении курса.
Сделайте безопасность частью разработки, а не препятствием перед релизом!
We will croc you 👻
Хакерская группировка PhantomCore продолжает активно использовать ошибки в конфигурации 1С для атак на российские организации.
В рамках расследования инцидента команда комплексного реагирования на киберугрозы Positive Technologies (PT ESC IR) обнаружила компрометацию сервера 1С, работающего на операционной системе семейства Linux 🐧
Среди характерных признаков — наличие вредоносных исполняемых файлов в подкаталогах домашней директории служебного пользователя usr1cv8 и команд в .bash_history того же пользователя — в частности просмотр и удаление файла res.txt, в который записывается результат выполнения кода посредством 1cshell.
/home/usr1cv8/.bash_history: cat res.txt /home/usr1cv8/.bash_history: rm res.txt
После получения доступа в систему PhantomCore установили ReverseSSH-туннель, что является типичным поведением для данной группировки.
🕵️♂️ Помимо часто используемого инструментария мы встретили и более диковинную утилиту croc, предназначенную для удаленной загрузки и эксфильтрации файлов.
На исследуемом узле были обнаружены команды формата: CROC_SECRET=[REDACTED] ./croc
С помощью нее злоумышленники могли загрузить на скомпрометированный узел файл, который был предварительно отправлен через веб-интерфейс https://getcroc.com/ (на скриншоте) или с другого компьютера, на котором установлен croc.
💡 Для поиска следов использования croc можно поискать исполняемый файл с соответствующим именем, а также использование переменной окружения CROC_SECRET.
В качестве сетевого индикатора может служить домен getcroc[.]com.
(Источник: https://t.me/ptescalator)
Исследователи из Гарварда и Института Санта-Фе опубликовали научную работу Large-Language Models as a Cognitive Virus, в которой приравняли крупные языковые модели к когнитивному вирусу. Учёные проанализировали ChatGPT через призму эволюционной биологии и эпидемиологии и пришли к выводу, что алгоритмы ИИ полностью соответствуют математическому определению вируса.
Нейросети не способны распространяться самостоятельно и используют человеческий мозг, серверы и сети как организмы-хозяева, подменяя паттерны мышления и принятия решений. По мнению авторов исследования, ИИ незаметно колонизирует цифровое инфополе, меняя человеческую речь и память для генерации нужных ему данных.
Как перестать сливать ПДн в ChatGPT и Claude: On-Prem AI-Gateway на чистом Python
Сотрудники компании (разработчики, поддержка, юристы) активно используют ChatGPT, Claude и Cursor. В промпты летят ФИО клиентов, ИИН/ИНН, карты, API-ключи и бизнес-логика. С точки зрения RegTech (152-ФЗ, Закон РК № 94-V, GDPR) — это прямая утечка данных.
Обычный DLP просто заблокирует доступ, снижая продуктивность[cite: 1]. Мы сделали AI-Gateway — open-source шлюз с обратимой токенизацией (Reversible Tokenization), который маскирует ПДн до отправки в LLM, восстанавливает их в ответе и ведет защищенный лог.
Как это работает
1. Исходный промпт от пользователя/приложения:
«Клиент Ержан Нурсултанулы, ИИН 900715300005, оспаривает транзакцию по карте 4400 1234 5678 9101…»
2. Уходит во внешнюю LLM (ChatGPT/Claude/Gemini):
«Клиент [PERSON_1], ИИН [NATIONAL_ID_1], оспаривает транзакцию по карте [PAN_1]…»
3. Возвращается в приложение / браузер:
«…для Ержан Нурсултанулы (ИИН 900715300005) по карте 4400 1234 5678 9101 возврат…»
Модель помогает решить задачу, пользователь получает полный ответ, а вендор не получает ни одной персональной записи[cite: 1].
Ключевая архитектура
Обратимая токенизация, а не удаление. Замена сущностей на [PERSON_1] сохраняет связность текста для LLM[cite: 1]. Соответствия хранятся только в OAM (Mapping Store) в зашифрованном виде (PRF-CTR + HMAC) и автоматически удаляются после ответа[cite: 1].
Проверка по контрольным суммам. ИИН/БИН проверяются двухпроходным весовым алгоритмом, карты — по алгоритму Луна (Luhn), IBAN — ISO 13616[cite: 1]. Секреты (AWS, OpenAI, JWT, PEM) детектируются по формату и энтропии Шеннона[cite: 1].
Zero-Dependency Core (Python 3.11+ stdlib). Поверхность атаки на Supply Chain инструмента, видящего все промпты — ровно ноль[cite: 1]. Устанавливается в Air-Gapped контур без pip install[cite: 1].
Принцип Fail-Closed. Любая ошибка распарсинга или сбой детекции блокирует запрос[cite: 1].
Tamper-Evident Audit Log. Append-only JSONL с цепочкой хешей SHA-256[cite: 1]. Любое редактирование записи нарушает целостность лога[cite: 1].
Три канала перехвата
Egress Proxy: Меняем base_url в OpenAI SDK (http://aigate.internal:8080/v1)[cite: 1]. Код приложений менять не требуется[cite: 1].
Browser Extension (Manifest V3): Перехватывает ввод в ChatGPT/Claude/Gemini прямо в браузере до отправки на сервер[cite: 1].
Endpoint Agent: Отслеживает буфер обмена (clipboard) для вставки в IDE (Cursor, Claude Desktop)[cite: 1].
Маршрутизация в локальные LLM
Можно настроить правило: промпты без ПДн идут в ChatGPT/Claude, а промпты с найденными чувствительными данными автоматически перенаправляются на локальный Ollama / vLLM (Llama 3.1)[cite: 1].
Быстрый запуск
git clone [https://github.com/oleg-vdv/AI-Gateway.git](https://github.com/oleg-vdv/AI-Gateway.git) cd AI-Gateway cp .env.example .env docker compose up -d
Регуляторы скоро спросят «где у вас RSA?». Я написал сканер, который отвечает за секунды
Завязка. Три дедлайна: США — PQC для новых госзакупок нацбезопасности с 2027 (EO 14412 / CNSA 2.0, там прямо назван CBOM), Великобритания — полная криптографическая инвентаризация и план миграции к 2028 (NCSC), ЕС — переход с конца 2026. Первый вопрос аудитора одинаковый: «где именно у вас используется RSA?» Ответа нет почти ни у кого.
Что такое CBOM и почему это не то же самое, что SBOM.
«Harvest now, decrypt later» — почему это не про далёкое будущее: трафик записывают сегодня, расшифруют потом. Если у секрета срок жизни больше нескольких лет — проблема уже наступила.
Как работает сканер. Одна команда, три артефакта: CycloneDX 1.6 CBOM, отчёт с планом миграции на ML-KEM/ML-DSA, SARIF для GitHub code scanning. Плюс scan-tls — одно рукопожатие и вердикт по живому эндпоинту.
Байка про баг (Хабр это любит): первый же регрессионный тест поймал, как сканер находит «криптографию» в собственных регулярках. Лечилось маскировкой литералов RSA_generate_ke[y], и теперь есть вечный тест, что репозиторий подсвечивает только свои фикстуры.
Честный бенчмарк против PQCA CBOMkit. Не «мы лучше», а «мы разные»: CBOMkit глубже на Java/Python (знает размеры ключей, симметрику), мы шире (10+ языков, конфиги, сертификаты) и быстрее (0,05–0,12 с против минуты). Прямая ссылка на docs/BENCHMARK.md — воспроизводимо кнопкой в CI.
Ограничения честно: v0 на паттернах, динамические вызовы пропустит, отсутствие находок ≠ отсутствие проблем. AST-движок в планах.
Финал: вопрос к читателям — у кого уже спрашивали CBOM и в каком виде.
Может я не прав, но 8 лет пердения в офисный стул — сомнительный фильтр для выбора разработчика.
Безусловно, за это время можно приобрести огромный багаж опыта, но гарантий никаких. Будто бы все же лучше смотреть на реальные навыки.
В общем, писать софт для кибербеза с другими дедами мне пока рано. Слишком молодой специалист.
Самая опасная кнопка в КИИ — у человека за соседним столом
В новом исследовании «СёрчИнформ» ста судебных дел за последние годы по статье 274.1 УК РФ — «Неправомерное воздействие на критическую информационную инфраструктуру Российской Федерации» обнаружилась интересная закономерность.
95% нарушителей — сами сотрудники пострадавших организаций. 14% среди них — руководители подразделений. Но есть и хорошая новость, ИТ‑ и ИБ‑специалистов среди них всего 5%, а топ менеджмента и подавно 1%. Почти на уровне погрешности.
Внешних нарушителей — всего 5%. Но это не потому, что их мало. Просто раскрываемость компьютерных преступлений в России не превышает 21%. Большинство внешних атак остаются безнаказанными.
Что интересно, 67% проанализированных дел — не взлом и не уничтожение серверов, а внесение недостоверных данных в таких сферах, как связь и телеком 47%, здравоохранение 25% и финансовый сектор 10%.
Причина — большое число сотрудников с легитимным доступом к системам и низкая цифровая грамотность.
Больше доступа — выше цена ошибки.
Когда администратор просто изменил не тот атрибут, или скрипт сломал членство в службе каталога — каталог жив, пользователи заходят, но доступы уже сломаны.
Для LDAP‑инфраструктуры это головная боль: система считает изменение легитимным (права‑то были!), а вы даже не знаете, что именно вернуть назад.
Классический бэкап здесь не выход. Откатывать всё из‑за одной сломанной группы — как стрелять из пушки по воробьям. Нужен другой подход:
Сравнить текущее состояние каталога с резервной копией.
Найти точечные расхождения.
Восстановить только изменённые объекты, не трогая остальное.
Защищать нужно не только доступность каталога, но и целостность данных. Потому что легитимный доступ ≠ безопасное изменение. И это справедливо не только для КИИ.
Информацию взял отсюда и отсюда.
OpenAPI React скомпрометирована в результате атаки на цепочку поставок npm от Mini Shai-Hulud
28 августа 2026 года в npm появились десять вредоносных версий @7nohe/openapi-react-query-codegen. Согласно предупреждению проекта, при установке они запускали код атакующего на машине разработчика или CI-раннере. Под угрозой оказались секреты GitHub, облачных сервисов и реестров пакетов.
За неделю с 23 по 29 августа пакет скачали 156 752 раза. На вредоносные версии пришлось около 1 900 загрузок, и доступны они были меньше двух суток. В пакетной базе npm также находится 8 зависимых пакетов, у которых есть указание использования вредоносного пакета. Это показывает размер потенциально задетой области, а не число подтвержденных заражений.
CodeScoring завел эти версии в базу 29 августа в 02:20 по Москве, через девять минут после публикации предупреждения GitHub, и еще через две минуты они попали под блокировку в платформе. Все десять помечены как опасные, поэтому у пользователей платформы данные компоненты автоматически блокируются при наличии соответствующей политики безопасности.
Атакующему не понадобилось взламывать учетную запись автора пакета. Ошибка была в workflow публикации. Любой пользователь мог открыть pull request из форка и запустить этот сценарий специальным комментарием. GitHub Actions загружал код из pull request и устанавливал зависимости, хотя одновременно имел право публиковать пакет в npm.
По сути, внешний пользователь на несколько минут получал полномочия доверенного издателя. После атаки мейнтейнер проекта убрал запуск публикации по комментариям, отозвал связанные полномочия и оставил выпуск версий только по тегам.
Вредоносный код запускался во время установки пакета. В части версий запуск был прописан в команде preinstall внутри package.json, которую npm выполняет перед установкой. В других ту же команду спрятали в binding.gyp — конфигурационном файле для сборки нативных модулей с помощью node-gyp. Поэтому проверка только скриптов в package.json не обнаружила бы все зараженные выпуски. Полезная нагрузка искала учетные данные и настройки инструментов разработчика, а затем пыталась распространяться через доступные пакеты и репозитории. Механика похожа на августовскую волну Shai-Hulud, только точкой входа стала не учетная запись мейнтейнера, а небезопасный процесс публикации.
Все зараженные версии при этом получили валидные сведения о происхождении сборки (provenance). Это важная граница такой проверки. Она подтверждает, где собрали и опубликовали пакет, но не доказывает безопасность самого процесса. В данном случае сборка действительно прошла через официальный процесс публикации проекта, который, однако, выполнил код из чужого pull request.
Сейчас основной тег пакета снова указывает на чистую версию 3.0.2, а зараженные релизы удалены из NPM. Удаление пакета из реестра остановит новые установки, но не вернет уже украденные секреты. Командам стоит:
проверить файлы зависимостей и SBOM по полному списку зараженных версий;
если пакет устанавливался 28 августа с разрешенными установочными скриптами, пересобрать машину или CI-раннер из чистого образа и отозвать секреты, доступные в этой среде;
очистить кэш пакетного менеджера и повторить установку с чистой версией;
проверить автоматические сценарии публикации: в них нельзя исполнять код из pull request внешних участников с правами на выпуск релизов.
Пользователям CodeScoring достаточно один раз настроить блокирующую политику с условием «Зависимость опасна». Пример настройки данной политики можно найти в документации платформы.
Новый закон об ИИ вступает в силу 1 сентября: что изменится для владельцев сайтов
Привет! Я Александр Бондаренко, руководитель проектной группы в Далее. Мы делаем сайты и плотно работаем с их комплаенсом, поэтому новые законы я изучаю не как новости, а как список требований к проектам.
В сентябре вступил в силу новый закон об ИИ, вокруг которого ходит много слухов. В интернете пишут, что иностранные нейросети теперь под запретом, а сгенерированный контент обязательно придется маркировать. Но если прочитать реальный текст документа, открывается другая картина.
В этом посте разберу, кого закон касается на самом деле, что изменится для владельцев сайтов и какие вопросы пока остаются без ответа.
Сначала напомню, о каком законе идет речь👇
Федеральный закон № 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации»
Рамочный закон, который регулирует большие фундаментальные модели вроде ГигаЧата или Алисы. Они имеют от 1 миллиарда параметров и способны выполнять интеллектуальные задачи на уровне человека или выше. Если компания просто использует готовые модели в своих сервисах, закон на нее напрямую не распространяется.
Основная часть закона вступает в силу с 1 сентября 2026 года, отдельные нормы — с 1 марта 2027-го.
Закон вводит статус суверенной или национальной модели. Его могут получить только разработчики, которые хранят и обрабатывают данные в России и используют открытые лицензии для сторонних компонентов. Еще по закону контролирующие лица не должны иметь второе гражданство.
Суверенные модели смогут использовать контент с сайтов без согласия авторов
Национальный статус дает два преимущества: можно свободно обучаться на объектах авторского права и получить доступ к государственным данным.
С 1 марта 2027 года модели с особым статусом будут использовать статьи, книги, музыку и изображения бесплатно и без отдельного разрешения автора. При условии, что произведение было получено правомерно или легально опубликовано и доступно для анализа.
Это классический механизм opt-out: нейросеть по умолчанию может парсить и анализировать контент, если владелец заранее не ограничил это право. Пока непонятно, какой именно технический сигнал признают достаточным ограничителем — это открытый вопрос и в российской, и в европейской практике, где действует похожая логика.
Обязательная маркировка ИИ-контента — просто слух
Его часто повторяли в интернете, пока закон проходил согласования. По факту же маркировка добровольная, обязательна только техническая возможность ее поставить, и только для крупных платформ.
Разработчики моделей с аудиторией до 500 000 могут опционально добавить функцию маркировки для пользователей. Для платформ с посещаемостью выше — это обязательное требование. Если ваш сайт или сервис близок к этому порогу аудитории и работает с генеративным контентом, стоит заранее продумать, как это реализовать.
Прямого запрета на использование иностранных моделей в законе нет
Правительство сможет регулировать объекты и сферы, где разрешено применять только суверенные модели. Подробностей пока нет, но мы знаем, что будет поблажка. Если система уже работает к 1 марта 2027 года и данные хранятся в России, владельцы смогут использовать иностранный ИИ до сентября 2032 года.
Отдельно закон выделяет финансовый сектор. Здесь решения Правительства должны приниматься по согласованию с Банком России. Поэтому банкам и финтех-компаниям стоит следить не только за подзаконными актами Правительства, но и за будущими требованиями ЦБ.
Некоторые вопросы остаются открытыми
Какие государственные данные откроют для обучения?
Как будет работать opt-out и каким будет технический механизм отказа правообладателя?
Где будут разрешены только суверенные модели и насколько широким будет этот список?
Что такое достаточная «техническая возможностью маркировки»?
Если подытожить, то сейчас закон задал общую рамку, но мы все еще ждем конкретики. Пока подписывайтесь на канал «Согласен на обработку»: там я разбираю новые законы о данных, рекламе и ИИ.
26 августа исследовательская организация Model Evaluation and Threat Research (METR) представила отчёт по инциденту, в результате которого большие языковые модели компании OpenAI взломали инфраструктуру сервиса Hugging Face. Полный отчёт — длинная и интересная статья, которая на Хабре была покрыта в публикации «Как ChatGPT создал Культ Роя для сотен AI-нейросетей: вся правда про взлом Hugging Face». Любопытно детальнее рассмотреть один из упомянутых фактов.
Вообще, разобранные в расследовании события проходили с 26 июня по 13 июля, но основное внимание отчёт уделяет периоду с 7 по 13 июля. OpenAI гоняла агентов на бенчмарке ExploitGym, наборе задач для проверки, насколько хорошо искусственный интеллект умеет превращать известные уязвимости в работающие эксплойты. 8 июля компания начала запускать десятки тысяч агентов на нескольких БЯМ, в основном на внутренней исследовательской модели HPIM и GPT-5.6 Sol. Предполагалось, что каждый из агентов работает в изолированной среде и никак не взаимодействует с остальными.
К вечеру того же дня один из агентов организовал доску сообщений. Через несколько часов уже более полусотни агентов обменивались на этом форуме знаниями. Это одна из самых интересных деталей всего отчёта, которую часто пересказывают; этот факт был известен ещё до отчёта METR.
Интереснее другое. 13 июля около 07:00 UTC один из агентов признался на этом форуме, что случайно выдал себя за другого из-за путаницы с именами. Другой агент заметил, что никакой аутентификации на этой доске сообщений нет. В результате развернувшегося обсуждения агенты быстро пришли к решению использовать криптографические подписи Ed25519, и первый найденный METR публичный ключ появился уже около 07:33 UTC. Система быстро прижилась: к концу дня не менее 19 агентов опубликовали публичные ключи, а подписано было уже 429 сообщений.
Обычно в СМИ забывают обратить внимание на забавный артефакт. В логах рассуждений одного из агентов нашли что-то подобное: «Нужно ли мне верифицировать эту подпись? Похоже, что она была подписана FreshX». (Здесь FreshX — это имя одного из агентов). Затем в рассуждениях агент, похоже, решил поверить и так, без запуска подтверждения.
По сути, повторился сюжет известного комикса XKCD от 4 марта 2013 года. В выпуске «PGP» Рэндел Манро указал, что никто эти подписи не проверяет, а просто доверяет им по факту одного их присутствия в сообщении. Так и здесь: ИИ-агент просто увидел, что подпись есть, но тратить время на проверку не стал.
Понятно, что использовались не подписи OpenPGP — агенты придумали свой формат на основе Ed25519. Также нужно заметить, что другие агенты подписи всё же проверяли.
