​Ещё один каталог с паролям по умолчанию. Отсортировано по компаниям.

Проникновение MPTCP в мире. В табличке видно у кого больше всего людей и кто знает что проблемы будут обязательно, поэтому готовится заранее и с большим отрывом. Хотя это может быть говорит, всего лишь, об использовании одного популярного ПО.
Все ссылки в статье по делу, там много интересного. Про суть MPTCP, наверное, лучше всего почитать по этой. Множественная адресация, что норма по сегодняшним дням, сразу привела к проблеме выбора адреса и замыкания на нём. По сути TCP не ограничивает никого одним маршрутом, но ограничивает одним адресом, вот это и пытаются решить. QUIC, кстати, это тоже пытается решать введением общего идентификатора, не зависящего от IP.
В грядущем 5G и всяких OneWeb должна быть полезная штука, конечно при наличии сетей поддержки, можно таких гибридов понастроить.

Надеюсь здесь все понятно без перевода

Когда-то софт был отделён от железа, но эти времена давно прошли. Страшилка про то что переустановкой ОС теперь не отделаешься и сервер, лёгким взмахом руки, любой может превратить в кирпич. Закалённые в боях сразу вспомнят про CIH и скажут что нас не напугать, но на самом деле ужасно неприятная штука. Ждём когда всё совсем сольётся и будет просто кнопка восстановления (сброса к базе) на боку любого устройства, включая и серверы.

Молитва сетевика.

К другим новостям: уже почти сутки продолжается расколбас в сети CenturyLink. Это крупный американский провайдер с капитализацией 16 инстаграммов`^w` миллиардов долларов. В результате проблем в сети недоступными оказались службы 911 в нескольких регионах США.

Наши источники сообщают, что файрфайтит только американская команда, follow-the-sun NOC не работает (сеть-то тормозит), люди по 20 часов в офисе. Некоторые едут на удалённые площадки, что-то на месте пытаются делать. Возможно, виной всему — один роутер в Техасе.

Вот тут твиттер CenturyLink, если кому-то интересно, как их там поливают новоявленные сетевые специалисты: https://twitter.com/CenturyLink

​Новогодний подарок в мою библиотеку. Жаль что такого у меня не было когда я начинал. Стал читать предисловие к "UNIX" по пути домой, не смог остановиться и дочитал добрую треть книги за полночи. Спасибо за подарок, просто золото. Почти неустаревающая классика.

T8 молодцы не только потому что делают уникальные вещи, но и потому что не забывают про просвещение. Всё что вы хотели узнать о DWDM (основы), но боялись спросить. Немного суховато написано, но чего ещё ждать от очень наукоёмкой компании. Прямая ссылка на буклет. У них ещё и курсы есть, тоже всё академически. Несколько дней, на выходе сертификат - коллеги были и остались довольны.

А ещё вчера в телеграме появился чатик про Эльбрусы, те самые, и главное что за сутки не скатился во флуд и флейм. Автор непосредственно практикующий разработчик отсюда. Так что всё из первых рук, почти. А совсем из первых можно в этом канале искать @elbrusworld.

Ещё позитива, думается следующий год таки будет массовое внедрение, как минимум заметный рост проникновения RPKI на стороне клиента и со стороны держателей ресурсов. VyOS скоро сделает (FRR внутри), CloudFlare почти сделал. Горячая тема на всех конференциях и многих новостей, так что следующий год возможно станет переломным. Если вы ещё не подписали свои ресурсы, подпишите, займёт не больше 5 минут в личном кабинете на ripe.net, только надо залогиниться.

​Если не видели, как я - виртуальные машины с Windows 7,8,10 на выбор для VirtualBox, Vagrant, VMware, Parallels, HyperV. Официальней некуда, без регистрации и СМС. Образы около 4,5 ГБайт запакованные, не очень требовательные - виртуальных 1024 RAM и 128 VideoRAM. Формально они для тестов браузера от IE8 до Edge, но и что-то другое пробовать никто не запрещает вроде бы (EULA я не читал), даже советуют снэпшот сделать чтобы можно было подольше попользоваться.

Интернет растёт и конца этому не видно, что не может не радовать. Возможно чуть замедлился рост IPv4 и ускорился IPv6, но только если чуть.

Всех Нас, с наступившим 2019 годом!

Так было в прошлом году. А смотреть за статистикой роста каждый день можно в моём боте @bgp_table_bot который копирует из ленты твиттера.

Вчера везде отметилась новость про natasha - быстрый stateless NAT на стероидах DPDK. Никаких портов, времени жизни и прочего - из одного заданного IP в другой заданный и только. Аналог этого у Juniper, например - inline NAT.

Почему это горячая тема и почему на это стоит обратить внимание, потому что хороших реализаций NAT очень мало, причём всё это усложняется тем что "хороший" для каждого случая имеет своё значение. За всю мою практику я попробовал много чего, в общем аппаратные firewall или балансировщики лучше умеют NAT (больше крутилок и режимов) чем более или менее чистые маршрутизаторы. Если воспринимать NAT как только механизм упаковки частных IP в публичные, то это почти везде работает плохо. Что-то обязательно ломается и диапазон этого весьма широк от непосредственно транслируемых протоколов/потоков до самой железки/системы которой в какой-то момент перестаёт хватать нужных ресурсов. И да, мы до сих пор не можем найти устраивающий нас NAT, такой какой нам нужен и IPv6 тут действительно на коне. Это если говорить про провайдинг.

Но NAT хорошо подходит в качестве уровня абстракции адресного пространства, когда надо скрыть внутреннюю структуру, сделать её гибкой, а наруже оставить только то с чем надо взаимодействовать, что мы точно знаем будет редко меняться. Наверное, в облачных датацентрах это находит своё применение (авторство как бы намекает), я не оттуда поэтому не могу сказать точно. Ещё пример, объединение двух разных сетей, когда на их границе выполняется двойное преобразование что исключает пересечение адресных пространств. Никакой экономии адресов при этом конечно не возникает - задача другая и цель.

Вот как раз про такие задачи и natasha. Никакой динамики, никаких много адресов в один, никакой памяти - есть правила какой IP в какой преобразовать, это делается, как обещают, на очень большой скорости. Помимо этого получился ещё PBR, даже больше чем NAT, так как можно задать какой пакет в какой интерфейс направить принудительно да ещё и с нужным маком, классическая маршрутизация от источника. Документация сильно страдает от недостаточной полноты, но исходники (как минимум описанная грамматика файла конфигурации) спасают.

У меня сейчас таких задач нет, но своё место должно найти. GPLv3 подразумевает что это скорее будущая часть какого-то большего продукта, чем самостоятельная утилита. А Наташа, просто, хорошее русское имя, а теперь ещё одна из реализаций NAT.

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

Но суть всё же в том, что взяв большой архив вирусов и проанализировав его, для чего, в том числе был написан DOS x86 эмулятор, была предпринята попытка отыскать результаты работы вируса в виде "полезной нагрузки". Несколько примеров есть в статье, но целиком можно увидеть здесь https://dosv.benjojo.co.uk. Для каждого вируса есть подробная страница (Link), там результаты анализа и GIF с тем что происходит на экране. Мне отыскать что-то красивое не очень удалось, но наверное там оно есть - хороший способ убить время на новогодних каникулах. Всё есть на GitHub.

Лучший способ закрепить теорию это практика. А практика сетей и протоколов, во многом, упирается в реализацию этих протоколов. Чудный пример реализации DHCP сервера на bash. Без заморочек, используются совершенно стандартные вещи вроде nc и od. Даже с теми ограничениями что в него заложены позволяет работать со стандартными клиентами DHCP.

DHCP это один из наиболее (как мне кажется) часто самостоятельно реализуемых серверов, может наравне с RADIUS. Многие биллинги идут по такому пути. Возможно в силу своей простоты, возможно в силу желания делать странные вещи. Даже если низкоуровневая часть: кодировка и формирование правильных пакетов лежит на каком-то известном инструментарии - то логика, часто сложная работающая с сырыми данными пишется самостоятельно. У нас в сети как раз такой путь. А ещё есть повод передать привет бывшему коллеге который реализовал TFTP сервер на Python, которым мы успешно до сих пор пользуемся.

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

Когда у тебя всего одна линия связи по земле, а остальное спутник и она рвётся. Сходите по ссылкам там графики в живую и немного подробностей аварии, время восстановления обещали 72 часа - она ещё продолжается.
Магистраль построили не так давно, до этого такие пинги были нормой.

PuTTY 20 лет.

Сканер IPv6 сетей спрашивали? Вот он - ipv666. Больше подробностей в блоге, читать надо с середины, потому что в начале базовое введение в IPv6.

Это не простой сканер, адресов слишком много чтобы их перебирать подряд. Но имея в основе вот такие работы можно получать результаты. Математическая статистика и анализ данных в помощь. Сначала, конечно, надо собрать стартовый набор на чём можно строить предположения, достигается всякими приманками-ловушками сайтами с котиками, открытыми данными других проектов и не только. Здесь цель выбрать как можно больше реальных адресов в атакуемом пространстве. А дальше инструментарий по сути уже готов и находится в открытом доступе.

Сканер использует готовую модель всё время уточняя её на основе вновь найденных активных адресов, используя техники отсечения заведомо неиспользуемых диапазонов.
Результат который приводится в блоге 5000 активных хостов, за 20 минут на диапазоне провайдера /32. Совсем неплохо.

Но количество адресов всё равно должно спасать и истинная рандомизация (чтобы энтропия зашкаливала), плюс частая смена как это всё уже написано в различных соглашениях по безопасности. Плохо что это всё может превратиться в их бесконечную замену со временем жизни 5-10 минут. Тот самый момент когда IPv6 стал достаточно популярен, чтобы на него обратили внимание - новая эра?

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

dig @a.root-servers.net +noall +answer +multi . dnskey | grep 'key id'

) ; ZSK; alg = RSASHA256 ; key id = 16749
) ; KSK; alg = RSASHA256 ; key id = 20326
) ; revoked KSK; alg = RSASHA256 ; key id = 19164

Если у вас FRRouting используется в качестве BGP спикера в общем Интернете и 7 января он внезапно стал дёргать сессиями, то это ничего страшного - просто эксперимент. Его останавливать не собираются и 15 января всё повторится. Кстати не факт что больше ничего не упало, просто именно это было сильно заметно.

FRRouting и в самом деле некорректно отрабатывает технический тип атрибута, как с этим бороться (проявляется если собрано с определённой опцией) написано в описании проблемы в первой ссылке. Главное знать что проблема именно в этом и успеть подготовиться, невозможно ведь читать все списки рассылки и профильные чатики.

Немного поспешил что KSK-2010 совсем всё, ещё нет - ключ отозван. Спасибо, что обратили на это моё внимание и поправили, будем исправляться. Собственно key id=19164 и есть тот самый revoke, как и написано. Что там внутри удобно смотреть на dnsviz.net, если навести на нужный ключ там будут подробные сведения кто кого подписывал и кто у кого и что отзывает.

Совсем всё будет в августе когда ключ затрут во всех местах, включая аппаратные модули. Из корневой зоны ключ должны удалить 22 марта. Собственно план работ (на 7 странице по датам в таблице).

Вот так будет правильно.