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

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

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

Серия статей про Cumulus Linux на theasciiconstruct.com, от базовой настройки интерфейсов до BGP, EVPN, VXLAN и это ещё не конец. Предполагается что используемые технологии и протоколы уже знакомы как и знаком Linux, вся суть именно в том как это на Cumulus. Используется единая топология, в каждой статье к сети добавляется новый функционал и выполняется его настройка. Быстрый обзор для желающих оценить: "А как оно там?"

Менеджер конфигураций CDIST для серверов. Шаблон конфигурации формируется на Shell. Говорят так лучше, не надо учить никаких YAML, а Shell и так все знают. Это подаётся как преимущество. Кроме того это полноценный язык с циклами и условиями и вызовом любых внешних модулей. Для управления серверами, опять же, нужен только Shell и доступ через SSH.

Сами шаблоны (манифесты) помимо Shell формируются из типов (действий). Фактически, это те же скрипты, соответственно можно создавать свои, но многие стандартные действия определены. Вот такая строчка в манифесте __file /etc/cdist-configured может создать файл cdist-configured на всех обслуживаемых хостах.

На первый взгляд выглядит просто, может даже очень просто - как внутренний проект который писали-писали, он разросся, а потом пришёл Ansible и надо было что-то решать. Но по факту требований действительно мало, кроме того что надо и правда хорошо разбираться и любить именно Shell. Разработчики его точно знают, это хорошо видно в приводимых примерах. Будет ли он удобным? Кому-то точно будет.

tcpcrypt добрался до RFC8548. У нас есть IPSec для L3, есть TLS для L7. Теперь есть tcpcrypt для L4.
Отличие - всё должно работать из коробки сетевого стека, L4 уровень делает его прозрачным и для NAT. Аутентификация не встроена (только шифрование), поэтому её придётся делать отдельно. Если узлы не договариваются о шифровании, используется обычный TCP. Простым языком что это за зверь можно читать здесь. Есть ещё сайт tcpcrypt.org, но там что-то с DNS не так и сейчас не работает :(

​Во время грозы все боятся молний, что обосновано. У нас не так часто такие аварии, но как правило они масштабны. Последний раз потеряли узел который делили со своими партнёрами, оборудование которых получило удар, а мы в довесок по медному патчу.

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

История о том как устроить себе DNS amplification attack и решить проблему честно "обманув" Unbound.

Дано, периодические задачи Hadoop в облачной среде и всплески PTR запросов. Всё это начинает упираться в лимиты AWS, что приводит к повторной попытке запроса и усиливает эффект. Так как система многоуровневая, то и второй уровень DNS пытается повторить запрос из-за таймаута, что даёт в итоге 7 кратное усиление количества запросов к серверам. А всё это вместе выливается в SERVFAIL.

Инженеры это аккуратно посчитали и пришли к выводу что лучше разделить логически обработку PTR запросов для серой сети и публичной и убрать один уровень.Так как Unbound считает время для каждого правила отдельно, а для PTR серой сети ответ приходит быстрее, это не вызывает роста повторных попыток запросов, как было раньше с общим счётчиком retry timeout на все запросы. Результат - полностью устранённое усиление из-за повторных запросов.

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

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

Мы тоже живём на Unbound в качестве кеширующего сервера. У нас около 3000 запросов в секунду и 95% попадание в кеш. Это, к слову, о порядке величин для сравнения с графиками из статьи.

P.S. Иногда я пропускаю интересные сообщения даже в тех каналах которые читаю. Спасибо огромное всем читателям кто делится со мной ссылками, мне всегда интересно. И многим кто потом читает посты в этом канале, я думаю, тоже. Без вас никак.

В уже очень далёком 1999 я купил компакт диск с названием на обложке "Техническая документация" (сейчас вместе со мной всплакнут мои однокурсники). Это была сборная солянка из дампов сайтов, например OpenNET каких-то учебников, How-To, утилиты... Не было никакой оболочки, всё было отсортировано по каталогам в которых надо было ещё разобраться.

Самый ценный для меня оказался, уже не помню точное название, ForHackers. Именно оттуда я узнал про TCP/IP и другие сетевые протоколы, прочитал про устройство ОС и компьютеров, как вообще устроен молодой в то время Интернет и телефонные сети, банковские карточки. Во многом это не было какая-то специфическая информация для взлома, это было просто описание систем и решений, удачно собранных в одном месте. Что-то вроде вот этого репозитория. Знающий человек уже хакер, всё просто - информация это сила.

Russ White про BGP Monitoring Protocol, который уже хочется начать использовать. Потому что некоторые вещи, из того что там есть, добываются очень большим трудом и всё равно не получается в полном объёме. А видеть что происходит с BGP в большом разрешении очень полезно. Это стандарт с 2016 года, в софтовых роутерах уже есть реализации (как минимум базовые) или они на подходе.

RIPE NCC проводит опрос о своей работе и пожеланиях, для всех кто работает с ними и их сервисами.

Ах, да. Есть возможность выиграть iPad.

​Fast это консольный и веб клиент одноименного спидтеста от Netflix, чуть подробностей в Записках админа. Мы очень давно, правда с переменным успехом, пользуемся speedtest-cli, которым тестируем скорость по разным направлением через различных провайдеров. Не могу сказать что это как-то помогает строить нашу аналитику, всё-таки больше полезен простой пинг, получается нагляднее. Измерения скорости очень нестабильный показатель, сильно зависящий от локального таймера и нагрузки на систему. Но абоненты любят смотреть на скорость, поэтому упускать такой показатель из виду не стоит.

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

Сегодня прямо прекрасное попадание на Honest Networker: подпись, видео и настроение.

Не люблю такие сравнения. Хотя статья вроде и называется чем отличается OpenBSD и Linux, но предугадать к чему придёт автор не сложно. Сообщество разработчиков OpenBSD продолжая следовать изначальной философии делает действительно многие отличные вещи, которые приняты и на других платформах.
Но надо признать что Linux победил. За счёт конкуренции внутри сообщества, за счёт достаточной гибкости в подходах, когда видимый результат бывает важнее способа его достижения. Это известная история с чего начал Торвальдс, реализовал только нужные системные вызовы ядра для bash, пытаясь его запустить и добавляя недостающие.
Небольшие команды лучше связаны и если у них есть отличная идея, получаются очень хорошие и эффективные её реализации, лучше чем в универсальных системах, лучше обслуживаемые. У OpenBSD, наверное, есть своя ниша, но пользоваться ей как системой, увы, мне не приходилось. Желание сделать обязательно систему для десктопа, которое присутствует в сообществах многих ОС, на мой взгляд, тормозит их и отрывает силы от тех полезных вещей которые стоит развивать.

Первые две статьи про LISP в решении Cisco Software Definition Access (SDA). Рассказывается что это за зверь и чем это всё отличается от подхода в рамках обычных сетевых протоколов. Терминология и самые основы. Примеры настройки во второй части.

Кто пропустил КРОС2019 можно уже скачать презентации https://cros.nag.ru/archive - повестка обычная, за жизнь провайдеров в общеглобальном смысле. Что делать с законами и продажами и каким средствами это можно достичь. В тренде умные домофоны и дома, IoT, QoE, повышение цен. И вечная тема как договориться с ЖЭУ (ТСЖ), чтобы тебя пустили в дом.
И ещё чуть-чуть видео в плейлисте на Youtube.

Много шпаргалок по различным аспектам сетей. Всё по разделам, есть оглавление. Сама шпаргалка - одна страничка в PDF.

Хорошая white paper на тему устойчивости шифрования к квантовым компьютерам.
Итоги:
1. Используйте где возможно симметричное шифрование с максимально возможной длиной ключа. Аналогично с хэш функциями.
2. Для новых долгосрочных проектов с ассимитричным шифрованием запланировать возможность замены алгоритма на квантовоустойчивый.
3. Если вас критично, что перехваченную сегодняинформацию вскроют при появлении квантовых компьютеров необходимо применять гибридные схемы.
4. Стандарт квантово устойчивого шифрования от nist появится не раньше 2022-2024. Сейчас аторая стадия конкурса из 26 алгоритмов.

Спасибо большое за ссылку от нашего подписчика: "Что по этому поводу думает Cisco".

Утилита которая из вывода netstat сделает красивые диаграммы взаимосвязи клиентов с сервисами. В дополнение к диаграмме будет статистика сколько клиентов привязано к каждому серверу (если в исходных данных объединены несколько серверов) и самые нагруженные сервисы по числу клиентов. Написано достаточно просто, чтобы разобраться не только тем кто в Ruby силён. И конечно, это полезно не только атакующему, хотя статья именно в этом ключе.