Comments 25
Хотелось бы услышать про обеспечение безопасности внутренних сервисов буквально парой правил. Пока что у меня бытует мнение, что IPv6 довольно хорошая дырка внутрь сети при неправильном подходе.
-1
Если запрещать все входящие IPv6-соединения по умолчанию, то работать он будет примерно так же, как и за NAT в IPv4. Зато на каждый компьютер свой IP, никаких проблем.
+2
Хм.
На CentOS 7 по умолчанию все закрыто.
Дырки из-за дырявых рук.
На CentOS 7 по умолчанию все закрыто.
Дырки из-за дырявых рук.
0
Нет, на самом деле бытует ошибочное мнение, будто NAT — инструмент безопасности.
+4
А можете привести примеры атак именно на NAT/PAT?
-1
Что вы понимаете под «атакой на NAT/PAT»?
Проблемы в реализации конкретного вендора? Возможность использовать его как инструмент для совершения вредоносной активности?
Моя реплика изначально была в том ключе, что обычный -j MASQUERADE считают достаточным уровнем защиты локальной сети. Хотя уровень защиты, обеспечиваемый подобным решением, ничем не превосходит аналогичное решение для IPv6 в виде -m state! RELATED,ESTABLISHED -j DROP, но при этом значительно сужает возможности.
Проблемы в реализации конкретного вендора? Возможность использовать его как инструмент для совершения вредоносной активности?
Моя реплика изначально была в том ключе, что обычный -j MASQUERADE считают достаточным уровнем защиты локальной сети. Хотя уровень защиты, обеспечиваемый подобным решением, ничем не превосходит аналогичное решение для IPv6 в виде -m state! RELATED,ESTABLISHED -j DROP, но при этом значительно сужает возможности.
0
# Если интерфейс lan смотрит в локальную сеть, то эти правила разрешают для IPv4/IPv6 только запрошенный из ЛС трафик.
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i lan -m state --state NEW -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i lan -m state --state NEW -j ACCEPT
0
Гораздо интереснее на ipv6 делается фейловер.
Ибо маскардинг — штука простая. Меняем маршрут в default gateway, сбрасываем таблицу соединений — и снова всё работает. А вот как перебросить ipv6 /64 на другой аплинк — пока представляю очень слабо.
Ибо маскардинг — штука простая. Меняем маршрут в default gateway, сбрасываем таблицу соединений — и снова всё работает. А вот как перебросить ipv6 /64 на другой аплинк — пока представляю очень слабо.
-1
Почему-же, с учетом количества доступных IPv6-адресов, в будущем, не должно быть проблем с тем, чтобы получить свой блок PI-адресов, далее по BGP анонсировать их обоим аплинком. Вот вам фейловер и балансировка! :)
Если же, речь о домашних пользователях, то есть такие вещи как NATv6 Prefix Translation, ну или же, обновлять по ICMPv6/DHCPv6 Анонсируемый префикс (получаемый от второго аплинка), в таком случае, адресация конечных машин будет неизменной. Просто, сменится префикс.
Если же, речь о домашних пользователях, то есть такие вещи как NATv6 Prefix Translation, ну или же, обновлять по ICMPv6/DHCPv6 Анонсируемый префикс (получаемый от второго аплинка), в таком случае, адресация конечных машин будет неизменной. Просто, сменится префикс.
0
Маршрутизация потребует меньшего количества ресурсов, чем традиционный проброс портов. Упростится мониторинг сети.
Почему?
Почему?
0
Навскидку:
проброс портов — приняли пакет, посмотрели в таблицу NAT, подменили адреса/порты в заголовке, передали дальше
маршрутизация — приняли пакет, посмотрели таблицу маршрутизации, передали дальше
Проброс чуть длиннее операция, плюс на многих железяках маршрутизация работает практически без нагрузки на центральный процессор
проброс портов — приняли пакет, посмотрели в таблицу NAT, подменили адреса/порты в заголовке, передали дальше
маршрутизация — приняли пакет, посмотрели таблицу маршрутизации, передали дальше
Проброс чуть длиннее операция, плюс на многих железяках маршрутизация работает практически без нагрузки на центральный процессор
0
Добавлю еще, что на некоторых железяках маршрутизация работает НЕ "… практически без нагрузки на центральный процессор", а совершенно без нагрузки на ЦП и в обход его, на отдельных микросхемах.
0
А IPv6 эти железки умеют, или скидывают на процессор, который к этому совершенно не готов?
0
Современные Л3-коммутаторы отлично маршрутизируют и IPv4 и IPv6 аппаратно, на скорости порта. С пакет-фильтром(stateless-файрволом), динамической маршрутизацией и прочими радостями.
Железки, способные делать быстрый NAT стоят намного дороже, а их функционал и область применения ограничены: это либо небольшие SOHO мыльницы, либо Security-девайсы по цене вертолета, либо специализированные Carrier Grade NAT платы/устройства по цене самолета.
Железки, способные делать быстрый NAT стоят намного дороже, а их функционал и область применения ограничены: это либо небольшие SOHO мыльницы, либо Security-девайсы по цене вертолета, либо специализированные Carrier Grade NAT платы/устройства по цене самолета.
0
либо Security-девайсы по цене вертолета
ASA стоит разумных денег, у железки за 150 тыр заявлено 180 Мбит для IPS, а простой NAT с FW наверняка и гигабит вытянет.
0
Мы убираем полностью одну функцию — NAT. А значит меньше нагрузка на железо, меньше возможных багов, ошибок при настройке и прочего. Что в любом раскладе хорошо. Просто мы привыкли к NAT, как данности. При этом вряд ли мы поставим на периметр сети компании обычный L3-коммутатор, даже если функций NAT нам не требуется. Всё равно потребуется какой-нибудь более менее нормальный FW/NGFW (statefull).
Другое дело, как я понимаю, провайдеры. Они, избавившись от NAT, могут достаточно хорошо сэкономить на железе.
Другое дело, как я понимаю, провайдеры. Они, избавившись от NAT, могут достаточно хорошо сэкономить на железе.
0
«Коммерческое использование» предусматривает получение прибыли, не?
По-моему, тема «перспективы использования IPv6 в целях извлечения прибыли» не раскрыта…
По-моему, тема «перспективы использования IPv6 в целях извлечения прибыли» не раскрыта…
0
В данном контексте «коммерческое» подразумевает использование с целью предоставления услуг, а не в тестовом режиме. См. выводы в конце: если вы предоставляете сервисы, то применять IPv6 можно и нужно. Если вы предоставляете доступ в Интернет конечным пользователям, то внедрение IPv6 принесет пока только дополнительные проблемы для техподдержки пользователей.
0
Оффтоп: это у вас на заббиксе шкурка такая или заббикс сам новой версии?
0
В 2016 году актуальнее будет заметка «Перспективы коммерческого использования сети Интернет в России (год 2016)»
-3
Sign up to leave a comment.
Перспективы коммерческого использования IPv6 в России (год 2016)