На rublacklist перевод WikiLeaks про СОРМ. Секрет Полишинеля, конечно. Да и статья не очень захватывающая. Самое интересное это документация на реализацию одного из вариантов СОРМ. Ничего секретного там нет, просто всё собрано в одном месте и доступно теперь не только заказчикам и исполнителям, но и широкой публике.

P.S. Наши, тоже могут по ЕСПД, не только ЦРУ

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

А у вас есть главный сетевой коммутатор? В Telegram есть и сегодня ему было не очень хорошо.

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

Простой сканер WEB сайтов , совсем новый. Пишет понятным языком, правда по английски. Есть косяк с импортированием модуля parse, потому что имя пересекается в глобальном пространстве. Решается переименованием каталога где модуль лежит и правкой пары файлов (Python27 ругается в нужных местах).

В общем на вскидку, мне понравился, удобнее для экспресс анализа многих других инструментов. KaliTut рекомендует.

Во многих устройствах можно применить конструкцию show [команда] | i regexp. Да-да именно regexp, самый что ни на есть настоящий. То есть, в запросе вида show ip int br | i 192.0.2.1 "точка" трактуется как любой символ, а не как "точка". IP 192.0.211.1 попадает под фильтр.

Исходя из известного факта: "Если у вас проблема и вы хотите решить её с помощью regexp, то теперь у вас две проблемы." - с этой конструкцией следует быть вдвойне внимательней. Запросы простые, но перестраховаться не помешает.

Многие проблемы при передаче в современных сетях происходят от отсутствия полноценной обратной связи между приёмником и передатчиком. Как в анекдоте про солдата сисадмина, отвечающего на вопрос почему пули не попадают в цель, что с его стороны всё нормально - пули ушли, проблемы на принимающей стороне. У IP есть ECN - Explicit Congestion Notification, RFC3168.

Для оптических сетей Juniper предлагает ввести LLDP расширение, чтобы конечные узлы обменивались информацией о BER (количестве ошибок в секунду в битовом потоке) и на основе этой информации управлять мощностью оптических передатчиков. Подбирая оптимальные с наименьшем уровнем ошибок. У большой компании всё серьёзно - поэтому они получили 5 сентября патент, ждём реализации.

Пока bobuk плетёт теории заговора, телеграм опять падает в Азии, на этот раз по электричеству. Странно конечно написано: "Всё питание и бесперебойники..." - но бывает, почему нет?

Многие заметили не слишком стабильную работу Телеграма последние пару дней. Вот вам статья, в которой ни разу не упоминается телеграм, но из которой становится понятно, почему такие проблемы: в Китае заблокировали WhatsApp.

Да, по соображениям цензуры и контроля. И нет, те, кто пользовались WhatsApp не могут вернуться на китайский WeChat, им нужно общаться со своими друзьями и партнерами за пределами Китая - поэтому у них два варианта: Facebook Messenger (который тоже частично заблокирован) и Telegram (частичные блокировки есть давно). Как следствие, азиатский сегмент телеграма получил непридвиденную нагрузку. Такая вот у меня умозрительная теория, подтверждений нет.

https://www.nytimes.com/2017/09/25/business/china-whatsapp-blocked.html?mcubz=3

Возвращаясь к "Пули вышли, проблемы на принимающей стороне", нельзя не вспомнить опцию 7 в IPv4 пакете, которая называется Record Route. Она теоретически позволяет записать весь маршрут со всеми промежуточными узлами на всём пути следования пакета, как туда так и обратно! Почему теоретически, потому что размер области с данными IP ограничен и туда не помещается больше 9 адресов: маршрут туда и маршрут обратно, т.е. можно проверить что-то не дальше чем в трёх хопах от себя.

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

$ ping 62.76.76.62 record
44 bytes from 62.76.76.62: icmp_seq=0 ttl=61 time=22 ms
RR: 195.208.208.30
194.226.29.177
194.226.75.93
62.76.76.62
194.226.29.182
195.208.210.2
172.10.17.9

$ tracert 62.76.76.62
1 172.10.17.1 4.723 ms 4.416 ms 3.762 ms
2 195.208.208.30 22.762 ms 21.945 ms 21.052 ms
3 194.226.29.182 22.450 ms 23.924 ms 23.503 ms
4 * * *

Практически любая утилита ping это позволяет делать. В Linux опция -R. В Windows -r [размер блока данных] - смело ставим 9, максимально возможное. В Juniper пишем record-route. В Cisco используем расширенный режим. Главное чтобы по пути нигде не зафильтровалось.