Транслятор сетевых ip-адресов с точки зрения internet-архитектуры (nat) (стр. 8 )

В противном случае, можно обеспечить доставку 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-модуля, полностью открыты (не защищены).

X. ПРАВИЛА РАСПРОСТРАНЕНИЯ NAT-МОДУЛЕЙ В

  INTERNET-СЕТИ

У, что NAT-модули продолжают распространяться в Internet-сети с довольно приличной скоростью, далее перечислены некоторые правила, которые по своей сути являются и предостерегающими, и рекомендательными:

определить способ получения IP-адресов по DNS-именам и обеспечить гарантированное получение необходимого ответа на каждый запрошеный IP-адрес у соответствующей DNS-администрации. Встроенный в NAT-модуль DNS-сервер или DNS-ALG-субмодуль будет, скорее всего, более управляемым, нежели попытки синхронизировать независимые DNS-системы, принадлежащие различным DNS-администрациям; определить настройку NAT-модуля: статическое или динамическое однозначное отображение IP-адресов. Если динамическое: убедиться, что TTL для ответных DNS-сообщений имеет значение “0”, и что DNS-клиенты уделяют внимание тому, чтобы служебные DNS-сообщения не хранились в кэш-памяти; определить разновидность используемого NAT-модуля: одиночный или параллельный (на несколько маршрутов). Если одиночный, то тогда учитывайте то, что NAT-модуль будет вносить сбои в работе системы. Если многомаршрутный, необходимо определить как настроить маршрутизаторы с обеих стороны NAT-модуля, чтобы поток IP-пакетов гарантированно проходил через один и тот же NAT-модуль в течении всех сеансов связи, инициированных прикладными службами (процессами); проверить прикладные службы, которым необходим для пробразования IP-адресов NAT-модуль, и проверить их иммунитет к трансляции IP-адресов. Если необходимо, использовать ALG-субмодуль или сформировать VPN-интерфейс для изоляции прикладной службы от NAT-модуля; установить необходимость в установлении соединений со стороны IP-узлов сети общего пользования с корпоративными IP-узлами, перечень корпоративных IP-узлов получателей сообщений, переданных IP-узлами сети общего пользования, и возможность одновременного использования номеров портов транспортного уровня в сети общего пользования. Если используются NAPT-модули, то они усложняют процедуры администрирования; если сообщения прикладных служб транслируются через NAPT - или RSIP-модуль, а это предполагает наличие всех номеров портов транспортного уровня с одним внешним IP-адресом (сети общего пользования), то тогда проверить, что этот IP-адрес должен принадлежать одному и тому же IP-узлу. Для преотвращения одновременного доступа нескольких корпоративных IP-узлов в сеть общего пользования потребуется административное управление; если поля полезной нагрузки транслируемых сообщений шифруются, то тогда содержание этих полей не может быть преобразовано, пока NAT-модуль не будет являться оконечной точкой защищеного сквозного соединения и выступать в роли шлюза между защищаемыми сетевыми сегментами. Это препятствует формированию реального защищенного сквозного соединения, так как часть маршрута доставки IP-пакетов между NAT-модулем и реальным оконечным IP-узлом становится открытой (не защищенной); определить маршрут следования DNS-сообщений (запросов и ответов на них). Если IP-узлы расположены с корпоративной стороны NAPT - или RSIP-модуля, и полагая что DNS-серверы должны “видеть друг друга”, то тогда может понадобиться дополнительный DNS-сервер в корпоративном сетевом сегменте; если в DNS-системе используются защищенные RR-записи (DNS-данные), то тогда DNS-ALG-субмодуль должен иметь доступ к криптоключам аутентифицированного источника DNS-данных, если эти данные транслируются через NAT-модуль; когда используются VPN - и NAT-технологии одновременно, то тогда во избежание коллизий необходимо определить информационно-распределительный центр для корпоративных IP-адресов; убедитесь в том, что прикладные службы, используемые внутри и за пределами корпоративной сети, исключают вставку корпоративных DNS-имен в сообщения или применяют уникальные зарегистрированные DNS-имена; если используется RSIP-модуль, необходимо установить предельную границу для конкретной корпоративной сети, соединенной с Internet-сетью. Так как если на маршруте доставки IP-пакетов будут встречаться другие разновидности NAT-модулей (включая модули распределения загрузки W3-серверов), то тогда RSIP-туннель (сквозное использование адресного блока — адрес/порт) будет нарушен; если используется RSIP-модуль, необходимо определить вероятность сбоев, вызванных переходом ТСР-протокола в режим ожидания “TCP_TIME_WAIT”, когда последующие корпоративные IP-узлы пытаются соединиться с только что завершившим сеанс связи IP-узлом в сети общего пользования.

XI. ЗАКЛЮЧЕНИЕ