Подкаст про WPA3 в основном в сравнении с WPA2 и вторая часть WPA3 Enterprise. Для тех кто неплохо погрузился в WiFi и внезапно и удивительно пропустил всё про WPA3. Надо понимать терминологию и ориентироваться в технологии в принципе, тогда можно увидеть и дампы Wireshark с отличиями в нужных местах. Я почти всё загуглил и понял что проспал момент когда WiFi стал работать на 6ГГц. А ещё наличие поддержки совместимости с прошлыми версиями нивелирует все улучшения, поэтому если включаете WPA3 включайте WPA3 only.

Я хочу застать рейсы если и не Москва - Кассиопея, то как минимум еженедельные Москва - Луна. Даже если не в этот раз, то обязательно в следующий. Маск, тоже Твиттером занялся и про Марс говорить перестал. Не надо останавливаться никому, не останавливайтесь пожалуйста.

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

Всем инженерам и ученым от космоса во всех странах удачи, Роскосмосу не опускать руки ни в коем случае, и ставить такие миссии на поток, это была лишь первая в России, первая всегда с шишками.

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

На недавно прошедшей Black Hat обратили внимание на BGP. Количество CVE последние годы с 2017 выросло, BGP везде, BGP старый, BGP не имеет встроенной безопасности, используемые реализации порой одного возраста с протоколом. Написанным BGP fuzzer, нашли ещё несколько DoS. Советуют не забывать обновляться, и это помимо всего остального о чём говорят в MANRS, RFC7454 и везде.

Немного архитектурных советов по OSPF как добиваться лучшей сходимости без подкрутки таймеров, с объяснениями.

Карьера разработчика встраиваемых систем, если надоела текущая работа или если вы уже там сравнить со своими знаниями. Есть раздел про сети с ссылками на Youtube в основном, но уж очень с базовыми уровнем.

Немного практики Wireshark на примере отладки Zabbix, можно было бы сразу в настройки Zabbix посмотреть, но так не интересно же.

Внутренности Linux при использовании bind() для неназначенного на интерфейсе адреса. Исходники ядра присутствуют в достаточном количестве, хотя начало статьи этого никак не предвещало. И IPv6, как главная причина разобраться почему сделано не совсем так как в IPv4. И даже ответ есть - "просто так получилось".

Ну что ж, инструкция как отключать IPv4 с помощью настройки DHCP опции 108 (RFC 8925) всё ещё объёмная и с большим количеством объяснений, историческими вставками и ссылкой на подкаст. Ждём когда появятся - "Нет времени объяснять, выключай IPv4".

Low Latency, Low Loss, and Scalable Throughput (L4S) RFC 9330 - наше счастливое будущее для всех, но это не точно. Описание подхода к уменьшению задержек до рамок 1-2мс в очереди и до 20-50мс из конца в конец в Интернете.

Основная предпосылка заключается в том что c очередями самими по себе всё в порядке, а всё дело в механизме определения перегрузок на стороне передатчика. Для этого нужна надёжная и объективная обратная связь, роль которой отдают старому доброму ECN, который обновили для этих целей до RFC 9331. Сеть при этом должна просто не мешать, всё работает на стороне хостов, но для этого надо выделить трафик работающий по L4S в отдельную короткую очередь, да и не забыть про тот трафик который не относится к L4S - RFC 9332. Сами протоколы очередей и контроля перегрузок существуют, их надо просто включить на хостах.

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

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

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

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

Порадовал только BIND, где DNSSEC включается одной строчкой конфигурации, всё остальное делается автоматически в последних версиях, настолько насколько возможно. Технически возможно всё, но для этого должна быть поддержка у вашего регистратора имен, поэтому что-то придётся понажимать руками периодически во время смены ключа подписи зоны. В любом случае я для себя этот момент закрыл в плане понимания глубины кроличьей норы точно. Я хотел привести какой-то всеобъемлющий график проникновения DNSSEC, но сходу не наткнулся на такой. Вот тут https://www.statdns.com для зоны COM выглядит всё печально, 6865629 подписанных из 159017162 всего - это 4%. С точки зрения проверки по DNSSEC всё выглядит немногим лучше, это тоже кстати одной строчкой конфигурации включается. Больше графиков вместе собирает Internet Society.

DNS, наверное, самый перехватываемый "легально" протокол и одновременно от него зависит почти всё в Интернете, а DNSSEC не нужен, как-то так.

Как-то приходилось мне копировать IOS через XMODEM, удачно но долго. Да и с D-Link тоже приходилось не раз. Через TFTP было бы быстрее. Но лучше не оставляйте флешку без нужного IOS.

У OSPF, iBGP и eBGP меняем AD, смотрим на результаты. Рассмотрено много вариантов, но не все, как минимум не понятно зачем у iBGP отдельная AD, когда всегда выигрывает eBGP. Это должно быть видно в случае когда есть IGP и iBGP маршрут без eBGP, тогда с оригинальной AD должен победить IGP. У автора такого варианта нет, IGP побеждает только eBGP с увеличенной AD.
В мире Juniper ситуация сложнее, как минимум там градаций гораздо больше.

Политики BGP для BIRD2, детальный, ооочень детальный разбор. Есть про всё, почти (про роли нет) - как фильтровать, очень много про то как фильтровать, как работать с пирами, апстримами и клиентами, IX, RPKI, комьюнити, препенды, приоритеты. И всё это с объяснением, мотивацией и ссылками на все ресурсы.
Это результат длинного пути, к этому приходишь самостоятельно рано или поздно, натыкаясь на разные косяки. Можно всё внимательно прочитать, принять к сведению и взять только то что считаете необходимым.

Сегодя и вчера все цитируют Ben Cox и его статью про проблемы с реализациями обработки атрибутов в BGP, да и вообще про подходы к обработке ошибок в BGP, когда сессия просто падает и фильтры при этом не очень помогают. Но честно, мы же про это знали, ведь такое случалось не раз и не два, и много-много ещё раз. В один год всё падало так часто, что я даже шестнадцатиричные дампы с листа читал.
Страшно на самом деле немного другое, что Ben Cox подошёл к этому прицельно со своим фаззером, в отличие от того что было представлено на Black Hat и бил знаючи и умеючи по больному месту, вскрыв проблемы в очень многих реализациях. И когда кто-то захочет сломать Интернет по-настоящему, у него это получится.
Если можете включить игнорирование ошибок в BGP, как говорится в статье - включите, но может быть от этого будет хуже, про такое в научных работах пишут: "Вопрос требует дальнейшего исследования". Остальным - удачи и обновлять свои BGP спикеры на исправленные, если можете.

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

tcpdump в примерах и задачах выбора только нужного из всего.

Горячие темы в сетях сейчас, которые, на мой взгляд, совсем не такие горячие как их автор описывает: ИИ в автоматизации, частный 5G, открытые сети, zero-trust.
С первым всё понятно, к автоматизации, к разговорам о которой все уже попривыкли, добавили ChatGPT, что оживило тему, но имхо, все уже успокоились. 5G тоже вроде как подостыл, хотя в новом номере Internet Protocol journal большая статья введение в технологию. Кому надо тому надо, но это точно не замена Wi-Fi. Помните, кстати, WiMAX?
И открытые сети далеко не новая история, такая не новая, что уже обыденность, такая же обыденность как zero-trust. Выбираем решение из многих, в конечном итоге вопрос перекладывания ответственности, хотим мы все риски забрать на себя или всё таки часть из низ спросить с вендора. При этом всё другое, вроде закрытости железа или ненулевое доверие облачному поставщику не исключается.

Какие шифры использовать в SSH для Cisco - пример с готовым конфигом. Кто давно не заглядывал, сейчас в моде эллиптические кривые, и AES c GCM, и битов побольше.
Если рассматривать в общем, то есть RFC9212, при условии что вы доверяете NSA (АНБ), некоторые сканеры безопасности ssh, например, не доверяют.
В любом случае, сначала проверьте на столе, потому что не всё может полететь из того что вы себе накрутите.

Я не думаю что вы не знаете кто такие linkmeup и что вот эти ребята устраивают очередной Linkmeetup. Смотрим на программу, покупаем билеты и отправляемся в Москву 10 октября. Обещают много всего, и в целом тем кто затащил полноценное офлайн мероприятие в пандемийном 2021, я думаю можно верить. Главное, не конкурсы и пиво, хотя оно тоже будет, главное люди, среди которых я тоже планирую оказаться.
Организаторам удачи и терпения и чтобы всё получилось так как задумали.

Когда договориться всем о безопасности BGP не получается, то надо договориться нескольким, создав острова безопаснсти и это увеличит безопасность, в том числе, остальных. Технически ничего нового, используются все известные практики описаные MANRS. Внутри защищаемой зоны вводится новое well-known комьюнити VERIFIED, на которое надо соответствующим образом реагировать. Правильность реакции оценивается техническим аудитом, для чего надо сливать свои маршруты на какой-то общий для зоны коллектор.
К сожалению я не верю что даже двое смогут договориться, не говоря уже о группе разных операторов и компаний, да ещё и качество этого договора в прямую зависит от внешнего аудита, а не встроено внутрь процесса. Ничто не мешает администраторам автономных систем продолжать ошибаться с той же частотой и периодичностью находясь внутри зоны так же, как они ошибаются сейчас. При этом Интернет как-то работает, во многом, на доверии и с очень свободными нравами, но может именно поэтому и работает.