Сервер Web организации обеспечивает ее присутствие в Internet. Однако распространяемые этим сервером данные могут содержать сведения частного характера, не предназначенные для чужих глаз. К сожалению, серверы Web представляют собой лакомую приманку для злоумышленников. Широкую огласку получили случаи "нападения" на серверы Министерства юстиции и даже ЦРУ: злоумышленники подменяли домашние страницы этих организаций на непристойные карикатуры. Поборники прав животных проникли на сервер Kriegsman Furs и заменили домашнюю страницу ссылкой на узлы, посвященные защите братьев наших меньших. Схожая судьба постигла серверы Министерства юстиции США, ЦРУ, Yahoo! и Fox. Дэн Фармер, один из создателей программы SATAN, для поиска брешей в защите сетей использовал еще не завершенную официально версию своего сканера для зондирования Web-серверов Internet и установил, что почти две трети из них имеют серьезные изъяны в защите.
Очевидно, что серверы Web защищены далеко не так надежно, как хо-телось бы. В некоторых простых случаях все дело в незаметных, но небезопасных огрехах в сценариях CGI. В других ситуациях угрозу представляет недостаточная защита операционной системы хоста.
Простейший способ укрепить защиту сервера Web состоит в размещении его за брандмауэром. Однако, действуя таким образом, пользователь как бы переносит проблемы защиты во внутрикорпоративную сеть, а это не самый удачный выход. Пока сервер Web располагается "по другую сторону" брандмауэра, внутренняя сеть защищена, а сервер - нет. Побочным эффектом от такого шага является усложнение администрирования сервера Web.
Лучшим выходом было бы компромиссное решение: размещение сервера Web в его собственной сети, запрет внешних соединений или ограничение доступа к внутренним серверам.
Немало пользователей размещают серверы Web за брандмауэром во внутренней сети. Такая диспозиция обеспечивает простоту управления, но ценой безопасности. Кроме того, в этом случае работать с сервером защищенным образом становится намного труднее.
Вернемся на несколько лет назад, чтобы посмотреть, что может случиться, когда общедоступный сервер Web размещается во внутренней сети (см. Рисунок 1). Допустим, конфигурация брандмауэра такова, что он пропускает только трафик, предназначенный серверу Web (HTTP и, возможно, HTTPS). Если злоумышленник прощупывает сеть в поисках слабых мест, то его зонд обнаружит только порт сервиса Web, и ничего более. Посылать пакеты UDP или TCP для других служб (SMTP, telnet, ftp, finger и других) злоумышленник не может, так как они полностью блокированы. Что же еще может случиться?
Первой выяснить это имела несчастье компания General Electric. В 1994 году (как назло, как раз в День Благодарения) хакер обнаружил лазейку на сервере Web компании, расположенном за брандмауэром во внутренней сети. Он послал HTTP-запрос по стандартному соединению TCP и воспользовался невыявленной ошибкой сервера Web. Исследовав систему, хакер сохранил TCP-соединение с сервером Web, однако теперь он уже мог взаимодействовать не с программным обеспечением сервера, а с интерпретатором команд.
Иными словами, изначально стандартное Web-соединение функционировало уже скорее как сеанс telnet. сервер Web теперь можно было использовать как базу для проникновения во внутрикорпоративную сеть. У хакера был удачный день - он пробрался во множество систем, и все благодаря туннелю через сервер Web, с которым брандмауэр разрешал устанавливать соединение извне.
Еще один недостаток размещения сервера за брандмауэром состоит в том, что пользователи невольно начинают рассматривать сервер Web как обычный внутренний сервер. Такое отношение недопустимо: сервер Web нуждается в особом внимании, так как он открыт для доступа внешних пользователей, даже если эта открытость и ограничивается HTTP. Восприятие сервера Web как неотъемлемого элемента брандмауэра вырабатывает у администраторов именно такое отношение, какое требуется, - подозрительное до помешательства.
Другая стратегия состоит в размещении сервера Web по другую сторону брандмауэра (в данном случае под брандмауэром мы понимаем шлюз приложений или брандмауэр с контекстной проверкой). Чаще всего между сервером Web и Internet по-прежнему располагается маршрутизатор, с помощью которого сервер Web можно защитить средствами фильтрации пакетов. Так что и в этом случае сервер Web не оказывается полностью беззащитным.
Достоинство такой конфигурации, безусловно, состоит в том, что, даже проникнув на сервер Web, злоумышленник все же остается по внешнюю сторону брандмауэра. При "атаке" на сервер брандмауэр ограничит доступ с сервера во внутрикорпоративную сеть (см. Рисунок 2).
С другой стороны, администрировать сервер Web становится намного труднее, поскольку доступ к нему оказывается в значительной мере затруднен - теперь между администратором и сервером Web находится брандмауэр. Кроме того, конфиденциальная информация оказывается как бы "за дверью" - за пределами внутренней сети. Допустим, сервер Web находился под охраной брандмауэра, и пользователи работали с ним, как с обычным сервером базы данных, и размещали на нем конфиденциальные данные, которые имеющие на то надлежащие права пользователи Web могли просматривать контролируемым образом. Теперь же сервер со всеми закрытыми данными надо вынести наружу.
Кому такое понравится? Смысл брандмауэров и состоит в том, чтобы защитить критически важные данные и внутреннюю сеть по периметру. Теперь эти данные оказываются "за оградой" и защищены только маршрутизатором. Стоит лишь кому-нибудь проникнуть на сервер - и все хранящиеся на нем сведения станут известны посторонним людям. Впрочем, справедливости ради стоит отметить, что то же самое произойдет и в том случае, если удастся атака на защищенный брандмауэром сервер Web.
Выход может быть только один - критически важные данные не следует хранить на сервере Web. Лучше разместить их на внутреннем сервере базы данных. Тогда вы можете создать многоуровневую систему защиты на основе сценариев CGI или других механизмов сервера Web, с помощью которых он обрабатывает запросы от внешних пользователей и передает их на внутренний сервер базы данных. Внутренний сервер способен проверить полномочия подающего запрос и предоставить ему ограниченную выборку закрытых данных. В этом случае сервер Web действует как клиент базы данных, используя средства удаленной идентификации пользователей (имя и пароль, например) для получения доступа к определенной части базы данных.
Брандмауэр позволит серверу Web обратиться только к серверу базы данных, но ни к каким другим внутренним ресурсам. Если даже злоумышленник проникнет на открытый сервер Web, единственной лазейкой во внутреннюю сеть для него остается сервер базы данных, а он имеет собственную защиту.
Вместо того чтобы выставлять сервер Web на всеобщее обозрение под ненадежной защитой маршрутизатора, вы можете выбрать компромиссный вариант. Сервер Web можно расположить в экранированной подсети, или "демилитаризованной зоне", т. е. фактически брандмауэр будет обслуживать три сети (см. Рисунок 3). В результате брандмауэр будет защищать и сервер Web, и внутреннюю сеть.
В такой конфигурации брандмауэр пропускает из Internet на сервер только трафик HTTP (и, возможно, S/HTTP). Кроме того, он контролирует доступ сервера Web во внутреннюю сеть, ограничивая его внутренними серверами баз данных. В дополнение к этому, внутренним пользователям следует разрешить доступ к серверу Web для тестирования.
Несмотря на все достоинства, этот подход имеет свои "подводные камни". Как пользователи внутренней сети будут администрировать сервер Web? Он по-прежнему остается лакомым кусочком для злоумышленников и нуждается в очень тщательном администрировании. Если администраторы Web станут относиться к нему так же, как к внутреннему серверу, - жди неприятностей.
Общедоступные серверы Web нужно конфигурировать как неприступные хосты (форт-хосты): все ненужные службы программного обеспечения с них следует удалить. В идеале на сервере должно остаться только необходимое ПО, и ничего более. Так, систему UNIX вполне можно настроить как форт-хост: при этом она будет содержать менее 100 файлов, без учета документов и сценариев. Все прочее программное обеспечение следует удалить, а лучше вообще не устанавливать. Если вы не хотите удалять ненужное ПО, то по крайней мере блокируйте те сетевые сервисы, которые не требуются серверу Web для выполнения его непосредственных функций.
Необходимо убедиться, что сервер Web допускает удаленное администрирование. Для безопасного удаленного администрирования мы рекомендуем использовать шифруемое соединение, организовать которое можно с помощью защищенного программного обеспечения telnet или Secure Shell (SSH).
Еще один принцип форт-хоста - сокращение до минимума числа пользовательских бюджетов. В идеале их вообще не должно быть, за исключением бюджетов системного администратора и мастера Web. Чем меньше в системе пользователей, тем меньше вероятность того, что кто-то из них сделает ошибку и откроет лазейку для злоумышленников.
Еще большей защищенности можно добиться, исключив необходимость человеческого вмешательства и автоматизировав администрирование общедоступного сервера Web. Невозможно? Это и так, и не так. Систему следует настроить таким образом, чтобы администраторы Web работали с внутренними серверами Web. Все изменения, сделанные на внутреннем сервере, затем нужно перенести на внешний, общедоступный сервер Web. В принципе, это можно сделать с помощью протокола совместного использования файлов, таких как Microsoft Server Message Block или Unix Network File System. Однако подобные протоколы не гарантируют защиты, и пользоваться ими не следует.
Вместо этого мы рекомендуем воспользоваться программным обеспечением зеркального копирования: оно обновит общедоступный сервер Web и перенесет все изменения, проделанные на внутреннем сервере. Для этого ни пользовательских, ни административных бюджетов не требуется, так как программное обеспечение зеркального копирования может зарегистрироваться на общедоступном сервере Web как самостоятельный объект.
Одно из преимуществ данного подхода состоит в том, что вы получаете оперативную резервную копию открытого сервера Web. Кроме того, перед перенесением изменений их можно протестировать. В отношении внутреннего сервера Web не требуется принимать таких строгих мер защиты, как в отношении общедоступного сервера, поэтому администраторам Web будет немного проще получить к нему доступ.
Нежелательно, однако, чтобы в систему было легко проникнуть изнутри. Ее по-прежнему требуется защитить от внутренних атак. Здесь мы можем предложить воспользоваться программным обеспечением контроля версий для данных на сервере Web. Оно позволяет определить, кто производил изменения, и обеспечивает возможность отката.
Windows NT приобрела популярность в качестве платформы сервера Web (в особенности для сетей Intranet), но не по заслугам. Считается, что администрировать NT проще, чем серверы UNIX аналогичного масштаба, и это в определенной степени верно. Другие особенности серверов NT, такие как аутентификация доменов и возможности совместного использования файлов, также привлекают внимание администраторов к этой ОС. И все же, сколь бы весомыми ни были соображения в пользу выбора NT в качестве сервера Web, все они ничего не стоят по сравнению с недостатками защиты.
Большинство администраторов Web до сих пор даже не знают, каким собственно образом злоумышленники атакуют их серверы. Сообщество пользователей UNIX уже накопило достаточный опыт для противодействия нападениям и укрепления своих систем. У адептов Microsoft такого опыта пока нет. К счастью, уделив внимание нескольким вполне очевидным вещам, вы сможете избавить себя от многих серьезных проблем.
Windows NT обладает прекрасными функциональными возможностями настройки и контроля доступа к файлам и каталогам. В качестве первого шага к обеспечению безопасности сервера Web на базе NT администратору следует воспользоваться списками контроля доступа (Access Control Lists, ACL). И все же, прежде чем переходить к описанию списков, мы хотели бы пояснить, кто имеет доступ к файлам на сервере Web.
Ниже мы будем предполагать, что сервер Web представляет собой Internet Information Server (IIS) на базе NT. (Кстати, тем, кто действительно использует этот сервер, следует обязательно установить и Service Patch 3, и последние "заплатки" для IIS. Без них любой сможет прочитать исходные тексты сценариев, добавив точку [.] или символы %2е в конец имен файлов.)
IIS предоставляет три метода подтверждения прав доступа к информации Web: анонимный, базовая регистрация открытым текстом и процедура "запрос-ответ" Windows NT. Большинство серверов Internet поддерживает только анонимный доступ, который на серверах IIS по умолчанию соответствует пользовательскому бюджету IUSR-computername. При инсталляции IIS программа установки автоматически добавляет на сервер NT этот бюджет, который затем используется службами IIS FTP, а также Gopher.
"Анонимный" бюджет IUSR-computername должен иметь право на локальную регистрацию, что достигается заданием параметра User Right to Logon. Другие права не требуются. Пользуясь Internet Service Manager (ISM), вы можете выбрать иное имя пользователя и пароль для этого бюджета. Бюджет не обязан входить в какую-либо группу.
Права бюджета IUSR-computername должны быть ограничены чтением и исполнением файлов и каталогов в пределах корневого каталога документов сервера Web (по умолчанию \InetPub\wwwroot\). Полные права следует предоставлять только группе (пользователю), ответственной за администрирование файлов сервера Web.
Для того чтобы настроить ACL для файлов Web, вы должны запустить Windows NT Explorer и войти через каталог \InetPub в каталог \wwwroot. Щелкните правой клавишей мыши на \wwwroot, выберите команду Properties и откройте закладку Security. Кнопка Permissions на закладке Security позволяет изменить права доступа. В большинстве систем NT в конфигурации по умолчанию пользовательской группе Everyone даются права Full Control. Эти установки можно заменить на Read, либо (например, в том случае, если планируется только анонимный доступ) отменить все права доступа для данной пользовательской группы.
Второй метод идентификации доступа - базовая регистрация открытым текстом. Эта стратегия не обеспечивает защиты. Она предполагает пересылку имени пользователя и пароля по сети в незашифрованном виде. Следовательно, такую информацию легко перехватить, особенно в сетях Intranet (да, впрочем, и в Internet тоже).
Windows NT предлагает и третий метод проверки прав доступа: процедуру "запрос-ответ". Ее преимущество состоит в более безопасной передаче имен пользователей и их паролей по сети. Кроме того, такой метод позволяет определять для файлов и каталогов на сервере Web, какие из них может видеть клиент Web. Система автоматически переходит к проверке прав доступа по методу "запрос-ответ", если анонимный пользовательский бюджет запрашивает ресурс, на который он не имеет прав.
Очевидный недостаток этого метода заключается в том, что каждый проходящий аутентификацию пользователь должен либо иметь бюджет на сервере Web, либо быть идентифицирован в домене. Однако далеко не всегда желательно, чтобы посторонние пользователи имели бюджеты в том или ином домене. Метод "запрос-ответ" хорошо подходит для серверов Web на базе Windows NT в сети Intranet, поскольку все пользователи, имеющие доступ к ресурсам Web, принадлежат к тому же домену, что и сервер Web.
Метод форт-хоста предполагает, как уже говорилось, укрепление сервера посредством удаления ненужных пользовательских бюджетов и сервисов. В случае сервера Web на базе NT его функции лучше всего ограничить только функциями сервера Web. При активном использовании эти функции отнимают столько ресурсов, что отказ от обслуживания других пользователей или предоставления сервисов не окажется непроизводительным разбазариванием ресурсов.
Принцип форт-хоста предполагает также отказ от сетевых пользовательских бюджетов. Все бюджеты должны быть локальными: они предназначаются для администрирования Web. Решение об открытии сетевых бюджетов для администраторов Web на Web-сервере Intranet зависит исключительно от важности хранимой на нем информации.
Следующий важный вопрос: какие сервисы будет разрешено предоставлять серверу Web? Как правило, NT предоставляет много сервисов по умолчанию, большинство которых не нужно, когда NT используется в качестве сервера Web.
Все эти сервисы, в особенности сервисы файлов и печати, следует отключить на серверах Web, доступ к которым открыт из Internet. Совместное же использование файлов на серверах Web в корпоративной сети Intranet следует разрешить исходя из важности хранящихся в общих каталогах данных. Помимо этого, NT имеет много других сервисов по умолчанию. Блокировать следует Simple Services, а также такие сервисы TCP/IP, как Echo и Character Generator, которые используются при отладке настроек TCP/IP.
Хотя от многих дополнительных сервисов следует отказаться, серверу Web может потребоваться выполнять и многие иные функции помимо простого обслуживания файлов Web. Например, серверы Web могут принимать и обрабатывать информацию от клиентов Web - как правило, собираемую с помощью форм. Один из методов обработки форм предполагает использование CGI. Этот интерфейс открывает лазейку для проникновения на серверы Web - не из-за недостатков интерфейса, а из-за того, что сценарии обработки вводимых пользовательских данных могут иметь ошибки в программировании. Организация, известная как CERT (Computer Emergency Response Team), только в 1997 году выпустила четыре предупреждения относительно безопасности Web и CGI (см. врезку "Ресурсы Internet").
Наиболее распространенной ошибкой в сценариях CGI можно считать некорректную обработку пользовательских данных. Изобретательный злоумышленник может воспользоваться этим и направить на сервер Web непредусмотренный ввод, в результате которого команды будут исполняться по "указке" хакера. Помимо CGI серверы IIS и NT поддерживают также ISAPI (Internet Server Application Programming Interface). Как известно, ISAPI имеет большую устойчивость к атакам такого рода.
Другая проблема со сценариями CGI заключается в том, что они могут использовать такие интерпретаторы, как CMD.EXE или Perl. Эти интерпретаторы ни в коем случае нельзя размещать в каталогах со сценариями! В ранних версиях Netscape Communicator интерпретатор Perl был помещен в каталог сценариев, так что любой желающий мог выполнить команду Perl на сервере Web по своему выбору.
На сервере NT в сети Intranet вы можете использовать фильтрацию пакетов. NT поддерживает простейшую фильтрацию пакетов, настроить которую можно посредством выбора закладки Protocols в апплете Network, в Control Panel. Для этого вам придется дважды щелкнуть мышью на TCP/IP, а затем выбрать кнопку Advanced в нижней части диалогового окна. Панель IP Address содержит флажок для блокирования/разблокирования защиты и кнопку Configure.
Щелчок мыши на Configure открывает меню, где вы можете указать, какие пакеты должен пропускать фильтр пакетов. Возможности фильтрации на редкость ограниченны: нельзя, например, открыть или закрыть для доступа некоторый диапазон портов или даже указать порт по имени. При выборе IP-протоколов нужно знать номер протокола, используемый в IP-заголовке и определенный в RFC1700. Однако не стоит пренебрегать и этой маломощной защитой. Обновленный IIS4 должен обеспечить лучшую фильтрацию.
Чем надежнее фильтрация пакетов, тем лучше защита. Например, сервер Web получает запросы через порт 80. Разрешив фильтру TCP пропускать только пакеты, адресованные этому порту, администратор тем самым запрещает использование всех других прикладных протоколов TCP/IP. Кроме того, он может, например, открыть порт 443 для протокола Secure Socket Layer (SSL). Теперь фильтр пакетов будет разрешать установку только соединений через порты 80 и 443. При этом исходящие соединения он никак не будет ограничивать.
(Стоит заметить, что локальные FTP-клиенты, функционирующие в активном режиме, будут работать некорректно, поскольку они должны устанавливать соединение с IIS-сервером для передачи данных через FTP-сервер. Клиент FTP в NT работает в
активном режиме и непременно вызовет это затруднение. Большинство FTP-клиентов, встроенных в браузеры Web, работают в пассивном режиме.)
Необходимо также иметь в виду, что подобная фильтрация защищает только от атак с использованием особенностей TCP/IP. NT же поддерживает и другие протоколы, такие как NetBIOS и Net-
Ware IPX. Маршрутизируемый протокол NetWare может представлять опасность с точки зрения удаленных атак. Сервер Web задействует только TCP/IP, поэтому другие протоколы следует отключить при помощи закладки Bindings в апплете Network. Это может затруднить аутентификацию доменов, совместное использование файлов и удаленное редактирование реестра пользователей. Однако в результате система станет более надежной.
Как становится ясно из приведенных рекомендаций, укрепление защиты сервера Web на базе NT предполагает отказ именно от тех функций, которыми NT и ценна. Понять, какие сервисы надо отключить и как управлять "урезанным"
NT-сервером - задача не из легких. Именно поэтому NT нельзя считать идеальной платформой для сервера Web. Тем, кто имеет опыт работы с UNIX, стоит подумать о том, чтобы развернуть сервер на этой платформе (согласно некоторым исследованиям, серверы Web на базе UNIX превосходят NT по производительности почти в два раза). Тем же, кто имеет дело только с продуктами Microsoft, при настройке сервера Web следует соблюдать особую осторожность.
