Comments 57
Причиной, по заявлению сотрудников «Ростелекома», стал сбой маршрутизатораДа-да, ни у кого в мире маршрутизаторы не сбоят вот так, а у ростелекома уж 4 раза и все разы ночью…
Признайтесь уже, человеческая ошибка — посадили криворукого ночью дежурить за магистральными шлюзами, а должного контроля не сделали… вот он от скуки и начал в 3 часа «улучшать» сеть…
Тестируют переход на православную карту Мир и обрубают способ вывода валюты зарубеж, т.к. невозможно будет ничего купить.
Биткойны сначала пусть заблокируют. Деньги уже давно прекрасно «текут» из страны в страну через них.
Но блокировать идеальную прачечную в стране с запредельной коррупцией вряд ли кто-нибудь станет.
Наворованное же тоже надо как-то выводить из страны :)
Но блокировать идеальную прачечную в стране с запредельной коррупцией вряд ли кто-нибудь станет.
Наворованное же тоже надо как-то выводить из страны :)
Вероятнее готовятся во время массовых народных волнений рубануть интернет, оставив только критичные сервисы, дабы не усугублять.
Вряд ли европейский или гонконгский банк можно отнести к критичным сервисам.
Если будут работать критичные сервисы, будет работать и dns.
А через dns можно гнать что угодно.
Потренеруйтесь заранее :)
А через dns можно гнать что угодно.
Потренеруйтесь заранее :)
DNS можно фильтровать.
Мне вот интересно, какие вычислительные ресурсы нужны, чтобы фильтровать DNS в масштабах страны. Если отлавливать туннели механически, короткий патч к софту для туннелирования решит проблему. Чтобы качественно отлавливать все возможные туннели вообще, нужна эвристика.
Будут разрешены запросы только к DNS серdthe провайдера, а DNS провайдера будет разрешать адреса только домены критичных сервисов.
Если у нас на самом деле будет dns whitelisting, будем гнать трафик через стеганографию и любую возможность публикации пользовательских данных на критичных сервисах.
Софт для этого уже написан, см. ссылку.
Вода дырочку найдёт.
Софт для этого уже написан, см. ссылку.
Вода дырочку найдёт.
А может банально неплатильщикам пытаются сделать доступными сайты банков, чтобы 3-D Secure можно было подтверждать? А мы тут панику развели.
Американцы сами обрубили нам возможность что-либо купить за рубежом, обвалив цены на нефть и курс рубля по отношению к доллару. А своя платёжная система нам нужна на случай выходок с их стороны. У них до сих пор бомбит, что Крым вернулся в Россию.
Какие негодяи америкосы, рубль нам уронили, цены на нефть нам обвалили, санкции ввели против конкретных лиц и компаний.
Шапочка из фольги не жмёт?
Это еще что! У меня вчера в лифте кто-то кнопки сжег. Говорят, он был подозрительно темнокожий.
И снег в субботу явно их рук дело (серьёзно — я такое от одного россиянина услышал, только, может, он рептилоидов имел в виду).
Мистер рутер, а почему у вас ник такой подозрительный странный?
Дожно быть "Товарищ маршрутизатор".
Вы уж определитесь, а кто как-то неаккуратненько получается.
В часы наименьшей нагрузки на сеть не скучают, а выполняют плановые работы.
Специалисты по кибербезопасности утверждают, что случившееся могло стать результатом учений: «Поскольку „Ростелеком“ сам или через дочерние компании присутствует на территории всей страны, в один узел собирался трафик маршрутов со всей России. Это могло понадобиться, чтобы проверить, какой объем трафика может прокачать один узел в случае отключения, изоляции российского сегмента сети, как, например, в случае с Северной Кореей»
Какой-то специфический выбор для выбора именно объемного трафика ;)
И в тоже время в новостях промелькнуло только это....
http://www.interfax.ru/business/559721
Сбербанк устранил сбой в обслуживании карт Visa
Клиенты банка жаловались, что не могут снять средства с карт в банкоматах и провести платежные операции посредством Visa
Москва. 24 апреля. INTERFAX.RU — Сбербанк России устранил неисправности в обслуживании карт Visa, сообщила пресс-служба банка.
"В результате внедрения новых функциональных возможностей некоторое время наблюдались технические проблемы в работе банковских карт Visa. На текущий момент обслуживание карт восстановлено в полном объеме", — отметил представитель банка.
http://www.rbc.ru/rbcfreenews/5901613d9a794726f1f0d681
Сбой произошел из-за «изменения настройки маршрутизации запросов», — уточняется в сообщении. «Приносим извинения Сбербанку и его клиентам за связанные с этим неудобства», — говорится в сообщении OpenWay.
Выбор трафика верный, более вероятно, что это учения по возможности реализации контроля и поиска неучтённых денежных потоков.
Готовяться ловить тунеядцев, а может кого и покрупнее.
А чтоб не получилось как с законом Яровой, проверяют возможность реализации в деле.
Ну или взяли на работу хакера ,как тут, вот он и тренируется по ночам!
Гхм, предлагаю внимательно прочитать ответ: «Из-за сбоя ПО маршрутизатора некорректно отработали фильтры, которые не пропускают во внешние сети анонсы внутренних статических маршрутов. При этом у ряда внешних операторов отсутствовали фильтры, проверяющие легитимность анонсов, в связи с чем неверная информация разошлась по интернету и нарушила маршрутизацию».
То есть у ростелекома внутри сети есть IP-адреса и AS-номера автономных систем других организаций.
Банальный вопрос, дорогой Ростелеком, зачем они тебе? А какие ещё виртуальные атономки у тебя есть?
То есть у ростелекома внутри сети есть IP-адреса и AS-номера автономных систем других организаций.
Банальный вопрос, дорогой Ростелеком, зачем они тебе? А какие ещё виртуальные атономки у тебя есть?
А это не может быть нужным для поддержки сервисов, для доступ к которым используется IP-адрес?
Например, для гуглового DNS. Прямо в данный момент у меня пинг из Москвы до 8.8.4.4 всего 2 мс, а маршрут содержит всего один узел между сетью моего провайдера и этим хостом. Т.е. явно отзывается сервер расположенный совсем недалеко.
Например, для гуглового DNS. Прямо в данный момент у меня пинг из Москвы до 8.8.4.4 всего 2 мс, а маршрут содержит всего один узел между сетью моего провайдера и этим хостом. Т.е. явно отзывается сервер расположенный совсем недалеко.
google пирится на msk-ix и отдает там свои dns. Да, 8.8.4.4 в Москве и в Нью-йорке — это два разных физических сервера. Но оба — в AS гугла, а не в AS Ростелекома. Чувствуете разницу?
Другое дело, что в контексте последних «сдвигов» в законодательстве я не удивлюсь, если окажется, что dns-резолв для вас будет делать ваш провайдер не глядя на то, к какому серверу вы сделали dns-запрос.
Другое дело, что в контексте последних «сдвигов» в законодательстве я не удивлюсь, если окажется, что dns-резолв для вас будет делать ваш провайдер не глядя на то, к какому серверу вы сделали dns-запрос.
Только не говорите, что не знаете о том, что на М9 стоят сервера google!
Далее: вспомните закон о хранении персональных данных на территории России — понятно, что все, кто его выполняет имеют сервера здесь и маршрут к ним отличается от маршрута из Японии.
Далее: вспомните закон о хранении персональных данных на территории России — понятно, что все, кто его выполняет имеют сервера здесь и маршрут к ним отличается от маршрута из Японии.
Берем AS всего мира, вычитаем AS РФ, получаем кол-во виртуальных AS у Ростелекома :)
В целом, сбой в сети «Ростелекома» (никто не утверждает наверняка, что это было сделано целенаправленно, называя проблему «сбоем») затронул сети 36 организаций. Префиксы этих организаций с указанием владельцев перечислены ниже.
В первоисточнике для https://arstechnica.com/security/2017/04/russian-controlled-telecom-hijacks-financial-services-internet-traffic/ ссылка на https://bgpmon.net/bgpstream-and-the-curious-case-of-as12389/ где так же в списке еще есть
Below the list of affected networks (other Rostelecom networks excluded)
49002 Federal State Unitary Enterprise Russian
41268 LANTA Ltd
5553 State Educational Institution of Higher
8291 The Federal Guard Service of the Russian
9162 The State Educational Institution of Hig
15835 ROSNIIROS Russian Institute for Public N
15468 38, Teatralnaya st.
Интересно 1546 38, Teatralnaya st. это Публичные акционерные общества КФ ОАО "РосТелеком" — г.Калуга, ул.Театральная,38?
Да, AS 15468 (KLGELECS-AS) — Калуга, Ростелеком:
https://www.ripe.net/ -> Search IP address or ASN -> as15468
https://apps.db.ripe.net/search/query.html?searchtext=as15468#resultsAnchor
aut-num: as15468 org: ORG-JR8-RIPE as-name: KLGELECS-AS descr: 38, Teatralnaya st. descr: Kaluga, Russia remarks: == our peer is: AS44237 CenterTelecom interregional backbone== ... organisation: ORG-JR8-RIPE org-name: PJSC Rostelecom org-type: LIR ... role: Kaluga Elecs NOC address: OJSC Rostelecom ... kaluga.ru
Также:
http://as-rank.caida.org/?mode0=as-info&mode1=as-table&as=15468&data-selected-id=42
http://www.cidr-report.org/cgi-bin/as-report?as=15468&view=2.0
http://bgp.he.net/AS15468
История маршрутов в BGPlay: https://stat.ripe.net/widget/bgplay#w.resource=as15468
Ну что… Надо начинать бэкапить себе заграничный Интернет на всякий случай…
А вот этот роутинг внутри России через Китай тоже порадовал.
А вот этот роутинг внутри России через Китай тоже порадовал.
пиринговые войны продолжаются? ужас…
Рутинг.
Помнится когда вышла локализация игры Айон там тоже были некие проблемы с коннектом к игровым серверам (пинг, дисконекты, потери пакетов). Позже, после долгих обсуждений с техподдержкой, прогонов бесчисленных tracert и пингов от клиента к серверу и обратно выяснилось что маршрут от клиента из Подмосковья к серверам в Москве шел так же через «Китай» (вроде бы те же Франкфурт и Стокгольм). Я так понимаю для наших провайдеров это вообще нормальное явление.
UFO just landed and posted this here
Интернет давно перерос масштабы гиковского междусобойчика и теперь мы все расплачиваемся за период романтического энтузиазма, когда и родились основные протоколы интернета. Это и огромное количество спама, корень которого в протоколах почты и отравление кэшей DNS и подмена их ответов и уже не раз происходившие ошибки маршрутизации. Фактом является, то что любое неосторожное движение или хуже, намеренный саботаж среди провайдеров средней руки может создать серьёзные проблемы для всего интернета. Попытки прикрутить к старым протоколам шифрование и защиту до сих пор остаются попытками хотя потребность созрела давно. Где DNSSEC? Где HTTP 2?
Битва за интернет проигрывается корпорациям и правительствам. Это видит любой кто был в интернете хотя бы в начале 2000-х
Битва за интернет проигрывается корпорациям и правительствам. Это видит любой кто был в интернете хотя бы в начале 2000-х
Вот так всегда: начали за здравие, а закончили DNSSEC.
Вместо того, чтобы разобраться в мешанине старых протоколов, давайте сверху наворачивать новые.
Никто не собирается разбираться в старых протоколах. Корпорациям это не нужно. Провайдерам услуг и подавно. Как показала практика последних лет сколько данные не сливай они только плечами пожимают. Крупные игроки погрязли в мелких войнах друг с другом. Тот же Mozilla упорствует во внедрении webp. Чего ради?
История точно такая же как с IPv6. Про него говорят уже сколько лет? Каждые пол года статья о том, что у очередного LIR'a закончились адреса. Сейчас уже даже SoHo железо поддерживает IPv6, а воз и ныне там.
По моему хватит ворошить старые протоколы, которые создавались во времена когда компьютеры были большие, а программы маленькие. Нужно решать проблему на корню, а не латать дыры пятью разными несовместимыми способами. Если бы не Google то мы бы HTTP 2 ещё лет 15 ждали в браузерах.
История точно такая же как с IPv6. Про него говорят уже сколько лет? Каждые пол года статья о том, что у очередного LIR'a закончились адреса. Сейчас уже даже SoHo железо поддерживает IPv6, а воз и ныне там.
По моему хватит ворошить старые протоколы, которые создавались во времена когда компьютеры были большие, а программы маленькие. Нужно решать проблему на корню, а не латать дыры пятью разными несовместимыми способами. Если бы не Google то мы бы HTTP 2 ещё лет 15 ждали в браузерах.
Бинарный гипертекстовый протокол, не умеющий нормально работать с reverse proxy и не работающий без шифрования? Было бы неплохо, если бы мы его ещё лет 30 не увидели.
Современные программисты — а в большей степени их менеджеры — очень любят вдохновляться тем фактом, что во время оно оперативной памяти было 640 Кб, а сейчас 8 Гб. В результате чего даже на телефонах 1 Гб — это уже слишком мало, а на серверах память уже терабайтами начинают считать. А делают все эти устройства все примерно то же самое, только в тысячу раз неэффективнее.
Старые протоколы создавались в расчете на эффективность, а новые — в расчете на закон Мура. И в результате в IPv6 снова приходится в случае необходимости заблокировать доступ с одного адреса банить всю сеть, потому что а) SLAAC и б) таблица отдельных IPv6-адресов ни в какую таблицу в памяти не влезет никогда. При этом в IPv4 банить подсетями стало не модно ещё 10-15 лет назад. Легко видеть, что с теоретико-протокольной точки зрения у нас должен был быть прогресс, а с точки зрения решаемых практических задач случился регресс.
В этом и проблема современных протоколов: когда инженеры, задолбавшиеся ловить утечки памяти и воображающие себе гигабайты RAM, пишут протоколы с расчетом реализовывать их потом на Java и C#, в итоге каждый из десятка этих протоколов начинает требовать эти гигабайты себе единолично, а задачи по этому решает все те же, что и старый добрый протокол 1979 года о 2 мбайт памяти. И еще хорошо, если решает не хуже.
Современные программисты — а в большей степени их менеджеры — очень любят вдохновляться тем фактом, что во время оно оперативной памяти было 640 Кб, а сейчас 8 Гб. В результате чего даже на телефонах 1 Гб — это уже слишком мало, а на серверах память уже терабайтами начинают считать. А делают все эти устройства все примерно то же самое, только в тысячу раз неэффективнее.
Старые протоколы создавались в расчете на эффективность, а новые — в расчете на закон Мура. И в результате в IPv6 снова приходится в случае необходимости заблокировать доступ с одного адреса банить всю сеть, потому что а) SLAAC и б) таблица отдельных IPv6-адресов ни в какую таблицу в памяти не влезет никогда. При этом в IPv4 банить подсетями стало не модно ещё 10-15 лет назад. Легко видеть, что с теоретико-протокольной точки зрения у нас должен был быть прогресс, а с точки зрения решаемых практических задач случился регресс.
В этом и проблема современных протоколов: когда инженеры, задолбавшиеся ловить утечки памяти и воображающие себе гигабайты RAM, пишут протоколы с расчетом реализовывать их потом на Java и C#, в итоге каждый из десятка этих протоколов начинает требовать эти гигабайты себе единолично, а задачи по этому решает все те же, что и старый добрый протокол 1979 года о 2 мбайт памяти. И еще хорошо, если решает не хуже.
Извините, но вы тут пишете откровенную глупость. Для разбора бинарных протоколов нужно меньше памяти, чем для разбора текстовых. Они по определению компактнее. Ну а то что современный мир где не только правительство, но и каждый вшивый провайдер желает посмотреть, чего я там по сети гоняю — требует шифрования это уже издержки современного мира. Если стоит выбор между купить ещё оперативки или наслаждаться подменой данный и слежкой, то я куплю оперативку.
А по поводу IPv6 просто почитайте документацию.
А по поводу IPv6 просто почитайте документацию.
Не извиню, потому что это не я пишу глупости, это вы читаете не написанное мной, а что-то из своей головы.
Поэтому рассмотрим не общий случай, а случай HTTP/2.
В современном WWW тела HTTP-ответов (то есть, контент) весят на порядки больше, чем заголовки. Web-страница, на которой мы сейчас общаемся, весит около 3,5 мегабайт и формируется 65 HTTP-запросами, что даёт нам около 55 килобайт на каждый ответ (и около 15 килобайт в среднем после gzip-сжатия), в то время как заголовки каждого что запроса, что ответа весят примерно 200-400 байт. И в доброй половине случаев это именно текст: HTML, CSS, Javascript, JSON, XML. С точки зрения памяти, бинаризация заголовков — это экономия на спичках.
Некоторая экономия могла бы быть разве что на стороне контент-сервера, который не парсит данные (включая тела POST- и других запросов), но вот беда: HTTP/2 на самом деле не вмешивается в сами заголовки, ограничиваясь сжатием и бинаризацией лишь формата передачи старого доброго текста. Ввиду этого что на сервере, что на клиенте памяти требуется ровно столько же, сколько и в HTTP/1. Более того, HTTP/2 добавляет обязательный overhead на хранение TLS-сессии, так что памяти требуется даже больше, чем в HTTP/1.
В обмен на эту экономию HTTP/2 нельзя диагностировать и отлаживать из обычной консоли tcpdump'ом, нужно, по совету его авторов, брать GUI-приложение. Это уже не говоря о том, что де-факто обязательное шифрование делает эту отладку ещё более трудоёмкой, а в ряде случаев вообще невозможной. То есть это не просто экономия на спичках, это, знаете, как в Советском Союзе: когда газ в квартирах оплачивался фиксированной суммой без счётчиков, люди, чтобы не тратить спички, просто не тушили конфорки и весь день жгли газ.
И да: можно было бы использовать для контента сжатие, но вот беда: ввиду всё того же шифрования и атак на него глава про сжатие в спецификации HTTP/2 написана эзоповым языком, предъявляет к реализациям протокола требование отличать конфиденциальные данные от неконфиденциальных (что вообще непонятно, как делать) и изобилует термином MUST NOT, что на практике будет в большинстве случаев приводить либо к отсутствию сжатия там, где оно надо, либо к компрометации данных там, где их нужно было защищать.
Если правительство страны, где вы живёте, захочет узнать, чем вы занимаетесь, оно это узнает. Если вам это не нравится, вам нужно либо выбрать другое правительство, либо изменить род деятельности, либо сменить страну проживания. Повальное внедрение шифрования приводит к компрометации этого самого шифрования и на выходе обеспечивает лишь, в лучшем случае, невозможность тайного досмотра. В качестве побочного эффекта от неуклюжих действий правительства страдают невинные люди.
А по поводу IPv6 вам, очевидно, просто нечего было сказать.
Для разбора бинарных протоколов нужно меньше памяти, чем для разбора текстовых. Они по определению компактнее.Заявление про «компактность по определению» в общем случае фактически неверно. Простой пример: запись числа «ноль» в текстовом протоколе JSON («0») занимает 1 байт, в то время как в его бинарной версии BSON она занимает 11 байт.
Поэтому рассмотрим не общий случай, а случай HTTP/2.
В современном WWW тела HTTP-ответов (то есть, контент) весят на порядки больше, чем заголовки. Web-страница, на которой мы сейчас общаемся, весит около 3,5 мегабайт и формируется 65 HTTP-запросами, что даёт нам около 55 килобайт на каждый ответ (и около 15 килобайт в среднем после gzip-сжатия), в то время как заголовки каждого что запроса, что ответа весят примерно 200-400 байт. И в доброй половине случаев это именно текст: HTML, CSS, Javascript, JSON, XML. С точки зрения памяти, бинаризация заголовков — это экономия на спичках.
Некоторая экономия могла бы быть разве что на стороне контент-сервера, который не парсит данные (включая тела POST- и других запросов), но вот беда: HTTP/2 на самом деле не вмешивается в сами заголовки, ограничиваясь сжатием и бинаризацией лишь формата передачи старого доброго текста. Ввиду этого что на сервере, что на клиенте памяти требуется ровно столько же, сколько и в HTTP/1. Более того, HTTP/2 добавляет обязательный overhead на хранение TLS-сессии, так что памяти требуется даже больше, чем в HTTP/1.
В обмен на эту экономию HTTP/2 нельзя диагностировать и отлаживать из обычной консоли tcpdump'ом, нужно, по совету его авторов, брать GUI-приложение. Это уже не говоря о том, что де-факто обязательное шифрование делает эту отладку ещё более трудоёмкой, а в ряде случаев вообще невозможной. То есть это не просто экономия на спичках, это, знаете, как в Советском Союзе: когда газ в квартирах оплачивался фиксированной суммой без счётчиков, люди, чтобы не тратить спички, просто не тушили конфорки и весь день жгли газ.
И да: можно было бы использовать для контента сжатие, но вот беда: ввиду всё того же шифрования и атак на него глава про сжатие в спецификации HTTP/2 написана эзоповым языком, предъявляет к реализациям протокола требование отличать конфиденциальные данные от неконфиденциальных (что вообще непонятно, как делать) и изобилует термином MUST NOT, что на практике будет в большинстве случаев приводить либо к отсутствию сжатия там, где оно надо, либо к компрометации данных там, где их нужно было защищать.
современный мир [..] требует шифрования«Современный мир» не требует шифрования, его требуют определённые прикладные задачи, в то время как ряд других задач шифрования не требует. Именно по этой причине авторы HTTP/2 в конечном счёте не стали включать требования к шифрованию в спецификацию. Отсутствие поддержки HTTP/2 over TCP — это самодеятельность корпораций, выпускающих браузеры, что также многое говорит нам о характере развития протоколов в последние годы.
не только правительство, но и каждый вшивый провайдер желает посмотреть, чего я там по сети гоняюПомните эту картинку?
Если правительство страны, где вы живёте, захочет узнать, чем вы занимаетесь, оно это узнает. Если вам это не нравится, вам нужно либо выбрать другое правительство, либо изменить род деятельности, либо сменить страну проживания. Повальное внедрение шифрования приводит к компрометации этого самого шифрования и на выходе обеспечивает лишь, в лучшем случае, невозможность тайного досмотра. В качестве побочного эффекта от неуклюжих действий правительства страдают невинные люди.
А по поводу IPv6 вам, очевидно, просто нечего было сказать.
<совпадение?>
А почему у Ростелекома логотип похож на ухо?
</совпадение?> :)
Sign up to leave a comment.
«Ростелеком» стал причиной крупного сбоя в работе известных финансовых сервисов