Одной проблемой меньше (нет конечно), но супермногоуровневая архитектура сетей похоже убила сетевую безопасность, как минимум понятие периметра между внутренней безопасной и внешней частью сети. Защищайте себя сами в том месте в котором ещё это можно сделать, на конечном устройстве, мнение Greg Ferro.

Если загрузить BGP Full view в свой Linux десктоп на GNOME, то он будет притормаживать. Дело не в том зачем на десктопе в графическом окружении миллион маршрутов, а дело в том что использовался обычный массив вместо хеша, но это уже поправили.

Geoff Huston представил свой ежегодный анализ состояния BGP, из двух частей - количественный и динамический - много и подробно, с картинками. IPv6 растёт бурно, IPv4 более стабильно и при этом общее количество адресов уменьшается, а количество префиксов растёт. Никаких статистических аномалий нету, 2020 должны прожить.

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

Привожу как есть, без купюр:
Hurricane Electric BGP Toolkit, CAIDA, RIPEStat, PeeringDB, RADAR.QRATOR, DNSLytics.com, BGPview.io, ipcalc.com, 2ip.wiki, aWebAnalysis.com, ipinfo.io, IPIP.net, dp-ip.com, ru.map-ix.net, IPv4info.ru

🔧 Тут ребята из BunnyCDN сделали странное (мы же все тут любим странное, да?) - проверили скорость резольвинга доменов верхнего уровня. Самыми быстрыми тут оказались зоны .biz, .buzz и .club, а самыми медленными из проверяемых .ru, .ly и .top. Сравнительная таблица и подробности теста по ссылке: https://bunnycdn.com/blog/is-your-fancy-new-domain-hurting-your-performance-gtld-benchmark/

#напочитать #dns

Если кто уже может в Segment Routing - ExaBGP в этом году подключились к процессу.

Про богоны есть отличное определение на вики: Bogon filtering is the practice of filtering bogons. Если кто не знает, это про траффик с немаршрутизируемых адресов.
А пост хороший, да.
https://theinternetprotocolblog.wordpress.com/2020/01/15/some-notes-on-ipv6-bogon-filtering/

Всё, что вы хотели знать о MAC адресе - действительно всё. Помимо структуры адреса очень много уделено статистике и распределению адресов, их случайности. Смело можно положить себе в закладки.

Ограничивать или нет скорость в гостевой сети вашего Wi-Fi? Что будет если все гости станут смотреть Netflix или скачивать файлы? Сломает ли это вашу сеть для критически важных функций?

Автор используя научный подход, выдвигает гипотезы, проводит тесты, анализирует и делает выводы. В ситуации потокового видео, которое скачивается частями, большую часть времени полоса остаётся свободной и сетевые устройства простаивают. Ограничивая скорость скачивания, тем самым мы увеличиваем время скачивания, а также время активного взаимодействия и работы устройств. Значительные изменения заметны после того как скорость зарезана меньше 10Мбит/c, тогда исчезают паузы. Для Wi-Fi, наверное, это особенно важно так как постоянно утилизируется эфир.

Таким образом если снять ограничения, доверившись механизмам управления трафиком между конечным клиентом и сервисом, то результат будет лучше. В тестах ни разу не была достигнута скорость больше 120Мбит/с при гигабитной полосе.

Но есть нюанс, если клиенты начнут своё взаимодействие одновременно, то проблемы будут точно. Вопрос в вероятности этого, например, для аэропорта или для учебного класса, где все работают по команде от учителя. То есть, прежде чем делать надо обязательно подумать и ограничивать или не ограничивать, исходя не из домыслов и статей в Интернете, а на основе опытов и расчётов. Как раз на что многим сетевым администраторам не достаёт времени или силы воли.
Вспомнили и про формулу Эрланга, потому что наука остаётся наукой даже если теперь вместо телефонных каналов Wi-Fi.

Отказоустойчивость межсетевого экрана отдельная песня. Потому что помимо симметричности трафика, для поднятия резерва надо добиться синхронизации состояний. У *BSD есть pfsync для этого и свежая статья как его приготовить. Не свежая есть на xakep.ru. Остальным остаётся полагаться только на своих вендоров и что они придумали с failover режимами.

​Ажиотаж спал и если вам действительно нужны IPv4, то судя по графикам очереди, получить статус LIR и свои /24 можно совершенно свободно.

Не все знают, но у Яндекса уже давно есть утилитка gixy для статического анализа мисконфигов в Nginx, позволяющая избежать множества проблем при конфигурировании любимого веб-сервера. И ребята ее постоянно обновляют вместе с документацией.

Так что при копировании очередных сниппетов с гитхаба, прогоните их хотя бы с помощью gixy :)

https://github.com/yandex/gixy

Наши подписчики подсказывают, за что им огромное спасибо, что у Nginx и так всё есть для облаков - Nginx Amplify. На кнопке регистрации написано for free, я нажимать не стал за ненадобностью, но если кто упустил этот момент - добро пожаловать, даже если окажется что это стоит денег.

Сети они такие, ага: LOOK, THE LATENCY FALLS EVERY TIME YOU CLAP YOUR HANDS AND SAY YOU BELIEVE. Но всем известно, что это из-за DNS.

Интересный документ с просторов Всемирного Экономического Форума, или вот сразу в PDF. Четыре принципа:

1. Protect consumers by default from widespread cyberattacks and act collectively with peers to identify and respond to known threats
2. Take action to raise awareness and understanding of threats and support consumers in protecting themselves and their networks
3. Work more closely with manufacturers and vendors of hardware, software and infrastructure to increase minimum levels
of security
4. Take action to shore up the security of routing and signalling to reinforce effective defence against attacks

Первые два пункта - думай за абонентов, третий - думай за производителя, и четвёртый - думай сам, MANRS.

Сегодня открываю отчёт Qrator Radar, а там новый открытый порт TCP 179 (BGP) у абонента. Осознаёт ли абонент опасность? Возможно там и вовсе не BGP или какое-то тестовое окружение развёрнуто, зачем вообще в общем случае абоненту на домашнем подключении BGP? И что c этим делать дальше? Не вмешиваться, следуя принципу мы дали канал, то что в канале нас не интересует? Или, как нам говорит документ выше, вмешаться и разобраться? Или превентивно заблокировать для всех?

Ладно это BGP, первый раз такое за много лет что у кого-то дома оказался BGP, с этим можно разобраться досконально. Но DNS или NTP торчит наружу очень часто у сотен абонентов если не у тысяч, это как раз те самые настройки по умолчанию домашних роутеров. Разобравшись с каждым появятся ещё тысячи. Остаётся только всех под  одну гребёнку причёсывать и блокировать. Хорошо ещё SMTP свою роль потерял, все на веб перелезли.

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

Linux впереди планеты всей по части MPTCP и добавили в ядро поддержку первой версии, когда все остальные ещё на нулевой. Год назад с проникновением было не очень, но вроде всё движется.

Диаграмма сети с Cisco Live Barcelona 2020, пример того как делает Cisco для Cisco.
А вот общая панель мониторинга. Не знаю что это, но похоже на Network Weathermap. На мой вкус не очень, чисто визуально. Лучше смотрится когда используется символические изображения устройств, а не фотографии, на вкус и цвет как говорится.

Результаты опроса почти 300 человек об автоматизации их сетей, для некоторых вопросов есть сравнение с 2016 годом. Затронуты совершенно разные аспекты и всё выглядит вполне неплохо. В консоль, однако, оставили себе возможность заходить подавляющее большинство респондентов в дополнение к автоматизированным способам. На GitHub есть сырые данные.

Как ломаются сетевые устройства на примере Mikrotik и CVE-2018-7445. Детально про процесс от поиска возможности до реализации эксплоита. Много про программный реверс-инжиниринг и разработку на низком уровне, но есть и про SMB и работу с Wireshark. Далеко от использования и практики сетей, но близко к самым основам. А ещё можно сравнить с тем как ломаются Cisco и оценить что сложнее, искать уязвимости, исправлять их, или сети эксплуатировать.