Последнюю неделю я погружался в мир IPv6 с головой, приключение было интересное.

Где-то год назад, когдя у меня появился роутер Keenetic, я решил перевести коробку от МТС innbox g84 в режим моста. Делается это не сложно, есть нужные инструкции по ссылке. По пути выяснилось, что роутер довольно троянский, в нем есть как минимум 3 (потенциально 4) учетки:

admin -- учетка, доступ к которой выдается клиенту
mgts -- учетка со стандартным паролем mtsoao, используется сотрудниками МТС, имеет повышенные привелегии в сравнении с admin
superadmin -- учетка с самыми высокими привелегиями, пароль получить можно только из бекапа прошивки
manufacturer (?) -- https://4pda.to/forum/index.php?showtopic=1038399&st=500#entry121072943

Так же, на роутере присутствует TR-069 -- протокол удаленного управления оборудованием пользователя. Можно выключить в настройках из-под superadmin, но после перезагрузки включится обратно.

В добавок, еще есть OMCI протокол, но до него руки не дошли.

В общем настроив большую часть учеток, отключив TR-069, и переведя в режим моста какое-то время он у меня работал, но только по IPv4 протоколу, с IPv6 были какие-то проблемы, на тот момент я решил не заморачиваться и просто отключил его везде, и отложил в долгий ящик.

И вот, руки наконец-то дошли, попробовав включить IPv6 от ISP в роутере кинетик, я получал prefix, ip, gateway для v6 от провайдера, адреса раздавались на устройства в сети, казалось бы, все работает, пинги идут, ssh работает. НО! Открыв браузер, и попытавшись зайти на какой-нибудь v6 сайт у меня не грузилась статика (да и в принципе все большие файлы не доходили до меня, либо доходили спустя пару минут). Долго провозившись с wireshark, traceroute, tracepath, curl картина не прояснилась, выглядело так, как будто разрывы на стороне провайдера. Попробовал убрать из цепочки кинетик, и напрямую подключиться к МТС роутеру в режиме моста. ПК получил и адрес внутри в4 сети провайдера и в6 адреса, но проблему это не решило.

Тогда я решил попробовать купить взамен МТС роутера ONT терминал. Ситуация оказалсь еще хуже. На нем все так же есть TR-069 и OCMI, который автоматически прописывает настройки от МТС, и даже если отключить, после рестарта он снова включиться. Но это полбеды, с IPv6 ситуация стала еще хуже, да, адрес все так же выдается, но в gateway на роутере прилетает адрес fe80::1, который ведет к самому этому ONT, но из-за того, что он в режиме моста, дальше до сети провайдера он не достукивается, отключить полностью IPv6 на этом терминале у меня не вышло. Перестало работать вообще все, и пинги, и dns, и curl. В общем, отвратительное решение.

Последним вариантом подключения стал этот XPON ONU STICK (спасибо за подсказку @dotrubic). Штука довольно простая, в один конец вставляется PON кабель, а второй в сам SFP порт в роутере. Далее, зайдя в админку, достаточно ввести PLOAM пароль и номер VLAN, по которой провайдер ведет к вам интернет (в моем случае номер 30). В самом ONU нет никакого dhcp, IPv6, ничего подобного, только 192.168.1.0/24 подсетка, с ручными маршрутами -- конфликтов больше не возникает, кинетику выдается и корректный перефикс, и корректный gateway. Все наконец-то ЗАРАБОТАЛО.

Пока все это настраивал возникало множество побочных проблем)

В keenetic нельзя указать свой IPv6 dns из веб-морды, человек из хорошего чата подсказал что это можно сделать через telnet так:

ipv6 subnet Default dns-server <address>

В моем keenetic SFP порт комбинированный с rj-45 портом под номером 4, по дефолту он находится в Home lan. Чтобы подключить в него XPON ONU STICK в бридж моде, нужно сделать его WAN портом из веб-интерфейса. Но, чтобы достучаться до веб морды самого стика нужно повесить alias на WAN порт, обычно это делается для интерфейса ISP следующей командой:

interface ISP ip alias 192.168.1.2 255.255.255.0

Не сразу получилось сообразить на какой из интерфейсов теперь нужно вешать алиас, но по итогу вышло вот так:

interface ge0/vlan4 ip alias 192.168.1.2 255.255.255.0

Теперь осталось только дочитать этот манускрипт -- https://yarique.bitbucket.io/ipv6_ru/ipv6_ru.htm

Вот теперь максимально добротно, благодаря туле, нашёл несколько несоответствий из upstream pico-fido, и пару своих багов, которые не были покрыты тестами текущими. В целом там не критичное было, но хотелось строгого соответствия спеке ctap 2.3 и u2f 1.1/1.2)

Доделал одну из крупных фич для RS-Key, очень ей доволен.

Trusted Display.

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

https://t.me/true_secator/8342

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

Вредоносная ПО нацелена на восемь браузеров на основе Chromium, включая Google Chrome, Microsoft Edge, Brave, Opera, Arc, Vivaldi, CocCoc и Yandex.

И это довольно старая и известная проблема, тут можно почитать подробнее:

https://www.wired.com/story/chrome-yubikey-phishing-webusb/

With the WebUSB feature in Chrome, however, a malicious website can bypass this safeguard by connecting directly to the token instead of using the browser’s CTAP API.

https://doc.qubes-os.org/en/latest/user/security-in-qubes/ctap-proxy.html#the-qubes-approach-to-ctap

Since the CTAP model assumes that the browser is trustworthy, any browser in the OS is able to access any key stored on the authenticator. The user has no way to know which keys have been accessed by which browsers for which services. If any of the browsers are compromised, it should be assumed that all the token’s keys have been compromised. (This problem can be mitigated, however, if the CTAP device has a special display to show the user what’s being authenticated.)

В аналогичном сегменте (именно security keys) я аналогов Trusted display не нашёл. Единственное, где я встречал решения подобного класса — Crypto Wallets (Trezor, Ledger, etc), но цена и функционал там соответствующие.

В текущем виде Trusted display поддерживает Fido2, OpenGPG, PIV, OTP, в общем, полный функциональный паритет с обычным ключем. Задавать, изменять и вводить пин код для всех протоколов можно с самого устройства. Пока что это версия 0.0.1 для него, ещё есть что допиливать, например, версию с аккумулятором и RTC, чтобы можно было OTP вводить без внешнего устройства.

Сам релиз:
https://github.com/TheMaxMur/RS-Key/releases/tag/v0.3.0

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

1. Атака на security researchers: Lazarus притворялись в твиттере и блогах "исследователями уязвимостей", долго зарабатывали себе репутацию, постепенно втягивали в исследования внешних настоящих специалистов в "совместную работу". Затем, присылали таргету (исследователю) проект с предоностным скриптом в build стадии, либо, заражали через 0-day в браузере на своих фейковых блогах. Делали они это с целью украсть наработки у этих исследователей и использовать их в своих атаках. См. картинку 1.

2. IDA Pro — троян: В продолжение прошлого кейса, теперь они встраивают трояны в сами тулзы для безопасников. IDA Pro широкоизвестен в узких кругах, это один из главных инструментов реверс-инженеров. Цель ровна та же, что и в прошлом случае, украсть наработки.

3. Double Supply Chain: Первая публично задокументированная "Double supply chain" атака. Заразили десктоп приложение 3CX, но Mandiant выяснил, что ещё до этого, сотрудник поствил зараженный трейдинг-клиент X_TRADER. См. картинку 2.

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

5. Маскировка под Windows обновление: Очередное внедрение через фишинг с вредоностными документами, но, в данном кейсе ВПО запускалось через легитимный клиент обновлений Windows, а в роли C2 использовался GitHub репозиторий.

6. 76% украденного в крипте за две атаки: Drift Protocol на ~$285 млн и KelpDAO на ~$292 млн, вместе ~$577 млн. Данные были актуальны на конец апреля 2026, в данный момент, в первом полугодии, доля атак Северной Кореи снизилась до 66%. Пока что, в сумме (не только Lazarus), за H1 украли на 1 лярд, не так много в сравнении с 2025, но там баланс украденного сильно смещает взлом bybit на 1.5 лярда, сейчас же, несмотря на уменьшение количества ворованных токенов, успешных атак стало больше. См. картинку 3.

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

Два хороших справочника по Lazarus:
1. Positive Technologies
2. MITRE ATT&CK G0032

САМЫЙ НАСТОЯЩИЙ АНДЕРГРАУНД