без сжатия

ISC DHCP - всё, используйте Kea или что-то другое, можно даже остаться и использовать ISC DHCP но уже без поддержки и развития, если конечно вы не покупаете поддержку у ISC. Помимо этого всегда можно сделать форк и для критических уязвимостей, возможно, будут делать исключения. Основной причиной завершения разработки названа сложность внесения изменений и тестирования существующего кода ввиду его зрелости, я так понимаю, что целиком уже никто не понимает как оно работает. И напоследок в объявлении небольшая история ISC DHCP и его четырёх основных авторов.

Карта точек присутствия IX от TeleGeography.

Вот да, безопасность сети не только правила в ACL добавлять.

Фокусируясь на защите оконечных устройств, ПК и серверов, нельзя забывать про сетевое оборудование, связывающее части корпоративной инфраструктуры в единое целое.

Его защита складывается из 4-х основных составляющих:
📌 Предотвращение, то есть правильная настройка механизмов собственной защиты коммутатора, маршрутизатора, точки доступа и т.п., достигаемая за счет настройки аутентификации админа, контроля доступа к интерфейсам управления и т.п. Спросите у своего вендора руководства по hardening'у его продукции (например, вот инструкции моего бывшего работодателя).
📌 Обнаружение, то есть мониторинг в реальном времени всех попыток вывести оборудование из строя или нарушить его функционирование (например, подменить таблицы маршрутизации или завалить интерфейсы паразитным трафиком). При этом не стоит ограничиваться только ретроспективным анализом происходящего - пялиться с разных ракурсов на то, как "падает" сетевое устройство, конечно, можно, но с последствиями придется разгребаться.
📌 Реагирование, то есть своевременная реакция на первые признаки происходящих плохих событий. Для этого нужно было заранее настроить регистрацию нужных событий на самом устройстве (загрузка ЦПУ, рост задержек в обработке трафика, рост объема трафика на управляющие интерфейсы, рост числа попыток аутентификации и т.п.).
📌 Восстановление, то есть возврат сетевого устройства в предъатакованное состояние, для чего нужно иметь резервную копию конфига, проверенную прошивку и т.п.

Отдельно стоит упомянуть встроенную систему защиты сетевого оборудования от вредоносной активности, которая проходит через него и которая может нарушить работу всей сетевой инфраструктуры. Это и атаки на канальном уровне, связанные с STP, ARP и т.п., и DDoS, и атаки более высокого, прикладного уровня. Не всегда сетевое оборудование обладает такой защитой (хотя базовая должна быть реализована), но тогда ее надо выстраивать на подступах к нему.

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

10 лет назад я сдал свой CCNA, сдал будучи уже 5 лет в телекоме, уже давно не будучи студентом, но после интенсивных курсов в Сетевой академии Cisco. Я волновался и переживал - это был достаточно серьёзный рубеж для меня. Можете мне не верить, но я не знал про дампы, я не сидел на форумах и тематических сайтах, коллега с которым мы сдавали практически одновременно за пару дней до даты экзамена спросил меня смотрел ли я на дампы и дал мне архив с картинками. Я решил не смотреть, в итоге я сдал, а он нет. Может показаться что я против дампов, но нет, у каждого свой путь и как инструмент подготовки именно к экзамену, он работает. У меня не было 1000 из 1000, насколько я помню, даже 900 не набрал, но близко к этому. С другой стороны экзамен не показался мне сложным, часть вопросов были на экзаменах в Сетевой академии, часть были аналогичные, то есть Академии было бы достаточно чтобы сдать. Но у меня был ещё и опыт и много-много переживаний. Вместе с сертификатом через месяц после экзамена приехала ещё пластиковая карточка в формате кредитки, с моим именем, идентификатором Cisco и конечной датой годности сертификата. Больше таких мне не присылали.

Я не стал ждать когда подойдёт срок завершения, так как опыт мне понравился и дальше, с периодичностью раз, иногда и два или три раза за год, сдавал какой-то экзамен. Не за каждый давался сертификат и не каждый сертификат давали при отсутствии предыдущего. В итоге у меня были CCNP R&S и CCDP и CCNA SP и несколько архивных, вроде CCNA Voice. В этот период у нас был клуб по интересам среди моих друзей коллег, мы не занимались вместе, но вместе обсуждали, вместе сдавали, от работодателя получали за это прибавки к ЗП. А потом Cisco поменяла своё видение и, с одной стороны, это лишило меня CCDP от которого я был в восторге наравне с CCNP R&S , с другой, наградило кучей Specialist сертификатов за каждый сданный экзамен. Это меня немного расстроило и я притормозил свой забег чтобы посмотреть а что же дальше.

А дальше была пандемия и смена провайдера на энтерпрайз, не уверен, хотя подозреваю что при найме на мои сертификаты всё-таки посмотрели. Так как каждый новый экзамен был действительно новый, следующего уровня или другой ветки, чтобы соответствовать своему новому месту я решил посмотреть на Security и на новую рекламируемую ветку с программерским уклоном. Параллельно я зашёл, не сказать что глубоко, в SD-LAN и SD-WAN в Cisco варианте. В итоге, всё это мне показалось очень Cisco специфичным, таким же как Voice ветка, в которой надо было знать какие менюшки кликать в CUCM. Можно сказать что остальные ветки не менее Cisco специфичны, всё же это их сертификация, но Cisco like консоль и подходы к маршрутизации и коммутации гораздо больше промышленный стандарт, чем Cisco API или продукты безопасности Cisco. Поэтому я планировал что в этом году доделаю ветку SP, хотя начатый мной путь был обнулён, но унификация позволила сдавать меньше экзаменов до сертификата. А CE баллы которые накопились за время поиска подходящего пути перед новым годом я потратил на продление всего того что у меня было вплоть до Professional уровня, на него уже не хватило.

Сейчас я не знаю свой статус просто потому что на cisco.com меня больше не пускает, а писем от них я не получал. От Сетевой Академии получал, которая видимо так и не стала до конца Cisco, от Juniper и от Palo Alto получал, а от Cisco нет. По честному конечно, их у меня нет, хотя на credly.com ещё можно всё увидеть. Равен ли сертификат знаниям? - нет конечно. Полезно ли это было их получать? - мне полезно, путь целиком от изучения и систематизации знаний до вишенки на торте в виде сертификата. Без вишенки проходить путь сложнее, опять же если говорить про себя. Вернусь ли я к этому пути по возможности? - скорее всего, в какой-то момент задор пропал, полезность, в целом, перестала быть такой очевидной, а выгода Cisco стала более очевидной. Однако в текущих обстоятельствах, здесь это стало сложнее сделать, а значит ценность возросла, пусть пока и по старой памяти, но может быть я пинаю дохлую лошадь...

Слайды про "Кто пишет RFC?": статистика по количеству авторов и годам в разрезе компаний, стран и институтов. Названия все знакомые, хотя и объём авторов из категории "Другие" существенен, разве что явно преобладают авторы из США, но в ниспадающем тренде. Количество черновых вариантов до выхода стандарта растёт, объём переписки рос до ~2010 года после чего не меняется, а вот количество вовлечённых в обсуждения участников снижается после роста.

Набор данных по производительности Starlink и немного графиков по ним - сёрфить в вебе неотличимо от провода.

Облака - это просто аренда серверов, а арендодателей можно пересчитать по пальцам одной руки. Экономии на операционной команде нет, децентрализация убита. Есть случаи когда облака решают, но это лишь случаи. Мнение David Heinemeier Hansson.

Просканировать все порты на всех IP в Интернете сложно и долго, но можно попытаться построить модель которая предсказывает наличие открытых портов на основе зависимостей по исходным данным. Обучение займёт какое-то время, зато само сканирование будет идти очень быстро, по сравнению с прямым перебором всех возможных портов на адресе. Ссылки на исходные коды и полную статью есть в тексте. Для работы нужен доступ к Google BigQuery.

Не доверяйте никому в Интернете, даже если это ваш собственный роутер. TP-Link перехватывает DNS запросы из благих побуждений, конечно, и для этого ему даже не надо быть роутером, достаточно выступать в роли точки доступа, главное чтобы трафик проходил сквозь него. Проверил у себя в домашней сети, отвечает достаточно невинно - при запросе tplinkap.net локальным адресом устройства, но сам факт перехвата всего DNS трафика напрягает и ещё как.

Введение в настройку Firewall в Junos. На самом деле это очень понятный и логичный инструмент и при возможности практики изучаемый самостоятельно достаточно быстро, тем более если был опыт с другими вендорами. Сравнение с ACL не совсем правильно, хотя и понятно как устоявшийся синоним механизма фильтрации трафика. Но ACL в контексте Cisco это не более чем список IP, протоколов, портов, флагов с привязанным к ним признаком разрешения или запрета. Удобное обобщение уже с которым делается сопоставление во многих возможных механизмах - политиках, route-map, access-group.
Поэтому Junos firewall по сравнению с ACL это космический корабль, где можно практически всё, а не жалкие no <line number>, remark <bla bla bla> , <line number> acl rule, для того чтобы просто поправить ошибку в комментарии. Именованные правила, вставка, переименование, удаление в любом месте, временное отключение, масса возможных сравнений и действий, несколько наборов фильтров одновременно списком для одного интерфейса. И многословность тут только в плюс, совместно с иерархическим конфигом позволяет меньше ошибаться, а следовательно реже ездить поднимать доступ напрямую с консоли у нечаянно заблокированных устройств.

Сравнение DNS over UDP, TCP, TLS, HTTPS и QUIC. Без шифрования сейчас не жизнь, поэтому лучший - DNS over QUIC, за счёт более быстрой установки сессии, без этого обычный DNS по UDP побеждает. В остальном всё плюс минус одинаковое. Поэтому сравнили ещё скорость загрузки страниц различных сайтов, там уже есть варианты что DoQ побеждает и UDP за счёт количества запросов, что нивелирует начальную задержку нужную для установки сессии. Впрочем, в этих случаях и DoH неплох - при 100500 DNS запросах на одной странице, вероятно, разницы не будет совсем. В среднем же DoQ немного медленнее UDP в этом тесте, но в итоге всё зависит от сайта.

Будьте последовательны в поиске и не спешите (если это возможно), тогда результат обязательно будет. Статья про поиск и решение проблемы с медленной передачей через Интернет, где в конечном итоге проблема была в Интернет, там определяется конкретное место, но это место далеко за зоной ответственности автора. Дампы, мониторинг и понимание принципов работы протоколов - рулят.

Раз уж несколько раз на глаза попалось, да и коллеги скинули ссылку на Хабр, вспомню как мы Cisco SCE «чинили». Всё как в статье - работала, перестала. При загрузке в консоли попадаем в U-Boot, видим что с ФС проблема на SD карте. Ну и потыкав немногочисленные кнопочки которые там были я затираю кусок памяти с этим самым U-Boot. Из того что осталось команды копирования и записи в память и диагностические тесты.
Благо в нашем дружном коллективе были люди которые лучше меня понимают в embedded, спасшие ситуацию написав код который копировал кусок памяти побайтово из рабочей железки, тут нам тоже повезло что она была, сохранив его в файл. И потом из этого файла также побайтово используя встроенный набор команд из того интерфейса что был доступен записывая кусок памяти в нерабочую. Про скорость копирования я говорить не буду. После того как мой косяк был поправлен, дальше перенесли образ флешки с рабочей на нерабочую, новую флешку мы купили. Но тут уже было сильно проще, на ней Linux и все можно было делать с обычных компов. А уже потом выдохнули и расслабились. Нам очень сильно повезло, тыкаться в слепую методом обезьянки и решить проблему. Впоследствии наши образцы помогли ещё некоторому количеству пострадавших от таких же проблем с флешками.

А теперь самое главное к чему я все это, у нас практически никогда не было никакой внятной поддержки даже для железок цену которых страшно называть. И такая ситуация не считалась критичной и мы далеко не одни так считали. То что могли чинили самостоятельно, ни для кого никогда не было никаких запретов вскрыть и перепаять блоки питания или память поменять на побольше. То что сейчас в такой ситуации оказались все - печально, я начал привыкать к поддержке 24/7 по любой мелочи. Но это не смертельно и для многих совершенно обычно. А уровень локальной поддержки подтянется, уровень инженеров которые смогут на месте чинить всё не обращаясь в ТП тоже.

Эмулятор x86 из браузера с WebAssembly с несколькими готовыми образами операционок, свои тоже можно использовать. Исходники доступны.
Напомню ещё про PCjs, там набор железа и софта побольше будет.

Если вы владели и использовали каким-то ресурсом в Интернет: доменным именем, IP адресом - то можете быть уверенным что освободив его, запросы на него будут приходить ещё очень и очень долго. Как, например, у Dataplane, новость "DNS Query Anomalies". Они конечно написали куда надо и даже заверили что никак этой ситуацией не воспользовались, но на такое поведение полагаться нельзя. Напротив, стоит предполагать что каждый утраченный вами ресурс будет использован, как минимум для сбора чувствительной для вас информации. Не теряйте свои ресурсы, а освободившиеся попридержите и помониторьте что на них прилетает.

И Radius тоже через TLS, черновик предложения стандарта протокола уже реализованного автором во FreeRADIUS.