Сегодня первый четверг мая, а значит пора отмечать Всемирный день пароля!
Когда же на смену этому дню придет Беспарольный день? Судя по таблице, с каждым годом пароль надо делать все длиннее и длиннее, а значит аутентификация без пароля будет становиться всё более востребованной.

3 Апреля изменился формат файлов дампов BGP, которые формируются Routing Information Service, вот тут технические детали. Результатом стало значительное, в 3 раза, уменьшение размера файла полного дампа и ещё более значительное уменьшение времени его формирования, от двух часов до 10-15 минут. Ввиду таких приятных изменений я поменял время оповещения в @FullViewBGPbot на 4, 12 и 20 часов по Москве, что ближе к фактическому времени снятия дампа и заодно добавил немного каждодневной информации по статистике, что пользователи бота уже заметили.

RFC9386 - про внедрение IPv6, в разрезе с разных точек. Наверное, ничего нового для многих, но собрано в одном месте.

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

Кроме как операторам, владельцам граничных AS, фильтровать особо и негде. На транзите с фильтрами маршрутов не всегда удаётся справиться, а уж фильтровать трафик с миллион неизвестными параметрами, точно никак. Поэтому, если у вас есть AS, то фильтруйте - не выпускайте ничего из своей сети с не вашими адресами, и не впускайте ничего в неё с вашими. На самом деле, я даже за провайдеров не уверен, что многие настроили такие фильтры. За хостинги и корпоративные сети вообще не уверен: мой хостинг позволяет спуфить, а в моей рабочей сети подобные фильтры появились только с моим приходом. На NAT тоже не надейтесь, он бывает разный.

Про один из новых механизмов работы Великого Китайского файрвола. Старые механизмы тоже упомянуты, какие-то, как активное сканирование, даже проверены. Суть - подобранные эмпирическим путём правила, которых исследователи нашли 5 штук, позволяют блокировать неизвестные протоколы шифрования ориентированные на сокрытие трафика. По большому счёту правило одно: трафик который выглядит как случайный блокируется. При этом, вероятность ошибки подобранных правил блокировки 0,6%. Известные протоколы определяются отдельно и отдельно же анализируются, но это к тем механизмам которые работают уже давно. Работает всё только с исходящим трафиком в котором проверяется только TCP и первый пакет в сессии с некоторой вероятностью, а степень покрытия разных частей Интернета разная.

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

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

Спуфить спутники, конечно, не так просто как спуфить IP адреса, но вполне себе осуществимо за разумную цену из доступных элементов. Авторы всю работу считают мощность сигнала, стараясь его минимизировать, которым надо заменить орининальный сигнал со спутника, чтобы приёмник ничего не понял и принял всё за чистую монету. Учитываются, в том числе, и направленные антены и шум. В, итоге, на расстоянии 100 метров до приёмника можно подменить всё что хочешь, а для некоторых типов систем можно и за 8км быть до приёмника, чтобы успешно передавать собственный сигнал взамен настоящего.
Если вы не шифруете данные со спутника, а с этим в основном всё плохо, то можно применить некоторые другие методы чтобы себя в какой-то мере обезопасить, в публикации они тоже приводятся.

Так, с почтой Vivaldi закончили, а как бразуер ещё поживёт. Вернулся обратно на Thunderbird по причине внезапной пропажи половины моих ящиков, всех фильтров и RSS из интерфейса. В настройках всё осталось и на диске все данные целы, но достучаться до них никак. Базовые вещи включить/выключить, переставить - не помогли. Я конечно ещё покопаюсь, но без почты мне тяжко, поэтому переехал. При том, что как сделана почта в Vivaldi мне нравится: лаконичный интерфейс, каждое письмо в отдельном eml файле, что мне и позволило очень быстро накопившийся архив забрать с собой. За неполные 5 месяцев почти 1000 сообщений которые я сразу не удалил, из них 3 от живых людей, которые были продублированы по другим каналам, а остальное уведомления и чеки, реклама, подписки, на списки рассылки я не подписан. В общем ничего полезного для домашнего использования, но привычка смотреть каждый день в почту ещё сильна.

Кровавый энтерпрайз be like:

1. 100500 систем управления и учёта с премиум подпиской
2. Половина из них на ранней стадии запуска, половина выводится из эксплуатации
3. Отклик 200мс
4. Доступ только к половине нужных инструментов и только в ручном режиме без API и пакетного выполнения
5. Менеджеры и аналитики доступа к интерфейсу не имеют или "не умеют" пользоваться
5. Команда автоматизации занята совмещением несовмещаемого, возможно умеют программировать
6. С тобой они не общаются и в твоей работе не разбираются
7. Половина данных не актуальна, половина отсутствует
8. Иногда "индус" из автоматизации случайно стирает первую половину
7. Пытаешься актуализировать данные, для чего поднимаешь локальные системы
8. 100500 локальных систем автоматизации, учёта и мониторинга без премиум подписки
9. Половина из них на ранней стадии запуска, половина выводится из эксплуатации
10. Периодически антивирус блочит твои скрипты и ты получаешь выговор от команды безопасности
...
Заполняешь форму ежемесячного отчёта в Excel вручную копируя данные и подбивая статистику

Ещё один сервис для отслеживания состояния Интернета с прицелом на Россию, и статья с описанием на Habr. Из интересного: привязка ASn к компании владельца и динамика по ASn. Обязательно надо вспомнить что уже давно есть IDIDB, там тоже много про Рунет.

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

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

Я бы прошёл мимо, мало ли какую ерунду пишут в Интернете, если бы не получил эту ссылку как ответ на решение задачи логирования антивирусом вызова curl с паролями в открытом виде, которые он нашёл после подстановки переменных окружения:
"Enter the username and Password and then make a CURL call as usual. Except that you do not have to use the – user (or) -u flag or enter clear text password. The SecureCLI will take care of encrypting your username and password into the Base64 format and appends it to the Authorization Request Header"

"Закодировать" (encode) и "Зашифровать" (encrypt) - разные вещи, в статье эти понятия путаются, Base64 совсем не про шифрование, это всё равно что в открытом виде передавать. Сайт, кстати, предусмотрительно заблокировал доступ из России, поэтому ходить туда не надо.

Готовый ответ как правильно, есть на Everything Curl - используйте конфигурационные файлы.

DNS всё ещё перехватывается, RIPE Labs подтверждает. Способы противодействия тоже давно известны - пользуйтесь.

Иван Пепельняк делится двумя ссылками про историю 8 битового байта. Если ещё не читали - Julia Evans собирает в кучу разные факты и Steven Bellovin про стародавние времена начиная c 19 века и IBM System/360. Зримо присутствует Frederick Phillips Brooks Jr. и вот тут как раз стоит прочитать Мифический человеко-месяц про атмосферу царившую на проекте во время разработки S/360.

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

На UKNOF51 ещё рассказывали про самые основы сети в Kubernetes. И в общем-то, ничего сверхинтересного там не рассказали, но примечательно что это было на конференции для Интернет операторов от регистратора доменных имён. С учётом самого базового и общего уровня сложности материала, можно сказать что до телеком сетей и систем, как минимум, в Британии Kubernetes массово ещё не добрался и может и не доберётся. А ещё то, что телеком - это сети про другое и инновации там про другое, поэтому может и вопросов из зала данное выступление не вызвало.

Если где-то коллекционируете тексты в трассировке, тогда ставьте количество хопов на максимум (у меня больше 130) и запускайте traceroute до becky.keekles.org, смысл в словах, наверное, тоже можно найти.

Случайно в поиске вылезла моя статья на Habr от 2016 года про свободные блоки в BGP, которые не видны в анонсах. Залез посмотреть на код который я писал, понял что я ничего не понимаю, но он запустился и я его прогнал по актуальным данным. Данные не совпали с моими представлениями :) и с теми данными которые были приведены в статье тоже не совпали. В итоге я нашёл там ошибку, прямо такую которая привела к двукратному увеличению в общей оценке по параметру количества префиксов выраженных в блоках по /8 и /24. Саму статью я править не стал, за всё время никто ошибку не увидел, да и на смысл статьи она не влияет сильно, тем более сейчас. В коде тоже есть глюк, и я не понял где он, зато понял как его обойти, исключив одно из вычислений в принципе, так как оно было нужно для другой статьи на Nag, но там ошибка меньше, порядка 2% в сторону увеличения.

Итак, текущее состояние с дырами в full-view в сравнении с подкорректированными данными за 2011 и 2016. На текущий момент если сложить всё вместе - чуть больше 38 блоков по /8 не видно в анонсах. Это обычные адреса, все зарезервированные я уже исключил. В 2016 году таких было 54,5, а в 2011 чуть больше 79 блоков по /8. Наверное, они где-то используются, как минимум на IX, да и в целом никто не заставляет их использовать в публичном пространстве, но тенденция к уменьшению хорошо видна. Самый большой невидимый целый 48.0.0.0/8.

Вот вам хороший повод накатить с утра. Праздник же!

https://servernews.ru/1087102