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

Ситуация
Недавно одна компания пригласила меня на работу в качестве консультанта. Специфика этого предприятия такова, что сотрудникам постоянно приходится посещать множество различных Web-узлов. Руководство поощряет использование компьютеров для игр, общения и других занятий, способствующих творческому подходу к работе. Проблема заключалась в том, что со времени выпуска Windows и Server 2003 Service Pack 1 (SP1) XP SP2 сотрудникам не удавалось добиться корректной работы многих посещаемых ими Web-узлов. В службу поддержки постоянно шли обращения за помощью для установки компонентов ActiveX, устранения проблем с зонами, активизации всплывающих окон и настройки параметров для файлов-«маяков» — всех элементов, необходимых для функционирования Web-узлов.

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

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

Я объяснил заказчику опасность ослабления мер защиты браузера и других программ. Например, пользователь может посетить Web-узел, который использует какое-нибудь уязвимое место в Microsoft Internet Explorer (IE), чтобы установить программу сбора информации о нажатиях на клавиши. В результате злоумышленник сможет перехватывать все данные, вводимые с клавиатуры. С этого момента пароли и любая другая конфиденциальная информация будут находиться под угрозой. Такая опасность возникает постоянно. Или пользователь неосторожно установит шпионскую программу, которая существенно снизит быстродействие системы или сделает ее неработоспособной.

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

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

Виртуальное решение

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

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

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

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

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

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

Подсеть VM

Я начал планирование с самого низкого уровня изоляции — виртуальной сети. Сеть можно было бы изолировать физически, но для простоты виртуальные машины были размещены в отдельной подсети. Это решение не идеально, но, по крайней мере, благодаря уникальным IP-адресам проще настроить брандмауэр, маршрутизаторы и систему обнаружения несанкционированного доступа для особого подхода к подсети VM. Организовав особую подсеть для виртуальных машин, можно без труда идентифицировать любые проблемы, исходящие от этих машин. Но главное, можно применить строгие правила брандмауэра, которые позволяют уменьшить риск, не влияя на просмотр Web.

Для виртуальных машин была выбрана сеть 10.1.0.0/16, так как в качестве основной сети компании использовалась подсеть 192.168.0.0/16. Для этой подсети был выделен специальный порт маршрутизатора, а тщательно составленные правила брандмауэра ограничили сетевые соединения от виртуальных машин.

Физические сетевые адаптеры — общие для виртуальных и базовых машин, поэтому необходим DHCP-сервер, который будет присваивать IP-адреса только виртуальным машинам. VMware располагает DHCP-функцией для гостевых операционных систем, но с главного маршрутизатора нельзя отличить трафик виртуальных машин от трафика базового компьютера. Поскольку уже планировалось использовать IPsec, я решил настроить DHCP-сервер, который может устанавливать связь только с системами, аутентифицированными через протокол IPsec.

Я осознавал, что решение задействовать IPsec может противоречить требованию малой нагрузки для администраторов. По итогам анализа риска было решено использовать аутентфикацию IPsec с общим ключом, чтобы обеспечить необходимый уровень изоляции без развертывания инфраструктуры открытых ключей. Сведения о применении IPsec для изоляции домена приведены в статье Microsoft «Server and Domain Isolation» по адресу microsoft.com/.../default.mspx.

Настройка браузера

Значительная часть проекта заключалась в настройке браузеров таким образом, чтобы пользователи не чувствовали стеснения, несмотря на принятые меры безопасности. Самым очевидным решением было ослабить некоторые параметры безопасности, чтобы ограничения IE меньше сказывались на таких задачах, как установка Java или загрузка и запуск компонента ActiveX.

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

Поэтому пришлось понаблюдать за некоторыми пользователями во время их работы с Internet. Большинство пользователей применяли те или иные приемы для обхода ограничений безопасности — использовали браузер Mozilla Firefox или Opera либо добавляли узлы в доверенный список IE. Но каждый сотрудник мог быстро назвать один или два узла, корректной работы которых не удавалось добиться никакими средствами. Это распространенная ситуация, когда узел в надежной зоне пытается загрузить компонент (например, Java) из узла в ограниченной зоне.

Я заметил, что пользователи не нуждались в неограниченном доступе в Internet — достаточно нескольких базовых компонентов, работающих с разнообразными Web-узлами. Кроме того, необходимые компоненты были весьма обычными, и их безопасность общепризнанна: в частности, Adobe Acrobat, Adobe ShockWave Player, Macromedia Flash и Apple QuickTime.

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

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

Затем я установил эти компоненты как одобренные администратором с помощью инструмента Profile Manager из комплекта Internet Explorer Administration Kit (IEAK) 6 SP1.

Заполнение зон

Составить список доверенных узлов было довольно сложно. Все сотрудники посещали обычные Web-узлы, но, чтобы избежать проблем совместимости, желательно, чтобы список узлов был исчерпывающим. Для подготовки этого списка использовалась бесплатная утилита Log Parser компании Microsoft.

Сначала я составил запрос, чтобы извлечь текущие списки доверенных узлов из десятка систем в сети. Вместе они точно отражали картину обращений в Web для всей сети. На каждой системе была запущена следующая команда Log Parser (вводится одной строкой):

C:\>logparser «SELECT DISTINCT
EXTRACT_TOKEN(Path, 8, ‘\’)
As Domain INTO
TrustedSites-
%COMPUTERNAME%.txt
FROM ‘HKCU\Software\Microsoft\
Windows\CurrentVersion\
Internet Settings\ZoneMap\
EscDomains’
WHERE ValueName LIKE
‘http%’ « -o:NAT -rtp: — 1
-headers:off

Данный запрос извлекает имена доменов из списка узлов в разделе реестра HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains и сохраняет этот список имен в текстовом файле в текущем каталоге.

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

C:\>logparser «SELECT Text AS
Domain, Count(*) AS Total INTO
TrustedSites.txt FROM
TrustedSites*.txt GROUP BY
Domain HAVING Total > 1
ORDER BY Total DESC»
-i:textline -o:nat -rtp: — 1

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

Я решил, что нет причин запрещать какие-либо узлы из доменов, внесенных в список. Поэтому вместо того, чтобы разрешать www.microsoft.com, support.microsoft.com, windowsupdate.microsoft.com и download. microsoft.com, можно использовать универсальный символ и разрешить *.microsoft.com. Благодаря универсальным символам значительно проще ввести список в реестр.

Чтобы составить список, который легко импортировать в реестр, я запустил еще один запрос Log Parser, но на этот раз формат вывода был более сложным. Для подготовки правильно форматированного .reg-файла я построил файл шаблона, сохранив текст, показанный на экране, в файле с именем reg.tpl. В следующей команде параметр -tpl используется для форматирования вывода с применением указанного шаблона:

C:\> logparser «SELECT Domain
INTO TrustedSites.reg FROM
TrustedSites.txt» -i:tsv
-iSeparator:space -nSep:2
-nFields:2 -o:tpl -tpl:reg.tpl

В результате был получен файл TrustedSites.reg, который можно добавить в реестр двойным щелчком мыши.

Заполняя список доверенных узлов, я подумал, что полезно подготовить и список запрещенных узлов. Эта задача оказалась гораздо проще, так как подготовительная работа уже была сделана. Чтобы добавить узлы в зону Restricted Sites, я использовал несколько программ, которые добавляют собственные списки запрещенных узлов, в том числе IESPYAD (по адресу http://www.spywarewarrior.com/uiuc/resource.htm), которая добавляет список известных опасных узлов и доменов в зону Restricted Sites браузера IE. В Firefox нет зоны, соответствующей Restricted Sites.

Построение виртуальных машин

Подготовленный шаблон VM был базовым экземпляром XP SP2. Ради простоты для задания политики безопасности использовался встроенный шаблон безопасности securews.inf. Виртуальные машины нуждаются в эффективной защите от опасных программ, поэтому я загрузил несколько бесплатных программ для борьбы с вирусами и другими вредителями: Javacool Software SpywareBlaster, Clam AntiVirus, бета-версию Microsoft Windows Defender и Spybot-Search & Destroy. Многие функции этих программ перекрываются, что обеспечивает более надежную защиту.

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

Виртуальное задание выполнено

Назначив базовые политики безопасности — а я убедил руководство компании запретить приложения для одноранговых сетей, обычный источник шпионских программ, — и проведя начальное обучение пользователей, я развернул образ на компьютерах сети. Поначалу некоторые пользователи выражали недовольство, но быстро успокоились после того, как привыкли работать с VM, и особенно когда обнаружили, что Web-узлы работают безупречно. В результате сотрудники компании получили удобный, а администраторы — безопасный доступ в Internet.