Обеспечение безопасности web-серверов

Планирование развертывания web-сервера

При планировании развертывания web-сервера следует рассмотреть следующие пункты:

• Определить цели web-сервера ;

  • Какие категории информации будут храниться в web-сервере.
  • Какие категории информации будут обрабатываться или передаваться через web-сервер.
  • Каковы требования безопасности для данной информации.
  • Существует ли информация, которая получена с другого сервера или хранится на другом сервере (например, backend база данных, почтовый сервер, прокси-сервер).
  • Какие еще сервисы предоставляет web-сервер (должен ли web-сервер выполняться на выделенном хосте).
  • Каковы требования безопасности для этих дополнительных сервисов.

• Определить сетевые сервисы, которые будет предоставлять web-сервер, и используемые при этом протоколы:

  • НТТР, НТТРS, SOAP и т.п. – протоколы взаимодействия с клиентами.
  • ODBC, JDBC, LDAP, LDAPS, NFS и т.п. – протоколы взаимодействия с backend-системами.
• Определить все необходимое ПО, которое требуется для поддержки функционирования web-сервера ;
• Определить категории пользователей web-сервера и всех backend-систем;
• Определить способы аутентификации пользователей и web-сервера и способы защиты аутентификационных данных;
• Определить, как будет предоставляться соответствующий доступ к информационным ресурсам.

Безопасность лежащей в основе ОС

Первым шагом в обеспечении безопасности web-сервера является безопасность лежащей в его основе ОС. Большинство общедоступных web-серверов функционируют на ОС общего назначения. Многих проблем безопасности можно избежать, если ОС соответствующим образом сконфигурирована. Конфигурации по умолчанию аппаратуры и ПО обычно поставляются производителями с упором на возможности безопасного функционирования и возможности легкого расширения. Так как производители не знают потребности безопасности каждой организации, каждый web-администратор должен сконфигурировать новые серверы в соответствии с требованиями безопасности своей организации.

Данная технология в различных ОС может сильно отличаться. Также могут существовать некоторые автоматизированные инструментальные средства для настройки ОС с точки зрения безопасности.

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

• возможность ограничить деятельность административного уровня или уровня root только авторизованными пользователями;
• возможность управлять доступом к данным на сервере;
• возможность запретить сетевые сервисы, не являющиеся необходимыми, которые встроены в ПО ОС или сервера;
• возможность управления доступом к различным формам выполнимых программ, таких как CGI-скрипты и plug-ins, на стороне сервера;
• возможность записывать в лог соответствующую деятельность сервера для определения проникновения и попыток проникновения.

Безопасное инсталлирование и конфигурирование ОС

Применение Patch и Upgrade ОС

После того как ОС инсталлирована, следует применить все patches и upgrades для удаления известных уязвимостей. Все ОС, реализованные сегодня, имеют известные уязвимости, которые должны быть удалены перед использованием ОС в качестве хоста web-сервера. Для адекватного определения и корректирования этих уязвимостей web-администратор должен:

• идентифицировать уязвимости и применить patches;
• смягчить уязвимости, для которых пока patches еще не доступны, не протестированы или не установлены;
• проводить регулярное инсталлирование fixes (часто называемых patches, hotfixes, service packs или updates).

Удаление или запрещение ненужных сервисов и приложений

Идеально, чтобы web-сервер был выделенным и использовался только для этой цели. Многие ОС сконфигурированы по умолчанию для предоставления более широкого круга сервисов и приложений, чем требуется web-серверу ; следовательно, web-администратор должен сконфигурировать ОС, удалив или запретив сервисы, не являющиеся необходимыми. Приведем некоторые примеры сервисов, которые обычно должны быть запрещены:

• NetBIOS, если не требуется.
• NFS, если не требуется.
• FTP.
• Berkley "r" сервисы (например, rlogin, rsh, rcp).
• Тelnet.
• NIS.
• SMTP.
• Компиляторы.
• Инструментальные средства разработки ПО, за исключением того случая, когда HTML страницы создаются каким-либо интерпретатором, например, Perl. В этом случае должен быть оставлен только используемый интерпретатор.

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

Удаление или запрещение ненужных сервисов усиливает безопасность web-сервера по следующим причинам:

• ненужные сервисы не могут быть скомпрометированы и использованы для атаки на хост или для повреждения сервисов web-сервера. Каждый имеющийся в наличии сервис увеличивает риск компрометации хоста, потому что каждый сервис потенциально открывает вход для доступа атакующего;
• обычно различные сервисы могут администрировать разные люди. Следует изолировать сервисы таким образом, чтобы каждый хост имел одного администратора при минимально возможных конфликтах между администраторами. Наличие одного администратора, отвечающего за хост, приводит к лучшему распределению обязанностей;
• хост может быть лучше сконфигурирован для удовлетворения требований конкретного сервиса. Различные сервисы могут требовать наличия различной аппаратуры и конфигураций ПО, которые приводят к возникновению уязвимостей или ограничениям сервиса;
• при уменьшении числа сервисов уменьшается и количество логов и записей лога, благодаря чему обнаружение некорректного поведения становится легче.

При конфигурировании ОС следует применять принцип "запретить все, за исключением того, что явно разрешено" — это означает запретить и по возможности удалить все сервисы и приложения и затем выборочно разрешить те, которые требуются web-серверу. Также нужно по возможности установить минимальную конфигурацию ОС, которая требуется для приложения web-сервера. Если система инсталляции ОС предоставляет опцию "минимальная инсталляция", то нужно выбрать ее, потому что это минимизирует усилия, требуемые для удаления ненужных сервисов. Многие скрипты или программы типа uninstall не выполняют полного удаления всех компонент сервиса; следовательно, всегда лучше по возможности избегать инсталлирования ненужных сервисов.

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

Конфигурирование аутентификации пользователя в ОС

Авторизованных пользователей, которые могут конфигурировать систему и запускать различные сервисы, обычно очень мало. Однако пользователей, которые могут иметь доступ к публичному web-серверу, может быть как неограниченное количество, так и некоторое ограниченное подмножество Интернет-сообщества. Для обеспечения политики безопасности web-администратор должен сконфигурировать систему для аутентификации пользователей, которым разрешен вход, требуя предоставления доказательства своей идентификации. Даже если web-сервер разрешает неаутентифицированный доступ к большинству сервисов, администрирование и другие типы специализированного доступа должны быть ограничены определенными персонами или ролями.

Конфигурирование компьютера для аутентификации обычно включает конфигурирование ОС, firmware и приложений на сервере, таких как ПО, которое реализует сетевой сервис. В специальных случаях для сайтов с высоким риском или хранящих важные данные можно также применять аппаратуру для аутентификации, например, токены или устройства с одноразовыми паролями. Использование аутентификационных механизмов, в которых аутентификационная информация является переиспользуемой (например, пароли) и передается в явном виде по сети, не рекомендуется, потому что информация может быть перехвачена и задействована атакующим для подделки под аутентифицированного пользователя.

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

• Удалить или запретить неиспользуемые аккаунты и группы, созданные по умолчанию. Конфигурация ОС по умолчанию часто включает аккаунт guest (как с паролем, так и без), аккаунты уровня администратора или root, связанные с локальными и сетевыми сервисами. Имена и пароли этих аккаунтов хорошо известны. Удаление или запрещение ненужных аккаунтов предотвращает их использование для проникновения, включая аккаунты guest, на компьютерах, содержащих чувствительную информацию. Если существует требование оставить аккаунт или группу guest, следует ограничить их доступ и изменить пароль в соответствии с политикой для паролей в организации. Для аккаунтов по умолчанию, которые необходимо оставить, следует изменить имена (где возможно, особенно для аккаунтов уровня администратора или root) и пароли в соответствии с политикой для паролей. Следует помнить, что имена аккаунтов и пароли по умолчанию хорошо известны злоумышленникам.
• Запретить неинтерактивные аккаунты. Запретить аккаунты (и связанные с ними пароли), которые должны существовать, но не требуют интерактивного входа. Для Unix-систем запретить входной shell или предоставить входной shell с функциональностью NULL ( /bin/false ).
• Создать группы пользователей. Привязать пользователей к соответствующим группам и назначать права группам. Данный подход предпочтительнее, чем назначать права индивидуальным пользователям.
• Создать аккаунты пользователей. Определить, кто авторизован использовать каждый компьютер и его сервисы. Создать только необходимые аккаунты. Не допускать использования разделяемых аккаунтов.

• Проверить политику для паролей в организации. Установить пароли аккаунтов соответствующим образом. Данная политика должна рассматривать следующее:

  • длина – минимальная длина паролей;
  • сложность – требуемые символы. Требуемые пароли содержат буквы как верхнего, так и нижнего регистров и, по крайней мере, один неалфавитный символ;
  • срок использования – как долго можно не изменять пароль. Требовать от пользователей периодически изменять пароли. Пароль уровня администратора или root должен изменяться каждые 30–120 дней. Пароль пользователя также должен периодически изменяться. Этот период определяется длиной и сложностью пароля в сочетании с чувствительностью защищаемой им информации;
  • переиспользуемость – может ли пароль переиспользоваться. Некоторые пользователи пытаются обойти требование устаревания пароля, изменяя пароль на тот, который они уже использовали до этого. Нужно по возможности гарантировать, что пользователь не может изменить пароль простым добавлением "предполагаемых" символов к своему исходному паролю. Например, исходный пароль был "mysecret", а измененный – "mysecret1" или "1mysecret";
  • авторство – кому разрешено изменять или переустанавливать пароли и какого типа доказательство требуется перед началом любых изменений.

• Сконфигурировать компьютеры для запрещения входа после небольшого числа неудачных попыток. Следует помнить, что может быть относительно легко для неавторизованного пользователя получить доступ к компьютеру, используя автоматические программные средства, которые перебирают все пароли. Чтобы ОС не предоставляла такую возможность, ее следует сконфигурировать таким образом, когда она будет запрещать вход после трех неудачных попыток. Обычно аккаунт блокируется на определенное время (например, 30 минут) или до тех пор, пока пользователь с соответствующими полномочиями не активирует его.

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

  Неудачные попытки сетевого входа не должны запрещать вход с консоли пользователя и тем более администратора. Заметим также, что все неудачные попытки по сети или с консоли должны регистрироваться. Также, если удаленное администрирование не предусмотрено, следует запретить возможность входа по сети аккаунтам уровня администратора или root.
• Инсталлировать и сконфигурировать другие механизмы безопасности для усиления аутентификации. Если информация на web-сервере требует этого – рассмотреть использование других аутентификационных механизмов, таких как токены, сертификаты клиента и сервера или системы одноразовых паролей. Хотя они могут быть более дорогими и трудными в реализации, это, возможно, оправдается в некоторых случаях. Когда используются подобные механизмы аутентификации и устройства, политика организации должна быть пересмотрена и в ней отражен наилучший способ их применения.
• Создавать и распространять отчеты об использовании аккаунтов пользователей. Для того чтобы гарантировать, что все неиспользуемые аккаунты удаляются своевременно, важно установить в организации систему, которая создает отчеты о пользовательских аккаунтах, включающие информацию, необходимую для определения того, должен ли аккаунт оставаться активным. Эти отчеты должны распространяться соответствующим пользователям и управляющему персоналу для определения индивидуумов, которым более не требуется иметь аккаунт.

Как отмечалось ранее, нарушитель, используя сетевые сниферы, может легко перехватить переиспользуемые пароли, передаваемые по сети в явном виде. Вместо этого следует использовать менее уязвимые технологии аутентификации и шифрования, такие как SSH и SSL/TLS.

Управление ресурсами на уровне ОС

Многие ОС имеют возможность указать конкретные привилегии доступа для файлов, директорий, устройств и других коммуникационных ресурсов. Тщательно продумывая управление доступом, web-администратор может уменьшить преднамеренные и непреднамеренные бреши в безопасности. Например, запрет доступа по чтению к файлам и директориям помогает обеспечить конфиденциальность информации, тогда как запрет доступа по записи помогает обеспечить целостность информации. Разрешая выполнение большинства инструментальных средств системного уровня только системным администратором, можно предотвратить внесение пользователями изменений в конфигурацию, которые понижают безопасность системы. Такое ограничение может также уменьшить возможность атакующего использовать эти инструментальные средства для атаки как на данную систему, так и на другие системы в сети. Так как управление ресурсами ОС тесно связано с управлением ресурсами web-сервера, данная проблема будет рассмотрена далее в деталях.