Я уже несколько лет методично выбирал устройства для умного дома, работающие по протоколу Zigbee, чтобы не зависеть от облака вендора. Однако прошлой осенью в моей жизни появилась кошка. В силу ограниченности вариантов, пришлось обзавестись рядом устройств, работающих только по Wi‑Fi и только с приложением вендора.
Под катом расскажу, как я преодолел это недоразумение.
Идея агрегатора новостей по кибербезопасности зародилась еще давно. Хотелось получать самое важное и без инфошума. LLM тогда ещё не были повседневным инструментом, и первую версию реализовал на модели суммаризации rut5_base_sum_gazeta, а важность считал textrank. Работало так себе. Потом появились сервисы, которые сами подбирают новости под настроенную ленту. Но оптимального решения так и не увидел – это либо про всё сразу, либо что-то про одну узкую тему.
Задача изначально выглядела простой. Моделей полно, готовых наработок должно было быть много. Но на практике уже первые недели ушли на тюнинг, и лучше при этом не становилось: поднял порог – канал молчит сутки, опустил – в ленту попали вебинары, квадранты и пресс-релизы продуктов. Из этого опыта родилось гибридное решение. Важность теперь считает формула из семи признаков, все логируется, а модель пишет тексты и отсекает нерелевантное.
Четвёртая часть цикла про свой удостоверяющий центр. В первой мы развернули Root CA и три промежуточных центра, во второй научились отзывать сертификаты и подняли OCSP-responder, в третьей настроили вход по клиентскому сертификату в nginx и Apache. Осталось ответить на вопрос, который возникает сразу после первого успешного входа: а откуда у людей берутся сертификаты?
Пока удостоверяющим центром пользуется один человек, openssl в терминале — идеальный интерфейс. Как только приходит второй с просьбой «выпусти мне тоже», начинается то, ради чего существуют регистрационные центры: заявки, роли, журнал и ответ на вопрос «кто и на каком основании это подписал».
В четвёртой части:
— PKCS#10 прямо в браузере. Ключ рождается в WebCrypto и не покидает его, запрос собирается на голом JavaScript без единой библиотеки, а результат проверяется настоящим openssl, а не «на глаз».
— Почему кнопке «получить сертификат» нельзя доверять отличительное имя: позволь заявителю назвать себя самому — и он выпишет себе сертификат с DN администратора. Настоящий, подписанный вашим же центром.
— PKIDesk: движок управления сертификатами на Go, без единой зависимости, под Apache-2.0. Разрезан по границе доверия — у веб-части нет ни ключей УЦ, ни index.txt, ни даже бинарника openssl. Плюс пять архитектурных развилок, за которые придётся отвечать перед аудитом.
— Три дефекта, которые вылезли только на живом стенде: правило subjectAltName = supplied, которое не выполнится никогда; просроченный сертификат, который остаётся действующим и занимает subject; гонка «выпустил — сразу зашёл», где nginx запоминает неудачную проверку отзыва.
— Четыре расширенных справочника, 237 параметров: openssl req, openssl genpkey, структура PKCS#10 и Web Crypto API — синтаксис, значения, умолчания и подводные камни, сверенные с официальной документацией.
Ставил утилиту по инструкции с сайта проекта: блок с командой, кнопка «скопировать», вставка в терминал. Перед Enter посмотрел на строку — вставилось не то, что было в блоке.
Проблема в том, что сайт полностью контролирует, что окажется в буфере обмена. Показать он может одно, положить — другое. И у страницы есть несколько способов сделать это так, что при вставке вы ничего не заметите.
Три месяца вместо запланированного одного. 360 попыток запуска модуля VPN, которые заканчиваются таймаутом без единой подсказки в логах. «Осиротевшие» мастер-ключи, которые формально проходят все проверки, но ломают миграцию на ровном месте. И дистрибутив ключей, который отказывается формироваться из-за одного просроченного ММК.
Звучит как список кошмаров сетевого инженера? Это наш реальный опыт перехода с ViPNet Administrator 4-й версии на ViPNet Prime. Без прикрас, с полным набором граблей и неожиданных поворотов. Если вы только собираетесь в этот путь — эта статья сэкономит вам недели работы и несколько седых волос.
С середины августа 2026 года у части абонентов «Ростелекома», «Дом.ру», «Таттелекома», SkyNet и «Билайна» одновременно перестал работать зашифрованный DNS от Google и Cloudflare. Не зависал, не подтормаживал, а именно перестал отвечать. Причём ложился он по-разному в зависимости от протокола, и это различие — самое интересное в истории.
Давайте разберём, что именно происходит на проводе, почему DoT и DoH ломаются не одинаково, как это потрогать руками, и что со всем этим делать.
Мониторинг зелёный, балансировщик отвечает, сертификат на месте — а пользователи пишут, что портала нет. Через сорок минут выясняется: часть клиентов получает новый адрес, часть — старый. Разъехался DNS. Разбираемся, почему резолвер стоит считать частью контура управления доступом, а не подписью к IP.
Проверял, что видно про домен заказчика снаружи, и выписал имена из журналов Certificate Transparency. В списке оказались jenkins, gitlab-runner и пара стендов с именами вида test-2 — ни одного из них в публичном DNS не было.
Имя знает не только команда. Его знает весь интернет, причём с того момента, как вы выпустили на этот хост TLS-сертификат.
Привет, Хабр! Меня зовут Алексей Лукацкий, я бизнес-консультант по безопасности и Chief Evangelist Officer в Positive Technologies, а до этого больше 18 лет проработал в Cisco. За свою карьеру я успел побыть программистом, администратором, аудитором, маркетологом, продавцом, преподавателем, rCISO, писателем и ИБ-евангелистом — и за всем этим стоит уже 35 лет в кибербезопасности, страшно даже произносить эту цифру вслух.
За эти три десятилетия я видел, как менялась индустрия: появлялись новые угрозы, регуляторы выпускали всё новые требования, а специалисты по безопасности учились работать с облаками, контейнерами и DevSecOps-практиками. Теперь настал черёд следующего большого изменения — искусственного интеллекта, и мне захотелось поделиться мыслями о том, как он влияет на нашу профессию и что с этим делать.
Вокруг искусственного интеллекта сегодня действительно много шума, и мнения о нём кардинально расходятся — от полного принятия до категорического отторжения. Одни считают, что ИИ вот-вот заменит специалистов по кибербезопасности, и указывают на нейросети, которые уже находят уязвимости на багбаунти-платформах или пишут нормативную документацию лучше человека. Другие, часто из старшего поколения, воспринимают ИИ как нечто враждебное, призывают запрещать и блокировать — и дальше начинаются истории с обходными путями и теневыми схемами использования.
Вместо философских рассуждений о том, заменит ли ИИ человека или нет, я хочу поговорить о практических вещах, которые каждый специалист по ИБ может использовать уже сегодня, причём сделать хорошо. Как не остаться на свалке истории, а наоборот — вскочить на ступеньку этого поезда и использовать ИИ как инструмент, который усиливает, а не заменяет.
В 2024 году главная база уязвимостей NVD фактически сломалась, в 2025-м чуть не остановилась вся программа CVE, а Евросоюз запустил свою базу EUVD. Эпоха единого источника закончилась. Разбираем, откуда брать данные сегодня, какие требования предъявлять к VM-инструменту и как должен быть устроен конвейер доставки уязвимостей у вендора.
Пять раундов дообучения детектора промпт-инъекций, четыре неудачи и только один успешный релиз. Разбираем, как собирать и размечать корпус на реальном корпоративном трафике, почему рост точности может обернуться потерей атак и какие гейты помогают не выкатить регресс в прод. Внутри — реальные метрики, причины откатов и практический процесс релиза модели.
Патч был на две строки: правка в проверке прав доступа. На ревью читается ровно то, что задумано, — апрув, мёрж. Через день выясняется, что проверка не срабатывает, хотя код перед глазами правильный.
На ревью смотрят глазами. Глаз видит символы так, как их нарисовал шрифт, а интерпретатор читает байты. Между этими двумя представлениями есть зазор, и в него помещается логика, которую при чтении кода не видно.
Этим зазором пользуются двумя способами, и оба закрываются одной проверкой.
Эхолот давно перестал быть просто прибором, показывающим рельеф водоёма. Сейчас это многофункциональный дисплей, своего рода мозговой центр лодки или катера, на который возлагается ведение картографии, управление двигателями, радио, подсветка, музыка и даже подача сигналов о бедствии или о человеке за бортом.
При этом безопасность таких важных систем порой оставляет желать лучшего. О том, какие абсурдные ошибки я заметил в прошивке одного из этих приборов и почему проверка подписи на файле обновления ещё не защищает от вмешательства в ПО — под кат.
«Он подписан, издатель известный» — этим аргументом закрывают вопрос про стороннюю программу, которую тянут в сборку или ставят на рабочий компьютер. Возразить с ходу нечем: вкладка «Цифровые подписи» в свойствах файла и правда показывает «Эта цифровая подпись действительна». Случаи, когда вредоносный файл подписан настоящим сертификатом, редки — на них и не рассчитывают. В таких разговорах я обычно зануда.
Подпись действительно кое-что подтверждает. Просто не то, что от неё ждут. Она говорит: «этот файл в момент подписи выпустил вот такой издатель, и после подписи содержимое не меняли». Она не говорит: «файл безопасен», «издатель — тот, за кого себя выдаёт прямо сейчас» и «ключ не украли полгода назад».
Последние две недели ленту заливает одинаковыми заголовками: «с 1 сентября изменения для операторов ГИС». Формулировка удобная и неверная. Точнее, верная процентов на сорок.
Приказ ФСТЭК от 27.02.2026 № 60 переписал не сроки и не методы. Он переписал пункт 3 Порядка аттестации, тот самый, где сказано, к кому этот порядок вообще применяется. Когда меняют список адресатов, «изменения для операторов ГИС» превращается в неточность, из‑за которой кто‑то не прочитает документ, решив, что он не про него.
Разберу, кто там теперь есть.
Разговор о том, кто на самом деле контролирует облако, часто начинается с регионов: где выполняется рабочая нагрузка и где хранятся её данные. Но выбор региона — только часть картины, архитектура платформы значит ровно столько же. Особенно важно, как она разделяет между кластерами ответственность за управление, исполнение, сборку и наблюдаемость.
Недавняя публикация сообщества CNCF, «От резидентности данных к цифровому суверенитету: архитектурные паттерны для cloud native-платформ», хорошо это обосновала. Под такими режимами, как EU Data Act, NIS-2, DORA и UK Data (Use and Access) Act, платформенным командам теперь приходится показывать не только то, где выполняются рабочие нагрузки. Нужно показать и то, как платформу эксплуатируют, защищают и по каким правилам ею распоряжаются, вплоть до плоскости управления.
Та статья изложила требования и представила паттерн «кластер на тенант» как один из способов провести границы изоляции. Команда VK Cloud перевела статью, в которой на те же требования смотрят под другим, но дополняющим углом: что происходит, если считать контроль над платформой свойством топологии её плоскостей. В качестве примера, который можно изучить самому, авторы берут OpenChoreo, внутреннюю open source-платформу разработки и проект CNCF Sandbox. Впрочем, сами архитектурные идеи применимы широко.
Однажды вечером я, как обычно, листал ленту одного синего маркетплейса и случайно наткнулся на электронный замок со сканером отпечатка пальца. По описанию — почти идеальное устройство за небольшие деньги: биометрия, защита от воды, какая-то «уникальная» микросхема. Звучит убедительно, но исследователь на то и исследователь, чтобы не принимать рекламные обещания на веру, а потому уже на следующий день замок лежал у меня на столе. Ну, а дальше сработал знакомый принцип: где один интересный девайс, там быстро появляется пара других…
Меня зовут Астафиев Денис, я ведущий специалист по аппаратным исследованиям в Бастионе. По работе я регулярно разбираю самые разные устройства, чтобы проверить, насколько можно доверять тому, что производитель обещает на коробке. Сегодня будем смотреть сразу на три замка с биометрией и искать слабые места в их защите.
Сразу оговорюсь: цель этой статьи — не любой ценой «дожать» дешевый китайский замок до уровня лабораторного исследования. Наоборот, мне хочется на простом и доступном примере показать, как обычно строится базовый аудит аппаратной безопасности и почему начинать его стоит совсем не с самых сложных атак.
Что может быть привычнее для разработчика, чем ежедневный ввод команд установки или обновления зависимостей: npm install, pip install, uv add, bundle add, cargo add? Пакетный менеджер находит нужную библиотеку, скачивает её вместе с транзитивными зависимостями и за несколько секунд устанавливает в проект сотни тысяч строк чужого кода. В этот самый момент мы не задумываемся о том, что совершаем серьёзный акт доверия. Мы доверяем автору пакета, его аккаунту, системе публикации, сборочному конвейеру и всем зависимостям, которые пакет подтянет вместе с собой. Бесспорно, большую часть этого кода мы не читали и, скорее всего, не прочитаем никогда. Пока всё работает как задумано, этот процесс остаётся незаметным. Но стоит злоумышленнику скомпроментировать хотя бы одно звено этой цепочки, и обычное добавление или обновление библиотеки превращается в установку вредоносного кода в сотни или даже тысячи проектов.
Именно на этой идее и строится атака на цепочку поставок — supply-chain attacks. Зачастую злоумышленнику не обязательно искать уязвимости непосредственно в вашем приложении, планировать дорогостоящие многовекторные атаки и применять социальную инженерию. Ему достаточно увести учётку разработчика даже не особо известного пакета, добавить бэкдор в новую версию, опубликовать её в тот же npm или PyPi — и вуаля: вот уже вредоносный код отправляет персональные данные ваших клиентов прямиком на серверы хакеров.
Наверное, многие уже видели или хотя бы слышали про цепочки атак, где пользователю показывают красивую фейковую Cloudflare CAPTCHA, а дальше предлагают выполнить несколько действий «для проверки».
Схема далеко не новая. Более того, я вообще не удивлюсь, если кто-то скажет: «Да мы это уже видели». И будет прав. Но, как обычно, старые идеи периодически достают из шкафа, немного перекрашивают и снова пускают в ход.
Вся эта история опять упирается в одну простую вещь — внимательность пользователя. Если человек сам выполнит то, что ему подсунули, дальше защита компьютера уже может не сильно помочь.
Совет про токен в адресе страницы кочует из статьи в статью в одной и той же формулировке: не кладите его в URL, иначе он уедет в заголовке Referer на все сторонние ресурсы, которые подключает ваша страница.
Совет правильный по выводу и неправильный по обоснованию. Через Referer он давно никуда не уезжает. А вот сам токен из URL утекает — просто в других местах, и там его обычно никто не ищет.
