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

VLAN

Виртуальные ЛВС (VLAN) относятся к довольно современным (с 1998 г.) возможностям, имеющимся в доступных коммутаторах высокого класса. Основной их целью является обеспечение гибкости в разделении коммутаторов по множеству широковещательных доменов ЛВС и облегчения охвата широковещательного домена множеством коммутаторов. VLAN часто используются для улучшения сетевой производительности путем совместной группировки систем, что основывается на интенсивных в широковещательном плане протоколах, таких, как NetBIOS и IPX. Сконфигурированные должным образом виртуальные ЛВС могут быть полезны в обеспечении безопасности, когда они используются для разделения и изоляции и могут устранить потребность в большом количестве меньших выделенных коммутаторов. Также они имеют преимущество, заключающееся в отсутствии ограничения границами отдельного коммутатора, что позволяет при выборе критерия группировки для систем не ограничиваться физическим расположением. Другим важным преимуществом является способность создавать множество подсетей, имея относительно небольшое количество физических сетевых устройств для мониторинга и обслуживания.

При неправильной конфигурации сети VLAN представляют собой некоторый риск для безопасности, чего не случается при использовании для определения границ безопасности выделенных коммутаторов. Хотя определенные на коммутаторе подсети и рассматриваются как "виртуальные", они нуждаются в маршрутизаторе для отправки и приема трафика из других подсетей. Если ваш проект безопасности нуждается в функциях брандмауэра между двумя подсетями, можно выполнить соединение между ними с использованием отдельных (внешних) маршрутизаторов и брандмауэров. Однако большинство коммутаторов высокого класса, такие, как Cisco Catalyst, способны как минимум обеспечивать элементы управления доступом в виде пакетной фильтрации между подсетями на одном и том же коммутаторе. Так как сети VLAN физически объединены на одном и том же коммутаторе, существует риск, что некоторые конфигурации могут позволить фальшивым пакетам попасть из одной VLAN в другую и обойти элементы управления маршрутизатора и брандмауэра между двумя подсетями.

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

Чтобы понять потенциальную уязвимость в безопасности сетей VLAN, вам необходимо понимать основы их работы. По существу, "заголовок тега" вставляется в Еthernet-фрейм сразу за MAC-адресом источника. Тег используется для идентификации того, к какой из VLAN принадлежит фрейм, и позволяет VLAN покрывать множество "магистральных" коммутаторов. Подробности "фреймового тегирования" VLAN расписаны в документе IEEE 802.1q и могут быть найдены по адресу:

http://standards.ieee.org/reading/ieee/std/lanman/802.1Q-1998.pdf

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

4.1.4 Прокси-серверы

Прикладные прокси

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

Прокси-серверы являются довольно уникальными в том смысле, что они выполняют функции разделения сетей подобно брандмауэру, а помимо этого могут еще и выступать в роли сервера с точки зрения клиента. Как было упомянуто выше, прокси могут работать как на сеансовом уровне (уровне 4), так и на прикладном уровне (уровне 7). Некоторые образцы брандмауэров реализуют возможности прокси сеансового уровня, однако, как правило, в специализированных системах используются возможности прокси прикладного уровня. Так как прокси прикладного уровня проверяют все пакеты, включая "полезную нагрузку" данных приложения, пропускная способность прикладного прокси будет значительно ниже, чем у просто фильтрующего пакеты маршрутизатора или у маршрутизатора, фильтрующего пакеты с учетом состояния.

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

Обратные прокси

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

Прямые прокси

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

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

4.1.5 Системы обнаружения вторжений

Существует несколько разновидностей методов, или "систем", обнаружения вторжений. Система обнаружения вторжений [intrusion detection system (IDS)] является системой, специально разработанной и реализованной для обнаружения вторжений. Любая IDS попадает в одну из следующих четырех основных категорий:

1. Системы обнаружения вторжений на уровне сети [Network intrusion detection systems (NIDS)]. Oбычно это интегрированные в сетевые аппаратные устройства системы для отслеживания TCP/IP пакетов и проверки на запрещенность запросов соединения. Они могут также иметь встроенные алгоритмы определения DoS-атак (отказ в обслуживании). Системы NIDS отслеживают сетевые пакеты с данными и пытаются обнаружить запросы на соединение потенциального злоумышленника. "Вторжение" может состоять из простой попытки соединения, а может и представлять собой аномальное количество запросов на соединение, что может означать атаку типа "отказ в обслуживании". NIDS должна иметь способность обнаруживать нетипичные закономерности в запросах на соединение. К примеру, NIDS должна определять большое число запросов на TCP-соединения к нескольким различным портам определенной машины и идентифицировать это событие как потенциальное сканирование TCP-портов. Обычно NIDS исполняется как независимое выделенное устройство, прозрачно отслеживающее весь сетевой трафик. Так как эти системы работают в сетевых устройствах, таких, как маршрутизаторы, концентраторы и коммутаторы, они могут защищать несколько систем. Существует также возможность реализовать обнаружение вторжений на уровне сети и на отдельном хосте, а в настоящее время стало общей практикой размещение некой формы NIDS на рабочих станциях для функционирования в качестве "персонального брандмауэра".
2. Обеспечение целостности данных хоста. При этом методе осуществляется мониторинг хоста на уровне операционной системы на предмет любых изменений в системных файлах и конфигурации либо в настройках реестра и в некоторых случаях в файлах данных приложений. Средства мониторинга обеспечивают целостность данных путем установления базиса системных данных при желаемом состоянии с последующим обнаружением и ведением отчетности по любым изменениям в этом базисе. Как правило, изменения записываются в журналы, а журналы используются для генерации отчетов; значит, системы обнаружения этого типа не всегда выдают отчет о событиях в реальном масштабе времени. В настоящее время такие продукты, как Tripwire, начали поддерживать интеграцию в системы мониторинга реального времени, такие, как IBM Tivoli Risk Manager и Tivoli Enterprise Console. За дополнительной информацией обратитесь по следующему адресу: http://tivoli.tripwire.com/
3. Мониторы работы журналов. Подобны мониторингу обеспечения целостности данных. Этот тип монитора разработан для просмотра файлов журналов с целью поиска необычных закономерностей. Под "необычной закономерностью" подразумевают соответствие определенных действий известной сигнатуре. К примеру, сигнатура может определять потенциальную попытку атаки переполнения буфера как повторяющуюся серию попыток доступа к серверу HTTP с использованием очень длинных строк получения ("get") URL.
4. Сканеры контента. Хотя в целом они сами являются классом, мы включили сканеры контента (такие, как вирус-сканеры, спам-фильтры и Web-фильтры) как особую категорию систем обнаружения вторжения. Единственным смыслом разработки сканеров контента явилась необходимость обнаружения пассивных атак, когда вторжение потенциально внедрено вовнутрь самих данных. Сканирование данных в процессе транзита является линией защиты, предназначенной для предотвращения потенциальных атак на предопределенные системы, будь то серверы или рабочие станции. В случае Web-фильтров для HTTP-трафика, спам-фильтров для электронной почты мы можем рассматривать это как нечто большее, чем технический прием по обеспечению некоторых мер управления доступом по отношению к неправильному применению или эксплуатации полосы пропускания и других ресурсов сети организации. Мы думаем, вы согласитесь, что получение незатребованной электронной почты ("спама") на самом деле является разновидностью вторжения и вы захотите обнаруживать и, в идеальном случае, предотвращать либо сильно ограничивать размер нанесенного им ущерба.

Пример программы-монитора активности для обнаружения неудачных попыток входа в систему на сервере Sametime можно найти в справочнике IBM Working with the Sametime Community Server Toolkit, SG24-6667, стр. 63-84. Этот простой пример может быть применим в качестве основы для создания своей собственной элементарной IDS хоста для Lotus Sametime. Однако отметьте, что он не содержит никаких алгоритмов для обнаружения каких-либо закономерностей неудавшихся входов в систему. Так как эти закономерности, или сигнатуры, отображающие атаки, могут быть достаточно сложными и даже изменяющимися по мере изобретения новых методов атак, мы не рекомендуем вам пытаться создавать собственную IDS. Список как общедоступных IDS (с открытым источником), так и коммерческих IDS, появляющихся достаточно своевременно, можно найти на сайте Purdue University COAST (Computer Operations, Audit, and Security Technology):

http://www.cerias.purdue.edu/coast/ids/ids-body.html#systems

Размещение IDS варьируется в зависимости от используемого типа, хотя для IDS на уровне сети и сканеров контента как наиболее соответствующее стремятся выбрать расположение в пределах или около периметров или границ сети. Системы NIDS, как правило, не располагают в сегментах ЛВС по причине большого объема пакетов данных, которые необходимо проверить. Стандартом "передового опыта" для большинства серверов стали расположенные на хосте системы IDS и сканеры контента, а для каждой рабочей станции широко распространенной практикой стало применение ограниченных сканеров контента (таких, как вирус-сканеры). Также на рабочих станциях быстро стало нормой применение "персональных брандмауэров", позволяющих как администратору, так и конечному пользователю блокировать следящие cookies Web-сайта, всплывающие окна и проводить блокировку входящих и исходящих портов/приложений.

4.1.6 Системы управления подлинностью и управления доступом на предприятии

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

Торговая марка IBM Tivoli предоставляет весь набор продуктов управления проверкой подлинности вместе с программой Tivoli Access Manager, обеспечивающей аспекты управления доступом и авторизацией. За дополнительной информацией относительно IBM Tivoli Access Manager и других продуктов Tivoli обратитесь, пожалуйста, к следующим публикациям IBM:

• Identity Management Design Guide with IBM Tivoli Identity Manager, SG24-6996
• Enterprise Security Architecture using IBM Tivoli, SG24-6014
• IBM Tivoli Access Manager for e-business, REDP3677

4.1.7 Серверы приложений

Термин "сервер" охватывает широкий спектр типов хостов и служб. С интеграцией основных сетевых служб, таких, как DNS или DHCP, в "сетевые устройства" концепция сервера как физической хост-машины за последние несколько лет изменилась. С точки зрения архитектуры мы должны касаться как внутренней безопасности, защищающей наши основные доступные серверы, так и дополнительной безопасности, которую мы должны предусмотреть путем их размещения внутри общей архитектуры, в связке с другими мероприятиями защитного характера, являющимися внешними для самого сервера.

Основные серверы инфраструктуры

Основными серверами инфраструктуры являются:

• DNS;
• хосты-ретрансляторы SMTP;
• серверы-репозитории FTP.

Все они подробно описаны в последующих разделах.

DNS

Целью вашей службы имен доменов [domain name service (DNS)] является трансляция имен хостов в IP-адреса и поддержка возможности выполнять обратный поиск, значающий транслирование IP-адресов в имена хостов. Второй функцией является обеспечение других доменов услугой обмена почтой, или MX- записями, регистрирующими хосты, принимающие SMTP-почту для вашего домена.

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

Как минимум внешняя DNS будет обеспечивать трансляцию имен и адресов для самого сервера имен (запись NS) и по меньшей мере одной записи MX. В конце концов, если вы не хотите регистрировать публичный хост обмена почтой, то вам, возможно, не понадобится публичный DNS-хост. На практике большинство организаций будут иметь по меньшей мере два подключенных к Интернету сервера имен, главный и вспомогательный. Типично также иметь по меньшей мере два зарегистрированных хоста обмена почтой. Помимо этих двух минимальных типов хостов, внешний или "публичный" DNS должен также регистрировать все хосты, к которым может быть осуществлен прямой доступ из Интернета, такие, как Web-серверы, FTP-серверы и прокси-серверы. Главной идеей внешней DNS является разглашение минимального количества информации людям, соединяющимся с сервисами, которые вы сделали доступными для пользователей Интернета.

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

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