Построение защищенных Web-приложений на основе IIS и MS SQL Server

Автор: Пользователь скрыл имя, 12 Июня 2012 в 15:50, курсовая работа

Описание работы

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

Работа содержит 1 файл

kurs.docx

— 5.59 Мб (Скачать)

А теперь можете включать свою фантазию. Не забудьте попробовать название компании и установленных приложений, если они вам известны.

  1. sqlpoke. Для честолюбивого хакера SQL, которому нужно узкоспециализированное средство, существует программа sqlpoke, также созданная хакером xaphan. Эта программа не пытается подобрать пароль учетной записи sa, вместо этого она ищет серверы SQL Server 2005 с пустыми паролями. Когда программа находит сервер SQL с пустым паролем учетной записи sa (который устанавливают невероятно часто), она выполняет предопределенный сценарий, который может содержать до 32 команд. Таким образом хакер может заранее подготовить набор средств для взлома для передачи по протоколу FTP, а после этой передачи сможет запустить "троянскую" программу одновременно с любым другим средством (как часть единого набора действий).

Заметим, что sqlpoke предоставляет пользователю возможность выбрать порт. Также имеется ограничение — возможно сканирование сетей только до класса В. Эта программа должна вселять страх в сердца тех, кто постоянно пользуется пустым паролем записи sa, чтобы ленивым разработчикам не нужно было его запрашивать. Можно представить, как следующей командой будут взломаны сотни серверов.

  1. Пользовательские ASP-страницы. Иногда злоумышленники предпочитают выполнять сканирование не напрямую со своих машин, а используют для грязной работы заранее взломанные узлы. Один из методов — создание для выполнения взлома собственной ASP-страницы на взломанном узле или бесплатном хостинге. Красота этого метода в том, что хакер может вторгаться в другие системы, сваливая всю вину на узел хостинга ASP.

Все, что нужно для подготовки этой атаки, — создать свою ASP-страницу, в которой используются объекты ActiveX Data Objects (ADO). Используя объекты ADO, хакер может указать тип используемого драйвера, имя пользователя, пароль и даже тип сетевой библиотеки для каждой цели. Если провайдер услуг Internet не проводит никакой фильтрации исходящих данных, то сервер, на котором выполняется такая ASP-страница, установит необходимое соединение и обеспечит обратную связь с хакером. При наличии скомпрометированной системы, злоумышленник может свободно пользоваться ею для запуска команд против узла-жертвы.

Предыдущий сценарий элементарно  можно изменить для проведения атак подбора пароля или даже атак по словарю, для чего нужно загрузить  на сервер файл словаря и использовать объект FileSystemObjеct, это значительно усилит ASP-инструментарий для SQL. Кроме сетевой библиотеки, можно указывать такие параметры, как TCP-порт, что дает возможность проверять и различные порты атакуемых компьютеров. Для использования других сетевых библиотек необходимо изменить параметр network в соответствии с именем сетевой библиотеки.

Для этого типа атаки не обязательно  использовать ASP. С сервера под  управлением Apache можно запустить сценарий РНР или Perl. Главная идея в том, что клиентские утилиты SQL имеют маленький размер и являются широко распространенными. Никогда не нужно считать, что у хакера есть только программа Query Analyzer или osql.ехе.

Потенциальный взломщик сервера SQL не имеет недостатка в средствах  и методах выполнения свой задачи. Прежде всего, нужно помнить, что SQL Server 2008 недостаточно хорошо ведет журналы событий, и даже после проведенной против сервера атаки перебором паролей из журналов не удастся получить достаточно полезной информации. Проверьте все описанные средства на своем сервере сами до того, как это сделают "плохие ребята".

 

 

 

 

2.5.4 Перехват  паролей для SQL сервера

 

 

Пусть была сделана попытка подключиться от имени sa, но в результате пароль оказался каким-то способом зашифрован. Однако взглянем на шаблон. Каждый второй байт последовательности равен ДБ (в шестнадцатеричной кодировке). Возникает подозрение, что здесь кроется что-то иное, нежели шифрование. И это действительно так. Ничего тут не происходит, кроме выполнения обычной операции XOR для скрытия пароля.

Начнем с разбора пароля по одному байту. Первый шестнадцатеричный знак (например А) в двоичной системе представлен  как 1010. Для получения пароля просто меняем первый и второй шестнадцатеричный  знаки каждого байта и выполняем  операцию XOR с числом 5А (правильно, это  будет число А5). После таких  вычислений будет получено шестнадцатеричное  выражение пароля. При известном  методе "шифрования" скрытие паролей  стало не более, чем легкой преградой, только раздражающей хакера. Помните, что пока выключено шифрование, этот способ работает для любой сетевой библиотеки, которая передает данные по сети. Любой, кто перехватит пароли при незашифрованной передаче, сможет элементарно преобразовать пароль в обычный текст и без проблем подключиться к серверу SQL. Если пароли и данные передаются по сети и могут быть перехвачены, то обязательно нужно использовать сетевые библиотеки с шифрованием. Если на сервер установить сертификат, то SQL Server 2008 будет автоматически шифровать пароли даже без использования сетевых библиотек с шифрованием.

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

Суровая действительность в мире систем безопасности такова, что уязвимые места приводят к эффекту падающих домино — сбои в совершенно разных системах могут свести на нет самую мощную защиту. В разработке приложений для SQL Server 2008, особенно приложений на базе Web, строки соединения необходимо хранить таким образом, чтобы приложение "знало", как подключиться к серверу. Приложение ни в коем случае не должно разглашать строку соединения неавторизованному пользователю.

Известны некоторые уязвимые места в IIS и других Web-серверах, которые позволяли просмотреть исходный код. Иногда причиной была одна из вышеперечисленных ошибок, иногда плохое администрирование. Пример — хранение строк соединения в файлах с расширениями .inc или .sre Неавторизированный пользователь легко может просмотреть сайт, найти файлы с именами наподобие connect.inc и узнать строку соединения, которой пользуется Web-сервер для подключения к серверу SQL. Если приложение использует собственное имя пользователя для подключения к SQL Server 2008, то также можно будет узнать имя пользователя и пароль. Естественным в данном случае решением будет использование расширений имен .asp (на серверах IIS) для всех включаемых файлов, чтобы они обрабатывались на стороне сервера.

Всегда нужно учитывать, что пароль может подсмотреть посторонний человек. Делайте все возможное для изоляции сервера SQL Server 2008, чтобы даже раскрытие исходного кода не привело к появлению бреши в системе безопасности. Также необходимо рассмотреть возможность использования аутентификации Windows в соединениях с SQL Server 2008, поскольку в этом случае не требуется передавать имя пользователя и пароль в строке соединения.

Программный код SQL Server 2008 не лишен многих из тех уязвимых мест, от которых страдают и другие серверы, например IIS. За годы существования кода SQL Server 2008 в нем были выявлены следующие ошибки:

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

Слишком часто эти уязвимые места  позволяли хакерам получить доступ, "подвесить" SQL Server или расширить привилегии скомпрометированного пользователя до уровня системного администратора. Как только пользователь становится системным администратором, он получает возможность выполнять любые команды сервера SQL и получает доступ к операционной системе через расширенную хранимую процедуру xp_cmdshell. На уровне операционной системы хакер имеет те же права, что и служебная учетная запись для самой программы SQL Server 2005. Слишком часто используется служебная учетная запись LocalSystem, учетная запись локального администратора или администратора домена.

Проблемы с сервером SQL Server 7.0 также касаются программ MSDE 1.0, а проблемы SQL Server 2000 — программ MSDE 2000. Исключение составляют уязвимые места, присущие специфичным для SQL Server функциям, которые не входят в "урезанные" EXPRESS-версии сервера SQL.

Переполнение буфера в SQL-службе Resolution Service

Возможность переполнения буфера в SQL-службе Resolution Service была выявлена Дэвидом Литчфилдом (David Litchfield) из Next Generation Security Software Ltd. Его открытие привело к появлению бюллетеня безопасности Microsoft MSO2-039 в июле 2002 года. Литч-филд обнаружил уязвимое место при отправке определенного количества байтов данных на компьютер, где запущен хотя бы один экземпляр SQL Server 2000. Из-за переполнения буфера происходит отказ в работе SQL-сервера. Дэвид отправил отчет о выявленной ошибке компании Microsoft, которая немедленно выпустила заплату для устранения уязвимого места.

Сразу после полуночи 25 января 2003 года в сети Internet началось распространение "червя" (известного как "червь" SQL Slammer), использующего это уязвимое место. Распространение червя привело к значительному снижению пропускной способности сетей Internet и вызвало отказ в работе многих крупных узлов и предоставляемых ими служб. Огромная скорость распространения явилась результатом небольшого размера '"червя" SQL Slammer использования протокола, не ориентированного на установление соединений (UDP). В результате от «червя» не смогло защитить ни основанное на сигнатурах антивирусное программное обеспечение, ни плохо настроенные брандмауэры. Распространение SQL Slammer позволило сделать ряд важных выводов:

        • серверы SQL установлены повсеместно, включая многие инсталляции MSDE;
        • многие из вариантов установки практически никак не администрируются;
    • многие из установленных серверов SQL непосредственно доступны через Internet.

Исходный код «червя» SQL Slammer был опубликован во многих периодических изданиях, например в журнале Wired, а код атаки доступен в Internet с момента выявления уязвимого места.

 

3 Совместная работа IIS 7 и MS SQL Server 2008

 

 

Репликация данных через Интернет обеспечивает доступ удаленных автономных пользователей к нужным для них данным с использованием соединения через Интернет. Репликация данных через Интернет:

  • виртуальная частная сеть;
  • параметр веб-синхронизации для репликации слиянием.

Репликации Microsoft SQL Server 2008 всех типов могут реплицировать данные через виртуальную частную сеть, но для репликации слиянием необходимо предусмотреть веб-синхронизацию.

Так как в данной курсовой работе необходимо рассмотреть совместную работу IIS 7 и Microsoft SQL Server 2008, то будет рассматриваться только второй способ репликации.

 

 

 

3.1 Настройка сервера IIS 7 для веб-синхронизации

 

 

В этом разделе описывается процесс  настройки вручную служб Microsoft Internet Information Services (IIS), которые будут использоваться при веб-синхронизации для репликации слиянием. Настройку необходимо выполнить вручную, поскольку мастер настройки веб-синхронизации не поддерживается в службах IIS 7.

Перед установкой необходимо убедиться, что приложение использует только платформу .NET Framework 2.0 или более позднюю версию и более ранние версии платформы .NET Framework на сервере IIS не установлены (рисунок 43). Более ранние версии платформы .NET Framework могут вызывать ошибки, например: «Недопустимый формат сообщения во время веб-синхронизации. Убедитесь в том, что компоненты репликации на веб-сервере настроены правильно».

 

Рисунок 43 – Проверка используемой версии .NET Framework

 

Чтобы использовать веб-синхронизацию, необходимо настроить службы IIS 7, выполнив следующие шаги:

  • установить и настроить средство прослушивания репликации Microsoft SQL Server на компьютере, на котором запущены службы IIS;
  • настроить протокол SSL (Secure Sockets Layer). Протокол SSL необходим для взаимодействия сервера IIS и всех подписчиков;
  • настройка проверки подлинности служб IIS;
  • настроить учетную запись и задать разрешения для средства прослушивания репликации SQL Server.

 

 

 

 

3.2 Установка и настройка средства прослушивания репликации SQL Server

 

 

В начале необходимо создать на компьютере, где запущены службы IIS, новый каталог для файла replisapi.dll. Этот каталог можно создать в любом расположении, но рекомендуется поместить его в каталоге <drive>:\inetpub. Например, создать каталог <drive>:\inetpub\SQLReplication\.

Далее нужно скопировать файл replisapi.dll из каталога <диск>:\Program Files\Microsoft SQL Server\100\ COM\ в каталог, созданный ранее (рисунок 44).

 

Рисунок 44 – Копирование файла  replisapi.dll

 

Далее нужно зарегистрировать файл replisapi.dll:

    • нажать кнопку Пуск, затем выбрать пункт Выполнить. В поле Открыть ввести cmd и нажать кнопку ОК;
    • в каталоге, созданном ранее, выполнить следующую команду:

Информация о работе Построение защищенных Web-приложений на основе IIS и MS SQL Server