Comments 46
Я конечно не эксперт, но если нужно всех закрыть, разве конструкция типа
не работает?
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTне работает?
Проблема не в том, что она работает или не работает. Кому ее писать?
Я считаю, что провайдерам нужно сделать блокировку входящих соединений по умолчанию, с возможностью ее отключения в любое время через личный кабинет. Но если такое невозможно или нетривиально, неотключаемой блокировки быть не должно.
Смотрите, главный вопрос будет «Где ее втыкать, эту блокировку?». Если кратко о проблеме, то на магистральном уровне ее втыкать дорого, а на уровне свича в подъезде хлопотно и/или не всегда возможно.
На устройстве, на котором вы бы настраивали NAT.
Вы с пользовательской стороны имеете ввиду или с операторской?
С пользовательской — это роутер, его не надо настраивать, по дефолту настроен.
С пользовательской — это роутер, его не надо настраивать, по дефолту настроен.
Я говорю про операторскую настройку, статья же о ней. Вы собирались применить NAT (PAT) для того, чтобы не пропускать входящие соединения. Это бессмысленно, т.к. то, что вы хотите, называется отслеживанием соединений (connection tracking, stateful firewall), и реализуется без NAT.
PAT просто не может работать без отслеживания соединений. А NAT, вообще говоря, может, например, Full Cone NAT, когда один адрес просто заменяется на другой, без отслеживания соединений, и без блокировки входящих подключений.
PAT просто не может работать без отслеживания соединений. А NAT, вообще говоря, может, например, Full Cone NAT, когда один адрес просто заменяется на другой, без отслеживания соединений, и без блокировки входящих подключений.
Прошивкописателям? Путь эти строчки будут стандартом де-факто. Кому надо, те сотрут :)
Ну, кто-то же написал во всех диртристах
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface eth1 -j ACCEPTНо NAT-то тут причем?
Кроме того, фаервол подразумевает некий способ опознавания «свой-чужой». Ну хотя бы по source IP.Я не понял проблему. Клиенту выдается, скажем, /56, в чем проблема идентификации «свой-чужой»? Каким образом NAT упрощает задачу?
Что невозможно в наших условиях интернет-кафе, 3G-LTE и вот этого всего.У МТС, вон, получилось.
1. Клиенту выдается хоть /48, вопросов нет. Как опознать, что это я, когда я хочу потыкать свой IoT-девайс с ноута в интернет-кафе?
2. Эм, пример можно в студию? Я, видимо, что-то пропустил.
2. Эм, пример можно в студию? Я, видимо, что-то пропустил.
1. Клиенту выдается хоть /48, вопросов нет. Как опознать, что это я, когда я хочу потыкать свой IoT-девайс с ноута в интернет-кафе?Вы говорите о stateless-файрволле, или о чем? Вы хотите дать возможность разрешать входящие соединения с определенных IP-адресов, а для всех остальных отключать эту возможность? Считаю, что это уже не провайдерское дело.
2. Эм, пример можно в студию? Я, видимо, что-то пропустил.Я говорил про IPv6 в сетях МТС: www.mts.ru/mobil_inet_and_tv/tarifu/internet_dly_odnogo/additionally_services_comp/ipv6
Вы говорите о stateless-файрволле, или о чем? Вы хотите дать возможность разрешать входящие соединения с определенных IP-адресов, а для всех остальных отключать эту возможность? Считаю, что это уже не провайдерское дело.
Я с Вами совершенно согласен. Только проблема в том, что это не дело пользователя. Ему плевать.
Подавляющее большинство IoT-устройств работают через «облако», некоторые даже не поддерживают прямые соединения.
Если пользователь хочет входящие соединения, пусть разрешит их в личном кабинете. В чем проблема-то?
Если пользователь хочет входящие соединения, пусть разрешит их в личном кабинете. В чем проблема-то?
Эти устройства сейчас работают «через облако» потому, что знают — в большинстве случаев они окажутся за NAT, нет смысла в прямом соединении.
Когда устройств станет больше, а latency начнет иметь все большее значение, локальные соединения станут более приемлемым механизмом. И рано или поздно мы получим открытые порты и белый IPv6.
Когда устройств станет больше, а latency начнет иметь все большее значение, локальные соединения станут более приемлемым механизмом. И рано или поздно мы получим открытые порты и белый IPv6.
Во-первых, сейчас у многих провайдеров выдается белый динамический IP. В этом случае нет никакого NAT, и тот же роутер Зинаиды Семеновны, у такого провайдера торчит портами наружу. Мир не рухнул.
Во-вторых, если уж это так необходимо, что мешает в IPv6, по-умолчанию пускать трафик через NAT, а по заявлению пользователя предоставлять ему прямой доступ? Например, сейчас пользователь может подключить себе белый статический IP, как отдельную услугу. С IPv6 можно делать так же, только не брать дополнительной абонентской платы, т.к. нет дефицита адресов. Это, с одной стороны, отсеет Зинаиду Семеновну, которая ничего не понимает в этих ваших айпишниках, а с другой те, кому NAT не нужен, без проблем получат белый IP.
Во-вторых, если уж это так необходимо, что мешает в IPv6, по-умолчанию пускать трафик через NAT, а по заявлению пользователя предоставлять ему прямой доступ? Например, сейчас пользователь может подключить себе белый статический IP, как отдельную услугу. С IPv6 можно делать так же, только не брать дополнительной абонентской платы, т.к. нет дефицита адресов. Это, с одной стороны, отсеет Зинаиду Семеновну, которая ничего не понимает в этих ваших айпишниках, а с другой те, кому NAT не нужен, без проблем получат белый IP.
См. мой изначальный посыл — я считаю, что NAT не есть признак протокола, IPv4 или IPv6. И не вижу проблемы давать NAT на IPv6, но увы, фанбоев с криками «NAT в IPv6 нинужен!!!111» я просто устал слушать.
IPv6 и создавался ради того, чтобы решить проблему недостатка адресов, т.к. NAT в IPv4 появился именно для этого. Запрещать установку новых входящих соединений умели и до изобретения NAT.
NAT повсеместно в IPv6 явно не нужен, а «фанбои» подразумевают именно это, когда говорят про ненужность NAT. Он нужен только для определенных, очень ограниченных применений, но не для того, чтобы блокировать возможность установки входящих соединений.
NAT повсеместно в IPv6 явно не нужен, а «фанбои» подразумевают именно это, когда говорят про ненужность NAT. Он нужен только для определенных, очень ограниченных применений, но не для того, чтобы блокировать возможность установки входящих соединений.
Смотрите, сейчас толком нет и не используется операторами никакое другое ограничение входящего трафика, кроме NAT. Поскольку оно решает две проблемы разом.
Я допускаю, что к массовому приходу IPv6 операторы научатся это делать без NAT, но ощутимо в этом сомневаюсь.
Я допускаю, что к массовому приходу IPv6 операторы научатся это делать без NAT, но ощутимо в этом сомневаюсь.
Из-за чего это? Ведь если оборудование способно делать PAT, то оно способно и просто отслеживать соединения.
Мне кажется, что вы пишете о положении вещей в провайдере, в котором вы работаете, а говорите от лица многих операторов.
Мне кажется, что вы пишете о положении вещей в провайдере, в котором вы работаете, а говорите от лица многих операторов.
Эм, я сразу пишу, что говорю от лица своего провайдера. Не более того.
Если говорить про других операторов, то им, обычно, вообще глубоко плевать на безопасность. На DNSSEC, который у нас включен на резолве. На флуд и атаки. Перечислять можно долго.
Я общаюсь с другими операторами, везде наблюдаю плюс/минус похожую картину.
Если говорить про других операторов, то им, обычно, вообще глубоко плевать на безопасность. На DNSSEC, который у нас включен на резолве. На флуд и атаки. Перечислять можно долго.
Я общаюсь с другими операторами, везде наблюдаю плюс/минус похожую картину.
NAT используется не от хорошей жизни и НИ В КОЕМ СЛУЧАЕ не в ограничительных целях. Да, в сети МТС, когда все только начиналось, для ВСЕХ мобильных абонентов использовалось 2048 public IPv4 адресов и именно они чистоганом выдавались абонентам. Достаточно быстро стало понятно, что их очень быстро будет мало и расширять их будет реально дорого и в какой-то момент просто невозможно. В те самые лохматые годы для целей трансляций использовался FW с полной инспекцией и попутно он выполнял-таки функции какой-то защиты абонентов от интернета (не наоборот). Спустя какое-то время стало понятно, что и FW для целей трансляции адресов на большом трафике да ещё и с логированием (для «спец. задач») не сильно то эффективен и в итоге, мы перешли на CGNAT с минимальным набором умной математики и максимальной плотностью толстых интерфейсов. Даже в таком варианте коробка, которая просто транлятит адреса — дорогое решение, хоть и пока необходимое.
Это я все к тому, что плюсы от неиспользования NAT есть и они выражаются во вполне реальные деньги. Мы не только не планируем делать трансляцию IPv6 адресов, но и в принципе не рассматривали такой странный вариант. Блокировать или не блокировать входящий трафик на 13х порты — это пока открытый вопрос.
Это я все к тому, что плюсы от неиспользования NAT есть и они выражаются во вполне реальные деньги. Мы не только не планируем делать трансляцию IPv6 адресов, но и в принципе не рассматривали такой странный вариант. Блокировать или не блокировать входящий трафик на 13х порты — это пока открытый вопрос.
Блокировать или не блокировать входящий трафик на 13х порты — это пока открытый вопрос.
Сейчас уже не нужно. А вот во времена MSBlast было еще как нужно, поверьте.
Это я все к тому, что плюсы от неиспользования NAT есть и они выражаются во вполне реальные деньги.
У Вас есть в этом особенность. Устройство может не держать открытой сессию, т.е. не быть доступным извне. А вот когда оно будет держать ее постоянно, то вангую веселые истории со сканом портов мобильных устройств и с соответствующими уязвимостями.
У Вас есть в этом особенность. Устройство может не держать открытой сессию, т.е. не быть доступным извне. А вот когда оно будет держать ее постоянно, то вангую веселые истории со сканом портов мобильных устройств и с соответствующими уязвимостями.
Тут главный вопрос кого и от кого нужно защищать/маскировать…
1. Абонентов от интернета
IPv4 {
Да, NAT действительно маскирует реальный адрес абонента и добраться до него простым сканированием IP/port уже не получится. Для этого нужно предпринять дополнительные действия, чтобы абонент сам «стукнулся» на вредоносный адрес. Но и тут уверенности в защищенности быть не должно.
}
IPv6 {
NAT-а нет, но у абонента не конкретный адрес, а огромная куча адресов и для того, чтобы его найти тоже придется что-то «скармливать» и опять же вынуждать демаскировать себя. Да, эта задача уже проще, но от вредоносных ресурсов и у IPv4 защита не ахти.
}
2. Интернет от абонентов
Тут что IPv4, что IPv6 разница не велика. Зараженные абоненты будут рыскать по сети в поисках жертвы. Причем NAT в этом раскладе вообще никак не мешает. Если представить, что на сети мобильного оператора одновременно работают десятки миллионов абонентов и скорости достигают десятки Мбит/с, то даже небольшая часть из них может наделать не мало бед. Причем от IPv4 трафика вреда будет на порядок больше. Просканировать весть IPv4 интернет гораздо проще тем более, что делать это можно не в одиночку, а из «бот-сети». В случае с IPv6 нужно «бить» по конкретным адресам, которые прописаны в DNS. Остальные способы уже не так очевидны.
3. Абонента от абонента
IPv4 {
В нашем случае, количество абонентов, которые выходят в сеть через одну коробку измеряется десятками/сотнями тысяч. Простор для скандирования «соседей» по IPv4 (приватные адреса) огромен. Именно поэтому на нас закрыт трафик абонент — абонент как таковой. Плюс это исключило возможность абонентам лазить по открытым шарам друг-друга (абоненты действительно не заморачиваются элементарными правилами безопасности).
}
IPv6 {
Тут смотрим п. 1 и понимаем, что сканированием найти другого абонента крайне не просто. Доступ абонент — абонент не закрываем.
}
Нарисую простой сценарий. Абонент заходит на не очень хороший сайт, который согласен за денежку вставить в код любой внешний url, который позволит идентифицировать IPv6-абонента.
Обратный скан будет произведен сразу же, без особых задержек, если с той стороны абонент интересен. А поскольку нынче не Edge на дворе, то скан будет быстрый, сочный, вкусный, со всеми пирогами.
Попробуйте такое с NAT.
Обратный скан будет произведен сразу же, без особых задержек, если с той стороны абонент интересен. А поскольку нынче не Edge на дворе, то скан будет быстрый, сочный, вкусный, со всеми пирогами.
Попробуйте такое с NAT.
А что мешает все позакрывать? Ведь файрвол то не зря придуман.
Эмм… могу конечно ошибаться в деталях, но у сотовых операторов PGW/GGSN не даст попасть на этого абона извне по умолчанию (и тут ipv4/ipv6 не имеет значения). Если конечно в профиле у него нет такой услуги специально. Но такого нет у 99.99% всех обычных абонентов.
Попасть на абонента с приватным IPv4 адресом из интернета без каких-либо ухищрений конечно нельзя. У нас (МТС) работает классический NAT. Трафик абонент — абонент с приватными IPv4 адресами у нас закрыт.
На абонентов с услугой RealIP (public IPv4 адрес, но динамический) попасть можно. Собственно, не вижу причин это закрывать.
Если говорить про IPv6, то доступ не закрыт, как абонент — абонент, так и интернет — абонент.
На абонентов с услугой RealIP (public IPv4 адрес, но динамический) попасть можно. Собственно, не вижу причин это закрывать.
Если говорить про IPv6, то доступ не закрыт, как абонент — абонент, так и интернет — абонент.
Сейчас уже не нужно. А вот во времена MSBlast было еще как нужно, поверьте.
Кому нужно? Оператору? А зачем?
В этом случае нет никакого NAT, и тот же роутер Зинаиды Семеновны, у такого провайдера торчит портами наружу.
Обычно в этом случае NAT стоит в роутере. Да, роутер торчит портами наружу, но только роутер. Телефон, планшет и телевизор Зинаиды Семеновны извне недостпны.
Две проблемы:
1) Патернализм. Вы предлагаете решать проблему IoT ботнетов с помощью «мы запретим» (подключаться к устройствам из сети). Ничего не напоминает?
2) Зачем при stateful firewall делать трансляцию? Да, мы разрешаем по-умолчанию только established. Правило пишется в два пинка на любом современном управляемом сетевом оборудовании.
Да, IoT — это плохо, но решать его надо на уровне IoT'а. Например, обязательным отзывом уязвимых моделей за счёт производителя. Либо OTT updates, либо оплачиваешь отзыв.
Почему из-за того, что кто-то производит автомобили без тормозов, мы ставим отбойники поперёк дороги «а вдруг он купил автомобиль без тормозов? Ну что, что остальным не проехать».
1) Патернализм. Вы предлагаете решать проблему IoT ботнетов с помощью «мы запретим» (подключаться к устройствам из сети). Ничего не напоминает?
2) Зачем при stateful firewall делать трансляцию? Да, мы разрешаем по-умолчанию только established. Правило пишется в два пинка на любом современном управляемом сетевом оборудовании.
Да, IoT — это плохо, но решать его надо на уровне IoT'а. Например, обязательным отзывом уязвимых моделей за счёт производителя. Либо OTT updates, либо оплачиваешь отзыв.
Почему из-за того, что кто-то производит автомобили без тормозов, мы ставим отбойники поперёк дороги «а вдруг он купил автомобиль без тормозов? Ну что, что остальным не проехать».
Разве обязательный отзыв не есть разновидность «запретим»?
Опять же, за чей счёт откроют центры сертификации и всякие комиссии по отзыву? Кто будет оплачивать бюрократически-юридические процессы?
Да и принудительные updates обозначают, что есть ещё одна дыра, и при утечке ключей можно заразить кучу устройств.
Опять же, за чей счёт откроют центры сертификации и всякие комиссии по отзыву? Кто будет оплачивать бюрократически-юридические процессы?
Да и принудительные updates обозначают, что есть ещё одна дыра, и при утечке ключей можно заразить кучу устройств.
Есть большая разница «запретим, чтобы не смог сделать плохо» и «заставить отвечать за то, что сделал плохо». Разница в том, что если сделал хорошо, в первом случае всё равно запретили (на всякий случай), а во втором — не наказывали, ибо всё сделано правильно.
Второй вариант стимулирует делать правильно и хорошо, первый вариант стимулирует всю ответственность перекладывать на запрещающего дядю.
Второй вариант стимулирует делать правильно и хорошо, первый вариант стимулирует всю ответственность перекладывать на запрещающего дядю.
Эм, относительно.
1. Да, я считаю патернализм оправданным, поскольку сами пользователи этого не делают (см. первую часть статьи). Делать это некому, кроме оператора.
2. Я, к сожалению, видел мало вменяемых реализаций statefull firewall, вернее, те, что видел, мне не оч. нравились.
А вот это уже неисправимый идеализм. На практике, когда производитель уже продал устройство (особенно если это стартап, с настроением «пропели, а там хоть не рассветай») требовать от него отзыва наивно. Он просто не будет этого делать.
Ну а про обновления — старая песня. Через какое-то время производитель объявляет EOL, и говорит, что больше вот этот девайс не поддерживает, дальше догадаетесь.
1. Да, я считаю патернализм оправданным, поскольку сами пользователи этого не делают (см. первую часть статьи). Делать это некому, кроме оператора.
2. Я, к сожалению, видел мало вменяемых реализаций statefull firewall, вернее, те, что видел, мне не оч. нравились.
Да, IoT — это плохо, но решать его надо на уровне IoT'а. Например, обязательным отзывом уязвимых моделей за счёт производителя. Либо OTT updates, либо оплачиваешь отзыв.
А вот это уже неисправимый идеализм. На практике, когда производитель уже продал устройство (особенно если это стартап, с настроением «пропели, а там хоть не рассветай») требовать от него отзыва наивно. Он просто не будет этого делать.
Ну а про обновления — старая песня. Через какое-то время производитель объявляет EOL, и говорит, что больше вот этот девайс не поддерживает, дальше догадаетесь.
Я прошу прощения. Ну хорошо, в4 сеть вы просканировали. А что с в6 сетью делать будете? Чем и как сканировать, ну например мой домашний /56?
Про это было много копий поломано. Вы вряд ли будете выдавать сложный адрес из середины диапазона, если будете выдавать его вручную, это раз. Различные протоколы могут «случайно» раскрыть Ваш адрес, это два. Перехват трафика с целью выявления адресов тоже никто не отменял, пусть это и достаточно сложный путь, это три.
В Хакере про это писали.
В Хакере про это писали.
Статью надо было назвать так:
«Я не умею в фаервол, поэтому как в пионернетах буду натить и срать хотел на е2е коннективити».
«Я не умею в фаервол, поэтому как в пионернетах буду натить и срать хотел на е2е коннективити».
Использовать NAT в качестве средства запрета идеологически не верно, так же как и роутинг, Не для того он был создан.
Если проломят роутер с натом (а их итак ломают), то проломят и все, что болтается на внутреннем интерфейсе.
Все крупные провайдеры дают в нагрузку роутеры, управляемые этими сами провайдерами автоматически. Вот и настройте в них файрволл толком, но без НАТа Если вас жаба душит подобное делать — пните юриста и добавьте в договор строчку "при обнаружении вредоносного трафика этот трафик будет блокироваться с обязательным уведомлением пользователя. Для отключения автоматической блокировки клиент должен уведомить оператора "
А требовать "включи НАТ, сволочь" от клиента — это трэш какой-то. дали мне подсеть адресов — я ее буду использовать, не дадите использовать — в суд подам за несоблюдение договора.
А кому его настраивать?
Что-то я запутался в логике высказываний. Т.е. вы говорите, что вы настраиваете NAT, а настроить файервол у вас некому? Т.е. для вас держать где-то кучу данных о соединениях пользователя проще, чем указать, что снаружи соединения создавать нельзя?
Возможно моё мнение покажется кому-то излишне жёстким, но… Тут всё должно быть как с автомобилями. Я хочу в пьяном угаре летать на своём авто по городу, без какие-либо прав и номеров (а зачем они мне?) и никак не отвечать за «всех тех козлов» которые случайно попали под мои колёса. Мне это удобно… но тут на помощь приходит государство с законами (причём в этом месте крайне полезными). И вот уже у нас есть сертификация автомобилей (попробуйте как продавать автомобиль без тормозов широким массам), номера, права, ППД, гражданская и уголовная ответственность за то, что вы натворили своим авто. Почему такого не должно быть в интернете? Решение этой проблемы это не задача оператора, а задача государства. Как только экономический урон от этих ботнетов превысит какой-то уровень, будет соотв. реакция (вспомните о том, что первых хакеров никто не осудил за взломы, потому что просто не было законов… только вот потом они быстро появились).
И да, платить за всё должны потребители. Это тот случай, когда это уместно и нормально. Появляются требования в железу, стоимость разработки возрастёт, железо подорожает. Но это, в отличии от всяких «законов яровой», как раз необходимое зло для нормального функционирования общества.
P.S. Вообще-то то, что творят сейчас операторы это скотство редкое, т.к. нормальный доступ в интернет это когда я могу пользоваться ЛЮБЫМИ протоколами на базе IP (он же не просто так называется Internet Protocol), а не только TCP, UDP и ICMP. Вообще любыми, даже не известными оператору (например самописными). Ну не операторское это дело всё что выше IP.
И да, платить за всё должны потребители. Это тот случай, когда это уместно и нормально. Появляются требования в железу, стоимость разработки возрастёт, железо подорожает. Но это, в отличии от всяких «законов яровой», как раз необходимое зло для нормального функционирования общества.
P.S. Вообще-то то, что творят сейчас операторы это скотство редкое, т.к. нормальный доступ в интернет это когда я могу пользоваться ЛЮБЫМИ протоколами на базе IP (он же не просто так называется Internet Protocol), а не только TCP, UDP и ICMP. Вообще любыми, даже не известными оператору (например самописными). Ну не операторское это дело всё что выше IP.
Автор так и не рассказал, чем егокостылиNAT лучше, чем правило в firewall, отключаемое через личный кабинет.
В более-менее нормальных домашних роутерах все входящие IPv6-соединения заблокированы, а дырки в фаерволе пробиваются через PCP (или вручную). По крайней мере, в Asus так.
То, что сейчас многие роутеры дырявые и не умеют в PCP — это издержки времени, скоро производители научатся делать нормально. На стороне провайдера городить фаерволе/NAT не надо.
Sign up to leave a comment.
IoT в роли мотиватора для NAT в IPv6