Все сказанное выше в полной мере относиться к управлению технологическими данными, которые собираются на основе SNMP-протокола (Simple Network Management Protocol — SNMP, RFC 2274). Любой SNMP-трафик содержит IP-адреса, и поэтому центральный модуль сбора SNMP-данных или SNMP-ALG-субмодуль будут вынуждены обрабатывать SNMP-данные, основываясь на текущих преобразованиях, осуществляемых NAT-модулями.
VIII. IPv6-АДРЕСАЦИЯ
Бытует мнение, что IPv6-адресация больше не нужна, так как NAT-модули снимают ограничения на использование адресного пространства и позволяют Internet-сети продолжать свое развитие и расширение. Но реализм ситуации заключается в обратном, то есть именно NAT-модули указывают на необходимость использования IPv6-адресации, причем с большей очевидностью, чем когда бы то ни было. Люди, старающиеся соединить несколько компьютеров с помощью одной линии связи с системой Internet-провайдера, готовы отказаться от некоторой функциональности, чтобы обеспечить минимальные затраты при создании корпоративной сети. Очень часто, причиной роста затрат на создание и развитие корпоративной сети является ощущуение недостатка (порой, весьма большого) IPv4-адресов, который мог быть ликвидирован с помощью более широкого применения IPv6-адресации. Этот “кризис ума” порождает рынок решений проблемы, которая уже решена с помощью IPv6-адресации, являющейся весьма гибкой системой.
Если бы NAT-метод не был бы предложен вообще, то тогда мотивация для решения проблемы быстро уменьшающегося IPv4-адресного пространства могла быть значительно больше. Учитывая, что ежедневно NAT-модули позволяют несчетному количеству новых IP-узлов подключиться в Internet-сети, чрезвычайно трудно выяснить реальное влияние на продление “жизни” IPv4-адресации, но очевидно, что NAT-модули продлевают ее. Также весьма трудно определить начало повсеместного использования IPv6-адресации, так как эта задержка связана с применением NAT-модулей, которые облегчают бремя нехватки IPv4-адресов и “уводят” интелллектуальный потенциал Internet-сообщества от принятия и внедрения долгосрочного решения.
Но в то же самое время, NAT-метод, с функциональной точки зрения, может быть “рискованным посредником” в распространении IPv6-адресации. В сетях передачи данных несколько миллионов компьютеров используют IPv4-адресацию. Некоторые из этих сетей подключены к Internet-сети, и являются, таким образом, ее компонентами, а другие являются изолированными корпоративными сетями. Это просто невероятно, что мог быть “день флага”·, когда в одно и то же время все существующие IP-узлы, использующие IPv4-адресацию, перешли на применение IPv6-адресации. Временной интервал, в течении которого Internet-сеть и корпоративные сети будут одновременно использовать обе системы адресации, будет весьма длительным. Первоначальный план перехода на IPv6-адресацию жестко зависел от способности новых IPv6-узлов использовать систему IPv4-адресации (“dual stack” — IP-узлы со сдвоенной архитектурой). Когда IP-узел со сдвоенной архитектурой запрашивал другой IP-узел в DNS-системе, в ответном DNS-сообщении он получал, либо IPv4-адрес, либо IPv6-адрес. Если в ответном DNS-сообщении будет представлен IPv4-адрес, то тогда IP-узел будет использовать этот адрес для установления соединения с другим IP-узлом. А если в ответном DNS-сообщении будет представлен IPv6-адрес, то тогда этот адрес может быть использован для установления соединения. Включение NAT-модуля в состав программного обеспечения маршрутизатора с целью преобразования IPv6-адресации в IPv4-адресацию обеспечивает широкое распространение IPv6-адресации, несмотря на обслуживание маршрута с IPv4-адресацией, если IPv6-адресация не возможна. И несмотря на то, что в такой ситуации возникает несколько проблем, которые касаются IPv4-соединений, тем не менее NAT-модуль, преобразующий IPv6-адреса в IPv4-адреса и наоброт, фактически формирует “свозное соединение” для систем с IPv6-адресацией.
В противном случае, можно обеспечить доставку IP-пакетов между системами с IPv6- и IPv4-адресациями, если осуществлять преобразование IP-адресов на границах между сетями с разными системами адресации. Стандарт RFC 1752 конкретизировал эту функцию, определив ее как необходимую при переходе от IPv4-адресации к IPv6-адресации, и при этом сформулировал ряд специфических проблем, требующих своего решения. Одной из таких проблем является преобразование заголовка IP-пакетов (то есть NAT-метод). Конечно, проблемы функционирования NAT-модулей, которые преобразуют IPv6-адреса в IPv4-адреса и наоброт, полностью совпадают с проблемами функционирования NAT-модулей, которые преобразуют только IPv4-адреса, и поэтому данный стандарт относится к этим двум проблемным областям.
IX. ВОПРОСЫ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ
Все NAT-модули (включая их NAPT-разновидности) имеют реальную возможность для снижения общего уровня безопасности, создавая при этом иллюзию “барьера безопасности”, так как не обеспечивают достижения целей, возлагаемых на сетевые экраны (брандмауэры). В оконечном IP-узле используются необходимые способы обеспечения безопасности, вследствие недоверия к маршрутам доставки IP-пакетов, которые могут проходить через скомпрометировавшие себя сетевые зоны, сетевым фильтрам или “непонятным” NAT-модулям, которые могут все время вносить изменения в режимы функционирования прикладной службы в ближайшем IP-узле. Как правило, все барьеры безопасности предполагают, что любые угрозы являются внешними, так как практический опыт показывает, что “заделывать внутренние бреши” гораздо легче.
IPsec-архитектура (RFC 2401) определяет несколько способов аутентификации на IP-уровне (на уровне IP-пакетов) и шифрования, которое используется в IP-сетях. Несмотря на то, что безопасность на сетевом уровне менее эффективна, чем на прикладном уровне, но говоря словами стандарта RFC 1752 “проведение аутентификации на сетевом уровне будет способствовать внедрению весьма необходимой, широкомасштабной инфраструктуры обеспечения безопасности для всей Internet-сети.”
NAT-модули нарушают способы аутентификации и шифрования IPsec-архитектуры, так как эти способы защиты информации зависят от IP-адресов в заголовках IP-пакетов транслируемых по сквозному соединению. Более того, NAT-модули могут затормозить дальнейшее распространение высоконадежных способов защиты информации в Internet-сети. Функционирование NAT-модулей влечет за собой появление нескольких специфических проблем, связанных с IPsec-архитектурой. Например:
применение АН-протокола невозможно, так как специальная хэш-функция защищает IP-адрес в заголовке IP-пакета;
аутентифицированные электронные сертификаты могут содержать IP-адрес в качестве элемента имени субъекта, который проходит процедуру аутентификации;
при использовании шифрования в “Ускоренном режиме” информационного обмена в период формирования защищенного виртуального соединения отдельные сообщения могут содержать IP-адреса и номера портов транспортного уровня с целью определения выбранной стратегии обеспечения информационной безопасности;
при использовании шифрования с открытыми ключами в период проведения информационного обмена в “Режиме модификации” отдельные сообщения будут содержать данные, удостоверяющие пользователей, в зашифрованном поле полезной нагрузки.
Существует возможность спроектировать и внедрить NAT-модули, способные функционировать совместно с IPsec-архитектурой, но весьма дифференцированно и в зависимости от конкретного случая, причем ценою ограничений на модель обеспечения надежности. Со всеми этими ограничениями, накладываемыми на системы обеспечения безопасности, NAT-модули представляют собой весьма существенное препятствие для интеграции систем защиты, которая имеет место в настоящее время в Internet-сети.
Как определено в стандарте RFC 2694, DNS-ALG-субмодуль обеспечить безопасность DNS-серверов в коропоративных сетевых сегментах. Внутризональные процедуры информационного обмена между DNSSEC-серверами, обеспечивающие необходимую модификацию данных в DNS-БД (база данных DNS-системы), потерпят провал. Это относится и к тем случаям, когда DNS-ALG-субмодуль “искажает” любые подписанные ответные DNS-сообщения, содержащие измененные DNS-данные. Например, это может быть случай, когда все DNS-запросы относительно объектов в сети общего пользования, направляются корпоративными IP-узлами, а DNS-сервер расположен внутри корпоративной сети. Все сказанное выше справедливо и в случае, когда все DNS-запросы относительно объектов корпоративной сети, направляются корпоративными IP-узлами, а DNS-сервер расположен в сети общего пользования. Любой DNS-ALG-субмодуль может только тогда модифицировать RR-записи с ЭЦП (подписанные DNS-данные), когда он имеет доступ к ключу, аутентифицированному источником DNS-данных. Группа DNSSEC-протоколов была специально разработана для того, чтобы исключить процедуру распределения этого ключа по сети, и для проведения процедуры аутентификации источника DNS-данных. Очевидно, что NAT-модули, которые используют DNS-ALG-субмодули для исправления DNS-имен объектов в DNS-запросах относительно IP-адресов, будут:
нарушать безопасность при изменении RR-записей в DNS-БД;
требовать доступа к ключам всех источников DNS-данных при получении на обработку DNS-запросов относительно IP-адресов.
Те способы обеспечения безопасности, которые не защищают или не транслируют IP-адреса в качестве идентификаторов (такие как TLS, SSL и SSH), могут функционировать в обслуживаемых NAT-модулями сетевых сегментах. Если прикладные службы способны формировать и использовать такого типа соединения, то тогда NAT-модули не будут создавать дополнительных проблем для их функционирования. Такие способы обеспечения безопасности не способны эффективно защитить все прикладные службы, так как IP-заголовок полностью открыт (не защищен), и они не запрещают проведение “губительных” управляющих процедур, подобных переходу на новый ТСР-сеанс связи.
Аргументы в пользу того, что NAT-модули могут функционировать в защищенном режиме, искажают смысл обеспечения безопасности сквозного соединения, так как NAT-модуль берет на себя роль оконечного объекта безопасности в сквозном соединении. С функциониальной точки зрения, NAT-модуль должен быть управляемым, как элемент защищаемого сетевого сегмента, и в этом режиме IP-пакеты, циркулирующие с незащищенной стороны NAT-модуля, полностью открыты (не защищены).
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 |


