Защита сервера Web
Сервер Web организации обеспечивает ее присутствие в Internet. Однако распространяемые этим сервером данные могут содержать сведения частного характера, не предназначенные для чужих глаз. К сожалению, серверы Web представляют собой лакомую приманку для злоумышленников. Широкую огласку получили случаи "нападения" на серверы Министерства юстиции и даже ЦРУ: злоумышленники подменяли домашние страницы этих организаций на непристойные карикатуры. Поборники прав животных проникли на сервер Kriegsman Furs и заменили домашнюю страницу ссылкой на узлы, посвященные защите братьев наших меньших. Схожая судьба постигла серверы Министерства юстиции США, ЦРУ, Yahoo! и Fox. Дэн Фармер, один из создателей программы SATAN, для поиска брешей в защите сетей использовал еще не завершенную официально версию своего сканера для зондирования Web-серверов Internet и установил, что почти две трети из них имеют серьезные изъяны в защите.
Очевидно, что серверы Web защищены далеко не так надежно, как хо-телось бы. В некоторых простых случаях все дело в незаметных, но небезопасных огрехах в сценариях CGI. В других ситуациях угрозу представляет недостаточная защита операционной системы хоста.
Простейший способ укрепить защиту сервера 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, злоумышленник все же остается по внешнюю сторону брандмауэра. При "атаке" на сервер брандмауэр ограничит доступ с сервера во внутрикорпоративную сеть (см. Рисунок 2).
Кому такое понравится? Смысл брандмауэров и состоит в том, чтобы защитить критически важные данные и внутреннюю сеть по периметру. Теперь эти данные оказываются "за оградой" и защищены только маршрутизатором. Стоит лишь кому-нибудь проникнуть на сервер - и все хранящиеся на нем сведения станут известны посторонним людям. Впрочем, справедливости ради стоит отметить, что то же самое произойдет и в том случае, если удастся атака на защищенный брандмауэром сервер Web.
Выход может быть только один - критически важные данные не следует хранить на сервере Web. Лучше разместить их на внутреннем сервере базы данных. Тогда вы можете создать многоуровневую систему защиты на основе сценариев CGI или других механизмов сервера Web, с помощью которых он обрабатывает запросы от внешних пользователей и передает их на внутренний сервер базы данных. Внутренний сервер способен проверить полномочия подающего запрос и предоставить ему ограниченную выборку закрытых данных. В этом случае сервер Web действует как клиент базы данных, используя средства удаленной идентификации пользователей (имя и пароль, например) для получения доступа к определенной части базы данных.
Брандмауэр позволит серверу Web обратиться только к серверу базы данных, но ни к каким другим внутренним ресурсам. Если даже злоумышленник проникнет на открытый сервер Web, единственной лазейкой во внутреннюю сеть для него остается сервер базы данных, а он имеет собственную защиту.
Несмотря на все достоинства, этот подход имеет свои "подводные камни". Как пользователи внутренней сети будут администрировать сервер Web? Он по-прежнему остается лакомым кусочком для злоумышленников и нуждается в очень тщательном администрировании. Если администраторы Web станут относиться к нему так же, как к внутреннему серверу, - жди неприятностей.
Общедоступные серверы Web нужно конфигурировать как неприступные хосты (форт-хосты): все ненужные службы программного обеспечения с них следует удалить. В идеале на сервере должно остаться только необходимое ПО, и ничего более. Так, систему UNIX вполне можно настроить как форт-хост: при этом она будет содержать менее 100 файлов, без учета документов и сценариев. Все прочее программное обеспечение следует удалить, а лучше вообще не устанавливать. Если вы не хотите удалять ненужное ПО, то по крайней мере блокируйте те сетевые сервисы, которые не требуются серверу Web для выполнения его непосредственных функций.
Необходимо убедиться, что сервер Web допускает удаленное администрирование. Для безопасного удаленного администрирования мы рекомендуем использовать шифруемое соединение, организовать которое можно с помощью защищенного программного обеспечения telnet или Secure Shell (SSH).
Еще один принцип форт-хоста - сокращение до минимума числа пользовательских бюджетов. В идеале их вообще не должно быть, за исключением бюджетов системного администратора и мастера Web. Чем меньше в системе пользователей, тем меньше вероятность того, что кто-то из них сделает ошибку и откроет лазейку для злоумышленников.
Вместо этого мы рекомендуем воспользоваться программным обеспечением зеркального копирования: оно обновит общедоступный сервер Web и перенесет все изменения, проделанные на внутреннем сервере. Для этого ни пользовательских, ни административных бюджетов не требуется, так как программное обеспечение зеркального копирования может зарегистрироваться на общедоступном сервере Web как самостоятельный объект.
Одно из преимуществ данного подхода состоит в том, что вы получаете оперативную резервную копию открытого сервера Web. Кроме того, перед перенесением изменений их можно протестировать. В отношении внутреннего сервера Web не требуется принимать таких строгих мер защиты, как в отношении общедоступного сервера, поэтому администраторам Web будет немного проще получить к нему доступ.
Нежелательно, однако, чтобы в систему было легко проникнуть изнутри. Ее по-прежнему требуется защитить от внутренних атак. Здесь мы можем предложить воспользоваться программным обеспечением контроля версий для данных на сервере Web. Оно позволяет определить, кто производил изменения, и обеспечивает возможность отката.
Большинство администраторов Web до сих пор даже не знают, каким собственно образом злоумышленники атакуют их серверы. Сообщество пользователей UNIX уже накопило достаточный опыт для противодействия нападениям и укрепления своих систем. У адептов Microsoft такого опыта пока нет. К счастью, уделив внимание нескольким вполне очевидным вещам, вы сможете избавить себя от многих серьезных проблем.
Ниже мы будем предполагать, что сервер 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 должны быть ограничены чтением и исполнением файлов и каталогов в пределах корневого каталога документов сервера 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. Решение об открытии сетевых бюджетов для администраторов 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 по своему выбору.
Щелчок мыши на 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. Это может затруднить аутентификацию доменов, совместное использование файлов и удаленное редактирование реестра пользователей. Однако в результате система станет более надежной.
NT-сервером - задача не из легких. Именно поэтому NT нельзя считать идеальной платформой для сервера Web. Тем, кто имеет опыт работы с UNIX, стоит подумать о том, чтобы развернуть сервер на этой платформе (согласно некоторым исследованиям, серверы Web на базе UNIX превосходят NT по производительности почти в два раза). Тем же, кто имеет дело только с продуктами Microsoft, при настройке сервера Web следует соблюдать особую осторожность.