Давайте я сразу раскрою карты: мое мнение и примеры будут основаны на опыте работы в региональном операторе связи, у которого несколько десятков тысяч абонентов, физических и юридических лиц. Один регион присутствия, ЦФО.
Проблема
Она в том, что пользователям в их большинстве плевать на безопасность. Любой пользователь хочет пользоваться компьютером или смартфоном и не особо заморачиваться. Любые слова от оператора связи о том, что его компьютер участвует в атаках или делает что-то плохое пользователь не воспринимает серьезно.
Почему? Потому что нет последствий.
Я серьезно. Даже если злоумышленники через доступ в интернет от имени этого пользователя совершат что-то ужасное, повесить это на самого пользователя будет достаточно сложно.
В итоге любое сообщение от оператора о том, что у пользователя что-то не так, воспринимается попыткой заработать на нем, пользователе, дополнительного бабла.
Нужно ли решать эту проблему оператору?
И да, и нет. Когда видишь на графике, что порядка 20% твоих исходящих DNS-запросов есть участие в атаке DNS watertorture, то ты, конечно, хочешь это решить. Получаешь список зараженных машин, их будет не так уж много, но дальше ничего. Примеры:
1. Муниципальное учреждение. Системный администратор отсутствует как класс, кое-как работающие, насквозь зараженные компьютеры. Они платят за интернет, поэтому отключать их как-то странно, с точки зрения оператора.
2. Торговая точка. Доступ есть у огромного количества продавцов, явно кто-то умудрился занести заразу. Вылечить? Да, но бесплатно это никто делать не будет. Лишние расходы. Не, не надо.
Можно продолжать, таких историй множество. Отключать таких абонентов от сети? Ну это значит, что нужно наступить на горло собственной выручке.
А IPv6 причем тут?
Фанбои IPv6, которые в реале даже дуалстека не нюхали, обычно любят орать с пеной у рта о том, что «В IPv6 нинужин NAT!!!!111».
Увы, но даже в IPv4 мире нас спасает от потоков гавна только NAT. Вы хотите примеров? Их есть у меня.
Итак, мы берем и сканируем при помощи Router Scan свою внутреннюю сеть. Что получаем? Ну, в моем случае 739 уязвимых роутеров. Часть из них неправильно настроены. Часть их них имеет уязвимости в прошивке. Неважно. Важно другое, это 739 вкусных целей.
Когда придет IPv6 без NAT, который там совершенно ненужен, станет понятно, что огромное количество IoT устройств (с буквой S, обозначающей security), произведены в Китае дядей Ляо. Разработчики софта для этих устройств имели весьма отдаленное представление о безопасности. Оставляли открытыми telnet со слабым паролем. Ну и так далее.
И знаете, что будет дальше, когда IoT пойдет в массы в регионы? Когда любая Зинаида Семеновна сможет купить 5-10 устройств для своей отличной двухкомнатной хрущевки? IPv6 с белым адресом поможет этим устройствам верно трудиться на славу своего господина ботовода. А к тому моменту стараниями маркетологов Зинаида Семеновна для себя и деток сможет взять и 300-400 мегабит в секунду пропускной полосы. Прелесть!
Ну, надо просто использовать фаервол!
Да, гениальная идея! Я согласен, где подписать? Правда, один сложный момент. А кому его настраивать?
Пользователю? Который просто умеет нажать кнопку и «чтобы работало»? Пользователь не будет этого делать, DDoS с его устройств, как мы уже выяснили, не его проблема.
Оператору? У оператора и так полно головной боли. Поэтому самый удобный statefull-фаервол = NAT. Как бы странно это ни звучало и не выглядело. И да, конечно, оператор вынужден даже сейчас это использовать. У множества операторов на ACL стоит запрет на трафик по 13x порту в сторону пользователя.
Кроме того, фаервол подразумевает некий способ опознавания «свой-чужой». Ну хотя бы по source IP. Что невозможно в наших условиях интернет-кафе, 3G-LTE и вот этого всего.
Поэтому все эти прекрасные рекомендации «используйте фаервол, а не NAT» разбиваются об стенку реальности.
Может быть что-то еще?
Да, есть еще один вариант. Когда оператор закрывает собой Level 3 и становится Level 2 провайдером. Такие в России есть, но мало. И использует виртуальный роутер, то есть, контролирует весь трафик абонента, предоставляя ему некоторые способы это контролировать, например, через приложение на телефоне или веб-интерфейс.
Но это не самый простой вариант, именно поэтому тема vCPE в России не так быстро развивается.
В профильном Telegram-чате верно предположили, что рано или позно операторы начнут фильтровать SYN-пакеты в сторону абонента. Да, но это, безусловно, тупиковый вариант.
Автор будет рад выслушать любые предложения по этому поводу, конструктивную критику, а также новые пути решения. И да, кто-нибудь, обязательно напишите в комментариях, что в IPv6 не нужен NAT.
А есть еще офигительные истории?
Оставлю одну, напоследок. В какой-то момент срабатывает мониторинг и мы видим порядка 7 тысяч DNS-запросов из нашей сети наружу вместо обычных 1,5. Причина? Один из клиентов включил 4 китайские IP-камеры. Занавес.
Комментарии (45)
ValdikSS
14.12.2017 16:57Но NAT-то тут причем?
Кроме того, фаервол подразумевает некий способ опознавания «свой-чужой». Ну хотя бы по source IP.
Я не понял проблему. Клиенту выдается, скажем, /56, в чем проблема идентификации «свой-чужой»? Каким образом NAT упрощает задачу?
Что невозможно в наших условиях интернет-кафе, 3G-LTE и вот этого всего.
У МТС, вон, получилось.
prometheus_ru Автор
14.12.2017 16:591. Клиенту выдается хоть /48, вопросов нет. Как опознать, что это я, когда я хочу потыкать свой IoT-девайс с ноута в интернет-кафе?
2. Эм, пример можно в студию? Я, видимо, что-то пропустил.ValdikSS
14.12.2017 17:011. Клиенту выдается хоть /48, вопросов нет. Как опознать, что это я, когда я хочу потыкать свой IoT-девайс с ноута в интернет-кафе?
Вы говорите о stateless-файрволле, или о чем? Вы хотите дать возможность разрешать входящие соединения с определенных IP-адресов, а для всех остальных отключать эту возможность? Считаю, что это уже не провайдерское дело.
2. Эм, пример можно в студию? Я, видимо, что-то пропустил.
Я говорил про IPv6 в сетях МТС: www.mts.ru/mobil_inet_and_tv/tarifu/internet_dly_odnogo/additionally_services_comp/ipv6
prometheus_ru Автор
14.12.2017 17:05Вы говорите о stateless-файрволле, или о чем? Вы хотите дать возможность разрешать входящие соединения с определенных IP-адресов, а для всех остальных отключать эту возможность? Считаю, что это уже не провайдерское дело.
Я с Вами совершенно согласен. Только проблема в том, что это не дело пользователя. Ему плевать.ValdikSS
14.12.2017 17:09Подавляющее большинство IoT-устройств работают через «облако», некоторые даже не поддерживают прямые соединения.
Если пользователь хочет входящие соединения, пусть разрешит их в личном кабинете. В чем проблема-то?prometheus_ru Автор
14.12.2017 17:20Эти устройства сейчас работают «через облако» потому, что знают — в большинстве случаев они окажутся за NAT, нет смысла в прямом соединении.
Когда устройств станет больше, а latency начнет иметь все большее значение, локальные соединения станут более приемлемым механизмом. И рано или поздно мы получим открытые порты и белый IPv6.ValdikSS
14.12.2017 17:24Техники, «пробивающие» NAT, при блокировке входящих соединений через отслеживание соединений без NAT в IPv6 будут работать в 100% случаев. Не вижу резона не применять их, все основные программы их поддерживают.
Да и, уверен, uPNP/NAT-PMP никуда не денется.
Cryvage
14.12.2017 17:11Во-первых, сейчас у многих провайдеров выдается белый динамический IP. В этом случае нет никакого NAT, и тот же роутер Зинаиды Семеновны, у такого провайдера торчит портами наружу. Мир не рухнул.
Во-вторых, если уж это так необходимо, что мешает в IPv6, по-умолчанию пускать трафик через NAT, а по заявлению пользователя предоставлять ему прямой доступ? Например, сейчас пользователь может подключить себе белый статический IP, как отдельную услугу. С IPv6 можно делать так же, только не брать дополнительной абонентской платы, т.к. нет дефицита адресов. Это, с одной стороны, отсеет Зинаиду Семеновну, которая ничего не понимает в этих ваших айпишниках, а с другой те, кому NAT не нужен, без проблем получат белый IP.prometheus_ru Автор
14.12.2017 17:13См. мой изначальный посыл — я считаю, что NAT не есть признак протокола, IPv4 или IPv6. И не вижу проблемы давать NAT на IPv6, но увы, фанбоев с криками «NAT в IPv6 нинужен!!!111» я просто устал слушать.
ValdikSS
14.12.2017 17:21IPv6 и создавался ради того, чтобы решить проблему недостатка адресов, т.к. NAT в IPv4 появился именно для этого. Запрещать установку новых входящих соединений умели и до изобретения NAT.
NAT повсеместно в IPv6 явно не нужен, а «фанбои» подразумевают именно это, когда говорят про ненужность NAT. Он нужен только для определенных, очень ограниченных применений, но не для того, чтобы блокировать возможность установки входящих соединений.prometheus_ru Автор
14.12.2017 17:25Смотрите, сейчас толком нет и не используется операторами никакое другое ограничение входящего трафика, кроме NAT. Поскольку оно решает две проблемы разом.
Я допускаю, что к массовому приходу IPv6 операторы научатся это делать без NAT, но ощутимо в этом сомневаюсь.ValdikSS
14.12.2017 17:31Из-за чего это? Ведь если оборудование способно делать PAT, то оно способно и просто отслеживать соединения.
Мне кажется, что вы пишете о положении вещей в провайдере, в котором вы работаете, а говорите от лица многих операторов.prometheus_ru Автор
14.12.2017 17:33Эм, я сразу пишу, что говорю от лица своего провайдера. Не более того.
Если говорить про других операторов, то им, обычно, вообще глубоко плевать на безопасность. На DNSSEC, который у нас включен на резолве. На флуд и атаки. Перечислять можно долго.
Я общаюсь с другими операторами, везде наблюдаю плюс/минус похожую картину.
eov
14.12.2017 18:35NAT используется не от хорошей жизни и НИ В КОЕМ СЛУЧАЕ не в ограничительных целях. Да, в сети МТС, когда все только начиналось, для ВСЕХ мобильных абонентов использовалось 2048 public IPv4 адресов и именно они чистоганом выдавались абонентам. Достаточно быстро стало понятно, что их очень быстро будет мало и расширять их будет реально дорого и в какой-то момент просто невозможно. В те самые лохматые годы для целей трансляций использовался FW с полной инспекцией и попутно он выполнял-таки функции какой-то защиты абонентов от интернета (не наоборот). Спустя какое-то время стало понятно, что и FW для целей трансляции адресов на большом трафике да ещё и с логированием (для «спец. задач») не сильно то эффективен и в итоге, мы перешли на CGNAT с минимальным набором умной математики и максимальной плотностью толстых интерфейсов. Даже в таком варианте коробка, которая просто транлятит адреса — дорогое решение, хоть и пока необходимое.
Это я все к тому, что плюсы от неиспользования NAT есть и они выражаются во вполне реальные деньги. Мы не только не планируем делать трансляцию IPv6 адресов, но и в принципе не рассматривали такой странный вариант. Блокировать или не блокировать входящий трафик на 13х порты — это пока открытый вопрос.prometheus_ru Автор
14.12.2017 22:14Блокировать или не блокировать входящий трафик на 13х порты — это пока открытый вопрос.
Сейчас уже не нужно. А вот во времена MSBlast было еще как нужно, поверьте.
Это я все к тому, что плюсы от неиспользования NAT есть и они выражаются во вполне реальные деньги.
У Вас есть в этом особенность. Устройство может не держать открытой сессию, т.е. не быть доступным извне. А вот когда оно будет держать ее постоянно, то вангую веселые истории со сканом портов мобильных устройств и с соответствующими уязвимостями.eov
14.12.2017 23:42У Вас есть в этом особенность. Устройство может не держать открытой сессию, т.е. не быть доступным извне. А вот когда оно будет держать ее постоянно, то вангую веселые истории со сканом портов мобильных устройств и с соответствующими уязвимостями.
Тут главный вопрос кого и от кого нужно защищать/маскировать…
1. Абонентов от интернета
IPv4 {
Да, NAT действительно маскирует реальный адрес абонента и добраться до него простым сканированием IP/port уже не получится. Для этого нужно предпринять дополнительные действия, чтобы абонент сам «стукнулся» на вредоносный адрес. Но и тут уверенности в защищенности быть не должно.
}
IPv6 {
NAT-а нет, но у абонента не конкретный адрес, а огромная куча адресов и для того, чтобы его найти тоже придется что-то «скармливать» и опять же вынуждать демаскировать себя. Да, эта задача уже проще, но от вредоносных ресурсов и у IPv4 защита не ахти.
}
2. Интернет от абонентов
Тут что IPv4, что IPv6 разница не велика. Зараженные абоненты будут рыскать по сети в поисках жертвы. Причем NAT в этом раскладе вообще никак не мешает. Если представить, что на сети мобильного оператора одновременно работают десятки миллионов абонентов и скорости достигают десятки Мбит/с, то даже небольшая часть из них может наделать не мало бед. Причем от IPv4 трафика вреда будет на порядок больше. Просканировать весть IPv4 интернет гораздо проще тем более, что делать это можно не в одиночку, а из «бот-сети». В случае с IPv6 нужно «бить» по конкретным адресам, которые прописаны в DNS. Остальные способы уже не так очевидны.
3. Абонента от абонента
IPv4 {
В нашем случае, количество абонентов, которые выходят в сеть через одну коробку измеряется десятками/сотнями тысяч. Простор для скандирования «соседей» по IPv4 (приватные адреса) огромен. Именно поэтому на нас закрыт трафик абонент — абонент как таковой. Плюс это исключило возможность абонентам лазить по открытым шарам друг-друга (абоненты действительно не заморачиваются элементарными правилами безопасности).
}
IPv6 {
Тут смотрим п. 1 и понимаем, что сканированием найти другого абонента крайне не просто. Доступ абонент — абонент не закрываем.
}prometheus_ru Автор
15.12.2017 00:26Нарисую простой сценарий. Абонент заходит на не очень хороший сайт, который согласен за денежку вставить в код любой внешний url, который позволит идентифицировать IPv6-абонента.
Обратный скан будет произведен сразу же, без особых задержек, если с той стороны абонент интересен. А поскольку нынче не Edge на дворе, то скан будет быстрый, сочный, вкусный, со всеми пирогами.
Попробуйте такое с NAT.satandyh
15.12.2017 15:35Эмм… могу конечно ошибаться в деталях, но у сотовых операторов PGW/GGSN не даст попасть на этого абона извне по умолчанию (и тут ipv4/ipv6 не имеет значения). Если конечно в профиле у него нет такой услуги специально. Но такого нет у 99.99% всех обычных абонентов.
eov
15.12.2017 16:11Попасть на абонента с приватным IPv4 адресом из интернета без каких-либо ухищрений конечно нельзя. У нас (МТС) работает классический NAT. Трафик абонент — абонент с приватными IPv4 адресами у нас закрыт.
На абонентов с услугой RealIP (public IPv4 адрес, но динамический) попасть можно. Собственно, не вижу причин это закрывать.
Если говорить про IPv6, то доступ не закрыт, как абонент — абонент, так и интернет — абонент.
VolCh
14.12.2017 22:00В этом случае нет никакого NAT, и тот же роутер Зинаиды Семеновны, у такого провайдера торчит портами наружу.
Обычно в этом случае NAT стоит в роутере. Да, роутер торчит портами наружу, но только роутер. Телефон, планшет и телевизор Зинаиды Семеновны извне недостпны.
amarao
14.12.2017 19:09Две проблемы:
1) Патернализм. Вы предлагаете решать проблему IoT ботнетов с помощью «мы запретим» (подключаться к устройствам из сети). Ничего не напоминает?
2) Зачем при stateful firewall делать трансляцию? Да, мы разрешаем по-умолчанию только established. Правило пишется в два пинка на любом современном управляемом сетевом оборудовании.
Да, IoT — это плохо, но решать его надо на уровне IoT'а. Например, обязательным отзывом уязвимых моделей за счёт производителя. Либо OTT updates, либо оплачиваешь отзыв.
Почему из-за того, что кто-то производит автомобили без тормозов, мы ставим отбойники поперёк дороги «а вдруг он купил автомобиль без тормозов? Ну что, что остальным не проехать».
qw1
14.12.2017 21:43Разве обязательный отзыв не есть разновидность «запретим»?
Опять же, за чей счёт откроют центры сертификации и всякие комиссии по отзыву? Кто будет оплачивать бюрократически-юридические процессы?
Да и принудительные updates обозначают, что есть ещё одна дыра, и при утечке ключей можно заразить кучу устройств.amarao
15.12.2017 14:03Есть большая разница «запретим, чтобы не смог сделать плохо» и «заставить отвечать за то, что сделал плохо». Разница в том, что если сделал хорошо, в первом случае всё равно запретили (на всякий случай), а во втором — не наказывали, ибо всё сделано правильно.
Второй вариант стимулирует делать правильно и хорошо, первый вариант стимулирует всю ответственность перекладывать на запрещающего дядю.
prometheus_ru Автор
14.12.2017 22:12Эм, относительно.
1. Да, я считаю патернализм оправданным, поскольку сами пользователи этого не делают (см. первую часть статьи). Делать это некому, кроме оператора.
2. Я, к сожалению, видел мало вменяемых реализаций statefull firewall, вернее, те, что видел, мне не оч. нравились.
Да, IoT — это плохо, но решать его надо на уровне IoT'а. Например, обязательным отзывом уязвимых моделей за счёт производителя. Либо OTT updates, либо оплачиваешь отзыв.
А вот это уже неисправимый идеализм. На практике, когда производитель уже продал устройство (особенно если это стартап, с настроением «пропели, а там хоть не рассветай») требовать от него отзыва наивно. Он просто не будет этого делать.
Ну а про обновления — старая песня. Через какое-то время производитель объявляет EOL, и говорит, что больше вот этот девайс не поддерживает, дальше догадаетесь.amarao
15.12.2017 14:04Что значит, «не будет делать»? Что происходит с производителем автомобиля, который «не хочет отзывать» модели с плохими тормозами?
martin74ua
14.12.2017 22:30Я прошу прощения. Ну хорошо, в4 сеть вы просканировали. А что с в6 сетью делать будете? Чем и как сканировать, ну например мой домашний /56?
prometheus_ru Автор
14.12.2017 22:39Про это было много копий поломано. Вы вряд ли будете выдавать сложный адрес из середины диапазона, если будете выдавать его вручную, это раз. Различные протоколы могут «случайно» раскрыть Ваш адрес, это два. Перехват трафика с целью выявления адресов тоже никто не отменял, пусть это и достаточно сложный путь, это три.
В Хакере про это писали.
tgz
14.12.2017 22:52Статью надо было назвать так:
«Я не умею в фаервол, поэтому как в пионернетах буду натить и срать хотел на е2е коннективити».
AkaZLOY
15.12.2017 04:10Использовать NAT в качестве средства запрета идеологически не верно, так же как и роутинг, Не для того он был создан.
zeronice
15.12.2017 08:59Если проломят роутер с натом (а их итак ломают), то проломят и все, что болтается на внутреннем интерфейсе.
Все крупные провайдеры дают в нагрузку роутеры, управляемые этими сами провайдерами автоматически. Вот и настройте в них файрволл толком, но без НАТа Если вас жаба душит подобное делать — пните юриста и добавьте в договор строчку "при обнаружении вредоносного трафика этот трафик будет блокироваться с обязательным уведомлением пользователя. Для отключения автоматической блокировки клиент должен уведомить оператора "
А требовать "включи НАТ, сволочь" от клиента — это трэш какой-то. дали мне подсеть адресов — я ее буду использовать, не дадите использовать — в суд подам за несоблюдение договора.
FSA
15.12.2017 10:14А кому его настраивать?
Что-то я запутался в логике высказываний. Т.е. вы говорите, что вы настраиваете NAT, а настроить файервол у вас некому? Т.е. для вас держать где-то кучу данных о соединениях пользователя проще, чем указать, что снаружи соединения создавать нельзя?
Komei
15.12.2017 11:53Возможно моё мнение покажется кому-то излишне жёстким, но… Тут всё должно быть как с автомобилями. Я хочу в пьяном угаре летать на своём авто по городу, без какие-либо прав и номеров (а зачем они мне?) и никак не отвечать за «всех тех козлов» которые случайно попали под мои колёса. Мне это удобно… но тут на помощь приходит государство с законами (причём в этом месте крайне полезными). И вот уже у нас есть сертификация автомобилей (попробуйте как продавать автомобиль без тормозов широким массам), номера, права, ППД, гражданская и уголовная ответственность за то, что вы натворили своим авто. Почему такого не должно быть в интернете? Решение этой проблемы это не задача оператора, а задача государства. Как только экономический урон от этих ботнетов превысит какой-то уровень, будет соотв. реакция (вспомните о том, что первых хакеров никто не осудил за взломы, потому что просто не было законов… только вот потом они быстро появились).
И да, платить за всё должны потребители. Это тот случай, когда это уместно и нормально. Появляются требования в железу, стоимость разработки возрастёт, железо подорожает. Но это, в отличии от всяких «законов яровой», как раз необходимое зло для нормального функционирования общества.
P.S. Вообще-то то, что творят сейчас операторы это скотство редкое, т.к. нормальный доступ в интернет это когда я могу пользоваться ЛЮБЫМИ протоколами на базе IP (он же не просто так называется Internet Protocol), а не только TCP, UDP и ICMP. Вообще любыми, даже не известными оператору (например самописными). Ну не операторское это дело всё что выше IP.
turbidit
15.12.2017 11:53Автор так и не рассказал, чем его
костылиNAT лучше, чем правило в firewall, отключаемое через личный кабинет.
GamePad64
15.12.2017 14:30В более-менее нормальных домашних роутерах все входящие IPv6-соединения заблокированы, а дырки в фаерволе пробиваются через PCP (или вручную). По крайней мере, в Asus так.
То, что сейчас многие роутеры дырявые и не умеют в PCP — это издержки времени, скоро производители научатся делать нормально. На стороне провайдера городить фаерволе/NAT не надо.
rogoz
Я конечно не эксперт, но если нужно всех закрыть, разве конструкция типа
-A FORWARD -i br0 -j ACCEPT-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
не работает?
prometheus_ru Автор
Проблема не в том, что она работает или не работает. Кому ее писать?
ValdikSS
Я считаю, что провайдерам нужно сделать блокировку входящих соединений по умолчанию, с возможностью ее отключения в любое время через личный кабинет. Но если такое невозможно или нетривиально, неотключаемой блокировки быть не должно.
prometheus_ru Автор
Смотрите, главный вопрос будет «Где ее втыкать, эту блокировку?». Если кратко о проблеме, то на магистральном уровне ее втыкать дорого, а на уровне свича в подъезде хлопотно и/или не всегда возможно.
ValdikSS
На устройстве, на котором вы бы настраивали NAT.
prometheus_ru Автор
Вы с пользовательской стороны имеете ввиду или с операторской?
С пользовательской — это роутер, его не надо настраивать, по дефолту настроен.
ValdikSS
Я говорю про операторскую настройку, статья же о ней. Вы собирались применить NAT (PAT) для того, чтобы не пропускать входящие соединения. Это бессмысленно, т.к. то, что вы хотите, называется отслеживанием соединений (connection tracking, stateful firewall), и реализуется без NAT.
PAT просто не может работать без отслеживания соединений. А NAT, вообще говоря, может, например, Full Cone NAT, когда один адрес просто заменяется на другой, без отслеживания соединений, и без блокировки входящих подключений.
MooNDeaR
Прошивкописателям? Путь эти строчки будут стандартом де-факто. Кому надо, те сотрут :)
ultraElephant
Ну, кто-то же написал во всех диртристах