Pull to refresh

Comments 25

Хотелось бы услышать про обеспечение безопасности внутренних сервисов буквально парой правил. Пока что у меня бытует мнение, что IPv6 довольно хорошая дырка внутрь сети при неправильном подходе.
Если запрещать все входящие IPv6-соединения по умолчанию, то работать он будет примерно так же, как и за NAT в IPv4. Зато на каждый компьютер свой IP, никаких проблем.
Хм.
На CentOS 7 по умолчанию все закрыто.
Дырки из-за дырявых рук.
В 7.2 minimal файервол по умолчанию даже не установлен.
Хм.
Тогда пофиг, что IPv4, что IPv6.
Устанавливаем файервол и все закрыто.
Нет, на самом деле бытует ошибочное мнение, будто NAT — инструмент безопасности.
А можете привести примеры атак именно на NAT/PAT?
Что вы понимаете под «атакой на NAT/PAT»?
Проблемы в реализации конкретного вендора? Возможность использовать его как инструмент для совершения вредоносной активности?

Моя реплика изначально была в том ключе, что обычный -j MASQUERADE считают достаточным уровнем защиты локальной сети. Хотя уровень защиты, обеспечиваемый подобным решением, ничем не превосходит аналогичное решение для IPv6 в виде -m state! RELATED,ESTABLISHED -j DROP, но при этом значительно сужает возможности.
# Если интерфейс lan смотрит в локальную сеть, то эти правила разрешают для IPv4/IPv6 только запрошенный из ЛС трафик.
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i lan -m state --state NEW -j ACCEPT
Гораздо интереснее на ipv6 делается фейловер.
Ибо маскардинг — штука простая. Меняем маршрут в default gateway, сбрасываем таблицу соединений — и снова всё работает. А вот как перебросить ipv6 /64 на другой аплинк — пока представляю очень слабо.
Почему-же, с учетом количества доступных IPv6-адресов, в будущем, не должно быть проблем с тем, чтобы получить свой блок PI-адресов, далее по BGP анонсировать их обоим аплинком. Вот вам фейловер и балансировка! :)
Если же, речь о домашних пользователях, то есть такие вещи как NATv6 Prefix Translation, ну или же, обновлять по ICMPv6/DHCPv6 Анонсируемый префикс (получаемый от второго аплинка), в таком случае, адресация конечных машин будет неизменной. Просто, сменится префикс.
Маршрутизация потребует меньшего количества ресурсов, чем традиционный проброс портов. Упростится мониторинг сети.

Почему?
Навскидку:
проброс портов — приняли пакет, посмотрели в таблицу NAT, подменили адреса/порты в заголовке, передали дальше
маршрутизация — приняли пакет, посмотрели таблицу маршрутизации, передали дальше
Проброс чуть длиннее операция, плюс на многих железяках маршрутизация работает практически без нагрузки на центральный процессор
Добавлю еще, что на некоторых железяках маршрутизация работает НЕ "… практически без нагрузки на центральный процессор", а совершенно без нагрузки на ЦП и в обход его, на отдельных микросхемах.
А IPv6 эти железки умеют, или скидывают на процессор, который к этому совершенно не готов?
Современные Л3-коммутаторы отлично маршрутизируют и IPv4 и IPv6 аппаратно, на скорости порта. С пакет-фильтром(stateless-файрволом), динамической маршрутизацией и прочими радостями.
Железки, способные делать быстрый NAT стоят намного дороже, а их функционал и область применения ограничены: это либо небольшие SOHO мыльницы, либо Security-девайсы по цене вертолета, либо специализированные Carrier Grade NAT платы/устройства по цене самолета.
либо Security-девайсы по цене вертолета

ASA стоит разумных денег, у железки за 150 тыр заявлено 180 Мбит для IPS, а простой NAT с FW наверняка и гигабит вытянет.
Это все равно не сопоставимо с line-rate 10G-портов на Л3-коммутаторах. Хотя FW туда сложно впихнуть, да
Мы убираем полностью одну функцию — NAT. А значит меньше нагрузка на железо, меньше возможных багов, ошибок при настройке и прочего. Что в любом раскладе хорошо. Просто мы привыкли к NAT, как данности. При этом вряд ли мы поставим на периметр сети компании обычный L3-коммутатор, даже если функций NAT нам не требуется. Всё равно потребуется какой-нибудь более менее нормальный FW/NGFW (statefull).
Другое дело, как я понимаю, провайдеры. Они, избавившись от NAT, могут достаточно хорошо сэкономить на железе.
«Коммерческое использование» предусматривает получение прибыли, не?

По-моему, тема «перспективы использования IPv6 в целях извлечения прибыли» не раскрыта…
В данном контексте «коммерческое» подразумевает использование с целью предоставления услуг, а не в тестовом режиме. См. выводы в конце: если вы предоставляете сервисы, то применять IPv6 можно и нужно. Если вы предоставляете доступ в Интернет конечным пользователям, то внедрение IPv6 принесет пока только дополнительные проблемы для техподдержки пользователей.
Оффтоп: это у вас на заббиксе шкурка такая или заббикс сам новой версии?
Просто заббикс, недавно скачанный с офсайта. Ничего специально не красил. Кстати вебморда работает (практически) без глюков на lighttpd и php 71.
В 2016 году актуальнее будет заметка «Перспективы коммерческого использования сети Интернет в России (год 2016)»
Sign up to leave a comment.

Articles