Компоненты и уровни безопасности

Хосты-ретрансляторы SMTP

Хосты-ретрансляторы SMTP являются выделенными серверами, используемыми для обработки всех SMTP-сообщений из Интернета, адресованными получателям в ваших внутренних доменах. Ваши хосты-ретрансляторы SMTP не должны выполнять никаких функций или служб, отличных от SMTP, и может быть использовано множество SMTP-серверов (таких, как UNIX sendmail и Domino). Сегодня популярно множество различных архитектур ретрансляции SMTP, а количество реализованных хостов-ретрансляторов варьируется в зависимости от размера организации. Передовым опытом является наличие по меньшей мере двух хостов-ретрансляторов SMTP для обеспечения дублирования. Зачастую в организациях желают назначить один или более хостов-ретрансляторов в качестве привилегированных ретрансляторов "входящих" сообщений и один или более хостов-ретрансляторов в качестве назначенных ретрансляторами "исходящих" сообщений. Хосты-ретрансляторы могут выполнять как "входящие", так и "исходящие" функции для дублирования, а заодно и для обеспечения некоторого баланса нагрузки. Для увеличения емкости число хостов-ретрансляторов может быть расширено в горизонтальном направлении. На рис. 4.3 показана типичная реализация хоста-ретранслятора SMTP, обеспечивающего входящее и исходящее дублирование и изолирующего ретрансляторы SMTP от внутренней сети.

увеличить изображение
Рис. 4.3. Пример реализации хоста-ретранслятора SMTP

В этом примере элементы внешней DNS имеют две записи обмена почтой MX (mail exchanger), и они перевешивают в пользу smtp1 как предпочтительного выбора для приема почты от имени домена acme.com. Если хост smtp1 не работает или недоступен, то внешние системы доставят сообщение smtp2. Для исходящих сообщений мы конфигурируем во внутренней сети почтовые серверы для отправки всех сообщений, адресованных за пределы внутренней сети, к виртуальному хосту-ретранслятору, называемому relay.acme.com. После этого во внутренней DNS мы определяем записи MX для виртуального хоста relay.acme.com, ссылающиеся на оба действительных хоста-ретранслятора, а в качестве предпочтительного маршрута при взвешивании вариантов решения предпочтение отдаем smtp2. Мы обращаемся к нему как к виртуальному хосту, потому что нет записи хоста (А). Заметьте, что записи "А" были для хостов smtp1 и smtp2. Эта схема обеспечивает выходную избыточность и обход отказа; если smtp2 не работает или недоступен, внутренние почтовые серверы доставят исходящие сообщения к smtp1. Важно заметить, что элементы внутренней DNS должны превращаться в сетевые адреса адаптеров хостов-ретрансляторов, доступных во внутренней сети. Подобным же образом элементы внешней DNS должны превращаться в адреса сетевых адаптеров, доступных извне.

За детальной информацией о передовом опыте предотвращения спама (незатребованной электронной почты) и эксплуатации хостов-ретрансляторов мы рекомендуем обратиться к справочнику Lotus Domino 6 spam Survival Guide for IBM e-Server, SG24-6930.

Серверы FTP

FTP-серверы являются серверами, предназначенными для получения из Интернета файлов с использованием протокола передачи файлов File Transport Protocol (FTP). Обычно они выступают только в роли репозиториев (хранилищ), хотя в зависимости от бизнес-потребностей организации они могут разрешать определенным пользователям возможность загрузки файлов из Интернета. Как правило, FTP-серверы необходимы для обмена файлами, которые являются слишком большими для отправки в виде приложений к сообщениям SMTP. Определение "большие" будет широко различаться в зависимости от ограничений размера сообщений, устанавливаемых участвующими в процессе хостами-ретрансляторами SMTP организации. Вы должны убедиться в том, что применяемые внешними пользователями учетные записи сильно ограничены, ограниченным должен быть и анонимный FTP (или ограниченным даже для другого выделенного хоста). Если ваш FTP-сервер поддерживает пассивный режим и вы приняли решение разрешить его, убедитесь, что диапазон номеров IP-портов данных ограничен до относительно небольшого конечного диапазона, а все остальные порты заблокированы брандмауэром.

SSL

Основой целью протокола защищенных сокетов [Secure Sockets Layer (SSL)] является обеспечение конфиденциальности и достоверности между двумя взаимодействующими приложениями. Протокол состоит из двух уровней. На самом нижнем уровне, на уровень выше некоторого надежного транспортного протокола, работает протокол записи SSL. Протокол записи SSL (SSL record protocol) используется для инкапсуляции различных протоколов более высокого уровня. Один из таких инкапсулированных протоколов, протокол подтверждения связи (рукопожатия) SSL (SSL handshaking protocol), позволяет проводить взаимную идентификацию сервера и клиента и согласовывать алгоритм шифрования и криптографические ключи еще до того момента, как протокол прикладного уровня передал или получил первый байт данных. Уникальным преимуществом SSL является его независимость от протокола прикладного уровня. Протокол более высокого уровня может явно работать поверх протокола SSL. Сеанс SSL всегда начинается с обмена "рукопожатиями" SSL. В процессе данного "рукопожатия" выполняются следующие шаги:

1. Клиент отправляет запрос на соединение.
2. Сервер направляет обратно подписанный сертификат.
3. Клиент проверяет, находится ли подписчик сертификата в его нормативном перечне допустимых сертификатов.
4. После этого клиент генерирует ключ сеанса, который будет использоваться для шифрования, и отправляет его серверу зашифрованным с помощью открытого ключа сервера (из сертификата, полученного на втором шаге).
5. Сервер использует секретный ключ для расшифровки сгенерированного клиентом ключа сеанса.
6. Выполняются HTTP-запрос клиента и HTTP-ответ сервера.

4.2 Модель архитектуры безопасности

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

В этом разделе мы опишем модель архитектуры безопасности, которая основана (хотя и неточно) на глобальной модели Web-архитектуры компании IBM. Модель имеет три высокоуровневых понятия, к которым мы обратимся в нескольких последующих разделах:

1. Зоны безопасности.
2. Границы зоны.
3. Правила для потоков данных.

4.2.1 DMZ-модель: ретроспектива

Важным понятием относительно потоков данных является понятие множества сетевых зон. Если обратиться к прошлому, мы увидим инфраструктуры, характеризуемые использованием DMZ, или демилитаризованной зоны (demilitarized zone). Термин DMZ был использован для идентификации демилитаризованной зоны по 38-й параллели, установленной по окончанию корейской войны в 1953 г. как разделительный буфер между вооруженными силами Севера и Юга Кореи. Он стал более широко использоваться в последующих вооруженных конфликтах и вырос до значения "область между двумя противниками, которую обе стороны согласились не оккупировать". Как этот термин пришел в жаргон компьютерной безопасности, можно только догадываться.

Частое использование термина "DMZ" в контексте ИT-безопасности привело к большой неразберихе, так как существует как минимум две различные и к тому же одинаково популярные интерпретации того, что обозначает этот термин.

По одной интерпретации DMZ является областью между граничным маршрутизатором и системой брандмауэров. Это похоже на аналогию военной "ничьей земли", так как в этой части сети не существует никаких хостов (рис. 4.4).

Рис. 4.4. DMZ как сеть между граничным маршрутизатором и брандмауэром

По другой интерпретации DMZ является "экранированной (скрытой, защищенной) подсетью" сети, которая не находится внутри частной сети и в то же время не является частью Интернета (рис. 4.5). В скрытой подсети, как следует из ее названия, для сокрытия ее от двух других сетей применяются IP-фильтры. В зависимости от размещения скрытой подсети DMZ она может быть предназначена для разрешения входящих сеансов по доступу к предложенным сервисам с обеспечением некоторой защиты путем изоляции внешне доступных серверов в DMZ от внутренних серверов. Вторая интерпретация возникла, вероятно, тогда, когда все большее количество организаций начало применять некоторые основные функции брандмауэров (такие, как IP-фильтрация и фильтрация по порту) на своих граничных маршрутизаторах. Имея сейчас некоторые основные функции брандмауэров еще до того места, где первоначально была область DMZ, эта часть сети стала эффективно скрытой подсетью, и люди начали размещать там ограниченное количество хост-систем и служб.

Рис. 4.5. DMZ как скрытая подсеть

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

В этой простой DMZ-модели мы имеем общедоступные серверы в DMZ и серверы, находящиеся во внутренней, частной сети. Разделение серверов приложений в основном происходит по двум соответствующим категориям: общие и частные.

Трехзонная модель была вполне достаточной до тех пор, пока количество доступных извне служб или приложений было довольно ограниченным. Этими службами обычно были Web-приложения (HTTP) и, возможно, передача файлов (FTP), часто использовавшие хост-бастион (жертву). В настоящее время мы видим бизнес-потребность в дополнительных службах, таких, как мгновенный обмен сообщениями, виртуальные конференции, совместные Web-пространства рабочих групп, экстранет- и интранет-порталы, доступ удаленных служащих и т. д. по нарастающей. Трехзонная модель с DMZ посередине ограничивает гибкость, необходимую нам для совершенствования уровней защиты множества служб.

4.2.2 Четырехзонная модель

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

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

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

Примечание. На некоторых платформах теоретически возможно обеспечить некоторый уровень разделения сервисов на отдельном хосте путем запуска служб под различными учетными записями, не имеющими привилегий администратора (root). Мы говорим, что разделение в пределах одного хоста является "теоретически" возможным, так как в реальности сложно сконфигурировать все должным образом, что подразумевает склонность к наличию ошибок, которые могут вести к непреднамеренным уязвимостям. К примеру, в UNIX-системах можно изолировать демонов (фоновые процессы или службы); однако, если конфигурация не выполнена должным образом, атакующий может быть способен взломать "chroot jail"^{1Принудительная смена корневого каталога для приложения; выполняется в UNIX-системах командой chroot.} и воздействовать на другие части системы. Простой поиск в Google по словам на тему "chroot breaking out" выдаст ссылки на огромное количество статей наподобие приведенной ниже:

http://www/bpfh.net/simes/computing/chroot-break.html

Мы не рекомендуем использовать разделение сервисов на отдельном хосте как метод сетевой безопасности, так как изоляция сервиса не может быть гарантирована.

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

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

1. Интернет-зона.
2. Прокси-зона.
3. Зона доступа к данным.
4. Интранет-зона.

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