Ещё одна, скорее утилитка чем система мониторинга, которая позволяет красиво нарисовать графики из различных источников на вашем текстовом экране Linux. Как поставить и что с этим делать чуть более подробнее написано на tecmint.com чем на GitHub. Выбор это хорошо.

APNIC исследовала точность часов в Интернете и пришла к выводу, что 53% почти точные насколько точен метод - плюс/минус 1 секунда. Остальное или отстаёт - 38% или спешит 9%, иногда это годы! (хотя и не такое значимое количество). В начале обширный ликбез про часы, NTP и вообще время, а сама суть примерно с середины.

Меня смутило не это, а метод каким они время собирали - сделали скрипт на JS (написано просто скрипт в браузере) и отсылали данные обратно на сервер где сравнивали уже с точным временем. Глупо, в наше-то время, но почему-то именно вот такая большая статья на профессиональном ресурсе сподвигла меня побеспокоится о том что они просто так взяли и собрали какие-то данные с моего (почему нет) компьютера. Всего больше сотни миллионов измерений в течение 80 дней. Я простил бы и прощаю это рекламщиками, но вот когда от "своих" такое получаешь...

​Downdetector конечно быстрые, но они всё же на реакции пользователей базируются. А вот у Apple есть страничка со статусом их сервисов (на русском в том числе), где помимо собственно статуса (работает - не работает) есть ещё данные о том когда последний раз не работало и сколько пользователей задело.

Если вдруг кто-то в ТП звонит (если вдруг кто-то Apple пользуется), чтобы оператор мог грамотно ответить. Ну и заодно понятно что Apple вообще считает за свои сервисы.

ISC написала dnsgen, чем заменила у себя dnsperf, потому что быстрее и процессор меньше грузится, о чём они у себя в блоге написали чуть подробнее. Для использования придётся компилировать.

Чтобы не отставать от ISC можно попробовать заменить iperf на nutcpp или mz по совету Johannes Weber. Вторая утилита вообще не для этого, но проверить работу сети под нагрузкой может ;)

Ещё раз про то что не надо путать зоны ответственности, если сервис для LAN пускай в LAN и остаётся. К недавним новостям (почти ежемесячным) про множественные уязвимости роутеров через UPnP протокол. Хотя это даже и не новость давно.

Статья про эксплуатацию UPnP уязвимости из Интернета. Выдержки из стандартов, дампы, диаграммы, статистика Shodan. И главное никакого прямо воздействия по сути, роутер сам всё отдаст его надо только попросить - согласно протоколу.

Долго лежал в закладках, но таки добрался чтобы посмотреть. Chiron - набор инструментов для проверки безопасности в IPv6 сети. Это именно инструменты, сценарии и результаты работы надо самостоятельно придумывать и интерпретировать. На текущем этапе, когда безопасность именно IPv6 постольку-поскольку даже минимальное воздействие может плохо кончится, поэтому что-то придумать совсем не сложно. Документация в PDF для начала, однако в исходники я чувствую всё равно придётся погружаться - там Python.

Набор доступных техник достаточно широк, наверное, используя совместно другие инструменты можно получить что-то подобное. С точки зрения просто сети, на себя обращает внимание реализация IPv4 to IPv6 proxy, который заменяет нижние заголовки IPv6 на IPv4, позволяя программам которые умеют только в IPv4 работать с сервисами только IPv6 на уровнях выше сетевой адресации. Пример в документации для сканера nikto.pl, но разумные мирные задачи для такого proxy тоже найдутся.

​Для GNS3 теперь можно получить сертификат уровня Associate (наверное дальше будет больше). Набор тем достаточно обширен и очень современен (может чересчур). Цена приемлемая, в общем почему нет, если GNS3 ваш рабочий инструмент.

Интернет это не Web, но во многом это лицо Интернета. Как оно выглядит с разных сторон можно посмотреть на этом сайте https://wpt.fyi/results/
Суммированный отчёт для 4 браузеров и обширного набора тестов на множество технологий применяемых в Web. Можно смотреть конкретно на каждый тест и на его конкретные ошибки. Сами тесты http://w3c-test.org - на них есть ссылки из результатов в отчёте, но можно и произвольно выбирать.

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

Вот такие пироги с трафиком. Могу сказать что у нас примерно такая же статистика. Eсли брать только HTTPS против HTTP то первого почти в два раза больше.
Картинка с конференции CoNEXT'18. Доклады в расписании интересно помечены - short и long, жаль сравнить не с чем, кажется удобным.

Зал славы уязвимостей последних лет - название, логотип, есть ли известные атаки.

Тут ребята зарелизи быстрый MRT парсер. В чатике проверили. Говорят и правда быстр :

~> time -p bgpscanner -s 192.65.0.0/24 -p '34549 6939' latest-bview.gz
=|192.65.0.0/24|34549 6939 62943 393668|80.77.16.114|i|||34549:200 34549:201|80.77.16.114 34549|1543448842|1
real 9.55
user 9.50
sys 0.04

~> du -sh latest-bview.gz
204M  latest-bview.gz

https://labs.ripe.net/Members/lorenzo_cogotti/new-mrt-bgp-reader-six-times-faster-than-its-predecessors
https://www.isolario.it/extra/publications/slides/RIPE77_slides.pdf

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

Сейчас модно golang, поэтому можно пойти и посмотреть как сделать VPN сервер на golang. Там ещё websocket и получилось достаточно просто чтобы понять всё целиком за один вечер.

Шпаргалки по командам Cisco, Huawei, Juniper и Nokia, в сравнении. В основном show для различных режимов и протоколов. И в pdf.

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

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

Это просто замечательно как несколько слов на английском плюс стандартный Cisco интерфейс и Python позволяют догадаться (надеюсь правильно) о чём написано в японской статье про скрытые команды Cisco IOS XE. Cisco CLI - международный язык сетевых инженеров :)

Не все команды, по мнению всех вендоров, доступны конечному потребителю (пусть это останется на их совести). Но если для IOS XE (Starting with Cisco IOS XE Fuji 16.8.1a) ввести service internal то скрытые команды будут также как и все остальные выводиться в подсказке по символу "?", а их использование логироваться %PARSER-5-HIDDEN: Warning!!!.
Автор приводит несколько примеров и дополнительно написал скрипт для встроенного Python, чтобы получать список таких команд в какой либо ветке настроек. Это не перебор, а именно то что отдаёт Cisco в режиме service internal.
Вероятно такой путь является правильным, потому что часто приходится просто перебирать или внезапно узнавать новую команду от техподдержки.

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

​Самый открытый провайдер это Ростелеком. Ничего не скрывает ни от кого. Найдено коллегой на улице на одном из распределительных шкафов.

Практика IPFS. С учётом того что CloudFlare недавно к этому движению подключился, то имеет смысл посмотреть поближе. Может даже поднять гейт.

Понятийный обзор нескольких видов атак на подбор соответствий паролей их хешам. Безопасность она как радиация - незаметна. В конце статьи несколько советов, наверное тривиальных, но всё же - не забываем посолить свои хеши.

Простой симулятор вирусной активности, активности центров управления ботнетами. Позволяет проверить как отреагирует система безопасности на периметре вашей сети (если она есть). Короткий ролик, ненужный, всё понятно без него.

Есть версии для разных платформ, надо только согласиться выполнять неподписанные файлы :)