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

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

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

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

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

kurs.docx

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

Однако проблемы возникают, когда  запрос файла Active Server передается не обработчику, а одному из многих других механизмов, которые поставляются совместно с сервером IIS. Это могут быть также и библиотеки ISAPI. Среди наиболее важных расширений ISAPI — программы ISM, Webhits, WebDAV, а в будущих версиях IIS — и протокол доступа к данным Simple Object Access Protocol (SOAP). В некоторых библиотеках этих расширений ISAPI есть ошибки, которые приводят к получению клиентом необработанного сервером исходного кода сценария ASP. Для запуска одной из этих библиотек достаточно просто запросить файл с состветствующим расширением (например, . htr) или подготовить специальный запрос HTTP.

Кроме ошибок в расширениях ISAPI, существуют и другие возможности доступа  к исходному коду. "Особый вклад" в усиление проблемы доступности  исходного кода "внесли" Web-службы, поскольку они обычно предназначены для предоставления значительного объема информации клиентам.

Простого исправления этой ошибки оказалось недостаточно. Компания Microsoft выпустила две отдельные заплаты для правильной обработки запросов файлов с расширением .htr, а затем была вынуждена выпустить и третью заплату, когда оказалось, что на серверах с внесенными исправлениями работает еще один вариант этой атаки. Этот вариант также основан на ошибке + .htr, только перед символами + .htr добавляется значение %3f.

 

 

 

 

1.6.5 DoS-атаки

 

 

Целью DoS (Denial of Service) атаки является блокировка каких-то ресурсов атакуемого, чаще всего это входная полоса пропускания, с целью ограничения доступа клиентов к серверу, узлу или сети жертвы. В качестве объекта атаки помимо полосы пропускания может быть вычислительная мощность процессора или информационные ресурсы операционной системы.

Как правило, атакер пытается организовать дело так, чтобы трафик на входе жертвы превосходил его (атакера) выходной трафик. Решить эту задачу он может разными методами. Наиболее распространенным является способ массового взлома машин и использования их для атаки (DDoS – Distributed Denial of Service Attacks). Другим приемом является умножение воздействия за счет других сетевых устройств, например, DNS-серверов (ресурсные запросы) или маршрутизаторов (использование широковещательных IP-адресов). Возможно совмещение нескольких методов DoS-атаки.

Атакеры могут применить различные способы для выявления и получения доступа к машинам-жертвам. Наиболее важными из них являются:

  • случайное сканирование. В этом подходе машина, зараженная вредоносным кодом (это может быть машина атакера или другая взломанная им ранее ЭВМ), сканирует определенную IP-область, выбирая адреса случайным образом, и пытается выявить уязвимую машину. Если такая обнаружена, делается попытка ее взлома и, в случае успеха, размещает там свой вредоносный код. Этот метод создает достаточно большой трафик, так как одни и те же адреса сканируются помногу раз. Преимуществом такого способа является достаточно быстрое заражение большого числа машин и создание впечатления, что сканирование происходит отовсюду. Однако высокий уровень трафика препятствует длительному продолжению атаки;
  • сканирование по списку. Задолго до начала сканирования атакер подготавливает достаточно обширный список потенциально уязвимых машин. Такой список может готовиться достаточно долгое время, чтобы не привлечь к этому внимания служб безопасности. Сканирование производится только для машин из этого списка. Когда обнаружена уязвимая машина, на нее устанавливается соответствующая программа, а список сканирования делится пополам. Вновь взломанной машине поручается сканирование машин одной из частей списка. Каждая из машин продолжает сканирование пока не сможет найти уязвимую ЭВМ. После этого список снова делится и процедура продолжается. Таким образом, число машин, участвующих во взломах, лавинообразно увеличивается;
  • топологическое сканирование. При топологическом сканировании используется информация, содержащаяся в машине жертвы, для поиска новых потенциальных жертв. При этом на диске взломанной машины ищутся URL, которые можно попробовать атаковать. Этот метод может оказаться даже несколько более эффективным, чем сканирование по списку;
  • сканирование локальной субсети. Этот вид сканирования работает за firewall. Взломанная машина ищет потенциальные жертвы в своей собственной локальной сети. Эта техника может использоваться в сочетании с другими способами атак, например, взломанная машина может начать сканирование локальной сети, а когда список таких машин будет исчерпан, переключиться на сканирование других сетевых объектов.
  • перестановочное сканирование. При этом типе сканирования все машины совместно используют общий псевдослучайный перестановочный список IP-адресов. Такой список может быть сформирован с помощью блочного 32-битного шифра с заранее заданным ключом. Если взломанная машина была инфицирована при сканировании по списку или из локальной сети, она начинает сканирование, начиная со своей позиции в списке перестановок. Если же она оказалась скомпрометирована в процессе перестановочного сканирования, она начинает сканирование с псевдослучайной позиции списка. В случае если она встретит уже инфицированную машину, она выбирает новую псевдослучайную позицию в списке перестановок и продолжает работу с этой точки. Распознавание инфицированных машин происходит за счет того, что их отклики отличаются от откликов не взломанных ЭВМ. Сканирование прекращается, если машина встретит заданное число инфицированных машин. После этого выбирается новый ключ перекодировок и начинается новая фаза сканирования. Факт такого сканирования труднее детектировать.

Можно выделить три механизма рассылки вредоносных кодов и построения сетей для атак:

  • централизованная рассылка. В этой схеме после выявления уязвимой системы, которая должна стать зомби, выдается команда в центр рассылки для копирования вредоносного кода (toolkit) во взломанную машину. После копирования этого кода осуществляется инсталляция вредоносной программы на машине жертвы. После инсталляции запускается новый цикл атак с уже захваченной машины. Для передачи кодов программ могут использоваться протоколы HTTP, FTP и RPC;
  • доставка от атакера (Back-chaining). В этой схеме все вредоносные коды доставляются в захваченную машину из ЭВМ атакера. В частности, средства атаки, установленные у атакера, включают в себя программы доставки вредоносных кодов жертве. Для этой цели на машине-жертве может использоваться протокол TFTP;
  • автономная рассылка. В этой схеме атакующая машина пересылает вредоносный код в машину-жертву в момент взлома.

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

Работа машин зомби может  быть автономной или синхронизоваться атакером (рисунок 27). Для того чтобы скрыть свой IP-адрес атакер фальсифицирует адрес отправителя. Помимо описанной выше разновидности DDoS-атаки существует разновидность DRDoS (Distributed Reflector DoS).

 

Рисунок 27 – DDoS-атака

DRDoS-атаки более вредоносны и здесь еще труднее выявить первоисточник атаки, так как в процесс вовлечено больше машин (рисунок 28).

 

Рисунок 28 – DRDoS-атака

 

CrashIIS является одной из разновидностей DoS-атак. Жертвой атаки CrashIIS обычно является Microsoft Windows IIS Web-сервер. Атакер посылает неверно сформированный GET-запрос, который выводит из строя Web-сервер.

В качестве защиты от DoS-атак Microsoft предлагает расширение Dynamic IP Restrictions Extension, которое интегрируется в IIS 7.0 и доступно как в 32-битном, так и в 64-битном варианте. Оно в первую очередь адресовано тем IT-профессионалам, которые хотят иметь под рукой настраиваемый модуль, способный помочь в блокировке и минимизации последствий DoS-атак, а также в предотвращении попыток взлома паролей через брутфорс. Достигаться это будет за счет временной блокировки IP-адресов, трафик с которых совпадает с имеющимися шаблонами вредоносного трафика. Анализ и блокировка могут осуществляться как в Web Server, так и в Web Site. Данное решение призвано заменить собой интегрированный в IIS 7 сервис IPv4 and Domain Restrictions.

В Microsoft выделяют шесть основных особенностей предлагаемого расширения:

  • блокировка IP на основе количества совпадающих запросов;
  • блокировка IP на основе числа запросов за определенный промежуток времени;
  • возможность изменения ответа сервера на запрос с заблокированного IP. Модуль может выдать ошибки 403 и 404, либо просто разорвать соединение без какого-либо уведомления;
  • регистрация динамически блокируемых адресов – все заблокированные IP записываются в лог-файл формата W3C;
  • отображение списка блокируемых в данный момент адресов (доступен через IIS Manager или через IIS RSCA API);
  • полная поддержка IPv6.

 

2 Microsoft SQL Server

 

 

2.1 Установка  Microsoft SQL Server 2008

 

 

В данном пункте рассмотрим установку  Microsoft SQL Server 2008 на операционную систему Windows Server 2008 R2.

Мастер установки предлагает ознакомиться с правилами поддержки установки, выбрать тип установки, ввести лицензионный ключ продукта и ознакомиться с условиями  лицензии. Опустим все эти пункты для краткости.

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

 

Рисунок 29 – Выбор компонентов

 

Далее предлагается осуществить настройку  экземпляра устанавливаемого сервера. Предлагается вариант по умолчанию, либо именованный экземпляр, который  можно настраивать. Для настройки доступны имя экземпляра, его идентификатор и корневой каталог. Примененные настройки можно видеть на рисунке 30.

 

Рисунок 30 – Настройка экземпляра

 

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

 

Рисунок 31 – Конфигурация учетных записей  служб сервера

 

На вкладке «Параметры сортировки»  нужно выбрать компонент Database Engine и службы Analysis Services (рисунок 32).

 

Рисунок 32 – Параметры сортировки конфигурации сервера

 

Далее настраивается компонент  Database Engine. Здесь настраивается режим проверки подлинности. Был выбран смешанный режим, так как он считается более безопасным и является более удобным (описание в пункте 2.2). Для смешанного режима нужно задать пароль и учетную запись администратора. Все настройки приведены на рисунке 33.

 

Рисунок 33 – настройка компонента Database Engine

 

Далее производится настройка служб  Analysis Services. Необходимо добавить пользователей, которые смогут настраивать эти службы (рисунок 34).

 

Рисунок 34 – Настройка служб Analysis Services

 

Далее происходит настройка работы служб Reporting Services (рисунок 35). Для целей данной курсовой работы необходимо выбрать «Установить конфигурацию по умолчанию для работы в собственном режиме».

 

Рисунок 35 – Настройка служб Reporting Services

Далее проверяется, удовлетворяет ли настройка всех пунктов, предъявляемым требованиям (рисунок 36).

 

Рисунок 36 – Правила установки

 

Далее происходит установка. В результате получается установленный Microsoft SQL Server 2008.

 

 

 

 

2.2 Аутентификация пользователя в MS SQL Server

 

 

При попытке подключения к серверу  БД сначала проверяется, какой метод аутентификации определен для данного пользователя.

При соединении с сервером MS SQL используются два типа аутентификации (рисунок 37):

1) аутентификация средствами СУБД (MS SQL). На MS SQL Server этот режим определяется как смешанный режим Mixed Mode (Windows NT Authentication and SQL Server Authentication). При использовании смешанного режима аутентификации средствами SQL Server проводится последовательная проверка имени пользователя (login) и его пароля (password); если эти параметры заданы корректно, то подключение завершается успешно, в противном случае пользователь также получает сообщение о невозможности подключиться к SQL Server. В случае смешанного режима часть пользователей может быть подключена к серверу с использованием стандартного режима, а часть с использованием интегрированного режима;

2) интегрированный режим аутентификации, называемый Windows Authentication Mode (Windows Authentication). Интегрированный режим предполагает, что для пользователя задается только одна учетная запись в операционной системе, как пользователя домена, а SQL Server идентифицирует пользователя по его данным в этой учетной записи. В этом случае пользователь задает только одно свое имя и один пароль. В данном варианте на сервере должны быть добавлены пользователи операционной системы.

Если определен Windows Authentication Mode, то далее проверяется, имеет ли данный пользователь домена доступ к ресурсу SQL Server, если он имеет доступ, то выполняется попытка подключения с использованием имени пользователя и пароля, определенных для пользователя домена; если данный пользователь имеет права подключения к SQL Server, то подключение выполняется успешно, в противном случае пользователь получает сообщение о том, что данному пользователю не разрешено подключение к SQL Server.

 

 
Рисунок 37 – Алгоритм проверки аутентификации пользователя в MS SQL Server

 

 

 

2.3 Олицетворение SQL Server

 

SQL Server и Microsoft Windows могут быть настроены таким образом, чтобы дать возможность экземпляру SQL Server выполнять соединение с другим экземпляром SQL Server в контексте пользователя Windows, прошедшего проверку подлинности. Это называется олицетворением или делегированием.

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

Делегирование учетных записей  может быть необходимым при обращении к поставщикам на различных компьютерах для выполнения распределенных запросов. Включение делегирования для распределенных запросов требует изменения конфигурации SQL Server и Active Directory.

SQL Server поддерживает явное олицетворение другого участника с помощью автономной инструкции EXECUTE AS, а также неявное олицетворение с помощью предложения EXECUTE AS в модулях. Олицетворение участников уровня сервера и имен входа выполняется с помощью автономной инструкции EXECUTE AS путем использования инструкции EXECUTE AS LOGIN. Олицетворение участников уровня базы данных и имен пользователей выполняется с помощью автономной инструкции EXECUTE AS путем использования инструкции EXECUTE AS USER.

Неявные олицетворения, выполняемые  через предложение EXECUTE AS в модулях, олицетворяют указанного пользователя или имя учетной записи на уровне базы данных или сервера. Олицетворение  зависит от уровня модуля: это либо модуль уровня базы данных (например, хранимая процедура или функция), либо модуль уровня сервера (например, триггер уровня сервера).

При олицетворении участника с  помощью инструкции EXECUTE AS LOGIN или  с помощью предложения EXECUTE AS внутри модуля области сервера областью олицетворения является весь сервер. Это означает, что после смены  контекста становится доступен любой  ресурс внутри сервера, к которому имеет доступ олицетворенное имя входа учетной записи.

Однако при олицетворении участника  с помощью инструкции EXECUTE AS USER или  с помощью предложения EXECUTE AS внутри модуля области базы данных область олицетворения по умолчанию ограничена базой данных. Это означает, что ссылки на объекты вне области базы данных будут возвращать ошибку. Причина такого поведения по умолчанию рассматривается в следующем сценарии.

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