Ограничивайте доступ к консоли контролируемых вами устройств настолько насколько можете, пусть даже это будет не очень удобно. Автор сосредоточился на WEB интерфейсах и WEB API, с конкретными примерами CVE, как более сложных системах которые сами по себе могут иметь уязвимости. Но в целом дело конечно не в этом. В текстовой консоли тоже можно наворотить дел если получишь к ней доступ.

Список лучших конференций для сетевиков из которого я узнал про ONUG, AWS re:Invent и WLPC (почти случайный отзыв о мероприятии). Наши Yandex.NextHop и Пиринговый форум уже совсем скоро в очном формате после долгого перерыва, хоть и не попали в список 7 лучших, достойны посещения. Программы представлены, регистрация открыта.

Russ White в 7 небольших заметках (1, 2, 3, 4, 5, 6, 7) растянутых на полгода, которые можно было объединить в одну, рассказывает про основы приватности с точки зрения сети - вас могут вычислить по IP. Поэтому сетевым инженерам стоит относиться к IP адресу и к любой собираемой технической информации как к персональным данным клиента/абонента, утечка которых не сильно отличается от утечки паспортных данных и ничем хорошим не кончится. Вас взломают, это дело времени, готовьтесь к этому.
А вот с точки зрения нашего государства у вас нет конфиденциальности в Интернете, сессии с вашим IP регистрируются и хранятся, а с приходом закона Яровой ещё и куча метаданных сверху. Интернет по паспорту уже давно с нами.

Как работает Wine - попытка объяснить это просто, но куски кода, элементарные, на ассемблере и Си увидеть придётся. На самом деле, то что вообще у нас есть Wine при всей сложности современных ОС и Windows особенно, можно только поражаться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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