тут прикол в том, что по операторы не имеют права получать доступ к тому, что передается в их сетях. а если так, то как тогда предоставлять данные? по факту будет так — "сложите данные сюда" и отойдите.
В явном виде, этого и не написано. А как операторы будут отвечать уже на второй год почему нет данных? Боюсь, что ответ «простите, не влезло» но прокатит.
Требований к применяемым техническим средствам накопления нет (их утверждает Минсвязи по согласованию с ФСБ и не установлен срок их утверждения). Получается, что Правительство "выкрутилось" — теперь дело за Минсвязи (добиться согласования от ФСБ) и только потом уже это головняк операторов (заказать оборудование и построить).
Операторов обязали ограничить рост трафика в 15% в год на ближайшие 5 лет.
Документ составлен так, что его можно прочитать в 2-х вариантах (двойные стандарты):
все операторы должны все сдать на прослушку с 1 июля для голоса и 1 октября для даты (большая тройка)
но можно включать по получению актов от ФСБ (Ростелеком). Сроки при этом можно не соблюдать.
Походу, нас не нужно отключать от Интернет (Клеменко давно намекал, что мы готовы). Мы сами (не без содействия РКН) от него отключимся и превратимся с Северную Корею и Кубу. Зато не будет проблем с нехваткой IP адресов...
Не рекомендуем потому, что их реально мало, а задачи которые они решают, обычно того не стоят. Вторая причина в том, что статический адрес «прибивается» к конкретному устройству GGSN/PGW (если грубо, то шлюз). При перемещениях по нашей сети трафик приходится «тащить» именно туда (бывают и экстремальные трассы абонент в Южно-Сахалинске, а трафик гнать в Москву). Трафик не большой, но с задержкой ничего не сделать.
У нас есть услуга, в рамках которой мы делаем отдельный APN и дотаскиваем транспорт (можно и VPN-ом) до сети клиента. В этом случае только SIM карты клиента получают доступ в эту сеть и можно каждому устройству сделать статичный адрес. Причём тут есть две опции. Первая — адрес выставляется у нас (HLR/HSS). Вторя — адрес запрашивается у radius-сервера клиента.
Статический IPv6 адрес мы пока тоже не делаем. Если почувствуем заинтересованность/востребованность этой опции, то рассмотрим и такую возможность.
Попасть на абонента с приватным IPv4 адресом из интернета без каких-либо ухищрений конечно нельзя. У нас (МТС) работает классический NAT. Трафик абонент — абонент с приватными IPv4 адресами у нас закрыт.
На абонентов с услугой RealIP (public IPv4 адрес, но динамический) попасть можно. Собственно, не вижу причин это закрывать.
Если говорить про IPv6, то доступ не закрыт, как абонент — абонент, так и интернет — абонент.
Услуга со статическим IPv4 адресом есть, но предоставляется но она доступна только корпоративным клиентам (не физическим лицам), и даже им мы не рекомендуем ее себе подключать.
Для IPv6 естественно, никакой NAT не используется. Каждое устройство, подключаемое к сети, получает префикс /64. Устройства, которые подключатся уже за модемом/смартфоном, получают также прямые IPv6 адреса все из того же префикса /64, что и основное устройство и тоже доступны из интернет по прямому адресу.
В следующем году мы планируем сделать prefix-delegation. Это означает, что роутерам будем выдавать дополнительный префикс /56.
У Вас есть в этом особенность. Устройство может не держать открытой сессию, т.е. не быть доступным извне. А вот когда оно будет держать ее постоянно, то вангую веселые истории со сканом портов мобильных устройств и с соответствующими уязвимостями.
Тут главный вопрос кого и от кого нужно защищать/маскировать…
1. Абонентов от интернета IPv4 {
Да, NAT действительно маскирует реальный адрес абонента и добраться до него простым сканированием IP/port уже не получится. Для этого нужно предпринять дополнительные действия, чтобы абонент сам «стукнулся» на вредоносный адрес. Но и тут уверенности в защищенности быть не должно. } IPv6 {
NAT-а нет, но у абонента не конкретный адрес, а огромная куча адресов и для того, чтобы его найти тоже придется что-то «скармливать» и опять же вынуждать демаскировать себя. Да, эта задача уже проще, но от вредоносных ресурсов и у IPv4 защита не ахти. }
2. Интернет от абонентов
Тут что IPv4, что IPv6 разница не велика. Зараженные абоненты будут рыскать по сети в поисках жертвы. Причем NAT в этом раскладе вообще никак не мешает. Если представить, что на сети мобильного оператора одновременно работают десятки миллионов абонентов и скорости достигают десятки Мбит/с, то даже небольшая часть из них может наделать не мало бед. Причем от IPv4 трафика вреда будет на порядок больше. Просканировать весть IPv4 интернет гораздо проще тем более, что делать это можно не в одиночку, а из «бот-сети». В случае с IPv6 нужно «бить» по конкретным адресам, которые прописаны в DNS. Остальные способы уже не так очевидны.
3. Абонента от абонента IPv4 {
В нашем случае, количество абонентов, которые выходят в сеть через одну коробку измеряется десятками/сотнями тысяч. Простор для скандирования «соседей» по IPv4 (приватные адреса) огромен. Именно поэтому на нас закрыт трафик абонент — абонент как таковой. Плюс это исключило возможность абонентам лазить по открытым шарам друг-друга (абоненты действительно не заморачиваются элементарными правилами безопасности). } IPv6 {
Тут смотрим п. 1 и понимаем, что сканированием найти другого абонента крайне не просто. Доступ абонент — абонент не закрываем. }
NAT используется не от хорошей жизни и НИ В КОЕМ СЛУЧАЕ не в ограничительных целях. Да, в сети МТС, когда все только начиналось, для ВСЕХ мобильных абонентов использовалось 2048 public IPv4 адресов и именно они чистоганом выдавались абонентам. Достаточно быстро стало понятно, что их очень быстро будет мало и расширять их будет реально дорого и в какой-то момент просто невозможно. В те самые лохматые годы для целей трансляций использовался FW с полной инспекцией и попутно он выполнял-таки функции какой-то защиты абонентов от интернета (не наоборот). Спустя какое-то время стало понятно, что и FW для целей трансляции адресов на большом трафике да ещё и с логированием (для «спец. задач») не сильно то эффективен и в итоге, мы перешли на CGNAT с минимальным набором умной математики и максимальной плотностью толстых интерфейсов. Даже в таком варианте коробка, которая просто транлятит адреса — дорогое решение, хоть и пока необходимое.
Это я все к тому, что плюсы от неиспользования NAT есть и они выражаются во вполне реальные деньги. Мы не только не планируем делать трансляцию IPv6 адресов, но и в принципе не рассматривали такой странный вариант. Блокировать или не блокировать входящий трафик на 13х порты — это пока открытый вопрос.
Все проще. Нужно запретить населению использовать иностранные замки, а для импортозамещенных будет универсальный ключ у каждого сотрудника КГБ.
Если прокатит, то и все сертификаты для РФ начнём выпускать с одним и тем же private.key. Зачем грузить КГБ с запоминанием разных ключей для разных ru-сайтов...
На мой скромный взгляд, дальнейшее регулирование интернета без принудительного перевода всех RU-ресурсов (остальные в блок) на отечественные сертификаты и адского дешифратора (на который еще нужно как-то подать трафик) становится практические невозможным.
Ясен пень, что доступа у оператора к этой конструкции не будет. Только что-то законы менять не хотят в сторону перекладывания ответственности за предоставление выборок с этой конструкции с операторов на того, кто реально будет такой доступ иметь. А еще не плохо бы наложить дополнительную ответственность на того, кто использует получаемые с нее данные на сидение в одиночке под страхом высшей меры за разглашение то, что случайно нашел третим лицам...
плохая идея. за такую реализацию все равно будем платить опять же мы...
Ставить прокси никто не запрещает, но и ответственность, за запись трафика всех абонентов никто не снимает.
автор в теме и про СОРМ1 и СОРМ2 и СОРМ3…
не вопрос. тогда меняем закон и ответственность за предоставление данных с операторов снимаем.
тут прикол в том, что по операторы не имеют права получать доступ к тому, что передается в их сетях. а если так, то как тогда предоставлять данные? по факту будет так — "сложите данные сюда" и отойдите.
В явном виде, этого и не написано. А как операторы будут отвечать уже на второй год почему нет данных? Боюсь, что ответ «простите, не влезло» но прокатит.
Из документа читается следующее:
Походу, нас не нужно отключать от Интернет (Клеменко давно намекал, что мы готовы). Мы сами (не без содействия РКН) от него отключимся и превратимся с Северную Корею и Кубу. Зато не будет проблем с нехваткой IP адресов...
У нас есть услуга, в рамках которой мы делаем отдельный APN и дотаскиваем транспорт (можно и VPN-ом) до сети клиента. В этом случае только SIM карты клиента получают доступ в эту сеть и можно каждому устройству сделать статичный адрес. Причём тут есть две опции. Первая — адрес выставляется у нас (HLR/HSS). Вторя — адрес запрашивается у radius-сервера клиента.
Статический IPv6 адрес мы пока тоже не делаем. Если почувствуем заинтересованность/востребованность этой опции, то рассмотрим и такую возможность.
На абонентов с услугой RealIP (public IPv4 адрес, но динамический) попасть можно. Собственно, не вижу причин это закрывать.
Если говорить про IPv6, то доступ не закрыт, как абонент — абонент, так и интернет — абонент.
Для IPv6 естественно, никакой NAT не используется. Каждое устройство, подключаемое к сети, получает префикс /64. Устройства, которые подключатся уже за модемом/смартфоном, получают также прямые IPv6 адреса все из того же префикса /64, что и основное устройство и тоже доступны из интернет по прямому адресу.
В следующем году мы планируем сделать prefix-delegation. Это означает, что роутерам будем выдавать дополнительный префикс /56.
Тут главный вопрос кого и от кого нужно защищать/маскировать…
1. Абонентов от интернета
IPv4 {
Да, NAT действительно маскирует реальный адрес абонента и добраться до него простым сканированием IP/port уже не получится. Для этого нужно предпринять дополнительные действия, чтобы абонент сам «стукнулся» на вредоносный адрес. Но и тут уверенности в защищенности быть не должно.
}
IPv6 {
NAT-а нет, но у абонента не конкретный адрес, а огромная куча адресов и для того, чтобы его найти тоже придется что-то «скармливать» и опять же вынуждать демаскировать себя. Да, эта задача уже проще, но от вредоносных ресурсов и у IPv4 защита не ахти.
}
2. Интернет от абонентов
Тут что IPv4, что IPv6 разница не велика. Зараженные абоненты будут рыскать по сети в поисках жертвы. Причем NAT в этом раскладе вообще никак не мешает. Если представить, что на сети мобильного оператора одновременно работают десятки миллионов абонентов и скорости достигают десятки Мбит/с, то даже небольшая часть из них может наделать не мало бед. Причем от IPv4 трафика вреда будет на порядок больше. Просканировать весть IPv4 интернет гораздо проще тем более, что делать это можно не в одиночку, а из «бот-сети». В случае с IPv6 нужно «бить» по конкретным адресам, которые прописаны в DNS. Остальные способы уже не так очевидны.
3. Абонента от абонента
IPv4 {
В нашем случае, количество абонентов, которые выходят в сеть через одну коробку измеряется десятками/сотнями тысяч. Простор для скандирования «соседей» по IPv4 (приватные адреса) огромен. Именно поэтому на нас закрыт трафик абонент — абонент как таковой. Плюс это исключило возможность абонентам лазить по открытым шарам друг-друга (абоненты действительно не заморачиваются элементарными правилами безопасности).
}
IPv6 {
Тут смотрим п. 1 и понимаем, что сканированием найти другого абонента крайне не просто. Доступ абонент — абонент не закрываем.
}
Это я все к тому, что плюсы от неиспользования NAT есть и они выражаются во вполне реальные деньги. Мы не только не планируем делать трансляцию IPv6 адресов, но и в принципе не рассматривали такой странный вариант. Блокировать или не блокировать входящий трафик на 13х порты — это пока открытый вопрос.
Все проще. Нужно запретить населению использовать иностранные замки, а для импортозамещенных будет универсальный ключ у каждого сотрудника КГБ.
Если прокатит, то и все сертификаты для РФ начнём выпускать с одним и тем же private.key. Зачем грузить КГБ с запоминанием разных ключей для разных ru-сайтов...
На мой скромный взгляд, дальнейшее регулирование интернета без принудительного перевода всех RU-ресурсов (остальные в блок) на отечественные сертификаты и адского дешифратора (на который еще нужно как-то подать трафик) становится практические невозможным.
Ясен пень, что доступа у оператора к этой конструкции не будет. Только что-то законы менять не хотят в сторону перекладывания ответственности за предоставление выборок с этой конструкции с операторов на того, кто реально будет такой доступ иметь. А еще не плохо бы наложить дополнительную ответственность на того, кто использует получаемые с нее данные на сидение в одиночке под страхом высшей меры за разглашение то, что случайно нашел третим лицам...