Патчкорд

Job Shijders напоминает нам всем про ASPA, реализуя подпись маршрутов для своей AS. Поэтому, раз все свои префиксы мы уже подписали (далеко не все), пора переходить к подписи AS_PATH. Это всё ещё draft и публичных инструментов для реализации этого механизма нет, в комментариях в твиттере есть небольшое обсуждение о сроках и перспективах.

Мне кажется что в этом году как-то рано стартанули готовиться к Новому году - со всех сторон уже ёлки с котами, advent календари (про это первый раз услышал) и гирлянды. Поэтому я тоже не стал тянуть и запилил новогоднюю ёлочку, без IPv6, но зато из консоли. Нужна Cisco с доступом в Интернет, я думаю Cisco-like консоли тоже подойдут, возможно Looking glass с Cisco, иногда там можно подставить свои команды. Критично 70 символов в строке.

Обрабатываются только первые 1120 Echo requests начиная с seq 0 и размером IP пакета, вместе со всеми заголовками, в 36 байт, это 8 необязательных байт данных ICMP. Время ожидания ответа ставим в 1 секунду, но даже так придётся подождать. Сначала я хотел сделать по программерски, даже освежил что-то из Си, но в итоге сделал по админски, самым простым способом, из-за чего цветов всего три: Timed Out, Success, Unreachable.

Теперь вы знаете откуда забирать свои сертификаты и лицензии, да и вопрос про название заиграл другими красками. Фото моего товарища уже оттуда.

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

От теории к практике - десятилетия научных и инженерных исследований, сведённых к нескольким несложным движениям.

Поиск проблемы с медленной загрузкой. Понять что это MTU и починить PMTUD, понять что это не помогло и починить снова, а потом ещё и причину найти. Взаимовыручка и профессиональная солидарность также присутствует, как и баги десятилетней давности. Очередной раз пройтись по граблям MTU - бесценно.

Краткая история оптики от Geoff Huston с самого начала, через проблемы и технологии их решения.

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

На самом деле тут даже не доверие к техническим средствам, а доверие между людьми. Поэтому цепочка для пользователя выглядит не как подписанный сертификат, а как: "Я доверяю Chrome, а чему уж доверяет Chrome это его дело". Но скорее вот так: "Я доверяю Васе Пупкину, на самом деле мне просто нравится что он пишет, который на канале в Telegram написал что использует Lynx и поэтому я тоже его использую, а уж чему доверяет Lynx это его дело". Обязательно есть кто-то, кто вручную правит доверенные центры сертификации в системе и даже знает процедуры их аудита, но таких людей не много, правда же? Сообщество (с большой буквы) за всем следит, но Сообщество это и вы в том числе и Вася Пупкин из Telegram и команда аудиторов из больших и популярных бразуеров, а все вместе просто люди, которые склонны верить в теории заговоров.

Cisco ClamAV, наконец-то, дозрел до версии 1, но с термином "свободный" надо что-то сделать :). В своё время, в списке рассылки для админов поддерживающих Centos репозитории меня удивило что репозитории в Иране не добавляют в общий лист, без каких-то других ущемлений - скачивай, обновляйся, держи локально, но иметь общедоступные для всех серверы в Иране нельзя, ибо юрисдикция США.
А так, я как-то раньше даже пользовался в связке с hMailServer для Windows, за неимением альтернатив.

Не все traceroute одинаковы, но мы ведь это и так знали. В iputils, так смутивший автора, сейчас одинаковые по поведению tracepath -6 и tracepath6, к которым можно добавлять опцию -p, чтобы конкретизировать порт на который отправится первый пакет и который будет увеличиваться на один с каждым новым пакетом. -p 33434 - сделает его похожим на классический traceroute, также это решит возможные проблемы с файрволлами, которые тихо фильтруют UDP порты за рамками возможных значений классического traceroute, поэтому эту опцию лучше использовать.
Для привычного traceroute, в моём CentOS Stream отдельный пакет, не стоящий по умолчанию, и в нём поведение traceroute -6 и traceroute6 тоже одинаково. Если хотите определённости - обновляйтесь и не смешивайте одинаковые утилиты из разных источников.

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

Компания Titania провела опрос 160 американских организаций о том как они работают с таким риском кибербезопасности и получили следующие результаты:
🔶 На снижение риска ошибок конфигурирования сети закладывается примерно 3,4% ИТ-бюджета (у нас поменьше, наверное). При этом, возможные убытки в случае наступления риска оцениваются в 9% дохода организации.
🔶 Больше половины опрошенных организаций проводят проверку конфигураций сетевых устройств не чаще раза в год. При этом 1% организаций делают это раз в неделю.
🔶 96% организаций проверяют настройки только межсетевых экранов, забывая про коммутаторы и маршрутизаторы.
🔶 В среднем организации обнаруживают 59 ошибок в конфигурациях в год, 5% из которых являются критическими (грубо говоря, прямой доступ во внутреннюю сеть).
🔶 Устранение ошибок в настройках сетевых устройств занимает в среднем до двух дней.

Про только файрволлы могу подтвердить, собственно, как ни странно, это наверно самый из понятных для условного ибшника механизмов - доступ открыть/закрыть и для чего. И больше всего раздражающий сетевика, кстати. Могу предположить, что если в организации и есть процесс проверки конфигурации сетевых устройств, то он базируется на каких-то из требований сертификации, тех же ISO 27000 или PCI DSS, где много про доступы и ограничения, отсюда и файрволлы.

А как бы вы убивали Интернет? Вот один из способов, комментарий тоже прочитайте. И я бы не рассматривал это с точки зрения только IPv6, где проблему можно сделать потому что каждый обладает очень большим адресным пространством. В IPv4 - массовый и легитимный анонс всего своего адресного пространства в префиксах по /24 может привести даже к более плачевным результатам, потому что размер BGP таблицы маршрутизации уже очень большой и лишние 100К могут сделать дело намного эффективнее, чем лишние 500К в IPv6. Сейчас префиксов /24 в IPv4 таблице чуть меньше 60%, а /48 в IPv6 чуть больше 45% так что есть что деагрегировать. Смотрим за статистикой @FullViewBGPbot или @bgp_table_bot и не забываем поставить лимиты и триггеры там где это необходимо.

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

Интересное исследование степени централизации DNS: https://www.potaroo.net/ispcol/2022-11/dns-ctl.html

TL/DR: рекурсивный DNS в целом не централизован, но открытые рекурсивные DNS высоко централизованы и Google имеет больше двух третей в этом сегменте (на картинке - централизация публичных рекурсивных DNS по экономикам). Сервис авторитетных DNS серверов умеренно централизован, четыре крупнейших провайдера (Amazon, Google, Cloudflare и Akamai) контролируют около 57.3% доли.

Подарок доставлен и теперь я тоже в деле. Это не с Kickstarter, там я поддерживал лишь морально. Пока не включал стараясь максимально растянуть удовольствие. Надеюсь, что смогу поковырять поглубже готового функционала и что мой SOC отнесётся с пониманием ;). А ещё я очень рад что у @zhovner_hub и всей команды всё получилось.

Хороший обыгрыш известной шутки - это наша страшная тайна, static route ещё и NAT. Не знаю как у вас с твиттером, поэтому картинкой, стащил отсюда.