Comments 73
Вопрос от не-специалиста. Выходит что собрав такие данные о пользователях, можно будет сопоставить их с данными куда пользователь ходил и выявить как минимум те XXX ( слово из трех букв) которые еще не выявили и потом заблочить?
В том числе
А с двойным ХХХ так получиться? (Тоже неспециалист)
куда ходили пользователи чебурнета и натоптали там, все уже и так заблочили:)
в россии нужно развивать строгую гигиену - люди, которые никогда не выходили из интернета, и никогда не заходили в чебурнет без трех букв (не понимаю почему вы стремаетесь писать открыто, но раз вы так далете, наверно знаете зачем, вы там живете все-таки) - это одна группа людей, назовем их "не заразными", и вторая группа людей, которые туда ходят без презерватива...
Это всё нужно для того, чтобы когда пользователь использует средства модификации сетевых пакетов (для просмотра ютуба, например), можно было потом сопоставить логи ТСПУ с логами маршрутизаторов провайдера, которые стоят уже после ТСПУ. Потому что это позволит выявить, каким именно образом трафик был модифицирован (ну и, соответственно, накатить нужный апдейт на ТСПУ, чтобы этот метод перестал работать). Ведь DPI-дурилки дурят только ТСПУ, а последующее оборудование (маршрутизаторы провайдера) должны получать правильный трафик, иначе они не смогли бы его правильно обрабатывать.
можно было потом сопоставить логи ТСПУ с логами маршрутизаторов провайдера, которые стоят уже после ТСПУ. Потому что это позволит выявить, каким именно образом трафик был модифицирован
Звучит очень странно. Сетевые пакеты модифицирует сетевое оборудование пользователя, а для выявления модификаций сравнивают почему-то логи маршрутизаторов провайдера и ТСПУ. Пользователь что, MITM для провайдера и ТСПУ?
Оборудование пользователя модифицирует трафик таким образом, что в зависимости от хопа, через который проходит трафик, разному промежуточному оборудованию подсовываются разные варианты:
ТСПУ получает искривлённый пакет;
оборудование провайдера - неискривлённый.
Если взять логи второго и сравнить с логами первого, то можно вычислить просачившийся трафик.
Оборудование пользователя модифицирует трафик таким образом, что в зависимости от хопа, через который проходит трафик, разному промежуточному оборудованию подсовываются разные варианты
Это вообще звучит фантастически. Отправитель IP пакета может сделать так, чтобы разные маршрутизаторы на пути пакета видели разное содержимое пакета? Может примеры какие-то есть?
В модификаторе пакетов специальный параметр есть, который устанавливает, через какое количество хопов искривлённый пакет должен перестать передаваться (ttl, auto-ttl).
В модификаторе пакетов специальный параметр есть, который устанавливает, через какое количество хопов искривлённый пакет должен перестать передаваться
И как это помогает сделать так, чтобы на разных маршрутизаторах по пути представить разное содержимое одного и того же пакета?
Он просто не передаётся дальше, вот и всё. Его задача - попасть на ТСПУ, а потом он больше не нужен.
А откуда конечный пользователь знает, какое количество хопов нужно выставить для ТСПУ?
Ещё раз - каким образом это всё позволяет сделать так, чтобы на разных маршрутизаторах по пути представить разное содержимое одного и того же пакета?
Бред какой-то несёте. Упомянутый fake request mode в goodbyedpi не делает пакет магическим. Наличие ТСПУ в локальной сети провайдера, в подавляющем большинстве сетевых конфигураций, никак не поможет узнать серый ip абонентов. Какие-то ещё сопоставления айпишников до и после ТСПУ, поиск трафика на ТСПУ по логам dhcp сервера провайдера (фактически, именно это и пытается выбить ркн) - одна история прохладнее другой.
Не нужно представлять разное содержимое одного и того же пакета. На ТСПУ отправляется искажённый пакет, дальше он просто не проходит, потому что у него ttl маленький. После этого пакета ТСПУ пропускает остальные пакеты. Один пакет (фейковый, с рукопожатием) - для ТСПУ. Остальные - нефейковые.
А для чего, по-вашему, ещё может быть нужен доступ к логам провайдера? Наличие информации о комбинации уникального (серого) IP-адреса и MAC-адреса не даёт ровным счётом ничего в плане идентификации. Чтобы по ней идентифицировать конкретного абонента, нужно знать:
по какому адресу расположен коммутатор, куда прилетают эти IP \ MAC;
номер порта на коммутаторе, куда воткнут кабель;
в какую квартиру этот кабель приходит.
Ничего из этого РКН у провайдеров не просит.
Если моя гипотеза неверна, изложите свою.
Один пакет (фейковый, с рукопожатием) - для ТСПУ. Остальные - нефейковые.
И все эти пакеты, как фейковые, так и не фейковые проходят и через ТСПУ и через маршрутизатор провайдера. Зачем их сравнивать и зачем для этого логи dhcp провайдера - остаётся вопросом.
А для чего, по-вашему, ещё может быть нужен доступ к логам провайдера?
Чтобы привязать конкретный трафик на ТСПУ к конкретному договору с провайдером, а значит и к пользователю.
Чтобы по ней идентифицировать конкретного абонента, нужно знать
Чтобы по ней идентифицировать конкретного абонента для серых ip, нужно заставить провайдера дампить и выгружать NAT таблицу, помимо dhcp логов.
Ничего из этого РКН у провайдеров не просит.
Откатает на белых ip и попросит.
И все эти пакеты, как фейковые, так и не фейковые проходят и через ТСПУ и через маршрутизатор провайдера.
Фейковый доходит до ТСПУ и ликвидируется, потому что у него ttl специально указан такой, чтобы он дальше ТСПУ не прошёл.
Чтобы по ней идентифицировать конкретного абонента для серых ip, нужно заставить провайдера дампить и выгружать NAT таблицу, помимо dhcp логов.
NAT-таблица ничего не даст. РКН просто узнает IP-адрес во внутренней сети. Чтобы по нему идентифицировать абонента, нужен доступ к биллингу. А часть ТСПУ и так видит этот внутренний адрес, потому что и так стоит прямо во внутренней сети.
Зачем их сравнивать и зачем для этого логи dhcp провайдера - остаётся вопросом.
Человек внизу выложил комментарий от РКН https://habr.com/ru/news/883806/comments/#comment_27943854 - они пишут, что им вообще MAC-адреса не нужны, а вся эта затея появилась только из-за того, что ТСПУ не может нормально блокировать трафик при одновременном использовании абонентом IPv4 и IPv6. И им нужно, чтобы провайдер им сообщал, какому IPv6 соответствует IPv4.
Возможно, при выделении просто двух IPv4 одному абоненту ТСПУ тоже испытывает трудности с тем, чтобы блокировать такой трафик. Поэтому и для обычного IPv4 тоже просят логи. И им всё равно, белый им пришлют айпишник или серый - главное, чтобы он относился к тому же трафику (того же абонента), который проходит через ТСПУ.
Фейковый доходит до ТСПУ и ликвидируется, потому что у него ttl специально указан такой, чтобы он дальше ТСПУ не прошёл.
И что? Как логи dhcp сервера помогут что-то проанализировать с этим пакетом?
ТСПУ не может нормально блокировать трафик при одновременном использовании абонентом IPv4 и IPv6
Не вижу ничего подобного в комментарии по ссылке.
И что? Как логи dhcp сервера помогут что-то проанализировать с этим пакетом?
Например, фейковый пакет был отправлен с одного IP, а остальной трафик - с другого. В итоге с точки зрения ТСПУ со второго IP соединение вообще не инициировалось, и оно не анализируется. А если провайдер подтвердит, что оба IP выданы одному абоненту, то РКН узнает, как через второй IP просочился трафик.
Не вижу ничего подобного в комментарии по ссылке.
Там чуть ниже:
Принадлежность трафика пользователю определяется по сетевому адресу. В связи с внедрением на сетях связи нового стандарта сетевого адреса (так называемого IPv6) и одновременного использования «старого» стандарта IPv4, операторы связи стали использовать технологию двойной адресации Dual-Stack. Трафик между пользователем (пользовательским приложением) и ресурсом идет по сетевым адресам разных стандартов. Переход на упомянутую технологию приводит к тому, что ТСПУ не может однозначно идентифицировать принадлежность трафика конкретному пользователю. Это приводит к снижению эффективности выявления трафика, направленного к противоправным ресурсам, и его ограничение. В целях решения обозначенной проблематики проектом приказа предусмотрена обязанность операторов связи передавать в Роскомнадзор информацию о сетевых адресах, выделенных оператором связи абоненту при оказании услуги по предоставлению доступа к сети «Интернет с использованием технологии Dual-Stack.
Не понятно, что за дополнительная информация появляется у провайдера, что её не было на ТСПУ и от туда РКН её не смог забрать?
Если ТСПУ пропустил трафик, то никак не определить, что этот трафик был модифицирован. Потому что если бы это можно было определить, то ТСПУ его бы и не пропускал.
Эээ, а как определить, что трафик был модифицирован?
Кажется кто-то из нас не понимает, как работает эта штука.
Ну вот осенью РКН же играл в кошки-мышки с нами. И куча работающих в сентябре модификаций стала определяться и блокаться. Грубо говоря, если раньше работала смена регистра букв, то теперь ТСПУ это сечёт.
Меня тоже интересует, что станет с модификаторами пакетов, когда этот закон примут.
Мне казалось, что измененный таким образом трафик один и тот же и для ТСПУ, и для оборудования операторов. Но только если оборудование операторов это просто труба, по которой текут данные и ему без разницы, то для ТСПУ такое изменение критично, потому что он занимается анализом пакетов.
Оборудованию провайдера ведь надо знать, куда направлять трафик. Ну то есть, если трафик предназначается для ютуба, то провайдер должен его отправить на ютуб. Берём логи провайдеров и сравниваем с логами ТСПУ:
если совпадает айпишник с айпишниками гугла, то проверяем поле Host на ТСПУ;
если Host не запрещённый, то направляем на ручную проверку (возможно, был использован модификатор пакетов).
Через месяц после внедрения можно будет через даркнет(а то и через телеграм бот, ага) "вычислять по айпи", как сейчас можно купить информацию о распознавании номеров машины дорожными камерами, или распознавание лиц в москве подъездными камерами или рейсы на которые ты регистрировался и в общем то ВСЮ персональную инфу которую когда-либо государство на тебя собирало, по тому что "государственное" всегда воспринимается как "бесхозное" и постоянно используется для получения наживы по методу "тащи с работы каждый гвоздь, ты здесь хозяин, а не гость" и это речь не про нашу страну конкретно, а про любую
Все идеи РКН от лукавого. Когда придумали блокировку сайтов, говорили о борьбе с терроризмом, наркотиками, детской порнографией, а по факту ресурсы используются для сведения счетов с владельцами Ютуба. Черные ящики ставили, для "повышения устойчивости российского интернета", а по факту только понизили его - создание единой точки отказа и кривые руки владельцев этих ящиков регулярно приводят "к временному ухудшению связанности сети".
А если провайдер выдает серые адреса, тогда смысл всей этой затеи?
Так ТСПУ же стоит внутри сети провайдера, поэтому тоже видит серые адреса.
Возможно, но не факт. У меня провайдер выдает то белые, то серые адреса при новой сессии PPPoE. Смысл ему ставить 2 ТСПУ, если можно поставить один на шлюзе в интернет?
Да нет особой разницы, белый айпишник или серый. Если серый, то по номеру порта определяется. Трафик же как-то разруливается из локальной сети наружу - вот точно так же и определяется, чей он (даже если 100 человек на одном белом айпи).
Логичнее было бы Маки собирать? Или нет?
"В компании пояснили, что в 95% случаев подключения клиентов‑физлиц к мобильным сетям через маршрутизатор широкополосного удалённого доступа (BRAS) нет возможности точно определить, что именно они используют для выхода в интернет: компьютер, ноутбук или смартфон."
...или роутеры с симкой.
Интересно, допустим, есть симка для роутеров/мобильных модемов и ноутбуков (точнее, тариф), а есть - для смартфонов. И использовать тариф для смартфонов в мобильном модеме уже не получается, оператор как-то это узнает.
Мне казалось, что симка сама по себе прекрасный идентификатор трафика, потому что она зарегистрирована на конкретного человека.
Так-то понятно, что этот закон принимают для усиления цензуры. Непонятно только, как будет это работать.
Так РКН им и ответил, что информация об оборудовании за роутером им не нужна. Только о самом роутере пользователя.
И почему только МТС отреагировал? А остальные мобильные операторы почему молчат? Или у них уже все настроено, что надо настроить?
"«Ростелеком» не видит больших проблем в предоставлении информации, которую запрашивает Роскомнадзор, и исполнит положения проекта в полном объёме, сообщили СМИ в компании".
А это не у него в последнее время было много аварий? Так может, то не аварии были, а оборудование свое отлаживали?
"В своем отзыве на приказ РКН в МТС указали, что те сведения, которые оператор получает об абоненте не из договора, в том числе адрес установки оборудования, абонентские номера, идентификатор пользовательского оборудования и другие данные, позволяющие идентифицировать абонента, сведения о соединениях, трафике и платежах, представляют собой тайну связи. Предоставлять третьим лицам такие сведения оператор может только с согласия абонента, если иное не предусмотрено законом".
Настораживает...
"«Часть предложений, в том числе от компании МТС будут учтены. Документу предстоит пройти этап подготовки заключения ОРВ (оценки регулирующего воздействия), регистрации в Минюсте. После этого он будет опубликован на портале pravo.gov.ru», — заявили в РКН.".
И сколько времени на это уйдет? К 1-му марта успеют? (Может, Кинетик не зря назвал именно эту дату?)
И почему только МТС отреагировал? А остальные мобильные операторы почему молчат?
Видимо, хотя бы одно яйцо у них осталось, пусть они и убрали его с логотипа.
У МТС заканчиваются свободные деньги. МТС давно уже платит дивиденды за счет заемных средств, а сейчас, с учетом высоких ставок, обслуживать большой долг стало очень накладно. Потому МТС очень не хочется тратить деньги на новые инициативы РКН. Так что, это письмо в защиту акционеров МТС, клиенты и яйца здесь не причем.
Тут вся штука в этом самом ID который "уникальный идентификатор оборудования" - то есть MAC раутера или IMEI телефона. Сейчас, чтобы понять куда пользователь ходит, нужно обращаться к оператору - и это долгий процесс.
После внедрения такой штуки к оператору обращаться больше не нужно - все достается из ТСПУ и переданных данных. Все эти ваши куй-бай-дик-пик-ай вокруг которых вы прыгаете и шумите тут ни при чем, на них всем глубоко пофиг.
По сути, это такой "большой брат" который следит за всеми и цель этой системы понять "а кто это у нас такой умный воооон туда ходит", с точностью до номера телефона и адреса регистрации практически в онлайн-режиме без обращения к операторам/провайдерам. Точнее провайдер присылает "а чей это IP" а с ТСПУ приходит "а куда этот IP ходит", дальше примитивный JOIN и все - теперь известно кто и куда и никаких запросов в провайдерам.
А еще это позволит например автоматически выявлять по профилям использование новых эндпоинтов публичных VPN и анонимайзеров и блочить их в течение суток - появился новый адрес на который толпой пошли сотни и тыщи юзеров - сработал триггер - сработал скан - положительный сигнал "это ВПН" - автоматическая блокировка на ТСПУ. Организационно и технически красивое и элегантное решение.
Точнее провайдер присылает "а чей это IP" а с ТСПУ приходит "а куда этот IP ходит", дальше примитивный JOIN и все - теперь известно кто и куда и никаких запросов в провайдерам.
Всё верно, и никакие маки в этой схеме не нужны.
А еще это позволит например автоматически выявлять по профилям использование новых эндпоинтов публичных VPN и анонимайзеров и блочить их в течение суток - появился новый адрес на который толпой пошли сотни и тыщи юзеров - сработал триггер - сработал скан - положительный сигнал "это ВПН" - автоматическая блокировка на ТСПУ. Организационно и технически красивое и элегантное решение.
Так это же и сейчас прекрасно можно сделать. Никакая доп. инфа о пользовательском оборудовании для этого не нужна.
в-целом сюда можно добавить прослойку ВСЕГДА ходить на какой-н 1 прокси сервак, а с него уже выходить куда надо...
Всё верно, и никакие маки в этой схеме не нужны.
Сейчас в этом нет онлайновости и много всякой процессуальной суеты. Вы не можете мониторить конкретные группы пользователей "на лету", только постфактум. Если вам нужно знать куда ходил абстрактный Алексей Квадратный, вы должны отправить оператору запрос "а выдай ка мне с какого IP ходил вот оный абонент". А если хотите трекать его постоянно - вам придется регулярно ходить с такими запросами. С вводом обсуждаемого механизма в этом больше нет нужды, оператор будет регулярно см отправлять все что нужно. Причем не только про Алексея, Василия или Федора, но про всех. Можно собирать профили пользователей, отслеживать их активность на протяжении сезонов и времени суток и много чего еще.
У - удобно. Хватило бы только место это все схоронить, но всю эту бигдикдату сделали же, что бы ее не использовать на благо всего хорошего против всего плохого?
Но можно придумать и более интересные и антидемократические применения. Например если внезапно куча оборудования какого-нибудь абстрактного вендора почему-то начнет внезапно ломиться куда-то, это вполне себе сигнал к тому что это может быть DDoS через какой-нибудь 0-day, или сработавшая закладка приехавшая через supply chain - и тогда это вполне себе станет видно.
"«Ростелеком» не видит больших проблем в предоставлении информации, которую запрашивает Роскомнадзор, и исполнит положения проекта в полном объёме, сообщили СМИ в компании".
Раз "Ростелеком" уже готов к исполнению этого приказа, то, может, и запросить информацию у его специалистов о том, как все это будет работать. Должны ведь абоненты знать о рисках, которые могут их ожидать. Даст он такой комментарий или нет?
ТСПУ не может однозначно идентифицировать принадлежность трафика конкретному пользователю, что приводит к снижению эффективности ограничения трафика к противоправным ресурсам.
Правильно ли понимаю, что трафик [не] ограничивается в зависимости от конкретного пользователя? Мне казалось, что если ресурс противоправный, то трафик надо ограничивать невзирая...
В «ЭР-Телекоме» отказались от комментариев. РБК направил запросы в «ВымпелКом» (бренд «Билайн») и «МегаФон».
https://www.rbc.ru/technology_and_media/19/02/2025/67b4bf069a79472b07661dab
Интересно будет ознакомиться с ответами.
А молодцы они, всё-таки. МТС. Остальные вон молчат в тряпочку.
Может, их просто уже так прижало, что дальше молчать и терпеть больше сил нет. Остальные все молчат, что подозрительно. А "Ростелеком" так и вовсе бодро рапортует о готовности исполнять приказ.
В любом случае, МТС спасибо, что обратили внимание на проблему. Еще бы это хоть как-то помогло остановить все происходящее...
Мне очень хотелось бы услышать от эксперта (юриста и связиста) о том, как практически собираются исполнять этот приказ, когда его примут, и что это будет означать для простого пользователя. Чтобы заранее оценить все риски.
Кто-нибудь вот этот документ читал?
Сводка поступивших предложений по итогам публикации текста проекта 02/08/12-24/00153276.docx
Выйти на него можно через карточку проекта, если заглянуть в пункт "Информация по этапу" - "Сводка предложений".
Я скопирую оттуда интересное, из графы "Комментарии разработчика" (так понимаю, что это РКН):
В пункте 2 проекта приказа конкретизуется перечень информации, позволяющей идентифицировать средства связи и пользовательское оборудование (оконечное оборудование) в сети «Интернет», предоставление сведений о фамилии, имени и отчестве абонентов, адресах абонентов или адресах установки оконечного оборудования, абонентских номерах сведений из баз данных систем расчета за оказанные услуги связи, в том числе о соединениях, трафике и платежах абонента проектом приказа не предусмотрено. Таким образом, предоставление сведений, составляющих тайну связи, проектом приказа не предусматривается.
В рамках подпункта а) пункта 2 проекта приказа необходимо предоставление пула IP-адресов, используемого оператором связи на территории субъектов Российской Федерации (город, район, округ, т.д.) с привязкой номера ТСПУ, через который проходит трафик данных IP-адресов. Адреса могут быть как публичные («белые»), так и непубличные («серые») в зависимости от места установки ТСПУ.
Идентификатор в данном случае обозначает обезличенный номер записи связки IPv4/IPv6, присвоенный оператором связи.
В пункте 2 проекта приказа конкретизуется перечень информации, позволяющей идентифицировать средства связи и пользовательское оборудование (оконечное оборудование) в сети «Интернет», предоставление сведений о фамилии, имени и отчестве абонентов, адресах абонентов или адресах установки оконечного оборудования, абонентских номерах сведений из баз данных систем расчета за оказанные услуги связи, в том числе о соединениях, трафике и платежах абонента проектом приказа не предусмотрено. Таким образом, предоставление сведений, составляющих тайну связи, проектом приказа не предусматривается.
Информация о соотнесении IP-адресов и субъектов Российской Федерации необходима для эффективного противодействия угрозам сети связи общего пользования. Вместе с тем пункт скорректирован.
В целях выполнения требований приказа отсутствует необходимость идентификации отдельного пользовательского оборудования. Требуются сведения о локализации выделяемого пользователям адресного пространства по субъектам Российской Федерации, а также сведения о выделяемых связках IPv4 и IPv6 адресов (Dual-Stack). Дополнительно отмечается, что не указаны предпосылки разделения в приказе требований по предоставлению данных по мобильным и фиксированным сетям.
В целях выполнения требований приказа отсутствует необходимость идентификации отдельного пользовательского оборудования. Требуются сведения о локализации выделяемого пользователям адресного пространства по субъектам Российской Федерации, а также сведения о выделяемых связках IPv4 и IPv6 адресов (Dual-Stack). Идентификация отдельных пользователей не требуется. Вместе с тем пункт скорректирован.
Оборудование ТСПУ – часть системы, являющейся объектом КИИ 1 категории, в связи с чем подключение должно осуществляться по зашифрованному сертифицированными криптографическими средствами каналу связи. Технически автоматизированная передача данных будет обеспечена сервисом API с моделью данных, приведенной в приказе.
Информация о соотнесении IP-адресов и субъектов Российской Федерации необходима для эффективного противодействия угрозам сети связи общего пользования.
Для эффективного противодействия угрозам сети связи общего пользования требуется обеспечение незамедлительной передачи данных по подпункту «г» п. 2 Проекта приказа.
Определение в проекте приказа вида сетевого протокола считаем избыточным. Подключение будет через API, его описание будет представлено при проведении мероприятий по подключению операторов связи.
12.1) ID назначается оператором связи, IPv6 может быть использован в качестве идентификатора.
12.2) В случае отсутствия TTL на мобильной сети связи, его можно не указывать.
12.3) В случае отсутствия продления в Operation, его можно не отражать.
12.4) Сокращение возможно, использование «::» предусмотрено в соответствии со стандартами RFC.
Определение порядка уведомления оператора связи надлежаще доставлена считаем избыточным. Передача сведений будет осуществляться через API, при первичном подключении и в случае выявления отклонений будет проводится взаимодействие с оператором связи по отладке передачи данных.
Срок, установленный проектом приказа обусловлен необходимостью принятия Роскомнадзором мер реагирования на угрозы устойчивости, безопасности и целостности функционирования на территории Российской Федерации сети «Интернет» и сети связи общего пользования.
Увеличение срока на более длительный период предоставления оператором связи в Роскомнадзор сведений о сетевых абонентов, чем 1 час, может привести к нарушению устойчивости, безопасности и целостности функционирования на территории Российской Федерации сети «Интернет» и сети связи общего пользования.
Информация по пунктам «а» -«в» пункта 2 проекта приказа передается в Роскомнадзор с использованием личного кабинета, размещенного на сайте Роскомнадзора. Данное требование отражено в подпункте «а» пункта 3 проекта приказа.
Требуется предоставление информации о пуле IP-адресов, закрепленных за определенным субъектов Российской Федерации с привязкой к идентификатору ТСПУ, через который проходит трафик данных адресов.
В пункте 2 проекта приказа конкретизуется перечень информации, позволяющей идентифицировать средства связи и пользовательское оборудование (оконечное оборудование) в сети «Интернет».
Предоставление сведений о MAC адресах пользователей, логинов авторизации, сведений о типах устройства проектом приказа не предусмотрено.
Терминология, использованная в проекте приказа, согласно правилам юридической техники, соответствует пункту 5.2-1 статьи 46 Федерального закона от 7 июля 2003 г. № 126 «О связи». У оператора связи по территориальному признаку закреплены пулы IP-адресов, информацию о которых и необходимо предоставить.
Необходимость в постоянном соединение с системами Роскомнадзора требуется только для операторов связи, использующих технологию Dual-Stack. Информацию об идентификаторе ТСПУ необходимо получить у вышестоящего оператора связи, осуществляющего пропуск трафика через ТСПУ.
Разработка проекта приказа предусмотрена часть.ю 5.2-1 статьи 46 Федерального закона от 07.07.2003 № 126-ФЗ "О связи".
Для выявления трафика, обеспечивающего доступ к противоправным ресурсам с целью их последующей блокировки на ТСПУ, проводится анализ трафика между пользователем и ресурсом. Принадлежность трафика пользователю определяется по сетевому адресу. В связи с внедрением на сетях связи нового стандарта сетевого адреса (так называемого IPv6) и одновременного использования «старого» стандарта IPv4, операторы связи стали использовать технологию двойной адресации Dual-Stack. Трафик между пользователем (пользовательским приложением) и ресурсом идет по сетевым адресам разных стандартов. Переход на упомянутую технологию приводит к тому, что ТСПУ не может однозначно идентифицировать принадлежность трафика конкретному пользователю. Это приводит к снижению эффективности выявления трафика, направленного к противоправным ресурсам, и его ограничение. В целях решения обозначенной проблематики проектом приказа предусмотрена обязанность операторов связи передавать в Роскомнадзор информацию о сетевых адресах, выделенных оператором связи абоненту при оказании услуги по предоставлению доступа к сети «Интернет с использованием технологии Dual-Stack. Ограничение доступа к VPN – сервисам, нарушающих законодательство Российской Федерации, в части обеспечения доступа к информации, запрещенной к распространению на территории Российской Федерации, осуществляется с использованием оборудования ТСПУ в рамках реагирования на угрозу противодействия (затруднения) ограничению доступа к информации или информационным ресурсам в сети «Интернет», доступ к которым подлежит ограничению в соответствии с законодательством Российской Федерации (подпункт «в» пункта 5 Правил централизованного управления сетью связи общего пользования, утвержденных постановлением Правительства Российской Федерации от 12 февраля 2020 г. № 127.
В МТС указали, что сейчас у компании нет технической возможности предоставлять сведения о регионе, районе, городском округе, в которых используются конкретные IP-адреса
Конечно нет 🤭 зато есть специально выделенный человек от фейсеров, который, при получении запроса, в течении нескольких минут, выдаст всё и даже больше за последние пол года 😎
Ну, возможно, хоть какой-то "большевик" (просто в плане размеров) в виде МТС выступает против полного рассекречивания пользовательских данных, ведущей всю нашу информационную безопасность в никуда.
Это все для нашего же блага, ну ну, по просьбам трудящихся так сказать.
В МТС сообщили о рисках для тайны связи в идее РКН о сборе IP-адресов пользовательского оборудования