Классификация firewall’ов и определение политики firewall’а

Выделенные прокси-серверы

Выделенные прокси-серверы отличаются от прикладных прокси в том, что они анализируют трафик только конкретного прикладного протокола и не обладают возможностями анализа всего трафика, что все-таки характерно для firewall’а прикладного уровня. По этой причине они обычно развертываются позади firewall’ов прикладного уровня. Типичное использование таково: основной firewall получает входящий трафик, определяет, какому приложению он предназначен, и затем передает обработку конкретного типа трафика соответствующему выделенному прокси-серверу, например, e-mail прокси серверу. Выделенный прокси-сервер при этом выполняет операции фильтрации и логирования трафика и затем перенаправляет его во внутренние системы. Этот сервер может также принимать исходящий трафик непосредственно от внутренних систем, фильтровать трафик и создавать логи, а затем передавать его firewall’у для последующей доставки. Обычно выделенные прокси-серверы используются для уменьшения нагрузки на firewall и выполнения более специализированной фильтрации и создания логов.

Как и в случае прикладных прокси, выделенные прокси позволяют выполнить аутентификацию пользователей. В случае использования выделенного прокси легче более точно ограничить исходящий трафик или проверять весь исходящий и входящий трафик, например, на наличие вирусов. Выделенные прокси-серверы могут также помочь в отслеживании внутренних атак или враждебного поведения внутренних пользователей. Фильтрация всего исходящего трафика сильно загружает общий firewall прикладного уровня и увеличивает стоимость администрирования.

В дополнение к функциям аутентификации и создания логов, выделенные прокси-серверы используются для сканирования web и e-mail содержимого, включая следующие функции:

• фильтрование Java-апплетов или приложений;
• фильтрование управлений ActiveX;
• фильтрование JavaScript;
• блокирование конкретных MIME-типов – например, "application/msword";
• сканирование и удаление вирусов;
• блокирование команд, специфичных для приложения, например, блокирование НТТР-команды PUT;
• блокирование команд, специфичных для пользователя, включая блокирование некоторых типов содержимого для конкретных пользователей.

Рис. 1.4. Примеры выделенных прикладных прокси-серверов

На рис. 1.4 показан пример топологии сети, которая имеет выделенные прокси-серверы для НТТР и e-mail, расположенные позади основного firewall’а. В этом случае e-mail прокси может быть SMTP-шлюзом организации для входящей почты. Основной firewall будет перенаправлять входящую почту к прокси для сканирования содержимого, после чего почта может становиться доступной внутренним пользователям на SMTP-сервере, например, по протоколам РОР3 или IMAP. НТТР-прокси должен обрабатывать исходящие соединения ко внешним web-серверам и, возможно, фильтровать активное содержимое. Прокси-сервером может выполняться кэширование часто используемых web-страниц, тем самым уменьшая трафик к firewall’у.

Гибридные технологии firewall’а

Недавние разработки в области сетевой инфраструктуры и информационной безопасности привели к стиранию границ между различными типами firewall’ов, которые обсуждались выше. Как результат, программные продукты firewall’ов соединяют функциональности нескольких различных типов firewall’ов. Например, многие производители прикладных прокси реализуют базовую функциональность пакетных фильтров.

Также многие разработчики пакетных фильтров или stateful inspection пакетных фильтров реализуют базовую функциональность прикладных прокси для ликвидации слабых мест, связанных с этими типами firewall’ов. В большинстве случаев производители реализуют прикладные прокси для улучшения создания логов и аутентификации пользователя.

После того как все основные производители будут использовать в своих продуктах в том или ином виде гибридные технологии, не всегда просто будет решить, какой продукт наиболее подходит для данного приложения или инфраструктуры предприятия. Гибридные свойства платформ firewall’ов делают особенно важной фазу оценки firewall’а. При выборе продукта важнее оценить поддерживаемое количество возможностей, чем формально смотреть тип firewall’а.

Трансляция сетевых адресов (NAT)

Технология трансляции сетевых адресов ( NAT ) была разработана для решения двух важных проблем, возникших в сетевой инженерии и безопасности. Во-первых, NAT является эффективным средством для скрытия схемы сетевой адресации позади firewall’а. В сущности, трансляция сетевых адресов позволяет организации развертывать схему адресации позади firewall’а в соответствии со своим выбором, в то же время поддерживая возможность соединяться с внешними ресурсами через firewall. Во-вторых, это решает проблему исчерпания пространства IP-адресов.

NAT выполняется в трех основных формах: статическая трансляция сетевых адресов, скрытая трансляция сетевых адресов и трансляция портов.

Статическая трансляция сетевых адресов

При статической трансляции сетевых адресов каждая внутренняя система или частная сеть имеет соответствующий, связанный с ней внешний IP-адрес. Данная технология используется редко из-за недостатка доступных IP-адресов. При статической трансляции сетевых адресов возможно предоставление доступа к ресурсам, размещенным позади firewall’а. Другими словами, внешняя система может иметь доступ ко внутреннему web-серверу; при этом адрес отображается с использованием статической трансляции сетевых адресов. Ниже приведен пример таблицы статической трансляции сетевых адресов, отображающей внутренние IP-адреса, к которым не выполняется роутинг, во внешние адреса, к которым выполняется роутинг.

Скрытая трансляция сетевых адресов

При скрытой трансляции все системы позади firewall’а разделяют некоторый внешний IP-адрес, к которому выполняется роутинг. Таким образом, при скрытой трансляции сетевых адресов все хосты позади firewall’а будут выглядеть как один хост. Такой тип трансляции является достаточно распространенным, но имеет одно существенное слабое место. Данная технология не позволяет сделать доступными для внешних пользователей те ресурсы, которые размещены позади firewall’а. Отображение от внешних систем во внутренние системы невозможно, следовательно, хосты, которые должны быть доступны внешним системам, не могут применять данное отображение адресов. Другое слабое место данного подхода состоит в том, что firewall в этом случае должен использовать свой собственный внешний интерфейсный сетевой адрес в качестве "заменяемого" или транслируемого адреса для всех систем и ресурсов, которые расположены позади него. Данное требование приводит к уменьшению гибкости данного механизма.