Этим летом мы потеряли двух админов, которые ушли в программисты. Ушли в соседний отдел, но всё же мы потеряли двух хороших, настоящих админов с прокачанными телеком навыками. Таких в наших краях не сразу и найдёшь. Один теперь занимается автоматизацией и интеграцией сетевых устройств во все наши системы управления, мониторинга и анализа. Получилась модная сейчас эволюция о которой все говорят. Второй в JavaScript ударился, в провайдере этому место тоже есть, но от админства совсем далеко.

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

ICMP богатый протокол и имеет в своём распоряжении, например, механизм синхронизации времени. NTP победил, но то что осталось позволяет получить много чувствительной информации об узле который отвечает на запрос, включая геолокацию с точностью до часового пояса. Обо всём об этом в исследовании представленном на конференции PAM 2019.

Если подходить к безопасности комплексно и серьёзно, то типы 13 и 14 ICMP которые отвечают за запросы и ответы timestamp, можно безболезненно запретить в своём фильтре, если за вас это не сделала уже операционная система, так как рабочих вариантов их использования в настоящее время не существует. При этом, согласно приведённым данным, больше 2 миллионов узлов ответили на запрос timestamp, а это около 15% из всех опрошенных. Можно взять nmap, который широко использует данный тип запроса и убедиться.

​На Chaos Constructions 2019 меня не было, но значок с Free Software меня нашёл благодаря хорошему товарищу который всё видел собственными глазами и передал привет от Ричарда Столлмана. А в довесок ещё несколько стикеров с логотипами и страшилками про то как за нами следят.
Значок большеват на мой вкус, но обязательно буду носить пока ещё тепло, прицеплю на свой свитер.

Суть вчерашних обсуждений в очень многих тематических чатах.

Джон Гилмор (не музыкант, а ex-Sun, соавтор BOOTP, основатель EFF) сотоварищи решили, что что-то много IPv4 адресов простаивает. А именно, 0.0.0.0/8, 127.0.0.0/8 (кроме 127.0.0.0/24), 225.0.0.0/8 - 231.0.0.0/8, 240.0.0.0/4. И надо их превратить (https://netdevconf.org/0x13/session.html?talk-ipv4-unicast-expansions) в обычные global unicast.

Патчи для линукса вышли. Это некоторым образом удовлетворяет требованию running code, так что останется rough consensus от IETF.

127.0.0.0/8 мне лично кажется слишком радикальным. А 240.0.0.0/4 могут и начать раздавать, это 16 /8, плюс 225.0.0.0/8 - 231.0.0.0/8 - это ещё 7 /8. 23 префикса /8 - это по четыре префикса на один RIR. Среднее время расходования /8 одним RIR, судя по данным https://ipv4.potaroo.net/ — от 6 до 12 месяцев. То есть, если предположить, что это пройдёт IETF, будет поддржано вендорами, ICANN, RIR, это оттянет текущую ситуацию на 2-3 года.

​В Oracle сделали суперкомпьютер, тут скорее как синоним кластера, самого большого из Raspberry Pi. Чуть больше описания с фотографиями на servethehome.com. Параметры производительности не приводятся, но приводится количество затраченных материалов.

40Гбит/c по воздуху, уже можно. Точнее 4 по 10Гбит/c на расстояние в 11км. В статье не так много технических деталей, но есть история вопроса.
Лучше резерв на радиолинке чем никакого, тем более гигабиты/c можно получать достаточно легко в пределах нескольких километров. Хотя такой резерв доставляет больше мороки, особенно тем кто всё время с кабелем работает.

Проверщик на живость URL по списку из файла, говорят что быстрый.

MANRS собрали в одном месте статистику по проблемам и готовности участников интернет отвечать за свои сети, называется observatory.manrs.org. Соответствие данных IRR действительности, покрытие RPKI, фильтрация, спуфинг, количество инцидентов с маршрутизацией. Можно смотреть по странам и по RIR, есть история и сравнения. Наверное, когда все примут соглашения MANRS, то все графики будут зелёные, но пока не так. Почитать что к чему, большое спасибо за ссылку от нашего подписчика, можно на arstechnica.com.

Yandex молодцы - включили проверку по RPKI, скоро у всех. Может расскажут на Nexthop, в программе есть доклад про безопасность в BGP.

Первый наш национальный домен SU отмечает своё день рождение сегодня. RU - младший брат.

В блоге Cloudflare детальный технический разбор закрытия TCP сокетов по истечении времени - в каких случаях это происходит, а в каких не происходит. Разбираются ситуации вокруг использования опции TCP_USER_TIMEOUT и как она сочетается с другими механизмами и параметрами, в частности с TCP keepalive при различных состояниях соединения.
В конце, конкретные рекомендации что и где включать для тех кто уже может в socket(). В начале, хорошо расписан процесс установления соединения TCP. Для админов есть опции sysсtl. И бонусом утилита которая используется в статье выложена на Github.

С помощью iperf можно генерировать и мультикаст трафик, собственно проверять его маршрутизацию, QoS. В статье и комментариях достаточно развёрнуто всё расписано. На сайте iperf то же, но покороче.

Белорусы собираются внедрять IPv6 добровольно-принудительно, и на это будет интересно посмотреть. Даже сейчас это может оказаться бегом впереди паровоза, хотя про IPv6 уже кто только не говорит, а IPv4 вот-вот очередной раз кончатся. Провайдерам придётся поднапрячься или сделать вид.

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

1. не ограничивать доступ
2. не обновляться
3. не знать какие устройства есть и как они функционируют
4. не обучать персонал и пользователей
5. использовать пароли по умолчанию

Так делать не надо, даже если это принтер.

PBR на ACI. По смыслу ничем не отличается от PBR на IOS или на чём угодно. Достаточно подробно написано, насколько может судить человек никогда не прикасавшийся к ACI. Интересно посмотреть на параллельный для меня мир, может, возможного будущего.

Очень обстоятельная статья на тему централизованности DNS. Сначала нагоняется много жути что централизованность плохо и это приводит к смерти такой системы (рынка) и даже приводятся графики что 90% пользователей используют не более 10% DNS резолверов, даже меньше 2%.
Но потом становится веселее, потому что исключается фактор, что пользователи большой сети дают больше процентов в статистику и проводятся уже более обнадёживающие показатели. Более половины пользователей используют серверы DNS внутри своей AS (своего интернет провайдера), а на долю публичных DNS приходится не более 30%. Живые графики можно смотреть на stats.labs.apnic.net.

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

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

DTP/LLDP/CDP/VTP, HSRP/VRRP, PIM, OSPF/EIGRP/RIP, Telnet/SSH/HTTP, SMI/ZTP - должны смотреть только туда куда нужно, быть выключены или заблокированы с помощью ACL. И это далеко не полный список, но при этом очень простой. А ещё не забываем про vlan hopping, например, что конечно посложнее, но не сильно. И конечно обновляемся, ошибки в ПО это обыденность.

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

В подтверждение предыдущего поста. Набор утилит для получения данных с каталистов, которые используют механизм трассировки на втором уровне для чего слушают UDP порт 2228. Я попробовал enumerate-vlans на Catalist 2950 (правда, совсем уже не новой) и всё отлично сработало:

C:\> enumerate-vlans.exe 192.0.2.2
Target info:
Hostname: c2950-F1C23
Platform: WS-C2950G-48-EI
Claimed IP: 192.0.2.2
Known IP Addresses:
192.0.2.2 responds from 192.0.2.2 8.053ms
Target address: 192.0.2.2
Listen address: 192.0.2.2
Local address: 203.0.113.2
4094 / 4094 [---------------------------] 100.00% 189 p/s

5 VLANs found: 11 15 91 313 516

При этом access-class на авторизацию не работает, то есть защищаться надо по другому. Доступно и из другой подсети, через маршрутизацию.

Компилируется go build. Подробности формата и примеры посложнее по этой ссылке.

Если на интерфейсе повесить несколько IP адресов, какой из них будет использоваться? В мире Juniper это сделано вот так:

Use preferred when the destination is on the same subnet.
Use primary when the destination is on a different subnet.
And remember that Lowest IP wins.

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