Russian LinkExchange Member

3. Вопросы Общего Порядка

В1: О чем беспокоиться?

Увы, много о чем. Существуют риски, затрагивающие серверы Web, локальные сети, в которых есть компьютеры с серверами Web и даже невинных пользователей браузеров.

Наиболее неприятны опасности для вебмастера. С того момента, когда вы установили у себя Web сервер, вы открыли в своей локальной сети окно, которым может пользоваться вся Internet. Большинство посетителей будут пользоваться только тем, что вы им предоставляете, однако некоторые попробуют получить доступ к вещам, которые вы не хотели бы предоставлять в публичное пользование. Другие, имеющие желание не только посмотреть, ноо и потрогать, будут пытаться открыть окно и проникнуть внутрь. Результаты могут быть различными, от просто раздражающих (например, вы обнаруживаете утром, что ваша домашняя страница заменена на идиотскую пародию), до разрушительных (например, похищение всей базы данных заказчиков вашей компании).

То, что ошибки в программах открывают лазейки в системе безопасности, рассматривается как истина людьми, занимающимися системной безопасностью. То, что большие и сложные программы содержат ошибки, является истиной для разработчиков программ. К сожалению, серверы Web являются большими и сложными программами, которые могут содержать лазейки в системе безопасности (что было подтверждено в ряде случаев). Более того, открытая архитектура серверов Web позволяет запускать любые скрипты CGI на сервере в ответ на запрос со стороны программы - клиента. Любой скрипт, установленный на вашем сервере, может содержать ошибку, и такая ошибка является потенциальной лазейкой.

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

Для конечного пользователя хождение по Web выглядит и безопасным, и анонимным. Это не так. Активные элементы, такие как элементы ActiveX или апплеты Java, делают возможным заражение системы пользователя компьютерным вирусом или внесение других опасных программ в систему. Сетевой администратор должен понимать, что активные элементы позволяют нежелательным программам обходить брандмауэры и проникать в локальную сеть. Даже без использования активных элементов, каждое действие пользователя оставляет запись в истории браузера, и заинтересованные лица могут получать очень подробные описания пользовательских вкусов и привычек.

Наконец, и конечные пользователи, и администраторы Web должны думать о конфиденциальности данных, передаваемых по сети. Протокол TCP/IP разрабатывался без учета проблем защиты и позволяет осуществлять "подслушивание" в сети. При передаче конфиденциальной информации между сервером и браузером она может быть перехвачена третьими лицами.

В2: О каких конкретных опасностях мы говорим?

В первом приближении, существует три перекрывающихся типа рисков:

1. Ошибки или неправильная настройка сервера позволяют посторонним:
   • Получать конфиденциальные документы, для них не предназначенные
   • Выполнять команды на компьютере, поддерживающем сервер, и модифицировать систему
   • Получать информацию о компьютере, на котором установлен Web сервер, могущую позволить проникнуть на компьютер.
   • Осуществлять "нападения с целью подавления", делая машину временно неработоспособной.
2. Риски на стороне клиента, включая:
   • Активные элементы, вызывающие сбои в браузере, повреждающие систему пользователя, нарушающие частную жизнь пользователя или просто надоедающие.
   • Использование не по назначению частной информации, осознанно или неосознанно предоставляемой пользователем.
3. Перехват данных, передаваемых по сети между сервером и браузером. Перехват возможен в любом месте на пути передачи информации, включая:
   • Сеть, в которой находится браузер
   • Сеть, в которой находится сервер (в том числе - intranet)
   • Провайдер доступа к Internet (ISP) пользователя
   • ISP сервера
   • Региональный провайдер любого из ISP.

Нужно понимать, что только "защищенные" ("secure") браузеры и серверы предусматривают защиту от перехвата данных в сети. При отсутствии защиты на одном из концов соединения возможен перехват конфиденциальной информации.

Защита от подслушивания и системная безопасность рассматриваются в разделах с 1 по 5. Безопасность на стороне клиента обсуждается в разделах 6 и 7. Раздел 8 содержит информацию по конкретным серверам.

В3: Являются ли какие-либо операционные системы более безопасными в качестве платформы для Web - серверов, чем другие?

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

Системы Unix, с их большим количеством встроенных серверов, сервисов, командных языков и интерпретаторов, особо уязвимы для нападений, просто потому, что в них имеется слишком много входов, которые могут быть использованы хакерами. Менее мощные системы, такие как Macintosh и машины с MS-Windows, взломать труднее. С другой стороны, на них труднее реализовать действительно сложные задачи, и приходится выбирать между удобством и безопасностью.

Конечно, всегда следует учитывать фактор опытности людей, администрирующих компьютер и программное обеспечение на сервере. Система Unix, управляемая опытным администратором, вероятно будет более безопасной, чем система MS Windows, установленная новичком.

В4: Являются ли какие-либо программы Web серверов более безопасными, чем другие?

Ответ снова - да, хотя безрассудно было бы давать четкие рекомендации в этом вопросе. В общем случае, чем больше возможностей предоставляет сервер, тем скорее в нем имеются лазейки. Простые серверы, позволяющие не многим более, чем давать доступ к статическим файлам, возможно, более безопасны, чем сложные серверы, предоставляющие такие возможности, как просмотр содержимого каталогов, выполнение скриптов CGI, обработка вставок на сервере (server-side includes) и программную обработку ошибок.

В версии 1.3 сервера NCSA для Unix содержится известная серьезная лазейка, найденная в марте 1995 года. Она позволяет постороннему пользователю выполнять любую команду на машине, на которой запущен сервер. Если у вас есть выполняемый файл httpd версии 1.3 с датой создания до марта 1995 года - не используйте его! Замените его на исправленный сервер 1.3 (доступен на http://hoohoo.ncsa.uiuc.edu/) или на версию 1.4 или более позднюю (доступна по тому же адресу). Версия Apache для замены NCSA также не содержит этой ошибки (http://www.hyperreal.com/apache/info.html)

Серверы различаются также возможностями ограничения доступа к отдельным документам или к частям дерева документов. Некоторые серверы не дают никакой возможности ограничения доступа, другие позволяют ограничивать доступ к директориям на основе IP адреса браузера или имени пользователя и пароля. Некоторые серверы, главным образом - коммерческие (например - Netsite Commerce Server, Open Market), позволяют также шифровать данные.

Сервер WN (автор - John Franks) заслуживает в этой связи особого упоминания, поскольку его организация сильно отличается от остальных Web серверов. Большинство серверов используют разрешительный подход к организации доступа, позволяя передачу любого документа из корня дерева документов, если это не запрещено явно, а WN использует запретительный подход. Сервер не передаст файл, если он не помещен специально в список разрешенных документов. Получение списков файлов и другие "неразборчивые" операции также запрещены. Получить информацию о защите сервера WN можно из его описания по адресу:

http://hopf.math.nwu.edu/docs/security.html

Таблица, сравнивающая особенности большого количества коммерческих и некоммерческих серверов помещена на узле WebCompare:

http://www.webcompare.com/

В5: Небезопасны ли скрипты CGI?

Скрипты CGI - основной источник лазеек в защите. Хотя протокол CGI (Common Gateway Interface) не является незащищенным по природе, скрипты CGI должны разрабатываться с той же тщательностью, что и собственно серверы. К сожалению, некоторые скрипты не выполняют этого требования в надежде, что администраторы будут устанавливать их у себя и не думать о вытекающих проблемах.

В6: Являются ли вставки на сервере небезопасными?

Вставки на сервере (server-side includes), обрабатывающие команды, включенные в текст документов HTML, тоже являются потенциальными лазейками. Набор имеющихся в них команд включает инструкции, заставляющие сервер выполнять произвольные системные команды и скрипты CGI. Если автор не знает о потенциальных проблемах, он может легко привнести нежелательные побочные эффекты. Увы, очень легко создать HTML файл, содержащий опасные вставки на сервере.

Некоторые серверы, в том числе - Apache и NCSA, позволяют администратору избирательно отключать те типы вставок, которые позволяют выполнять произвольные команды. См. подробности в В10.

В7: Какие предосторожности общего порядка следует соблюдать?

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

• Кто имеет право использования системы
• Когда он имеет право ее использования
• Что он имеет право делать (разные группы лиц могут иметь разные права доступа)
• Какова процедура получения доступа к системе
• Какова процедура отзыва права доступа (например, когда работник увольняется)
• Какие действия допустимы при работе
• Каковы методы прямого и удаленного доступа к системе
• Каковы процедуры контроля
• Какая реакция предусмотрена в случае наршения безопасности системы

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

1. Вы сами будете четко знать, что можно и чего нельзя делать. Если у Вас нет четких правил, Вам труднее понять, когда произошло нарушение.
2. Ваши пользователи будут понимать, что такое политика защиты информации. Правила, зафиксированные на бумаге, повышают уровень понимания проблемы и создают базу для обсуждения.
3. Правила безопасности задают уровень требований, для которых надо создавать техническую базу. Это позволяет бороться с синдромом "сперва купим, а там разберемся".
4. Правила могут помочь Вам в судебных разбирательствах в случае, если Вы будете отвечать за нарушение безопасности ситемы.

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

Вот некоторые предосторожности, которые следует соблюдать на серверах, установленных под Unix или NT:

1. Ограничивайте число пользователей в системе. Удаляйте ненужных пользователей.
2. Следите за тем, чтобы пользователи, имеющие возможность входа в систему, выбирали хорошие пароли. Программа Crack поможет вам обнаружить плохие пароли:

   ftp://ftp.cert.org/pub/tools/crack/

3. Отключите службы, которые вы не используете. Например, если вам не нужен FTP вход на машину, на которой установлен Web сервер, физически уничтожте ftp демона (т.е. сотрите файл ftpd). То же самое касается tftp, sendmail, gopher, клиентов NIS (network information service), NFS (networked file system), finger, systat и чего угодно еще, что может быть в системе. Проверте файл /etc/inetd.conf на предмет демонов, которые могут скрываться в системе, и закомментируйте тех, которых вы не используете.
4. Удалите оболочки и интерпретаторы, кроме тех, которые вам абсолютно необходимы. Например, если вы не используете скрипты на основе Perl, то удалите интерпретатор Perl.
5. Регулярно проверяйте файлы трассировки системы и Web на предмет обнаружения следов подозрительной активности. Программы Tripwire (Unix) и Internet Security Scanner (Unix & NT) полезны для проверки системных архивов и критичных файлов на попытки взлома:

   Tripwire

   ftp://coast.cs.purdue.edu/pub/COAST/Tripwire/

   Internet Security Scanner

   Мы еще вернемся к вопросу проверки файлов трассировки Web на предмет подозрительной активности.

6. Убедитесь, что у вас правильно установлены права доступа для системных файлов. Программа COPS может в этом помочь:

   ftp://ftp.cert.org/pub/tools/cops/

   Для Windows NT можете попробовать Administrator Assistant Toolkit от Midwestern Commerce:

   http://www.ntsecurity.com

Учитывайте возможность того, что _местный_ пользователь может по ошибке изменить конфигурационный файл сервера или документы WWW и открыть тем самым лазейку в защите. Вы должны установить права доступа к директориям сервера и документов так, чтобы разрешить изменения только тем пользователям, которым вы доверяете. Многие создают группу пользователей "www", к которой добавляют надежных авторов Web документов. Только этой группе пользователей разрешается запись в корневой директорий для документов. Чтобы еще усилить безопасность, права на запись в корневой директорий сервера, где хранятся жизненно важные файлы, предоставляются только официальному системному администратору Web сервера. Многие создают для этой цели пользователя "www".

В8: Где можно получить дополнительную информацию по безопасности в сетях?

Следует упомянуть следующие хорошие книги:

• Unix System Security: A Guide for Users and System Administrators, by David Curry
• Practical Unix Security, by Simson Garfinkel and Gene Spafford
• Windows NT Security Guide, by Stephan Sutton.

Источник текущей информации, включая обнаружение новых лазеек в безопасности - CERT Coordination Center advisories, рассылается через телеконференцию comp.security.announce и доступен в виде архива по адресу:

ftp://ftp.cert.org/pub/cert_advisories/

Список рассылки, посвященный вопросам безопасности в WWW, поддерживается IETF Web Transaction Security Working Group. Для подписки на него пошлите e-mail на адрес www-security-request@nsmx.rutgers.edu, в тексте письма напишите:

SUBSCRIBE www-security ваш_адрес_e-mail

Ряд списков вопросов и ответов по безопасности поддерживается компанией Internet Security Systems, Inc. Списки можно найти по адресу:

http://www.iss.net/sec_info/addsec.html

Главный список вопросов и ответов о WWW (WWW FAQ) также содержит вопросы и ответы относительно проблем безопасности Web, таких, как обработка файлов трассировки и источники программного обеспечения для серверов. Последние версии можно найти по адресу:

http://www.boutell.com/faq/

Перевод - Дмитрий Громов

Last modified: Mon Apr 13 17:54:04 EST 1997