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

Есть ли у атакующего, находящегося за пределами периметра корпоративной сети, возможность атаковать клиентское программное обеспечение? Да, если он может пронести свои данные внутрь периметра. А сделать это можно опять же через легального пользователя. Особенно если у него есть доступ в Internet. Электронное письмо, Web-страница, посещенная пользователем, — все это потенциальная база для развития атаки. Кроме того, даже на пользовательской машине могут работать серверные компоненты, начиная со служб сервера NetBIOS/CIFS и заканчивая различными программами обмена сообщениями, такими, как ICQ и AIM и агентами одноранговых сетей (Morpheus, Kazaa).

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

Впрочем, проблема безопасности клиентского программного обеспечения не нова. Как она решается сегодня в организациях (исходя из того, что многим из них так или иначе требуется постоянный доступ сотрудников хотя бы к электронной почте)? Очевидный ответ — использовать антивирусы и контент-фильтры. Но можно ли считать такую защиту надежной? Нет, поскольку и антивирус, и контент-фильтр действуют на основе сигнатур и способны отслеживаить лишь те атаки, которые известны на момент создания, т. е. пытаются догнать атакующего, а не остановить его. Конечно же, читатели могут возразить, что контент-фильтр настраивается на запрет определенной категории опасной информации — исполняемых файлов, сценариев и т. д. Но формат сообщения электронной почты или Web-страницы имеет достаточно сложную структуру, определяемую большим числом стандартов. Если формат сообщения полностью удовлетворяет стандартам и в программе нет ошибок, то ее поведение полностью предсказуемо. А что если в программе есть ошибки или формат сообщения нестандартный? В таком случае контент-фильтр может, например, принять решение об отсутствии в сообщении вложенных файлов, а клиентская программа найдет, выделит и запустит исполняемый файл [1]. И на сегодняшний день не существует ни одного контент-фильтра, предполагающего возможность нестандартного поведения клиентской программы или атакующего. Кроме того, современные контент-фильтры не в состоянии распознать в разрешенном трафике запрещенное содержимое, сокрытое при помощи стеганографических методов [2]. А анализ сетей многих крупных компаний показывает, что безопасности клиентских систем, их своевременному обновлению и защите внимания практически не уделяется, и в сети используются программы, содержащие известные ошибки. Значит, чувствовать себя в безопасности пока невозможно.

Существует ли более простое решение этой проблемы?

От любого ли клиентского программного обеспечения исходит потенциальная угроза? Ответ: от любого, работающего с данными пользователя. Что, собственно, означает «да». Но явно можно выделить группу программ, угроза от которых максимальна, — это программы, работающие с Internet. Остальные мы условно будем называть неопасными. А значит, надо каким-то образом изолировать одни программы, с которыми работает пользователь, от других, и главное — отделить их от конфиденциальных данных.

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

В первом случае мы оставляем опасные и неопасные приложения в рамках одной операционной среды, но даем им разные привилегии доступа. Т. е. каждый пользователь имеет две учетные записи — одну для запуска опасных приложений и вторую для безопасных. Такой подход легко реализуется в среде Windows с помощью команды RunAs. Кроме очевидного неудобства для пользователя этому подходу присущи и другие недостатки. Во-первых, приложения разных уровней доступа могут продолжать взаимодействовать между собой через среду пользователя, что открывает возможность, например, для shatter-атак [3]. Во-вторых, при настройке и сопровождении каждой клиентской системы нам придется уделять огромное внимание локальной безопасности, как если бы за каждым компьютером работали два пользователя с разным уровнем доступа. Применение персональных брандмауэров и фильтров уровней приложения в данном случае проблемы не решает. Известны многочисленные методы (DLL injection, системные механизмы отладки), применив которые, можно заставить легальное приложение изменить свое поведение так, как требуется атакующему, если тот уже получил доступ к контексту пользователя, в котором запущено легальное приложение.

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

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

Рассмотрим пример практической реализации подобного решения. Корпоративная сеть, построенная на основе службы каталогов Active Directory, использует диапазон адресов 10.0.0.0/8 и пространство имен dom.isec. Для доступа к Internet используется Microsoft ISA Server с адресом внутреннего интерфейса 10.1.1.1/24. В сети имеется ряд контроллеров домена, один (или несколько) из которых выделяется для обслуживания запросов терминальных серверов. Хотя бы один из этих серверов должен исполнять роль сервера глобального каталога (Global Catalog, GC). В рассматриваемом примере для такой цели выделен один сервер с адресом 10.1.1.2/24 и FQDN dc.dom.isec (см. Рисунок 1).

Рисунок 1. Схема сети.

Терминальный сервер подключается к дополнительному интерфейсу, установленному на сервере ISA. В примере данный интерфейс имеет адрес 192.168.1.1/24. Серверу выделен IP-адрес 192.168.1.2/24. Поскольку сервер ISA, согласно статье TechNet KB329807 [4], не поддерживает размещение в демилитаризованной зоне компьютеров, являющихся членами домена Active Directory (видимо, это связано с отсутствием правила публикации протокола ICMP), необходимо включить сети 192.168.1.0/24 в таблицу локальных адресов (Local Address Table, LAT) сервера ISA. Для фильтрации пакетов между сетью предприятия и сервером терминала используются возможности службы Remote Routing and Access Server (RRAS), установленной на сервере ISA. Данный сервер входит в комплект поставки Windows 2000, однако после установки находится в неактивном состоянии и требует запуска вручную. Применяется следующая схема фильтрации пакетов: выходной фильтр на интерфейсе с адресом 10.1.1.0/24 пропускает только пакеты с номерами портов получателя, соответствующими службам, необходимым для аутентификации сервера терминала в службе каталогов Active Directory. Кроме того, на данном интерфейсе разрешается взаимодействие клиентов корпоративной сети с сервером терминалов (см. Листинг 1).

Порт 88 UDP используется протоколом Kerberos, служба NTP, необходимая для синхронизации времени, задействует порт 123 UDP, на порту 389 работает служба LDAP. Порт 445 TCP задействован службой Common Internet File System и Server Message Block (CIFS/SMB), необходимой для доступа к файлам (групповым политикам) на контроллерах домена. Порт 135 применяется службой EndPointMapper протокола RPC. Порт 1026 выделен для службы Name Service Provider Interface. По умолчанию, номер порта для данной службы выделяется динамически в процессе инициализации системы и публикуется через службу EndPointMapper. В тех случаях, когда необходимо закрепить данную службу на определенном номере порта, согласно рекомендациям статьи KB224196, в разделе реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesNTDSParameters создается параметр TCP/IP Port типа DWORD, значение которого будет использоваться службой NTDS после перезагрузки системы. Следует помнить, что значение данного параметра должно быть больше 1024. Прохождение ICMP-пакетов разрешено, поскольку они применяются функцией определения ближайшего контроллера домена.

Входной фильтр на интерфейсе 192.168.2.1/24 (см. Листинг 2) ограничивает пакеты, исходящие из сети с терминальным сервером. К разрешенным пакетам относятся пакеты сервера терминала, пакеты, направленные к порту 8080 сервера ISA (на данном порту работает служба посредника HTTP), и все пакеты с адресом получателя, соответствующим IP-адресу сервера dc.dom.isec. В том случае, если необходимо разрешить серверу терминала аутентифицироваться на дополнительном контроллере домена, достаточно указать данный сервер в списке.

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

Приведенные листинги, полученные при помощи утилиты netsh, являются фрагментами сценариев настройки сервера RRAS. Они могут быть импортированы в его конфигурацию при помощи команды

netsh -c routing -f .

Дальнейшая настройка осуществляется посредством групповых политик. Для сервера терминалов формируется отдельное организационное подразделение, для которого создается объект групповой политики, имеющий статус Block Policy Inheritance. Это дает возможность конфигурировать сервер на основе его персональной политики. В качестве основы для настройки используются шаблон Baseline.inf из состава Microsoft Security Operation Guide и шаблон ocfilesw.inf, входящий в стандартную поставку Windows. В разделе Restricted Groups закрепляются члены группы Administrators (Administrator, Domain Users), Users (Internet Users) и Power Users (None).

В раздел File System добавляются параметры, устанавливающие разрешения. К ним относятся ограничение доступа к файлу %systemroot%system32MSGINA.DLL [5], блокировка которого приводит к отказу в обслуживании сервера терминалов. Необходимо запретить членам группы Users запись и включить аудит событий записи в любое место диска, за исключением их собственного профиля. Кроме того, желательно ограничить доступ пользователей к потенциально опасным утилитам на уровне разрешений NTFS, для чего следует запретить в политике доступ к этим утилитам членам группы Internet Users. Список утилит должен содержать важнейшие системные утилиты. Он может быть основан на рекомендациях приложения A Security Operations Guide for Windows 2000 Server [6] и расширен за счет поиска исполняемых файлов, импортирующих библиотеки wininet.dll, wsock32.dll, ws2_32.dll и netapi.dll. Дополнительно можно запретить пользователям группы Users изменять разрешения и запускать файлы (Change Permissions — Deny, Execute — Deny) в папке с их профилем.

Кроме того, желательно разрешить для сервера блокирование пользовательских политик (Group Policy Loopback). Данный параметр позволяет настраивать рабочую среду пользователей, работающих в терминальной сессии, только на основе политики, применяемой к учетной записи компьютера. В статье «Локальная угроза», опубликованной в предыдущем номере, рекомендовалось блокировать данную возможность в групповой политике уровня домена, имеющего статус No Override. Для того чтобы позволить серверу терминала использовать данную возможность, его учетной записи необходимо запретить чтение и применение этой групповой политики. Требуется открыть оснастку управления Active Directory Users and Computers и включить расширенный режим отображения (View > Advanced Features). Выбрав соответствующий объект групповой политики, нужно на закладке Security установить соответствующие разрешения. Таким образом, настройки среды пользователей, такие, как перенаправление папок My Documents, в случае входа на сервер терминала применяться не будут.

В параметрах Logon Locally и Access this computer from network раздела политики User Rights Assignment необходимо указать группы Administrators и Internet Users. Группа Internet Users содержит учетные записи пользователей, имеющих доступ к ресурсам глобальной сети. В том случае, если пользователи разделяются по типу службы, в эту группу включаются группы, содержащие учетные записи пользователей, которым разрешено применять тот или иной протокол (к примеру, Internet HTTP и Internet FTP). Включение в группы Internet* учетных записей, принадлежащих группе Domain Admins, крайне нежелательно.

Поскольку сервер терминалов имеет возможность доступа к ресурсам внешней сети (и, соответственно, пользователи внешней сети могут получить доступ к его ресурсам), желательно дополнительно ограничить его сетевые возможности, что можно сделать через политики IPSec. Данный подход позволяет фильтровать трафик сервера при помощи примитивного межсетевого экрана, имеющего, однако, большие возможности, чем стандартная фильтрация портов на сетевых интерфейсах. Для отладки фильтров можно задействовать утилиту ipsecpol.exe, входящую в состав Resource Kit. Сценарий настройки фильтров IPSec, используемый в данном примере, приведен в Листинге 3. После завершения отладки желательно добавить эти настройки в раздел IP Security Policies объекта групповой политики.

В разделе политики User Configuration целесообразно определить настройки, касающиеся рабочей среды пользователя. К ним относятся настройки Proxy Server и зон безопасности для Internet Explorer (Windows Settings > Internet Explorer Maintains), запрет изменения этих настроек (Administrative Templates > Internet Explorer), ограничение запускаемых приложений (System > Run Only Allowed Windows Application) и дополнительные ограничения интерфейса пользователя.

Особое внимание следует уделить настройкам безопасности приложений, таким, как разрешенные компоненты и зоны безопасности Internet Explorer. Для централизованной настройки Outlook в политику необходимо импортировать шаблон OUTLK10.ADM из состава Office.

Следует помнить, что данные настройки будут применяться ко всем пользователям, получившим доступ к системе, в том числе и к администраторам. Поэтому параметры должны содержать суммарные разрешения, необходимые для каждого из пользователей. В случае сбоя системы возможность запуска утилит, которые нужны для восстановления, будет доступна при локальной загрузке системы в режиме защиты от сбоев с интерфейсом командной строки. Подробнее о настройках безопасности сервера терминалов рассказано в статье [7].

Последним этапом является настройка сервера ISA для разрешения доступа к ресурсам Internet пользователям сервера терминалов. С этой целью создаются правила доступа Protocol Access Rules. К примеру, пользователям группы DOMInternet HTTP разрешается доступ к внешним ресурсам по протоколам HTTP и HTTPS.

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

Подобный подход также можно использовать для более защищенного доступа к ресурсам внутренней сети клиентов удаленного доступа VPN. Клиенты VPN фактически напрямую подключены к Internet, а с другой стороны — имеют прямой доступ к ресурсам сети. Для разделения этих сетей клиенту выделяется IP-адрес из диапазона, принадлежащего демилитаризованной зоне корпоративной сети, в которой установлен терминальный сервер (см. Рисунок 2). После чего клиент по протоколу RDP соединяется с сервером терминала, и уже из этой сессии получает возможность работать с внутренними ресурсами. Таким образом, у клиента VPN не будет возможности нарушить безопасность intranet, например заразить внутренние серверы вирусом.

Рисунок 2. Подключение клиентов VPN.

Владимир Дубровин — начальник сервис-центра группы компаний СЕНДИ, координатор проекта SECURITY.NNOV, MCSE. С ним можно связаться по адресу: 3APA3A@SECURITY.NNOV.RU.

Сергей Гордейчик — инструктор учебного центра, MCSE. С ним можно связаться по адресу: Gordey@infosec.ru.

Дебют сервера IBM ITANIUM

Семейство 64-разрядных процессоров Intel, некогда в насмешку названное Itanic, проходит этап успешного развития. На этой неделе представители IBM сообщили о выпуске первого Intel-сервера eServer x450 c 16 процессорами Itanium 2 (либо 32-разрядными Xeon) и новой шиной PCI Extended (PCI-X). Система предполагает загрузку Windows Server 2003 и способна поддерживать как 32-разрядную, так и 64-разрядную архитектуру.

По словам старшего вице-президента компании Intel Майка Фистера, возглавляющего группу Enterprise Platforms Group, Intel и IBM заинтересованы в продолжении совместной работы над созданием обладающих высокой степенью масштабируемости платформ как для 32-разрядных, так и для 64-разрядных приложений. «Сегодня eServer x450 готов к развертыванию в пользовательской среде и, кроме того, способен обеспечить независимым производителям программных продуктов платформу для разработки и настройки приложений. Платформы на базе Intel-процессора Itanium 2 демонстрируют выдающуюся производительность, надежность и масштабируемость при снижении себестоимости», — заявил он.

Ссылки по теме:
  1. SECURITY.NNOV: Bypassing content filtering software http://www.security.nnov.ru/advisories/content.asp
  2. Использование стеганографии для обхода межсетевых экранов http://networkpenetration.com/protocol_steg.html
  3. Shatter-атаки против приложений Win32 http://www.security.nnov.ru/search/news.asp?binid=2241
  4. Microsoft TechNet http://www.microsoft.com/technet
  5. Windows 2000 Terminal Services MSGINA.DLL denial of service http://www.iss.net/security_center/static/ 11141.php
  6. A Security Operations Guide for Windows 2000 Server http://www.microsoft.com/TechNet/security/ prodtech/windows/windows2000/staysecure/
  7. NSA Guide to Securing Microsoft Windows 2000 Terminal Services http://www.nsa.gov/snac/win2k/guides/w2k-19.pdf