На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Компромиссный путь

Вместо того, чтобы выставлять сервер Web на всеобщее обозре­ние под ненадежной защитой маршрутизатора, вы можете выбрать компромиссный вариант. Сервер Web можно расположить в экрани­рованной подсети, или «демилитаризованной зоне», т. е. фактически брандмауэр будет обслуживать три сети. В результате брандмауэр будет защищать и сервер Web, и внутреннюю сеть.
В такой конфигурации брандмауэр пропускает из Internet на сервер только трафик HTTP (и, возможно, HTTPS). Кроме того, он
контролирует доступ сервера 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 Pack 6, и последние «заплатки» для IIS. Без них любой сможет прочитать исходные тексты сценариев, добавив точку [.] или символы       в конец имен файлов.)
IIS предоставляет три метода подтверждения прав доступа к ин­формации Web: анонимный, базовая регистрация открытым текстом и процедура «запрос-ответ» Windows NT. Большинство серверов Internet поддерживает только анонимный доступ, который на серве­рах IIS, по умолчанию, соответствует пользовательскому бюджету IUSR-computername. При инсталляции IIS программа установки ав­томатически добавляет на сервер NT этот бюджет, который затем ис­пользуется службами IIS FTP, а также Gopher.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика