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

 

 

Рекомендации по защите сервера IIS

Одна из ключевых мер, не упомянутых и следующем списке, — это разработка и реализация Weh-приложений, при которой в первую очередь учитывается безопасность приложения. Все меры, перечисленные в представленном списке, не остановят хакера, который проник на сайт под видом "легитимного" анонимного или авторизованного пользователя. На уровне приложений достаточно одного неверного предположения в логике построения сайта, чтобы
ли ваша команда Web-разработчиков не очень сильна в вопросах безопасности, обязательно пригласите для проверки специалистов. Как можно раньше, (насколько это позволяет цикл разработки приложения) запланируйте проверку разработки и реализации третьей, незаин-
терссованной стороной. Помните: все вводимые данные могут быть введены с преступными намерениями, поэтому обязательно проверяйте их!
Следуйте нашим специальным рекомендациям, которые предложены в глазе 10, "Хакинг сервера IIS", (здесь были удалены некоторые пункты, которые дублируют приведенные выше рекомендации).
т Применяйте контроль доступа на уровне сети с помощью маршрутизаторов, брандмауэров и других устройств для создания защищенного периметра вокруг Web-серверов. Блокируйте все несущественные коммуникации в обоих направлениях (список часто используемых при взломе портов в Windows см. в главе 3, "Предварительный сбор данных и сканирование"). Самое худшее, что можно сделать, — предоставить доступ к легко взламываемой службе, например SMB (если нужно, перечитайте главы 4, "Инвентаризация", и 5, "Атака на службы Windows").
■ Обеспечьте блокирование исходящих соединений для Web-сервера, чтобы не дать хакеру возможности загрузить файлы из удаленной системы по протоколу TFTP или FTP либо подключить удаленную службу к командному интерпретатору системы. Простейшим путем для этого является создание механизма для блокирования исходящих SYN-пакетов перед Web-узлами (учтите, что при этом будет сильно ограничен исходящий трафик).
■ Блокируйте все несущественные входящие и исходящие соединения Web-сервера на уровне узла, чтобы обеспечить "многоуровневую защиту". Для управления доступом ксети на уровне узла в Windows можно воспользоваться TCP/IP Security, фильтрами IPSec или брандмауэром ICF (см. главу 16, "Возможности и средства защиты в системах Windows"). При использовании фильтров IPSec не забудьте установить правильное значение параметра реестра MoDef aultExempt.
■ Изучите и примените настройки, рассмотренные в списке Microsoft IIS 4 Security Checklist (за исключением вопросов, которые не относятся к версии 1 IS 5, но их мало), и в списке Secure Internet Information Services 5 Checklist (большинство из этих настроек установлены по умолчанию в Windows Server 2003 IIS 6).
Внимательно следите за выпусками "горячих исправлений" (Hotfix)! В главе 10, "Хакинг сервера 11S", мы рассказали, какой урон может быть нанесен с помощью атак на переполнение буфера наподобие атаки с использованием уязвимого места HTR. Хотя уже есть хорошие решения проблемы для HTR, обычно ошибки переполнения буфера исправляются только на уровне кода с помощью заплаты от производителя, поэтому до обновления сервер остается уязвимым.
■ Удалите неиспользуемые соответствия (по расширениям файлов) для сценариев и неиспользуемые библиотеки ISAPI, Неприятности могут возникнуть при использовании вредоносных запросов .htr, переполнении буфера запросами .printer и других атаках, вызванных ошибками в библиотеках ISAPI (хотя эта функция по умолчанию реализована a Windows Server 2003, но никогда не помешает двойная проверка).
■ Отключите ненужные службы. Для работы сервера IIS требуются такие службы: ITS Admin Service, Protected Storage и World Wide Web Publishing Service. Кроме того, в Windows 2000 и последующих версиях Windows невозможно остановить такие службы, используя графический интерфейс: Event Log, Plug and Play, Remote Procedure Call (RPC), Security Accounts Manager, Terminal Services (если служба была установлена, что для Web-сервера не рекомендуется) и служба Windows Management Instrumentation Driver Extensions. Все остальное можно отключить. Даже в одиночку сервер I1S сможет обслуживать запросы Web-страниц. В зависимости от архитектуры Web-приложений, может потребоваться включение других служб для обеспечения некоторых функций, например, для доступа к базам данных. Особенно обратите внимание на отключение служб Indexing Service, FTP Publishing Service, SMTP Service и Telnet.
■ He сохраняйте корневых каталогов Web-серверов на системном диске (которым обычно является диск С: \), чтобы в системный каталог нельзя было попасть, используя программы
атаки с использованием свойств файловой системы, наподобие атак Unicode или атаки двойного декодирования (с помощью строки 'точка-точка-косая черта" невозможно перейти на другой диск). Для копирования каталогов с сохранением списков контроля доступа (ACL) NTFS используйте утилиту Robocopy из пакета Reskit с параметром /SEC.
■ Всегда используйте файловую систему NTFS на дисках Web-сервера и явным образом настраивайте списки контроля доступа (ACL.). Для облегчения этой работы используйте утилиту cacls. Для всех исполняемых файлов каталога %sysCemroot% должны быть установлены права System: Full, Administrators: Full.
■ Удалите разрешение на запись и выполнение файлов во всех каталогах для групп Everyone, Users и других непривилегированных групп. Удалите разрешение на запись файлов во всех каталогах для пользователей IUSRh IWAM, а также с осторожностью предоставляйте права выполнения программ. Обратитесь к рекомендациям относительно списков контроля доступа для виртуальных каталогов в перечне Secure IIS 5 Checklist. -
■ Найдите И удалите вызовы функции RevertToSelf в существующих приложениях ISAPI, чтобы их нельзя было использовать для расширения привилегий учетных записей IUSR или IWAM. Проверьте, чтобы параметр безопасности сервера IIS Application Protection был установлен в значение Medium (Средняя — значение по умолчанию) или High (Высокая), тогда вызовы функции RevertToSelf будут возвращать управление только с правами учетной записи IWAM (эта информация касается версий до IIS6, а новая модель выполнения процессов 1IS 6 устраняет необходимость в большинстве этих действий).
■ Не храните секретную информацию в файлах Active Server или во включаемых файлах! . Используйте для конечных операций объекты СОМ или аутентификацию SQL, встроенную в Windows, чтобы в сценариях ASP пароли не нужно было использовать в строках доступа. Обязательно пользуйтесь тегами <%%> для выделения в сценариях информации, предназначенной для выполнения на сервере. Хотя такой способ защищает не от всех типов атак по раскрытию исходного кода, разработчики, по крайней мере, будут помнить о том, что их код может попасть в плохие руки.
■ Отключите службу Parent Paths, которая позволяет использовать символы ". . " в сценариях и вызовах приложений для функций наподобие MapPath. Откройте свойства нужного компьютера сети с помощью IIS Admin (файл iis .msc), измените основные свойства: WWW Scrvice^Home Directory1^ Application Settings о Configuration ^Application Options и снимите флажок для пункта Enable Parent Palhs.
■ Переимснуйтефайлысрасширениями . inc В файлы с расширениями . asp (не забудьте изменить ссылки в существующих сценариях ASP). Тогда файл . inc нельзя будет просто загрузить и посмотреть текст программы, даже если будет точно известно его полное имя.
■ Удалите с Web-узла все файлы примеров и ненужные функции (в списке Secure IIS 5 Checklist описано, что конкретно нужно удалять). Если существует виртуальный каталог TISADMPWD, удалите его (этот каталог будет в системе, если было выполнено обновление с I1S 4 до версии 1IS 5).
■ Остановите службу администрирования Web-узла и удалите виртуальные каталоги IlSAdminH USHelp вместе с их физическими двойниками. Тогда станет невозможным администрирование IIS на основе Web. Хотя сервер IIS ограничивает доступ к этим каталогам по умолчанию локальной системой, порт остается доступным для внешних интерфейсов (это TCP-порт с четырехзначным номером). Незачем давать хакерам дополнительные инструменты администрирования для использования против вас, если они могут получить эти инструменты, используя методы атаки вроде ошибки Unicode.
■ Серьезно обдумайте, следует ли осуществлять удаленное управление Web-узлом. Если да, то примите самые строгие меры обеспечения безопасности и зашиты механизма удаленного администрирования. Мы рекомендуем не делать Web-серверы доступными с помощью других служб {естественно, за исключением самой Web-службы), а вместо
этого создать систему удаленного администрирования, которая находится в едином сегменте сети с Web-сервером и связана с ним. Все удаленное администрирование должно быть ограничено только этой специально выделенной системой. В качестве утилит удаленного администрирования рекомендуются программы Terminal Server и Secure Shell, которые обеспечивают защиту и шифрование связи.
■ Установите программу URLScan и настройте ее для ограничения доступа HTTP-вызовов к ресурсам, которые часто используются при атаках (более подробная информация по этой теме содержится в главе 10, "Хакинг сервера IIS").
А Проверяйте код сценариев и текст HTML на наличие ссылок на определенные файлы И каталоги. Например, при поиске в Internet можно легко обнаружить ссылки на файлы TSWeb/defaulC.htm. Такие ссылки сразу привлекут к вашему узлу любителей взлома службы Terminal Service.
НА ЗАМЕТКУ
Благодарим Майкла Говарда (Michael Howard), Эрика Шульца (Eric Schultze) и Дэвида ЛеБпанка (David LeBlanc) из Microsoft за существенные и полезные советы по составлению приведенного списка.

Рекомендации по защите сервера SQL
Здесь собраны рекомендации по настройке защиты сервера SQLServer, взятые из главы И, "Хакинг сервера SQL", (некоторые пункты были удалены, так как они дублируют данные выше рекомендации).
Т Для ограничения возможностей соединения с SQL Server, используйте брандмауэр. Напрямую подключаться к SQI^-ccpacpaM должны только те машины, которые будут отправлять запросы к их службам. Например, если SQL Server является хранилищем данных для витрины Web-магазина, то никакие машины, кроме Web-сервера, не должны иметь возможность подключиться напрямую к SQL Server.
■ Следите за выходом пакетов обновления для программы SQL Server.
Щ Внимательно изучите настройки режима безопасности программы SQL Server. Несмотря на то, что использование аутентификации Windows для SQL Server кажется достаточно безопасным, это возможно не всегда и не во всех окружениях. Потратьте время на анализ такой возможности и, если позволяют обстоятельства, отключите использование пар "имя пользователя/пароль" для подключения к серверу SQL. Благог даря этому можно будет не использовать имя пользователя и пароль в строках соединения с сервером в приложениях, работающих по технологии "клиент-сервер".
■ Включите ведение журнала аутентификации в SQL Server. По умолчанию ведение журнала аутентификации в SQL Server отключено. Исправить ситуацию можно одной командой, И сделать это рекомендуется как можно раньте. Можно воспользоваться программой En­terprise Manager и заглянуть в свойства сервера на вкладке безопасности или вызвать команду для SQLServerc помощью программы Query Analyzer или osql. ехе (следующая команда разбита на несколько строк из-за ограниченной ширины страницы).
Master. .xp_lnstance_i:egwrite WHKEY_LOCAL_MACHINE-,WSOFTWARE Ь \Microsoft\t4SSQbServer\MSSQLServer', W'Audi tLevel ', REG_DtiORD, 3
■ По возможности применяйте шифрование данных. Хотя SQL Server не имеет встроенной поддержки для шифрования отдельных полей, можно легко реализовать собственное шифрование через интерфейс CryptoAPI от Microsoft и размещать в базе данных шифрованную информацию. Разработки других компаний по этому вопросу перечислены в главе 11, "Хакинг сервера SQL", они позволяют шифровать данные на сервере SQL Server посредством расширенных хранимых процедур (используйте эти программы на свой страхи риск).
Ш Используйте принцип наименьших привилегий. Зачем запускать приложение от имени учетной записи sa или предоставлять пользователю права владельца базы данных? Лучше потратьте свое время иа этапе установки приложения, чтобы создать низкопри­вилегированную учетную запись для ежедневного использования. Ненамного больше времени потребуется на предоставление конкретных прав и разрешений для всех объектов, но все затраты с лихвой окупятся, если кто-то захватит контроль над приложением и попытается с его помощью пробить стену защиты.
■ Не запускайте службу SQL в контексте привилегированной пользовательской учетной записи. Создайте пользовательскую учетную запись (не администратора) И введите во время установки сервера ее данные. Таким образом, пользователи, которые выполняют расши­ренные хранимые процедуры как системные администраторы, не смогут получить права системного администратора локальной системы или учетной записи LocalSystem.
■ Выполняйте тщательную проверку входных данных. Никогда не считайте надежной информацию, которая поступает от программы-клиента. Проверку данных на стороне клиента можно легко обойти, так что ваш код JavaScript не будет надежной защитой. Единственный способ убедиться в том, что переданные клиентом данные не создадут проблем в приложении, — тщательно их проверить. Проверка не должна быть слишком сложной. Если поле данных должно содержать число, то можно проверить, что введенное число находится в разрешенных пределах. Если поле ввода может содержать цифры и буквы, то проверьте, приемлема ли длина и содержимое ввода. Для проверки входящих данных на предмет содержания только разрешенных символов очень удобно использовать регулярные выражения, даже при сложном формате вводимых данных, адресов электронной почты, паролей и IP-адресов.
■ С осторожностью пользуйтесь хранимыми процедурами. Хранимые процедуры дают приложению преимущества в производительности и безопасности. Хранимые процедуры являются заранее скомпилированными SQL-командами, имеют строго типизированные параметры ввода и позволяют разработчику получить доступ на выполнение процедуры, не давая прямого доступа к тем объектам, которые используются в процедуре. Наиболее распространенная ошибка, которую допускают при реализации хранимых процедур, — построение строк команд для передачи строки на выполнение серверу SQL. Если вы реализуете хранимую процедуру, используйте выполнение команд через объекты ADO, чтобы каждый параметр передавался правильно и не было возможности ввести код в строку команды. Также помните, что нужно полностью удалить такие мощные хранимые процедуры, как xp_cmdshell. В главе 11, "Хакинг сервера SQL", перечислены расширенные хранимые процедуры, которые необходимо отключить.
Hjj] Удаление или ограничение доступа к хранимым расширенным процедурам может привести к выходу из строя сервера SQL Server.
■ Используйте для поиска уязвимых мест в программах утилиту SQL Profiler. Отличный способ поиска уязвимых мест для введения кода SQL — вводить строку программы атаки в поля ввода приложения При запущенной программе SQL Profiler И одновременно проводить мониторинг получаемых сервером данных. Чтобы облегчить задачу, можно использовать фильтр поля TextData программы SQL Profiler, который соответствует строке программы атаки. Примеры содержатся в главе II, "Хакинг сервера SQL". А Организуйте систему уведомлений о тревоге при выявлении потенциально опасных действий. Создав сигналы тревоги для ключевых событий программы SQL Server (таких, как неудачные подключения), можно оповещать администраторов о нарушениях в работе. Например, можно создать сигнал тревоги для события номер 18456 (неудачная попытка подключения К серверу), в котором есть строка • sa' (кавычки нужны, чтобы тревога не срабатывала каждый раз при подключении пользователя "Lisa"). Администратор получит возможность уведомления об обращении К серверу SQL Server в случаях, когда в тексте сообщения встречается слово sa, а это характерно для атак перебором.

 

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