Собираете логи с Windows машин? Моя практика не привела меня даже к возможности начать такое делать, но вопрос интересный.
JPCERT/CC выпустила SysmonSearch - систему которая позволяет собрать и анализировать логи Windows Sysmon. Вывести статистику, искать по логам и мониторить выискивая аномальное поведение. Есть GitHub, но можно сразу docker использовать. Весь сервер разворачивается на Linux (по крайней мере инструкции только под него написаны). Внутри Python, Kibana и Elasticsearch.

ICANN своё дело сделала - KSK rollover случился. Новый ключ id=20326 используется для подписи корневой зоны.
Теперь дело за малым, подождать и посмотреть что всё работает как и работало.

​И всё-таки карта IPv6 интернета есть. Правда основана не на том сколько хостов ответило, а на том сколько сетей было анонсировано в BGP.

Как это было сделано написано в блоге APNIC, подходит не только для IPv6. Инструмент доступный и открытый для использования.

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

Немного шпионская история про порт 1999, который позволял идентифицировать устройства Cisco (сейчас нет). Теории заговора, грязные хаки, потерянная партия роутеров, Советский Союз и Финляндия, интересная история одним словом.

IANA, кстати, держит его в зарезервированных, начиная с 1985 (HSRP) одна Cisco.

RIPE77 в самом разгаре со вчера и целую неделю впереди. По ссылке интерактивное меню - презентации уже доступны, видео по мере поступления.

Навскидку - про DDoS и то что невозможно с ним бороться не вмешиваясь в абонентский трафик, какой-бы клиент не был. NTT достаточно мягко (не блокирует, а режет полосу) обходится на 29 слайде. Можно брать на вооружение:

Implementing exploitable port filters
NANOG - Job Snijders job@ntt.net: “NTT has deployed rate limiters on all external facing interfaces”

ipv4 access-list exploitable-ports
permit udp any eq ntp any
permit udp any eq 1900 any
permit udp any eq 19 any
permit udp any eq 11211 any
!
ipv6 access-list exploitable-ports-v6
permit udp any eq ntp any
permit udp any eq 1900 any
permit udp any eq 19 any
permit udp any eq 11211 any
!
class-map match-any exploitable-ports
match access-group ipv4 exploitable-ports
match access-group ipv6 exploitable-ports-v6
!
policy-map ntt-external-in
class exploitable-ports
police rate percent 1
conform-action transmit
exceed-action drop
set precedence 0
set mpls experimental topmost 0
class class-default
set mpls experimental imposition 0
set precedence 0
!
interface Bundle-Ether19
description Customer: the best customer
service-policy input ntt-external-in
!
interface Bundle-Ether20
service-policy input ntt-external-in

У Neighbour Discovery есть расширение Secure Neighbour Discovery которое решает проблемы доверия между участниками. И это не было бы так важно (насколько хорошо защищен ваш ARP в пределах широковещательного домена?), если бы ещё не SLAAC и назначение адресов. Я в домашней сеточке до сих пор переживаю что у меня SLAAC и кто угодно может прислать мне адреса - DHCP, как минимум, предсказуемей. Остальное, вроде спуфинга, подмены роутеров и всевозможных DoS решается в комплексе.

Так вот, приемлемой реализации SEND RFC3971 - нет. Поэтому появился проект iSEND который ставит своей целью реализацию протокола в достаточной степени для эксплуатации в Linux подобных системах (на уровне пользователя), включая Android. Задействуют ip6tables для обработки. Альфу версию надеются выпустить к концу года.

Путь ещё долгий. Но это на самом деле очень полезная реализация, которая позволит спать спокойно очень многим админам и не админам тоже.

В libssh обнаружена уязвимость CVE-2018-10933 в духе "Скажи слово друг и проходи". Если атакующий пошлёт сообщение об успешном входе - буквально, то сервер его пустит. Библиотека популярная, поэтому оперативно обновляемся.

​Ресурс на котором можно посмотреть все некорректные префиксы BGP использующие RPKI. Есть фильтр по странам, ASn, RIR, протоколу. Приводится не только сам префикс но и причина по которой он не прошёл проверку. Обновление информации - по расписанию. Целей гораздо больше, всё только начинается.

Всего сейчас видно 1,592 IPv4 и 86 IPv6 префиксов с проблемами. С учётом того, что RPKI практически не используется, то это не вызывает проблем с маршрутизацией (глобально) и с немалой долей вероятности является сигналом администратору всего лишь проверить актуальность ROA.
Например, 185.54.244.0/24 анонсируется с неверной AS57822, а должен с AS49673 которая принадлежит той же организации.

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

​DENDY (NES) на PHP в консоли.

Пока у меня перезагружается, можно в телеграме посмотреть на смешные картинки.

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

;* * * * * * REVISION HISTORY * * * * * *

; 08/18/82 2.42 Increase stack from 80 to 256 (Damn! Overflowed again!)

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

Поэтому адреса были собраны, препарированы и сформированы в отчёте на сайте http://entropy-ip.com. Адреса обезличены в старшей части - все префиксы 2001:db8::/32. По факту в простом отчёте префикс всегда 2001:db8:0000::/40 и 14 октет всегда 0, возможно это издержки набора данных (тем более что некоторые границы видно и в других местах). Но так как в полный отчёт я погрузился не до конца не могу по этому поводу ничего сказать. Его можно читать, если вы давно не видели формул придётся кое-что вспомнить. Там сильно разжёвано по существу, но некоторые отсылки придётся вспоминать или пропускать

Простой отчёт не содержит никаких уравнений и читается легче:

1. Сначала посчитали энтропию (чем больше число, тем больший разброс значений в этом месте IPv6 адреса) - это синяя линия на первом графике. Так как статья академическая то сравнили ещё со значением ACR из другой академической статьи (на него можно внимания не обращать).

2. На основе значений энтропии выделили несколько сегментов в IPv6 адресе, по тому как сильно отличаются они друг от друга. В этих сегментах (один или несколько октетов), посчитали статистику появления того или иного значения. Если задан диапазон значений (зелёный курсив со звёздочкой), то из него уже исключены все ранее приведённые значения. Например, вероятность что в 16 октете будет число 3 - 9,5%, а что будет какое либо другое число кроме 3,5,4,8 - 67,52%

3. Дальше построили Байесову сеть - зависимость появления какого либо числа в каком-то месте, от того какое число стоит в другом месте. И сделали интерактивную табличку, в которой можно выбрать число и увидеть как изменится вероятность (отличается цветом) появление других чисел в адресе. Такие же таблички приведены на первой странице http://entropy-ip.com для разных наборов данных (ссылки Dataset).

В самом конце были сгенерированы адреса, которые с большой вероятностью могут встретится в сети и быть активными. Попадание при используемом методе 40% и вот это уже очень много - перебирать ничего не нужно даже если активна всего половина адресов из предполагаемых то это в бесконечное количество раз лучше чем проверить даже 2^64.
Конечно остаётся вопрос получения исходных данных по которым можно проводить анализ. Но это не такой сложный вопрос, особенно если иметь определённую цель. Тем более что инструментарий доступен на GitHub Akamai, а метод расписан от и до.

​Вчера робот Ubuntu который следит за зеркалами напомнил нам, что мы забыли синхронизировать новый релиз 18.10. Релизы у нас синхронизируются раз в сутки, позже чем выкатываются на основном зеркале. Это не противоречит правилам, но в этот раз робот заметил и напомнил.

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

Но тут сама Canonical выложила подобный отчёт на основе данных которые она может собирать начиная с версии 18.04. Его русский вариант в переводе Василия Алексеенко. Россия в лидерах по количеству пользователей Ubuntu, не зря значит мы держим наше зеркало ;)

Cisco привела список своих решений в отношении которых проводится проверка по поводу libssh уязвимости. И их там много, включая например IOS XR Software. Того чего нет в списке - 100% не может быть затронуто. Секция "Уязвимые" пустая, пока.

Самостоятельно проверить можно с помощью LibSSH Scaner - качается с GitHub.

Новый Knot 2.7 теперь может в географии разбираться с помощью модуля GeoIP. Примерно вот так:

www.example.com:
- geo: "CZ;Prague"
A: 192.0.2.0
TXT: "Prague"
- geo: "CZ;Brno"
A: 192.0.2.1
TXT: "Brno"
- geo: "CZ;*"
A: 192.0.2.2
TXT: "Czechia"

Поддержка EDNS присутствует.

ASCII картинки заголовков протоколов форматированные в стиле RFC. Есть уже готовые заголовки, а можно конструировать самим какие захочется. Парочка опций командной строки для корректировки вывода. Написано не Python.

Очередной мощный пост от Vincent Bernat, весьма подробно рассказывающий о механизме BGP LLGR с примерами на актуальных платформах. Рекомендуется к прочтению, впрочем как и весь блог на постоянной основе, там всегда много интересного. https://vincent.bernat.ch/en/blog/2018-bgp-llgr

MSK-IX и DE-CIX собираются установить прямой пиринг. Неплохо, неплохо. Вот будет-ли общий пиринговый вилан... посмотрим.

Очень хорошая и простая (во всех смыслах), но от этого ещё более хорошая, статья про основы балансировки сегодня на Habr. От DNS до BGP, от Apache и Nginx прокси до кода на стороне клиента. Всё что нужно знать для практического понимания балансировки, совсем без углубления в детали и с отличной подачей.

Этот же вопрос куда детальней на большом Highload или от Yandex (везде видео).