Хорошо и подробно про mtr, с примерами. Это вторая часть серии.

Сегодня пиринговый форум - цель моего раннего утреннего перелёта. Кто не дошёл, есть трансляция https://peering-forum.ru/live/

Много где засветилась новость про то что можно ломать VPN - на OpenNET достаточно понятно пишут, но много внимания уделили не сути, а режимам rp_filter и методам перебора. Можно читать оригинальный тред, там подробнее, но ровно про то же.

Что важно:
1. Зашифрованный трафик остаётся зашифрованным и его не расшифровывают
2. Используемый метод позволяет влиять на то что будет передаваться внутри туннеля
3. Это влияние можно использовать чтобы выяснить параметры соединения внутри туннеля, например, адресацию
4. Это можно использовать чтобы добавлять/подменять реальный трафик внутри туннеля, но вслепую. Ответ будет зашифрованным внутри туннеля и поэтому атака предполагает ещё и его перехват и анализ на основе статистики и сигнатур
5. Атака возможна потому что пакет обрабатывается одинаково в соответствии со своим адресом в не зависимости на какой из интерфейсов он пришёл

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

P.S. Там камни в огород systemd летят в связи с этим, но тут больше дело в том, чтобы знать свою систему и понимать как всё работает.

Скорость исполнения, против скорости разработки. Скорость выполнения посчитать легко и даже можно калории посчитать и там всё ясно с тем кто на коне. А вот со скоростью разработки и поддержки сложнее, иначе бы не было ни Ruby ни Java.

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

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

Пока пароли всё ещё в ходу - статья про то как сделать хороший пароль - всё дело в длине и уникальности:

1. Каждому ресурсу свой пароль
2. Если пароль содержит цифры, буквы и спец.символы это не значит что он хороший
3. Ответ на секретный вопрос для восстановления пароля сделайте другим не менее сложным паролем
4. Двухфакторная аутентификация
5. и менеджер паролей

Приводится несколько заблуждений, например, по поводу частоты смены паролей, в конце пару ссылок по теме, в том числе на чекер сложности паролей от Dropbox.

На нашем недавнем тепло-семейном сборе в Москве (кстати, спасибо всем, кто пришёл) узнал прекрасную историю про бурления масс вокруг мнения не безызвестного нам всем товарища Пепельняка. Иван человек простой и прямо говорит, что проблема не в BGP, а в руках и головах инженеров, которые им пользуются.
Ну и понеслось...
https://blog.ipspace.net/2019/12/bgp-and-car-safety.html

Шпаргалка nmap - основные команды и опции.

Подробнейший отчёт о состоянии возможности спуфинга в Интернете по материалам собранными проектом spoofer.caida.org. Интересно, что для исходящего трафика проверки делают многие, но далеко не все, а вот для входящего - нет. То есть многие сети принимают пакеты из внешних источников, в которых адрес отправителя значится внутренним. Не стоит забывать и транзитные моменты - два апстрима или пиринга, а между ними бегает трафик с поддельными адресами, хотя маршруты и не утекают. Масла в огонь добавляет NAT, который может с лёгкостью транслировать не свой адрес. И конечно IPv6, спуфить внутри своей /64 могут почти все клиенты, вроде логично, хотя около 9% не могут вообще спуфить.

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

К проекту CAIDA Spoofer можно присоедениться, есть клиенты для популярных ОС и исходники, и конечно если можете фильтровать - фильтруйте. Когда нибудь усилия будут вознаграждены и DDoS, вирусов, сканеров станет меньше.

💻 Занятная панель для настройки работы с SSH на большом количестве серверов https://www.bastillion.io/ Тут тебе и управление ключами, и 2fa, и собственные возможности для соединения, аудит и контроль доступа, и гуй для всего этого.

#ssh #bastillion

Кому-то разминка для ума, а кому-то настоящий вызов - не только про Cisco, сети и подготовку к экзаменам, но и на умение пользоваться Wireshark.
Ответы в картинках, даже если заглянуть в которые раньше чем ответ найден, всё равно окажутся полезными.

Ещё одна серия статей про TLS, много вводной информации в первых трёх частях, буквально на пальцах, но с классическими Бобом и Алисой - просто теория. И последняя часть разбор дампов рукопожатия TLS.

Сделать систему надёжной совсем не просто, даже если все нужные компоненты реализованы это ещё ничего не значит. Несколько правил, скорее вопросов которые сформулировал Mark Brooker:

1. Усложнение системы для обеспечения избыточности не должно ухудшать её доступность;
2. Система должна смочь запуститься в аварийном режиме;
3. Система должна гарантированно определять какие из компонентов рабочие, а какие нет;
4. Система должна иметь возможность вернуться в режим с резервированием.

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

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

Из любой позиционной системы счисления в десятичную на bash:

> echo $((2#111))
7
> echo $((16#FF))
255
> echo $((36#ZEBRA))
59454982

На самом деле это просто, относительно, посчитать и в уме - никаких тебе делений, расставляй вес разряда умножай и складывай. Первые 255 можно в принципе в памяти держать, как и многие ключевые значения, вроде 0xFFFF. А вот обратно всё интереснее, но для этого bc есть. Там же из комментариев:

> echo "ibase=2\n111"|bc
7
> echo "obase=2\n7"|bc
111

Если давно хотелось потрогать SD-WAN и понять из-за чего так много шума, но выглядит это сложно и не ясно с чего начать, то вам царский подгон.
Лаба в стиле минимал техно =)

https://neckercube.com/posts/2019-12-18-cisco-sdwan-basic-configuration-lab/

Министерство обороны США планирует избавиться от своих IPv4 адресов не позднее чем через 10 лет и начать процесс продажи не позднее чем через 2 года: "S.1790 - National Defense Authorization Act for Fiscal Year 2020 / SEC. 1088. DISPOSAL OF IPV4 ADDRESSES".

Всего 13 блоков по /8:

6.0.0.0/8, 7.0.0.0/8, 11.0.0.0/8, 21.0.0.0/8, 22.0.0.0/8, 26.0.0.0/8, 28.0.0.0/8, 29.0.0.0/8, 30.0.0.0/8, 33.0.0.0/8, 55.0.0.0/8, 214.0.0.0/8, 215.0.0.0/8

Оценить масштаб можно вот на этой карте (по ссылке в хорошем разрешении) ищем US Army и DoD. Карта 2007 года, на текущий момент считаем что unallocated регионов нет. Это примерно 1/20 всего теоретического адресного пространства.

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

З.Ы. Спасибо большое за ссылку нашему подписчику, чуть не прошёл мимо этого, без вас никуда.

На CNews собрали в кучу всю историю падения Айхора. Пострадавшие и так всё знают, а вот для остальных очень поучительная история получилась. https://www.cnews.ru/news/top/2019-12-18_vojna_vokrug_rossijskogo

Тест по BGP с упором на организацию внутренней архитектуры сервис провайдера: iBGP, MP-BGP, RR. 30 вопросов мне дались тяжеловато, темы которые до сих пор для меня сбоку. Но тесты для этого, в том числе, и нужны - показать где границы проходят.