Брандмауэр и виртуальная частная сеть

Очень часто брандмауэры и виртуальные частные сети обсуждаются в пределах одного контекста. Ведь, по сути, брандмауэры контролируют доступ к ресурсам, а VPN-устройства отвечают за безопасность каналов связи между сетевыми компьютерами. Поэтому очень важно понимать основы взаимодействия брандмауэров и вир­туальных частных сетей:

· В зависимости от сетевой архитектуры, крайне важная функция трансляции сетевых адресов NAT (Network Address Translation) может оказаться несовмес­тимой с некоторыми реализациями VPN.

· VPN способны создавать сквозные связующие "туннели", проходящие через сетевой периметр, а потому крайне проблемные в плане контроля доступа со стороны брандмауэра, которому трудно анализировать зашифрованный тра­фик.

· Только конечные точки VPN-канала обладают доступом к данным в незашиф­рованном виде, поскольку именно VPN-устройства отвечают за дешифрацию и аутентификацию данных; сам по себе такой подход может гарантировать определенную защищенность VPN-устройств.

Благодаря своим функциям шифрования и охраны конфиденциальности пе­редаваемых данных, VPN можно использовать для обхода IDS-систем (IDS - Intrusion Detection Systems, Системы обнаружения вторжений), не спо­собных обнаружить вторжения со стороны зашифрованных каналов связи.

По сути, во время принятия решения о внедрении VPN-компонентов в сетевую архитектуру администратор сети стоит перед выбором из двух вариантов: поддержка VPN-модуля в качестве обособленного от брандмауэра устройства или же интегра­ция VPN в брандмауэр для обеспечения обеих функций одной системой. Разумеет­ся, каждый из этих вариантов наделен своими сильными и слабыми сторонами.

Брандмауэр плюс VPN в качестве обособленного, внешнего устройства.

Существует множество вариантов проектирования сети, позволяющих сделать конечную точку VPN внешним по отношению к брандмауэру устройством. Далее пере­числены наиболее типичные варианты размещения аппаратного обеспечения VPN:

· внутри DMZ-зоны, между брандмауэром и граничным маршрутизатором;

· внутри подзащитной сети, на сетевых адаптерах брандмауэра;

· внутри экранированной сети, позади брандмауэра;

· параллельно с брандмауэром на точке входа в подзащитную сеть.

Система трансляции адресов NAT является причиной большинства проблем, возникающих в случае обособленного по отношению к брандмауэру варианта раз­мещения VPN-оборудования. Например, в случае применения какой-либо схемы аутентификации вроде АН-заголовка, исходящие пакеты, которые вначале проходят обработку в VPN-устройстве и лишь затем обрабатываются брандмауэром для трансляции адресов, скорее всего не смогут пройти проверку целостности на другом конце VPN-соединения. Это происходит потому, что во время расчета контрольной суммы пакета с АН-аутентификацией принимаются во внимание все его заголовки. Проблема в том, что во время последующей трансляции адресов, NAT заменяет адрес источника пакета, а, значит, рассчитанная на предыдущем этапе контрольная сумма оказывается ошибочной. Еще одна проблема отдельно расположенных VPN-устройств заключается в управлении адресами: некоторые из VPN-спецификации требуют, чтобы внешнее VPN-устройство обладало легальным IP-адресом. Например, в случае аутентифика­ции согласно стандарту Х.509, сбой может произойти на IKE-фазе работы IPSec из-за того, что данный стандарт привязан к конкретным сетевым адресам, которые за­меняются согласно схеме NAT-преобразования.

Большинство вышеперечисленных потенциальных проблем с NAT-преобразова­ниями адресов можно решить путем размещения VPN-устройств ближе к внешнему миру, т.е. между брандмауэром и маршрутизатором, но это, в свою очередь, может вызвать ряд принципиально иных проблем. Многие читатели, вероятно, знают, что большинство приложений, использующих в своей работе DCOM-протоколы (Distributed Component Object Model - распределенная модель компонентных объектов) не работают с некоторыми применениями NAT. Это вызвано тем, что сис­тема трансляции адресов NAT преобразует только расположенные в заголовках па­кетов адреса источника, а приложения (на уровне протоколов прикладного уровня OSI) вкладывают информацию об адресе и в содержимое пакета.

Еще одним очевидным недостатком размещения VPN-устройств перед брандма­уэром является отсутствие соответствующей защиты с его стороны. Другими слова­ми, в случае взлома VPN-системы, злоумышленник получает прямой доступ к дан­ным, конфиденциальность которых обеспечивалась средствами VPN.

Брандмауэр и VPN, размещенные как единое целое.

Вариант устройства, объединяющего функции брандмауэра и VPN в одной сис­теме, наверняка позволит сэкономить определенное количество денег по сравне­нию с решением, использующим два отдельных устройства. Правда, большая часть этой экономии не касается первоначальных затрат на приобретение соответствую­щего комплекса средств, поскольку добавление к брандмауэру VPN-функциональ­ности потребует покупки дополнительных программных лицензий, а также, воз­можно, обновления аппаратной части. Иначе говоря, интегрированное решение оказывается менее дорогостоящим в плане своего дальнейшего технического сопро­вождения. Более того, коммерческие реализации VPN наподобие Check Point VPN-1 могут похвастаться интеграцией в графическую оболочку, используемую для управ­ления соответствующим брандмауэром Check Point. Большинство интегрированных решений попросту не вызывают ранее описанных проблем, связанных с NAT, а зна­чит, обеспечивают более надежный доступ к данным, за который отвечает брандма­уэр.

Один из главных минусов интегрированного решения заключается в ограничен­ности вариантов оптимизации соответствующих VPN и брандмауэр-компонент. Другими словами, максимально удовлетворяющие запросам реализации брандмауэ­ров могут оказаться не приспособленными к построению на их основе VPN-компо­нентов. А значит, вполне возможны ситуации, в которых выгоднее обратиться к ранее рассмотренному варианту применения внешнего специализированного VPN-устройства. Иначе использование интегрированного решения лишь привяжет сеть к пожизненно неизменному и неоптимальному применению брандмауэра и VPN в рамках одной системы.