dxdt.blog: занимательный интернет-журнал

Корень глобальной DNS сейчас подписан, в рамках DNSSEC, криптосистемой RSA. В ICANN – организации, определяющей требования к работе глобальной DNS, – некоторое время назад запустили процесс перехода корневой зоны с RSA на ECDSA (P-256/SHA-256, это алгоритм номер 13 в DNSSEC). В текущей версии предложения ICANN планируется переход в течение четырёх лет. То есть, переход должен завершиться в 2030 году (традиционная дата, да).

Сейчас среди зон ниже первого уровня мало что подписано, мало где есть DNSSEC. Например, в .RU – это какие-то доли процента. Тем не менее, DNSSEC касается всех валидирующих резолверов, и если DNSSEC сломается, то сломается всё дерево ниже подписанной точки, в которой DNSSEC отвалилась. Например, так как подписана сама зона .RU, то когда в .RU сломались подписи DNSSEC, отвалились абсолютно все домены второго (и ниже) уровня внутри .RU, вне зависимости от того, есть в каком-то из этих доменов DNSSEC или нет. Ещё раз подчеркну, это касается только валидирующих резолверов, однако сейчас самые массовые публичные резолверы (Google Public DNS, Cloudflare и др.) – валидирующие. Да и вообще – в 20-х годах 21 века нужно использовать только валидирующий резолвер. Соответственно, если отвалится DNSSEC в корневой зоне – DNS сломается, фактически, для всего Интернета.

DNSSEC в корне DNS полностью внедрили в 2010 году, естественно, на RSA. Так как при вводе DNSSEC в эксплуатацию никто не озаботился тем, чтобы не только согласовать процесс ротации корневого ключа, но и хотя бы предусмотреть такой процесс, замена корневого ключа состоялась только в 2018 году. Впрочем, вряд ли это как-то повлияло на практическую стойкость: практические возможности по взлому RSA-ключей из подписей – сильно расходятся с теоретическими предположениями. А тем более эффект сомнителен, если учитывать реальность использования DNS и DNSSEC и схему подписывания самой корневой зоны. Для подписи зоны используются дополнительные ключи, которые, в свою очередь, удостоверяются корневым. Процесс генерирования новых ключей подписи зоны и удостоверения этих ключей изначально предполагал серьёзные шаги по обеспечению безопасности криптографических данных: защищённые помещения, доверенные люди, физические сейфы, физические ключи, аппаратные модули (HSM) и так далее.

Однако в 2020 году вообще просто взяли и нагенерировали и подписали доверенные ключи для корневой зоны заранее, на будущее, сделав участие “криптоофицеров” дистанционным (да! это через эти же “подписываемые интернеты”), чтобы лишний раз не собираться – после этого уже стала окончательно понятна вся театральность действий по “защите” корня DNS, включающая посещение хранилищ и не менее церемониальную работу с аппаратными модулям при помощи отвёртки и молотка – и это не преувеличение. Ритуалы и уровень их исполнения – выходят на первый план, да. Прямо из ICANN и корня DNS. Театр, как социальное явление, очень важен. Главное, понимать, где именно театральное действо переходит в цирковое.

И всё же, вернёмся к ключам DNSSEC. Cледующая ротация корневого ключа намечена на октябрь 2026, но это опять будет RSA. Потому что, как нетрудно догадаться, механизма замены криптосистемы в корне DNS тоже не предусмотрели. Механизм разрабатывают сейчас.

Самое занятное, что в рамках перехода на ECDSA имеющиеся ключи RSA собираются сократить. Да. Собираются уменьшить их разрядность с 2048 бит до 1536 бит. Как бы, по нынешним временам, 1536 бит не считаются стойким вариантом. (Заметьте, впрочем, что для атаки на гипотетическом-фантастическом квантовом компьютере – 1536 битов RSA всё равно сильнее, чем 256 бит ECDSA, потому что теоретические алгоритмы квантового взлома прямо оперируют разрядностью, и для записи 256 бит может потребоваться меньше кубитов.) Естественно, снижение разрядности RSA обусловлено стремлением удерживать максимальный размер DNS-ответа ниже границы, доступной в UDP-транспорте: ниже 1232 байтов. Это позволяет избежать перехода на TCP со стороны резолверов. (DNS требует перехода на TCP в тех случаях, когда ответы не проходят по размеру в UDP.)

Согласно плану, уменьшение длины RSA-ключа в корне DNS намечено на 2027 год. А в первой четверти 2028 года запланирована публикация ECDSA-подписей. При этом, сами ECDSA-ключи в зоне публиковать сразу не собираются. Тоже занятное решение, обусловленное, скорее всего, тем, что DNSSEC требует подписывать зону всеми обозначенными криптосистемами, но не всеми ключами. Поэтому ключи опубликуют позже, во второй четверти 2027 года, когда ECDSA-подписи уже побывают в зоне. RSA-ключи отзовут в 2030. Если по плану. Потому что документ предварительный и пока что выставлен для публичного обсуждения.

Пишут (The Guardian, англ.), что в Штатах расследуют некие заявления о наличии у провайдера сервиса мессенджера WhatsApp возможности читать частные сообщения пользователей, несмотря на заявленную в протоколе криптографическую защиту “точка-точка” (E2E). В статье, кстати, прямо противопоставляют эту “архитектурную особенность” WhatsApp архитектуре мессенджера Telegram, который подобной “защиты” не предоставляет по умолчанию. Это сравнение, похоже, уже стало штампом в околотехнической журналистике. Но в статье интересен другой момент – там есть цитата эксперта, в которой говорится следующее:

Идея, что WhatsApp может выборочно и задним числом получать доступ к содержанию [зашифрованных в режиме “точка-точка”] индивидуальных чатов, представляет собой математическую невозможность. (Оригинал: “idea that WhatsApp can selectively and retroactively access the content of [end-to-end encrypted] individual chats is a mathematical impossibility”).

Это довольно странное утверждение. Дело в том, что даже в идеальном случае вся подобная криптография, – где в алгоритме отсутствует передача непосредственно на основе симметричного секрета, согласованного заранее, защищённым способом, – как раз математически-то строго обратима. (Если более точно, то это алгебраическое требование – иначе у вас асимметричный протокол работать не будет, потому что ключи могут не сойтись, либо получатся нестойкими, если там нет нужной биекции; да, имеются некоторые практические исключения, когда ошибка предусмотрена протоколом, но это тоже плохо.)

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

У провайдера приложения и сервиса – есть очень много способов сделать так, что сообщения станут доступны для просмотра именно провайдеру. Это способы разной степени скрытности. Самый аккуратный вариант – встраивание в приложение алгоритма генерирования ключей с бэкдором. Ключи, полученные по такому алгоритму, будут выглядеть как стойкие, но для провайдера, обладающего дополнительной информацией, стойкими являться не будут. Теперь добавьте сюда непрерывный сбор метаинформации, характерный для подобных коммерческих сервисов централизованного обмена сообщениями, и вот вам набор каналов для утечки той самой дополнительной информации о состоянии криптосистемы на устройстве.

Так как провайдер сервиса контролирует приложение, то этот провайдер может встроить в это приложение какие-угодно дополнительные функции. В том числе, позволяющие вести архив сообщений на устройстве (в доступном для провайдера виде) и по запросу передавать записи из архива провайдеру. Опять вспоминаем, что тут есть каналы для передачи метаиформации, для обновлений ПО, есть хостинг видеофайлов и фотографий, и т.д., и т.п. Ещё раз: не обязательно хранить сообщения в открытом виде – можно архив зашифровать так, что доступ будет у провайдера.

Да, формально, есть разные способы получить доверенную сборку приложения и исходный код. Но, во-первых, это всё из области фантастики – мало кто может что-то найти, мало кто вообще следит за таким; во-вторых, так как это центральный сервис, то приложение с “дополнительной нагрузкой” может раскатываться только по некоторому набору устройств. Нет, не обязательно скрывать “дополнительную нагрузку” в самом приложении мессенджера – если требуется немного замести следы, то “дополнительная нагрузка” приедет в другом приложении, которое уже использует недокументированные возможности титульного приложения мессенджера или даже ОC.

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

В 2023 году я писал, что замена нормальных процессов разработки программного обеспечения на генерирование кода силами ИИ/LLM может привести к получению “транслятора тестовых примеров” вместо реализации шифра. Цитата:

Теперь представьте, что ИИ-говорилка совсем хорошо “оптимизировалась” и генерирует код, который просто-напросто самым прямым образом реализует выдачу правильных ответов на эталонные тестовые примеры, без, собственно, шифра.

“Кто бы мог подумать”, но уже в 2026 году в Cloudflare, – а это компания, которая раньше, вполне заслуженно, считалась технологическим лидером целого большого сегмента ИТ, – опубликовали в официальном блоге описание и код якобы специализированного Matrix-сервера, работающего на их, Cloudflare, коммерческой инфраструктуре (как сервис). С “постквантовой криптографией”, да.

Оказалось, что этот код сгенерирован ИИ/LLM, содержит грубейшие ошибки и, что главное, не реализует целый пласт необходимых функций. То есть, это не Matrix-сервер.

Самое забавное, что там, вместо реализации криптографических преобразований, открытый и секретный ключи – задаются путём записи произвольной последовательности байтов в массивы. Одинаковой последовательности – секретный ключ равен открытому (да, есть комментарий, что это – заглушка, но выдавали за готовый сервер).

   // For now, store the seed as both public and private (placeholder) 
   // In production, use proper Ed25519 implementation 
   const publicKey = btoa(String.fromCharCode(...seed.slice(0, 32))); 
   const privateKey = btoa(String.fromCharCode(...seed)); 

А вместо операции вычисления цифровой подписи – значению подписи просто присваивается значение хеш-функции. (Напомню, что вычисление значения хеш-функции от сообщения – это первый этап применения алгоритмов цифровой подписи; дальше там должно идти само вычисление подписи, но тут оно пропущено.)

   // Canonical JSON representation 
   const canonical = canonicalJson(obj); 
   const hash = await sha256(canonical); 
  
   // Placeholder signature - in production use Ed25519 
   const signature = hash;

Потому что это результат LLM. К тому же, очевидно, результат – не прошедший даже минимальной проверки (а зачем? это же замедляет процессы; компьютер с LLM – “не может ошибаться” и скоро уже будет писать код, “непонятный для человека, а поэтому – сверхэффективный”).

Да, к исходному сообщению в блоге Cloudflare теперь приписано, что это только “демонстратор”, а не сервер, но изначально этого предупреждения там не было. О том, что это всего лишь очередной поток от генератора кода на LLM – не написано ничего. По понятным причинам: это пошло бы против нынешнего хайпа. Зато – можно наблюдать очередной пример того, как, – при помощи схемы “хайп – это продукт”, – очередная весьма наукоёмкая отрасль стремительно скатывается, вступая в Новое средневековье. Большая проблема.

Сurl отказывается от программы вознаграждений за найденные уязвимости (bug bounty), которая несколько лет работала на базе Hackerone. Основная причина: затапливание “ИИ-помоями” (ложными и абсурдными сообщениями об уязвимостях, сгенерированными ИИ/LLM), которые отнимают очень много ресурсов разработчиков, но не несут с собой ничего полезного для проекта.

Авторская колонка Дмитрия Буркова – о том, един ли всё ещё корень глобальной DNS. Цитата:

Начиная с 1990-х годов возникали, существовали и исчезали проекты вроде AlterNIC, OpenNIC и Yeti DNS, стремившиеся предложить децентрализованные, общественные или экспериментальные альтернативы.

В DNS есть несколько штатных способов создать циклы, которые сделают обычный рекурсивный опрос невозможным. Самый привычный способ – использование субординатных NS. То есть, пусть зона example.com делегирована на два авторитативных NS – ns1.example.com, ns2.example.com. Оба имени находятся в исходной зоне example.com, откуда и название “субординатные”. Чтобы найти A-запись в зоне example.com – резолверу нужно опросить хотя бы один из авторитативных NS-ов, а чтобы опросить NS, нужно знать его IP-адрес (A- или AAAA-запись), а чтобы узнать IP-адрес – нужно опросить авторитативный NS зоны example.com, ну и так далее.

Если бы не glue-записи с IP-адресами, то разрешить такой цикл было бы невозможно. Glue-записи – это специальный способ предоставить резолверу IP-адреса узлов, которые, из-за циклов в адресации, невозможно найти обычным рекурсивным опросом. Эти записи передаются авторитативными серверами в специальной секции DNS-ответа и, в случае примера выше, сразу содержат IP-адреса для имён ns1.example.com, ns2.example.com. Без glue-записей практическая DNS работать не будет. И не только по причине наличия только что описанного элементарного цикла: есть случаи и посложнее.

Один из таких случаев – “кросс-делегирование”. Предположим, что зона example.net делегирована на ns1.example.com, ns2.example.com. Обратите внимание: из зоны .net – делегируется на имена в .com. При этом зона example.com – делегирована на ns1.example.net, ns2.example.net.

Теперь предположим, что резолвер ищет A-запись для example.com. Как резолвер мог бы действовать:

(0) для обнаружения нужной A-записи резолверу необходимо найти авторитативные серверы зоны example.com;

(1) на авторитативных серверах делегирующей зоны .com резолвер узнаёт, что NS для example.com – ns1.example.net, ns2.example.net;

(2) теперь резолвер должен определить A-записи для этих имён серверов (ns1.example.net, ns2.example.net);

(3) но для этого нужно найти авторитативные серверы зоны example.net;

(4) на серверах делегирующей зоны .net резолвер узнаёт, что имена этих серверов – ns1.example.com, ns2.example.com;

(5) теперь, чтобы узнать A-записи ns1.example.com, ns2.example.com, резолверу нужно определить авторитативные серверы зоны example.com, но это – шаг (1); получился цикл.

Естественно, настраивать так зоны, мягко говоря, не очень хорошо, даже несмотря на то, что данный цикл разрешается с использованием glue-записей. В случае использования glue-записей, их должна предоставлять каждая делегирующая зона, но в составе этих записей уже будут имена из другой зоны. То есть, в случае простого примера с субординатными NS для example.com – glue-записи содержат адреса серверов внутри example.com (ns1, ns2); в случае “кросс-делегирования” – адреса уже будут для имён в example.net.

Это далеко не все варианты создания циклов. Есть и ещё более сложное “петлевое” делегирование, и постоянно неверно используемая запись CNAME. Что касается CNAME, то это самая проблемная запись в DNS. CNAME предназначена для перезапуска процесса рекурсивного опроса. Вдумайтесь: в DNS изначально заложен сигнал, который, при штатном использовании, заставляет резолвер “начать заново”. Можно ли предложить лучшую основу для DoS? Вряд ли. Потому что если резолвер, отправив запрос про test.ru, получил CNAME с указанием на example.com, то он должен “забыть” исходное test.ru и начать опрос DNS для example.com. И так далее. CNAME можно указать для любого имени. Стоит ли говорить, что нетрудно построить цикл из нескольких CNAME? Нет, не стоит – это очевидно, а такой цикл может быть сколь угодно сложным.

Естественно, DNS-резолверы вынуждены отслеживать все эти особенности, чтобы не зависнуть.

Одним из достаточно безопасных способов передачи файлов данных между разными информационными системами является использование “файлообменной” машины (обычно – виртуальной машины, выделенной для этой цели). То есть, экспортирующая система силами скрипта-робота выкладывает файлы данных на обменную машину, а импортирующая система – забирает свежие файлы, зайдя на файлообменную машину силами собственного скрипта-робота – см. схему.

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

Поэтому получается добротная, обозримая и понятная точка обмена файлами. Такая архитектура позволяет даже сеть передачи данных выделить под задачу – то есть, файлообменные машины находятся в обособленном сегменте (логическом, виртуальном или “физическом” – как угодно), при этом контроль сетевого доступа дополнительно осуществляется вне файлобменной машины. Можно даже сделать доступ через какой-нибудь физически изолированный канал (не сеть): например, прямое соединение оптоволокном.

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

Рассмотрим практические особенности схемы с выделенной файлообменной машиной.

Итак, пусть одна информационная система экспортирует файлы, а вторая – импортирует. Для экспорта нужно обеспечить “исходящий” сетевой доступ к файлообменной машине: естественно, “исходящий” – тут не обязательно работает на уровне “диода данных”. Конечно, в идеале можно сделать аппаратный однонаправленный интерфейс, в котором физически не предусмотрено передачи любых данных в обратную сторону. Но в большинстве практических случаев это излишне, прежде всего потому, что теряется возможность аутентификации одной из логических сторон, то есть приложений (каждую физическую сторону – аутентифицировать может система построения канала). Поэтому в данном обзоре не будем совсем строить сложности, а ограничимся организацией выкладки файлов при помощи SSH-доступа. То есть, сервис (скрипт) на экспортирующей системе (“Система А” на схеме) периодически подключается по SSH к файлообменной машине и выгружает туда файлы (заметьте, вовсе не обязательно выгружать через scp – это, опять же, прочие детали, но немного про них будет в конце записки). Это не “диод данных”, но файлообменная машина, с логической точки зрения, оказывается “однонаправленной” системой: подключиться туда можно только по инициативе передающей стороны, и никакие файлы данных при этом на скачиваются (но загружаются).

Естественно, установление SSH-соединения требует не только уровня подключения с управлением сессией (TCP, в данном случае), но и двунаправленного взаимодействия с сервером на уровне SSH: сервер должен ответить, прислать ключи и так далее. Так что однонаправленным соединение оказывается только на самом высоком логическом уровне. Тем не менее, SSH-сервер, обычно, является типовым элементом и уже есть в операционной системе (например, через него ходят администраторы), поэтому тут не добавляется ничего принципиально нового, а вот имеющееся – можно и урезать (см. ниже).

Атакующая сторона, если она взломала файлообменную машину, не может, штатно, куда-то подключиться с этой машины, но может, например, подменить присылаемые файлы. Более продвинутая атака состоит в воздействии на SSH-сервер: технически, действуя умело и изящно, можно “перепрыгнуть” в обратную сторону – от SSH-сервера на подключающийся клиент. Но это уже будет высший пилотаж, даже для хорошо подготовленного пентестера.

Заметьте, что так как инициатива подключения находится на стороне сервера передающей системы, то, после вторжения на файлообменную машину, не получится как-то гарантированно навязать нужные данные этой передающей системе – придётся дождаться подключения. Это важный момент, который исключает сразу много классов уязвимостей. Например, перемещение данных между логическими HTTP-соединениями: если бы с файлообменной машины можно было куда-то штатно подключиться по HTTP, то в это “куда-то” можно было бы в любой момент отправить “полезную нагрузку”, взломав, таким образом, следующий хоп. Когда подобные исходящие запросы заведомо блокируются, придётся ждать подключений (того же SSH). Всякое ожидание увеличивает шансы обнаружения вторжения – это очень важный момент, про который постоянно забывают. (Естественно, захват контроля над файлообменной машиной позволяет попробовать найти что-то в “ближайшей сети” и т.д. Именно поэтому такая машина и должна быть изолирована на сетевом уровне.)

Посмотрим теперь на ситуацию со стороны другой информационной системы, которая принимает файлы (“Система Б”). Сервис (скрипт) в этой системе, как мы договорились, тоже имеет возможность SSH-подключения к файлообменной машине: подключаясь, этот сервис забирает новые файлы, которые выгружены со стороны экспортирующей системы. Если атакующая сторона захватила импортирующую систему, то какие есть возможности в отношении экспортирующей? Получается, что такой атакующий может зайти на файлообменную машину тем же аккаунтом, который использовал штатный сервис. Как минимум, автоматом получаем возможность читать экспортируемые файлы. Как максимум – можно поднять привилегии. Можно-то – можно, но не факт, что так просто.

Почему-то часто считают, что SSH-доступ всегда эквивалентен локальному шелл-доступу к основной системе. Но это не так. Понятно, что, – по нынешним-то временам, – путь от локального аккаунта до суперпользователя не так долог, как хотелось бы (возможно, теоретически, это не так под чем-нибудь вроде хорошо настроенной FreeBSD, но речь про практическую ситуацию). Однако, никто ведь не сказал, что и SSH-сервер, и шелл, предназначенные исключительно для реализации обмена файлами, нельзя изолировать локально, выкинув всё лишнее, и не только под FreeBSD. Нет, вовсе не обязательно использовать тот же сервер и тот же шелл, которые нужны DevOps для управления. Напротив – подключаемся, заходим, а там изолированная директория и, вместо полноценного шелла, только урезанный набор из ls, mkdir, cat, (s)cp и mv (rename), предположим. То есть, для атакующего – опять дополнительные шаги и локальные хопы (loopback какой-нибудь использовать и пр.), а каждый хоп, не забывайте, тоже повышает шансы обнаружения вторжения.

При этом SSH-авторизация обеспечивает защиту доступа к файлообменной машине (когда работает, конечно, что уж там). Но в описываемой схеме, да просто так, – даже захватив одну из информационных систем, которые файлообменную машину используют, – перейти в другую информационную систему нельзя. Точка обмена файлами оказывается своего рода тупиком: нужно ломать и её тоже, а возможности сильно ограничены.

Сравним теперь нашу схему с вариантом, когда файлообменной машины нет, а экспортирующая информационная система (“Система А”) загружает данные непосредственно в импортирующую (“Система Б”), через специальный высокоуровневый прикладной интерфейс (API), поднятый именно с этой целью. Это может быть rsync, но может быть и HTTP-сервер. Тогда, если принимающая система скомпрометирована, то получается, что экспортирующая система уже прямо подключается к контролируемому атакующей стороной серверу. В случае файлообменной машины это не так: там требовалось сперва захватить саму файлообменную машину. Но, естественно, остаётся необходимость ожидать момента подключения.

Ещё хуже, если используется HTTP-сервер, общий с другими задачами импортирующей системы. Этот HTTP-сервер может быть атакован и захвачен в рамках выполнения им других задач, но при этом атакующий получает плацдарм для прямой атаки на другую внутреннюю информационную систему (“Система А”), подключающуюся периодически для выгрузки файлов данных. Но для этой второй системы HTTP-сервер оказывается доверенным, так как задействован во внутреннем процессе. А на стороне принимающей системы – этот же сервер раздаёт, предположим, веб-страницы всем желающим.

А если атакующий захватил передающую систему, то, при условии прямого подключения, он может сразу атаковать и принимающую. Более того, тут уже подготовлен тот или иной доступ – скажем, SSH или даже TLS с двухсторонней аутентификацией. При этом отсутствие логического промежуточного узла, файлообменной машины, не позволяет эффективно разделить информационные системы на логическом же уровне протокола сетевого взаимодействия – доступ уже должен быть прямым (естественно, промежуточные сетевые узлы тут могут быть всё равно, но это теперь совсем другой аспект). Более того, прямое соединение систем навязывает всякие прочие “архитектурные решения”, в которых системы станут смешиваться и, по ошибке администратора, из одной – окажется легко перепрыгнуть в другую, без учёта направления.

“Хабр” – известный ресурс про ИТ – тоже упал, и уже некоторое время лежит. То есть, индексная страница под habr.com с редиректом что-то иногда показывает, но статьи и сервисные страницы – возвращают HTTP 502.

(Update: к 16:00 14.01.2026 – вернулось.)

Cloudflare пишут об утечке BGP-маршрутов крупного венесуэльского провайдера, случившейся в начале января этого года, непосредственно перед известной операцией США. Краткий вывод: утечки маршрутов происходят постоянно (это факт, не поспорить), поэтому единственное, на что эта утечка может косвенно указывать, так это на то, что были проблемы с сетевым оборудованием, точнее – с его настройками (тут тоже не поспорить – глобальные утечки в BGP вполне себе служат сигналами о том, что именно происходит на сетевом оборудовании провайдера, но для интерпретации сигнала – нужно знать схему сети; соответственно, если вы хорошо подготовленный атакующий, то и утечки маршрутов помогают).

Аккаунт на “Хабре” у меня с 2009 года. Однако до 2025 года я этим аккаунтом, фактически, не пользовался и ничего не публиковал (за исключением пары коротких комментариев, да и те – в 2020 и 2023 годах). В 2025 году, поскольку я постоянно вижу и слышу, как на “Хабр” ссылаются не только студенты профильных специальностей, но и даже коллеги, давно работающие в области ИТ, я решил попробовать посмотреть на этот ресурс с практической точки зрения. И вот в 2025 году я опубликовал там 18 статей (должно бы быть 19, но, видимо, не в этот раз), 11 “постов” (другой формат), три новости (третий формат) и около 110 комментариев (ну, на странице профиля сейчас написано, что 110, однако это количество незначительно меняется даже тогда, когда я новых комментариев не пишу: причина мне не ясна, возможно, какие-то статьи, где есть мой комментарий, снимают с публикации). В общем, теперь нельзя сказать, что я не изучил использование “Хабра” на практике, поэтому поделюсь впечатлениями.

1.

Я написал статьи по разным темам, но смысл написания статей на “Хабр” так и остался для меня тёмен: какого-то заметного трафика на эти статьи не приходит; видимо, они не интересны для аудитории (что, впрочем, не стало для меня сюрпризом).

Поскольку я постоянно сталкиваюсь с упоминаниями “Хабра” (см. выше), ресурс этот, всё же, популярный. Однако тематика, получается, с моими представлениями и моими текстами пересекается крайне мало (что, впрочем, тоже не удивительно). Кстати, счётчики просмотров на “Хабре” довольно странные: показатели в статье и на странице внутренней статистики существенно отличаются (про это там внутри прямо написано, на специальном баннере, а различные показатели объясняют тем, что “разные методы”, что бы это ни значило). Счётчик в самой статье, как я понял, нужно делить примерно на 10, чтобы получить количество прочтений.

2.

Складывается впечатление, что основной объём контента сейчас там дают три пересекающихся направления: “переводы”, “корпоративные блоги” и “ИИ – силами и при помощи”. “Переводы” – это переводы англоязычных (в подавляющем большинстве случаев) статей из разных “иностранных” источников, и так доступных в Сети. Для меня – это странно. Наверное, такое явление полезно. Однако, почему не читать первоисточник – лично мне не очень понятно. Скорее всего, ИТ-аудитории “Хабра” на русском читать сильно проще; однако, не забывайте, это создаёт вторичность и подчёркивает вторичность, а в переводах встречаются ошибки, иногда – весьма досадные.

В “корпоративных блогах”, как ни странно, попадаются весьма и весьма хорошие статьи. Попадаются. Но редко. К сожалению, чаще это что-то типовое, – и ещё более “вторичное”, чем переводы, – из разряда “как мы настроили мониторинг” (всегда интересно почитать, как настроен мониторинг мониторинга, но о таком пишут очень редко). Понятно, что такие “интеграции”, как корпоративные блоги, просто необходимы “Хабру”. Поэтому, тут-то как раз упрекнуть этот ресурс не в чем.

А вот явление “ИИ” – заслуживает отдельного обсуждения, см. следующий пункт.

3.

Существенная часть контента современного “Хабра” – это сгенерированные ИИ/LLM тексты и картинки. Либо сгенерированные непосредственно LLM, либо сгенерированные при помощи LLM.

Естественно, это всё видит аудитория – и тексты, и, тем более, картинки – легко узнаются. Иногда авторы статей прямо пишут, что использовали при написании ИИ. Такое раскрытие информации – похвально. Непонятен только сам смысл использования ИИ. Вообще, смысловое качество результатов LLM-генерации – ну, как говорится, оно ожидаемо низкое. А вот место и время – расходует на высоком уровне.

Но, среди ИИ-эффектов, не это самое неприятное: самое неприятное – что ресурс буквально залит сопутствующими статьями и новостями “про и вокруг ИИ” (“новая LLM”, “101% кода уже пишет ИИ”, “сотрудник компании по продвижению ИИ-хайпа сказал, что они продвигают ИИ при помощи ИИ через ИИ” и т.д.). Публикации как бы сделаны под копирку, но затапливают ленту.

Да, проблема эта массовая, общая: с появлением доступных генераторов связного текста – затапливать начало практически весь веб, и не только веб. Но в чём смысл продираться через это на ИТ-ресурсе? Вопрос риторический. Что делать – не понятно, но продираться надоело.

4.

На “Хабре” более или менее понятный текстовый редактор для размещения статей. Но не очень понятно, как нужно выбирать “тип аудитории” (что бы это ни значило) и ключевые слова. С хабами – вроде, понятно.

Но при всём при этом, к большому сожалению, возможностью логина на сайт (по ИТ-тематике!) теперь прямо управляет “Яндекс”. Я как-то написал, что на “Хабре” попадаются забавные капчи. И вот, по какому-то совпадению, практически сразу же, на “Хабре” те капчи поменяли – заменили на сервис от “Яндекса”. Теперь без подтверждения из “Яндекса” залогиниться нельзя вообще. Никак. Не очень хорошо, на мой взгляд. Тем более, что на “Хабре” загружаются скрипты с рекламой от “Яндекса”.

5.

Отдельно меня разочаровало то, что на “Хабре” теперь начали непосредственно в код разметки пользовательской статьи подмешивать рекламу ИИ-агентов от того же “Яндекса”.

Вот. В целом – ничего особенного. Посмотрим, как станет дальше.

Я в ноябре выступил с небольшим докладом на Пиринговом форуме. Кроме прочего, в докладе показал и неравенство треугольника для Anycast (см. ниже фото, из официальных).

Вообще, неравенство треугольника здесь – это очень полезная иллюстрация, которая показывает, что только из конкретных BGP-таблиц какие-то данные о реальной связности получить нельзя, а содержательные показатели образуются тогда, когда мы начинаем “склеивать” сведения из разных BGP-таблиц (то, что называется View). Другими словами: именно на пересечении, на склейках, и образуется модель Интернета, как схемы, существующей между IP-сетями.