Thursday, October 18th, 2018

Настройка членов домена в демилитаризованной зоне между двумя ISA-серверами – Часть 1: Концепции демилитаризованной зоны и зон безопасности

Published on Февраль 10, 2009 by   ·   Комментариев нет

В первой части статьи, посвященной настройке членов домена с двумя ISA-серверами в демилитаризованной зоне, мы обсудим концепции создания ДМЗ.

Если вы хотите прочитать другие части этой статьи, то, пожалуйста, перейдите по ссылкам:

Демилитаризованные зоны – это интенсивно обсуждаемая тема нашего времени. Я прочел много статей, посвященных смерти ДМЗ, о том, что ДМЗ больше не нужны, что ДМЗ не предоставляют никакой дополнительной безопасности, что использовать ДМЗ нереально, поскольку единственно реальная защита основана на отдельных узлах, что ДМЗ не нужны, поскольку брандмауэры сами по себе неэффективны, и потому больше не требуются, и что нет разницы (в вопросе безопасности) между любыми сетями с выходом в Интернет (или вообще любыми сетями).

Должен признать, что все эти статьи, рассуждения и диссертации достаточно интересны, и иногда в них содержатся идеи, заслуживающие внимания. Почти все они имеют целью развлечь аудиторию, поскольку в них авторам присущ полет фантазии. Но в целом, общая идея того, что ДМЗ (которые являются обычными зонами безопасности) мертвы или не предоставляют дополнительной защиты и контроля доступа, на 98,6 % является полной ерундой.

ДМЗ становятся зонами безопасности

Проблема, с которой сталкиваются эти «специалисты» по безопасности, состоит в том, что все ДМЗ создаются по-разному. Не все узлы принадлежат одной и той же зоне безопасности. Узлы, принадлежащие различным зонам безопасности, должны быть разделены устройствами контроля доступа для уменьшения (обратите внимание: не для предотвращения) быстрого распространения несанкционированных действий из одной зоны безопасности в другие. Непонимание этого означает добровольный отказ от недоверия.

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

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

Однако, я уверен, что торжество безопасности, основанной на отдельных узлах, не придет еще в течение двух-трех десятков лет, а то и вообще никогда не придет. Поэтому использование устройств, установленных меж зон безопасности, будет по-прежнему необходимо и популярно. Моя уверенность базируется на знании медицины и законов. В медицине вирусы и бактерии изменяются для подавления наших попыток создать действительно эффективное противовирусное средство; а законы пытаются уменьшить проявления преступности с момента ее появления. Хакеры и другие сетевые преступники ничем не отличаются от вредных микробов или бандитов, они будут существовать и в будущем, и лучшие из них будут придумывать свои методики и средства для разрушения самых серьезных систем защиты.

Вот почему нам всегда будет нужен брандмауэр как устройство безопасности, которое предоставляет сильную защиту. Брандмауэры продолжат появляться, и в будущем мы наверняка увидим объединение функций современных брандмауэров с функциями обычной проверки на уровне пакетов, обычной проверки на уровне приложений, IPS и IDS в одном устройстве. Главное препятствие – это производительность системы, но мы по опыту знаем, что эта проблемы рано или поздно будет решена. Маркетологи, конечно, поменяют термин «брандмауэр» на что-нибудь другое (поскольку нынешний брандмауэр к тому времени станет устаревшим устройством), но брандмауэры будут существовать, как бы их не называли торговцы и профаны от безопасности.

Имейте в виду, что демилитаризованная зона – это не только то место, в котором корпоративная сеть встречается с Интернетом. Нет одной демилитаризованной зоны, но есть несколько демилитаризованных зон. Часто бывает очень трудно общаться с администраторами брандмауэров 90-х годов прошлого века, которые считают устройства фильтрации пакетов серьезными решениями для безопасности и рассуждают только об «открытии и закрытии портов». Все сети, кроме наипростейших, имеют несколько демилитаризованных зон, и устройства контроля доступа (такие, как ISA-сервер) должны быть расположены на их границе для их разделения. Вот одна из главных причин того, почему я не люблю односетевые ISA-серверы: односетевой ISA-сервер дает лишь иллюзию защиты, и, поскольку он не является пограничным устройством, его очень легко обойти.

Определите зоны безопасности

Ключевой идеей в создании ДМЗ является расположение компьютеров в различных зонах безопасности в разных сегментах, причем сегменты разделены сетевыми устройствами безопасности, такими как ISA-сервер. Вам нужно суметь определить зоны безопасности. Есть много способов для их определения, вот некоторые из них:

  • Зона может содержать все службы, выполняющие похожие функции
  • Зона может содержать все компьютеры, входящие в один и тот же домен Active Directory
  • Зона может содержать все службы, которые зависят друг от друга
  • Зона может содержать все компьютеры под управлением недоверенных пользователей
  • Зона может содержать все устройства, управляемые доверенным партнером
  • Зона может содержать все устройства с выходом в Интернет

Серьезное обсуждение классификации и сегментации зон безопасности выходит за пределы данной статьи. Я хочу рассказать об одном из важных методов определения зон безопасности: расположение в зоне безопасности устройств с выходом в Интернет, отделенных от остальных устройств (без выхода в Интернет).

Термин «с выходом в Интернет» означает, что к данным компьютерам или устройствам возможны входящие соединения. Считается, что любое устройство, принимающее соединения от узлов Интернета, имеет выход в Интернет. Расположение всех устройств с выходом в Интернет в сегментах сети, отделенных от устройств без выхода в Интернет, — это хорошо известный и универсальный метод сокращения возможностей для атак. Также уменьшаются и некоторые риски, свойственные расположению устройств с выходом в Интернет в зонах безопасности, которые не предназначены для принятия входящих соединений от узлов Интернета.

Вот несколько типов сегментов ДМЗ, где можно установить устройства с выходом в Интернет:

  • ДМЗ анонимного доступа – Такие ДМЗ позволяют анонимным пользователям соединяться с устройствами с выходом в Интернет, находящимся в ДМЗ, а серверы, находящиеся в ДМЗ, разрешают анонимные соединения с ними. Очень часто в ДМЗ анонимного доступа располагаются входящие SMTP-ретрансляторы и открытые DNS-серверы.
  • ДМЗ аутентифицированного доступа — ДМЗ аутентифицированного доступа гораздо больше защищены, чем ДМЗ анонимного доступа, поскольку пользователи проходят аутентификацию на брандмауэре до того, как соединение переадресуется на сервер в ДМЗ. Анонимные соединения с ДМЗ аутентифицированного доступа запрещены, что уменьшает огромное количество атак на сервер в такой ДМЗ
  • ДМЗ смешанного анонимного и аутентифицированного доступа – Такие ДМЗ разрешают анонимные соединения через брандмауэр, но сами серверы в ДМЗ требуют аутентификации. Эти серверы могут производить аутентификацию с помощью локальной базы данных пользователей, домена Active Directory, расположенного в ДМЗ, или домена Active Directory, расположенного в корпоративной сети за внутренним брандмауэром

На Рисунке 1 показаны несколько зон безопасности ДМЗ. Красная зона показывает ДМЗ анонимного доступа, где внутренний ISA-сервер разрешает анонимные соединения со службами, расположенными в этом сегменте. ДМЗ аутентифицированного доступа показывает зону безопасности, доступ к которой разрешен только аутентифицированным пользователям. Это требует как минимум предварительной аутентификации на ISA-сервере для доступа к ресурсам этой зоны. Серверы в этой зоне также могут требовать аутентификации, но ключевой особенностью является то, что все соединения должны быть аутентифицированы до того, как они будут проходит аутентификацию на сервере. Зона «Honeypot» представляет собой более традиционную ДМЗ, в которой разрешен анонимный доступ почти всем протоколам из внутренних узлов, и самым распространенным протоколам из внешней сети. В данной ДМЗ можно расположить системы IDS/IPS и «Honeypot».

Демилитаризованная зона

Рисунок 1

Внешние Exchange-серверы должны находиться в одном из сегментов ДМЗ

Обратите внимание: внешний Exchange-сервер расположен в ДМЗ аутентифицированного доступа. Это дает высокий уровень защиты путем удаления внешнего Exchange-сервера из зоны безопасности внутренних Exchange-серверов. Такая конфигурация хороша тем, что внутренние Exchange-серверы обычно не имеют выход в Интернет, в то время как внешние обладают им почти всегда.

Обычный поток проходит через каждую ДМЗ, в которой устройства с выходом в Интернет отделены от устройств, не принимающих входящие соединения от узлов Интернет. Очевидно, что зона атаки, представленная Интернетом, гораздо больше любой потенциальной зоны атаки, представленной узлами в сетях без выхода в Интернет. Если нет особых причин (а их может быть очень много), следует всегда отделять устройства с выходом в Интернет от сетей, не предназначенных для узлов с выходом в Интернет.

Одним из лучших примеров решения этой проблемы является решение с внешним и внутренним Exchange-серверами. Поскольку внешний Exchange-сервер обычно является узлом с выходом в Интернет, он должен всегда находиться в сегменте ДМЗ и никогда не располагаться в той же зоне безопасности, что и внутренний Exchange-сервер.

Расположение внешнего Exchange-сервера с выходом в Интернет в отдельном сегменте ДМЗ является важной особенностью. При развертывании внешнего и внутреннего Exchange-серверов следует принять во внимание информацию (которую я недавно узнал из технических описаний) о том, что можно расположить внешний и внутренний Exchange-серверы в одной зоне безопасности и получить такой же уровень безопасности, как и при установке внешнего Exchange-сервера в ДМЗ аутентифицированного доступа. Подумайте об этом и решите, какой вариант предлагает наивысший уровень защиты, и я думаю, вы согласитесь со мной, что внешний Exchange-сервер следует поместить в отдельную зону безопасности.

Описание сценария

В данной статье мы рассмотрим сценарий с двумя ISA-серверами, при котором внутренний ISA-сервер является членом домена корпоративной сети, а внешний не является членом домена и входит в свою собственную рабочую группу. Web-сервер будет располагаться в ДМЗ между внешним и внутренним ISA-серверами и будет членом домена корпоративной сети. Контроллеры домена корпоративной сети находятся за внутренним ISA-сервером, внутридоменные соединения между web-сервером корпоративной сети и отдельным контроллером домена разрешены.

На Рисунке 2 изображена схема примера сети для нашей статьи.

Структура корпоративных сетей

Рисунок 2

Если вы знакомы с книгой Configuring ISA Server 2004 (Настройка ISA Server 2004), то вы увидите, что мы используем обычную IP-адресацию и схему именования, которая была использована в книге и на сайте ISAServer.org в течение последних двух лет.

Вот некоторые компоненты нашего решения, которые выделяют интересные и важные проблемы при настройке и управлении ISA-сервером во многих сценариях:

  • Между внутренней сетью по умолчанию за внутренним ISA-сервером и сегментом ДМЗ существуют отношения маршрутизации
  • Для контроля трафика от сети ДМЗ к внутренней сети по умолчанию за внутренним ISA-сервером используются правила доступа (не правила публикации)
  • Для правильной маршрутизации соединений от сети ДМЗ и внутренней сети по умолчанию за внутренним ISA-сервером используются записи таблицы маршрутизации

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

Данная статья состоит из четырех частей:

  • Часть 1 – Концепции создания и внедрения ДМЗ и зон сетевой безопасности
  • Часть 2 – Настройка внутреннего ISA-сервера
  • Часть 3 – Настройка web-сервера в ДМЗ и внешнего ISA-сервера
  • Часть 4 – Использование аутентификации RADIUS на внешнем ISA-сервере

Мы детально рассмотрим следующие темы:

  • Настройка внутреннего ISA-сервера с сетью ДМЗ ISA-сервера
  • Настройка внутреннего ISA-сервера с сетевым правилом, устанавливающим отношения маршрутизации между внутренней сетью по умолчанию для внутреннего ISA-сервера и сетью ДМЗ ISA-сервера
  • Создание правила доступа, разрешающего внутридоменные соединения между сервером ДМЗ и контроллером домены во внутренней сети по умолчанию для внутреннего ISA-сервера
  • Создание правила доступа, контролирующего входящий доступ из внутренней сети по умолчанию для внутреннего ISA-сервера в ДМЗ и Интернет
  • Настройка записи в таблице маршрутизации на сервере ДМЗ
  • Ввод сервера ДМЗ в домен, расположенный во внутренней сети по умолчанию за внутренним ISA-сервером
  • Настройка внутренней сети по умолчанию внешнего ISA-сервера
  • Настройка записи в таблице маршрутизации на внешнем ISA-сервере
  • Создание правила доступа All Open (Все открыто) на внешнем ISA-сервере
  • Создание правила web-публикации на внешнем ISA-сервере
  • Настройка аутентификации RADIUS на внешнем ISA-сервере
  • Проверка решения

Резюме

В первой части статьи, посвященной настройке членов домена в демилитаризованной зоне с двумя ISA-серверами, мы обсудили концепции создания ДМЗ. Одним из ключевых положений является то, что не существует одной зоны. В настоящий момент в большинстве организаций существует несколько ДМЗ, которые определяются границами зон безопасности. Также мы определили три вида ДМЗ: ДМЗ анонимного доступа, ДМЗ аутентифицированного доступа и смешанную ДМЗ анонимного и аутентифицированного доступа. Мы закончили эту часть обсуждением вопроса, почему внешние Exchange-серверы должны быть расположены в ДМЗ, которые отделены от зон безопасности для внутренних Exchange-серверов.

www.isaserver.org


Смотрите также:

Tags: , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]