Установка и защита серверов IIS (часть 2)

Вероятно, рано или поздно кто-то спросит вас: «Знаете, я бы хотел, чтобы этот каталог/веб-сайт был доступен только по паролю». Вы могли бы это сделать? Вы можете по желанию перейти на вкладку «Безопасность каталога» меню настройки веб-сайта (или каталога), включить параметр «Встроенная проверка подлинности Windows» или «Базовая проверка подлинности». Нажмите OK, и? Возможно, ваш сервер просто стал «чуть более» уязвимым для атак. Наиболее вероятные причины проблемы:

• Подслушивание или взлом пароля
• Атаки методом перебора пароля
• Неудачные попытки подбора пароля могут привести к блокировке аккаунта

Конечно, эти опасности тривиальны. Однако это не меняет того факта, что это подлинные опасности, и поэтому их следует анализировать. Эти советы могут быть полезны:

• Никогда не используйте опцию «Базовая аутентификация». Он вызывает пересылку пароля пользователя через Интернет без каких-либо гарантий и может быть использован впоследствии пронырливыми парнями из той сети, в которой в данный момент работает браузер пользователя. Однако программа управления интернет-услугами предупреждает вас, что это небезопасный вариант.

• Если вы хотите использовать метод «Дайджест-аутентификация», ваш сервер должен принадлежать к домену Active Directory, где пароли пользователей должны быть сохранены в расшифровываемой форме. Кроме того, пароль будет уязвим для атак с повторением, т. е. таких атак, при которых перехватчик повторяет полный URL-адрес с паролем,
• Аутентификация не должна выполняться в наборе учетных записей (т. е. в домене), предназначенном для других задач. Отделение домена, предназначенного только для онлайн-аутентификации в Интернете, и размещение его вместе с вашим веб-сервером в изолированной области сети — хорошая идея, хотя это и дорого.
• Попробуйте ограничить доступ к сайтам, которые разрешают IP-аутентификацию пользователя. Это не надежная защита, но она помогает предотвратить атаки на учетные записи,
• Не предоставляйте аккаунты всем желающим. В противном случае вы быстро потеряете контроль над тем, кто может и кто не может использовать сайты WWW с ограниченным доступом. Создайте бумажную копию того, кто, когда и почему имеет учетную запись и срок ее действия,
• Если ваша служба должна быть доступна для учетных записей, которые могут быть созданы без участия администратора, вы должны использовать аутентификацию на уровне приложения, например, с использованием базы данных, включающей список учетных записей, которые будут использоваться сайтом ASP, который аутентифицирует пароли. Конечно, такая аутентификация обрабатывается в виде обычного текста, поэтому вы можете зашифровать ее с использованием защищенного протокола http (HTTPS). Ваше решение должно зависеть от объема данных, защищенных паролем. Вместо предоставления учетной записи и пароля вы можете разрешить пользователю доступ на основе его сертификата (электронной подписи). К сожалению, для этого решения требуется протокол HTTPS (т. е. HTTP, зашифрованный протоколом SSL). Таким образом, вы можете войти пользователя в учетную запись Windows, а также с использованием авторизации собственного приложения. Отсутствие пароля, безусловно, было бы удобно и повысило бы безопасность.

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

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

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

• Необходимость покупки сертификата сервера. Цена может превышать несколько сотен евро за сертификат со сроком действия в один год. По истечении срока действия его необходимо покупать заново, что требует затрат на аналогичную сумму денег. Конечно, есть возможность оформить справку самостоятельно или через дружелюбного администратора сети. Однако этот способ заставил бы пользователя потерять уверенность в связи с правильным сервером. Откуда ему или ей знать, что сертификат защищен, если его не выпускала доверенная компания? Тем не менее, это дешевое решение, позволяющее сохранить остальные преимущества протокола HTTPS (его конфиденциальность и аутентификацию пользователей), о чем будет рассказано в следующей статье.
• Необходимость выделения выделенного IP-номера для WWW-сервиса, доступного по протоколу HTTPS. Использование host-headers для обслуживания нескольких HTTPS-сайтов на одном IP-адресе невозможно. Вы можете назначать номера портов, отличные от стандартного 443. Несколько лет назад это требование не было проблемой, но сейчас серверов очень много, и объем адресного пространства IP-протокола не вырос. Более того, все чаще компании решают разместить свои WWW-сервера у своих интернет-провайдеров, пулы IP-адресов которых недостаточно велики.
• Отсутствие возможности контролировать общение. Система, которая должна защищать от прослушивания злоумышленниками, также не позволяет системам обнаружения вторжений отслеживать попытки взлома.
• Сильно загруженный WWW-сервер. Если трафик на вашем сайте достигает сотен тысяч HTTP-запросов, вы, конечно, не можете позволить себе HTTPS-сервис для всего сайта. Это связано с тем, что служба шифрования (запуск SSL-сессии и кодирование данных) очень сильно нагружает процессор и значительно замедляет связь с клиентом. [1][2]

Конечно, нужно иметь в виду тот факт, что HTTPS ни в коем случае не заменяет основные меры безопасности WWW-сервера. Использование протокола HTTPS не является «волшебным» способом ограничить доступ хакеров, вирусов и других нежелательных гостей к вашему сайту. Подключения к сайту по протоколу HTTPS могут быть менее популярны, но это не исключает возможности их использования для атак!

Стоит ли в этом случае использовать HTTPS? Да, но вы должны знать об ограничениях, упомянутых ранее, и противодействовать им. Вариантом для HTTPS является VPN — виртуальная частная сеть.

Вот отличия этих технологий:

1. Во-первых, пользователь VPN должен получить пароль к сети, во-вторых, он должен подключиться к ней с помощью соответствующего программного обеспечения, такого как встроенная в Windows2000 служба IPSec. Это исключает высокую доступность услуг, потому что вы не должны отдавать пароль к защищенной сети любому, кто его попросит. В противном случае рано или поздно учетные записи пользователей VPN выйдут из-под вашего контроля, и защита станет горизонтальной, что еще опаснее, чем ее отсутствие. В отличие от VPN, протокол HTTPS позволяет кодировать данные независимо от аутентификации пользователя. По общему признанию, можно принудительно выполнить аутентификацию другой стороны в настройках IIS, но этот параметр необязателен и не нужен для работы HTTPS.
2. VPN дает доступ не к конкретному сервису, а к выбранному адресу или группе адресов в защищаемой сети. Если вы решите использовать VPN, вы должны подумать, насколько широким должен быть доступ пользователей к сети, защищенной VPN. Это может быть один сервер, небольшая их группа или, иногда, большая часть сети. Кроме того, вы должны рассмотреть способы разделения сети — действительно ли VPN позволит заблокировать доступ к определенным IP-номерам? Устройства CISCO блокируют их, используя возможности протокола IPSec. К сожалению, некоторые программы, устанавливающие соединение по протоколу IPSec, не распознают эти параметры. В этом случае можно эффективно ограничить доступность сети, установив дополнительные маршрутизаторы, разделив сеть на сегменты.
3. Высокая цена. Откровенно говоря, обычный компьютер с установленным Windows 2000 Server, предоставляющим услуги RRAS, может стать устройством VPN. Однако в большинстве случаев этого недостаточно. Запуск VPN на брандмауэре позволяет более точно защитить сеть, но цена такого устройства может быть выше, чем цена выделенного компьютера.
4. Отсутствие возможности аутентификации VPN-клиента по отношению к веб-серверу с помощью сертификата. Очевидно, что само VPN-подключение может использовать сертификат, который не будет представлен серверу, поскольку он не может его прочитать без использования HTTPS. Вы можете запустить HTTPS-соединение внутри VPN, но в этой ситуации было бы безопаснее и дешевле вообще обойтись без VPN.

Другой возможностью является «делегирование» кодирования HTTPS другим устройствам, так называемым ускорителям SSL. Они берут на себя обслуживание входящих HTTPS-запросов и передают обычные HTTP-запросы на WWW-сервер. Благодаря этому возможен мониторинг трафика серверов с использованием инструментов отслеживания злоумышленников, а также освобождение серверов от затратных по мощности ЦП операций шифрования. К сожалению, использование ускорителей SSL затрудняет (или даже делает невозможным) чтение сертификатов пользователей веб-сервером. Другим серьезным недостатком является цена. [3]

Во многих ситуациях вы можете полностью отказаться от шифрования, но помните о том, что передаваемая информация может быть перехвачена. Сделайте вывод о возможных последствиях – не вся информация в зашифрованном соединении стоит того, чтобы нагружать процессоры дополнительной нагрузкой J. Подсказка для веб-мастеров: javascripts, картинки и таблицы стилей, т.е. все элементы, загружаемые браузером для отображения сайта, также будут зашифровано. Чем больше их количество и объем, тем дороже становится криптография — с учетом загрузки процессора и времени передачи. Очевидно, что могут быть закодированы только некоторые элементы сайта, но такая ситуация вызовет недоверие пользователей: стоит ли доверять подписям? А не графика? Или, может быть, скриптам DHTML тоже нельзя доверять?

Давайте закончим эту теоретическую диссертацию и приступим к установке защиты HTTPS на вашем сайте. Для этого необходимо использовать тестовый сертификат, выданный VeriSign Incorporated. Однако этот сертификат не сделает ваш сервер надежным для ваших пользователей, потому что вы сами можете выдать его для своей системы. К сожалению, вам придется взимать плату за аутентификацию собственного сервера [4][5]. Давайте найдем веб-сайт [6] VeriSign Incorporated, на котором описаны продукты для обеспечения безопасности веб-сайтов. Нажмите кнопку «Попробовать» под продуктом, расположенным вторым сверху.

Впоследствии вам нужно будет ответить на короткую анкету и передать ее, нажав кнопку «Отправить». После отправки анкеты вы увидите информационный сайт. Прежде чем нажимать кнопку «Продолжить», попробуйте прочитать его с полным пониманием. Следующим шагом является формирование запроса на сертификат – для его получения зайдите в представленное ранее приложение MMC 'Internet Server Manager' (при этом оставляя окно Internet Explorer все время открытым), щелкните правой кнопкой мыши на названии вашей компании и откройте окно «Свойства». Перейдя на вкладку «Безопасность каталога», нажмите кнопку «Сертификат сервера…» в самом нижнем из разделов «Безопасная связь». На домашней странице «Мастер сертификатов IIS» перейдите к выбору операции и найдите параметр «Создать новый сертификат». Следующий экран позволит вам выбрать только один вариант: «Подготовить запрос сейчас, но отправить его позже». Затем заполните поля, необходимые для сертификата — имя должно совпадать с DNS-именем вашего сайта, а длина не должна быть меньше 1024 бит.

На следующем экране заполните поля «Организация» и «Подразделение» (в первом поле должно быть указано название вашей компании, во втором — название отдела или места соответственно). На следующем экране введите полное DNS-имя вашего веб-сайта (в моем примере это будет www.company name.pl, но читатель, естественно, должен ввести полное имя сервера, доступного из Интернета или интранета). Нажмите «Далее» и введите информацию о вашей организации — не забудьте указать название своей страны (PL для Польши и т. д.), а также введите штат/область и город или населенный пункт. На последнем экране выберите место и имя файла для сохранения вашего запроса — для вашего удобства выберите «Рабочий стол текущего пользователя». После нажатия кнопки «Далее» вам будет представлена идентификационная информация, которая указана в сертификате вашего сервера — эта информация будет доступна любому пользователю, имеющему доступ к HTTPS-соединению с вашим сервером. Если вы покупаете сертификат, убедитесь, что он включает данные, которые должны быть сертифицированы как действительные поставщиком сертификата — при необходимости вы можете вернуться к исправлению данных. После нажатия кнопки «Далее» вы увидите файл certreq.txt. Вернитесь в центр регистрации VeriSign и нажмите «Продолжить». Вам будет предложено отправить запрос на подпись сертификата (CSR), а затем появится большое текстовое поле для копирования и вставки содержимого ранее созданного файла certreq.txt.

После нажатия кнопки «Продолжить» вы перейдете к информации вашего CSR, ранее введенной в IIS. Вы должны заполнить регистрационную форму, указав дополнительную контактную информацию root. Ознакомившись с соглашением о тестовом сертификате, нажмите кнопку «Принять». Вам будет предоставлена информация об обработке сертификата. После утверждения сертификата VeriSign вернет вам подписанный сертификат по электронной почте. Прежде чем проверить свой почтовый ящик, вы должны установить тестовый корневой сертификат CA на свой WWW-сервер и в любой браузер, который будет использовать HTTPS-соединение (это недостаток тестовых и бесплатных загружаемых сертификатов — коммерчески распространяемые сертификаты обычно устанавливаются по умолчанию в Интернете). браузерах и на сервере IIS). Выберите ссылку «Часто задаваемые вопросы», и вы снова увидите Заявление VeriSign о практике сертификации в отношении использования сертификата тестирования. сертификат на самом деле» и не проверяет подлинность пользователя сертификата (следующий недостаток тестовых сертификатов). Нажмите кнопку «Принять», чтобы открыть окно для сохранения файла «getcert.cer» — найдите его, например, на рабочем столе активного пользователя.

Затем вы можете открыть его обычным способом и увидеть сертификат подписи для вашего сервера. Теперь вам нужно установить его на свой веб-сервер — для этого нажмите кнопку «Установить сертификат…» и нажмите «Далее» на первой странице «Мастера импорта сертификатов». На следующей странице выберите параметр «Поместить все сертификаты в следующее хранилище» и нажмите кнопку «Обзор…». Вам будет представлено окно выбора места назначения сертификата — вы должны выбрать опцию «Показать физические хранилища», а затем выбрать «Доверенные корневые центры сертификации> Локальный компьютер».

Затем продолжите — на последней странице мастера нажмите кнопку «Готово», чтобы выйти из мастера. Вы получите окно сообщения, подтверждающее, что сертификат был создан. Если вы сейчас закроете страницу сертификата и снова запустите ее, вы увидите, что сертификат выделен без отметки отмены — это означает, что импорт сертификата прошел успешно и отныне ваш компьютер будет доверять этому сертификату ЦС и любым другим сертификатам. подписаны тем же органом.

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

Теперь вы можете проверить свою электронную почту — ожидается, что VeriSign отправит сообщение о новом сертификате для вашего сервера не позднее одного часа. В конце сертификата вы увидите часть, разделенную символами «——BEGIN CERTIFICATE——» и «——END CERTIFICATE—-».

Чтобы скопировать сертификат сервера, добавьте строки начального сертификата и конечного сертификата в текстовый редактор, например Блокнот. Сохраните сертификат сервера в виде текстового файла (с расширением файла.cer для вашего удобства), вернитесь на вкладку «Безопасность каталога» на странице конфигурации вашего веб-сайта и снова нажмите кнопку «Сертификат сервера». На этот раз выберите операцию «Обработать ожидающий запрос и установить сертификат». В следующем окне мастера выберите файл сертификата, который вы ранее сохранили на диске, и подтвердите информацию о сертификате. Наконец, нажмите на кнопку «Готово». Теперь вы можете проверить настройки SSL для вашего сайта. На вкладке «Безопасность каталога» под кнопкой «Сертификат сервера» вы увидите два выделенных поля: «Просмотр сертификата» (представляющее то же содержимое сертификата, что и для пользователей сервера) и «Редактировать» (для изменить настройки моста HTTPS на текущем веб-сайте, в каталоге или в файле). Прежде чем подключаться к веб-серверу через зашифрованное соединение, вы должны привязать порт и идентификатор к своему веб-сайту. Выберите вкладку «Веб-сайт», нажмите кнопку «Дополнительно…», чтобы открыть окно, в котором вы сможете перейти к процедуре присоединения IP-номера к веб-сайту (а также для присоединения имен, таких как заголовки узлов). Окно содержит два списка: верхний содержит незашифрованные данные веб-сайта, а нижний относится к безопасным соединениям SSL. Нажмите кнопку «Добавить» под нижним списком и в «Расширенной идентификации SSL веб-сайта» выберите IP-адрес и введите номер порта (обычно 443). Естественно, это может быть тот же IP-адрес, который был присвоен незашифрованному веб-сайту. Наконец, вы должны подтвердить внесенные вами изменения.

Теперь вы можете подключиться к веб-серверу через HTTPS. Помните, что такое подключение должно соответствовать следующим требованиям:

• Связь между сервером и пользователем браузера защищена одним и тем же корневым сертификатом (корневым сертификатом, поскольку он аутентифицирует владельцев других сертификатов) — в приведенном примере; это VeriSign Test CA Root;
• Серверу предоставлен сертификат, выданный органом, который является владельцем указанного корневого сертификата;
• Служба WWW работает через безопасный порт SSL и доступна из веб-браузера пользователя;
• Пользователь взаимодействует с сервером, используя то же DNS-имя, которое указано в сертификате сервера. Естественно, достаточно, если имя сервера "разведено" клиентом с помощью записи в локальном файле Hosts (для Windows 2000 это файл c:winntsystem32driversetchost) - можно проверить свой сертификат без использования DNS-сервера.

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

Каков наилучший способ включить аутентификацию пользователей на основе сертификатов? Используйте настройки HTTPS. Нажмите кнопку «Изменить» в разделе «Безопасная связь», и на вкладке «Безопасность каталога» вы увидите поле «Безопасная связь».

Вы можете выбрать один из следующих вариантов:

• Требовать безопасный канал (SSL) — этот параметр означает, что веб-сайт (или страница / каталог) будет доступен только через зашифрованное соединение. Любая попытка активировать HTTP-соединение будет генерировать сообщение об ошибке «403 SSL required». Вы также можете установить минимальную 128-битную стойкость шифрования (с точки зрения симметричного ключа), используя опцию «Требовать 128-битное шифрование».
• Клиентские сертификаты — это позволяет читать или даже принудительно выполнять аутентификацию пользователя с использованием его собственного SSL-сертификата. Установка значения «игнорировать» приводит к тому, что IIS не читает содержимое клиентских сертификатов. Установка «принять» позволит ему читать содержимое сертификатов в WWW-приложении (т. е. страницы ASP) — с использованием коллекции Request.ClientCertificate [7] и определенных полей коллекции Request.ServerVariables [8]. Если вы включили эту последнюю опцию на основе SSL-аутентификации, вы также можете выбрать опцию «требовать сертификат клиента» — пользователи, не прошедшие аутентификацию по сертификату, получат сообщение об ошибке «403 Требуется сертификат клиента».
• Включить сопоставление клиентских сертификатов — это позволяет входить в учетные записи пользователей Windows с использованием сертификатов, то есть без необходимости отправлять пароль пользователю. Этот параметр может иметь значение, если вы собираетесь защищать ресурсы сервера с помощью ACL, например, ограничивая доступ к файлам веб-сайта для избранных пользователей. Если вы собираетесь использовать эту опцию, вы должны определить правило сопоставления сертификатов — нажмите кнопку «Изменить…», чтобы открыть соответствующее окно.

Возможны два правила сопоставления сертификатов:

• 1-к-1: Один-к-одному — это сопоставление одного пользовательского сертификата с одной учетной записью пользователя (достаточно использовать только общедоступную часть, например, взятую из сообщения с электронной подписью). Этот сертификат можно использовать для сопоставления с учетной записью пользователя для аутентификации. Теперь пользователь может использовать Secure Socket Layer (SSL) для безопасного подключения к веб-странице из любого места, предоставления своего клиентского сертификата веб-серверу и входа в систему с использованием собственной учетной записи пользователя. Всякий раз, когда пользователь меняет свою учетную запись, вам придется заново настраивать сопоставление.
• Many-to-1: вы можете установить правило, которое сопоставляет все сертификаты, выпущенные этим центром сертификации. Это правило сопоставления означает, что многие сертификаты могут быть сопоставлены с одной учетной записью пользователя, и не требуется никаких изменений конфигурации всякий раз, когда пользователь меняет свой сертификат — достаточно, чтобы основные данные сертификата оставались неизменными. Вы можете проверить данные, указанные в полях Тема (информация о владельце сертификата) и Эмитент (информация об издателе сертификата). Примерное отображение «многие к 1» показано на рисунке 12.

В то время как очень простая страница ASP для чтения сертификата представлена в файле default.asp.

Помните, что с пользовательскими сертификатами может потребоваться установка на сервер дополнительных сертификатов — тех, которые использовались для подписи пользовательских сертификатов. Если вы пользуетесь бесплатными загружаемыми сертификатами, такими как Thawte Freemail [9], вам также следует загрузить сертификат «Personal Free mail RSA 2000.8.30», который представляет собой сертификат CA Thawte Freemail, используемый для подписи и шифрования электронной почты, иначе вы не сможете иметь возможность идентифицировать подписавшего. Эта операция не является ни необходимой, ни рискованной — промежуточные сертификаты автоматически наследуют доверие
настройки их корней, которые установлены по умолчанию в вашей операционной системе.

Если вы хотите ограничить пользовательские сертификаты сертификатами корневого ЦС, используйте самую низкую опцию в окне «Безопасная связь»:

• Включить список доверенных сертификатов: здесь вы можете выбрать список доверенных сертификатов ЦС. Нажмите кнопку «Создать…», чтобы создать конкретный список, выбирая сертификаты ЦС как из локальных «Доверенных корневых центров сертификации» (это тот же список, который вы использовали для размещения корневого тестового сертификата ЦС Thawte), так и из файловой системы.

Если вы используете сопоставление сертификатов, вы, очевидно, воспользуетесь преимуществами учетных записей Windows, но для многих приложений это не требуется. Сертификат можно проверить и прочитать без сопоставления сертификатов, как это представлено в листинге default.asp. Таким образом, сертификат пользователя можно использовать, например, для аутентификации пользователей в списке учетных записей, хранящемся в базе данных, — без использования паролей пользователей! Поскольку сертификат проверяется IIS, достаточно прочитать поле «Флаги» (которое должно быть равно 1), а также «Издатель» и «Серийный номер» (или «Издатель» и «Тема») — тогда это может быть используется как ключ для однозначного указания пользователя в списке учетных записей вашего приложения.

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

здесь

Бронек Козицки последние восемь лет работал сетевым администратором. Пять лет были посвящены системам на базе Windows NT. Он занимается администрированием баз данных SQL Server, приложений, вопросами сетевой безопасности и эффективностью интернет-серверов. Он пишет серверные решения (в основном расширения служб IIS — SMTP и W3SVC) на языке C++. Помимо программирования, он занимается обучением расширенному использованию C++, таким как: методология, идиомы, стили программирования и современные особенности языка. Он был членом редакционной коллегии журнала WinSecurity Magazine, где он был главным редактором страниц базы знаний Microsoft. В настоящее время он работает сетевым администратором в Getin SP SA, компании, предоставляющей интернет-услуги. Свободное время он проводит с женой, гуляя или в кино, или читая книги, предпочтительно научную фантастику. Он чемпион мира по приготовлению горячего шоколада с пеной или капучино.

Библиография:

[1] http://www.microsoft.com/technet/prodtechnol/iis/maintain/optimize/iis5tune.asp
[2] http://www.microsoft.com/technet/prodtechnol/iis/reskit/iis50rg/iischp5.asp
[3] http://www.sonicguard.com/SSL-R.asp
[4] http://www.polcert.pl/www.html
[5] http://www.certum.pl/pl/produkty/servery_www/index.html
[6] http://www.verisign.com/products/site/index.html
[7] http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/vbob8q5h.asp
[8] http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/vbob5vsj.asp
[9] http://www.thawte.com/html/COMMUNITY/personal/index.html