Разработка метода защиты сайтов от сканирования и хаотичных интенсивных запросов

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

Таблица 2.1 - Виды сканирования сайта и методы защиты от проведения сканирования

Вид исследования	Метод противодействия	Эффект от использования метода
1	2	3
Ручное сканирование содержимого сайта	1. Установка временной задержки между запросами, исходящими от одного пользователя 2. Использование на веб-сервере мощного модуля под названием mod_rewrite, дающего возможность создания «дружественных адресов» или ЧПУ 3. Отказ от использования robots.txt	1. Возможность существенно замедлить проведение сканирования сайта 2. Возможность скрыть структуру сайта, а также оставить в тайне от злоумышленника принцип формирования URL-адресов на ресурсе 3. Усложнит изучение структуры веб-ресурса, с одной стороны, правда, может привести к некоторым проблемам с индексацией содержимого сайта
Сканирование сайта при помощи программы-краулера	1. Установка временной задержки между запросами, исходящими от одного пользователя 2. Использование на веб-сервере мощного модуля под названием mod_rewrite, дающего возможность создания «дружественных адресов» или ЧПУ 3. Отказ от использования robots.txt	1. Возможность существенно замедлить проведение сканирования сайта 2. Возможность скрыть структуру сайта, а также оставить в тайне от злоумышленника принцип формирования URL-адресов на ресурсе 3. Усложнит изучение структуры веб-ресурса, с одной стороны, правда, может привести к некоторым проблемам с индексацией содержимого сайта
	5. Использование нестандартных способов перенаправления	5. Часть программ-краулеров не сможет обработать такие перенаправления, а значит не справится с поставленной задачей.
Исследование сайта при помощи поисковой системы	1. Для закрытых частей сайта необходимо использовать криптографический протокол SSL 2. Правильно настроить разрешенные для сканирования поисковым роботом страницы в файле robots.txt	1. Роботу поисковой системы не удастся обойти такого рода защиту, а значит «закрытая» страница не попадет в индексную базу поисковой системы 2. Робот поисковой системы будет игнорировать те каталоги, которые запрещены к индексированию в файле robots.txt
Исследование сайта при помощи утилит для автоматического поиска известных уязвимостей	1. Установка временной задержки между запросами, исходящими от одного пользователя 2. Регулярное обновление (замена или же удаление) используемых на сайте скриптов, в которых была	1. Возможность существенно замедлить проведение сканирования сайта 2. Регулярное обновление используемых скриптов, даст возможность устранить найденные в этих скриптах уязвимости
	обнаружена уязвимость 3. Проведение регулярного аудита сайта при помощи подобных программ	3. Эта мера даст возможность выявить уязвимости сайта «заблаговременно» и, соответственно, принять меры, связанные с их ликвидацией

Анализируя информацию, приведенную в таблице 2.1 можно отметить, что наиболее эффективным методом противодействия всем видам сканирования и исследования сайта является установка некоторой временной задержки между различными запросами, исходящими от одного пользователя (следует делать привязку к IP-адресу пользователя). Иначе говоря, в определенный промежуток времени, одному пользователю удастся отправить небольшое ограниченное количество запросов к страницам сайта. Это, с одной стороны, позволит существенно замедлить (или даже сделать невозможным) процесс сканирования и исследования сайта, а с другой стороны, данный метод не будет создавать серьезных неудобств для простых пользователей, не ставящих перед собой цель исследовать структуру сайта.

2.2 Методы защиты от хаотичных интенсивных запросов

Исходя из приведенного в предыдущей главе анализа различных видов хаотичных интенсивных запросов, проведем исследование существующих методов защиты от таких действий пользователей и от создания такого рода нагрузки на веб-сервер.

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

Рассмотрим методы защиты от различных видов хаотичных интенсивных запросов.

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

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

Во время полного перебора сложного пароля злоумышленнику может понадобиться очень много времени. Подобные временные затраты, вполне возможно, окажутся несопоставимыми с получаемым результатом.

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

Подбор пользовательского пароля будет существенно упрощен для злоумышленника, в случае, если ему станет известно имя учтенной записи пользователя [4, стр. 28-29].

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

Кроме того, как ранее упоминалось, множество программ подбора пользовательских паролей вполне может быть нейтрализовано путем использования нестандартных сообщений, в процессе произведения формоориентированной аутентификации. Такого рода прием легко сможет существенно затруднить использование программных инструментов разного рода для подбора пользовательских паролей [2, стр. 164].

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

Такими скриптами считаются:

- форумы;

- формы обратной связи;

- чаты;

- гостевые книги;

- формы, на которых пользователь может посмотреть, а также оставить собственные комментарии.

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

Существует довольно много методов защиты сайта от флуда. Ниже приведем некоторые из них:

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

2. Запрет на получение сообщений от одного и того же пользователя с определенным IP-адресом на протяжении определенного промежутка времени. В таком случае, у злоумышленника будет возможность «пофлудить» (отправить какое-либо сообщение) не чаще, нежели один раз в заранее заданный промежуток времени.

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

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

5. Запрет на создание одинаковых сообщений. Имеется ввиду то, что от одного и того же пользователя сервер не должен принимать два абсолютно одинаковых сообщения, вне зависимости от промежутка времени между ними. Дело в том, что создание абсолютно одинаковых сообщений можно считать бессмысленным.

Вышеприведенные методы, дадут возможность выстроить приемлемый уровень обороны сайта от флуда со стороны пользователей. Правда, будет ли этот уровень достаточным чтобы решать поставленные задачи. Это зависит, прежде всего, от того, как именно будут реализованные настройки. К примеру, в случае, если создать запрет на отправку более чем 5 сообщений от одного пользователя за 10 секунд, то флудер сможет направить не более 30 сообщений за одну минуту. Правда, администратору, стоит учесть тот факт, что злоумышленник может быть не один, или же он будет использовать анонимные прокси-сервера, для достижения поставленной цели.

В случае привязки к IP-адресу пользователя не следует забывать о том, что существуют обширные сети, пользователи которых в Интернете видны под одним и тем же IP-адресом (NAT с перегрузкой). В то время как реально в подобной сети может иметься тысяча или даже десять тысяч различных компьютеров. В подобном случае работа множества пользователей, такого рода сетей, на защищаемом веб-сайте окажется затрудненной. В то же время злоумышленник запросто обойдет такого рода препятствие, для этого он воспользуется помощью нескольких различных анонимных прокси-серверов.

Конечно же, всегда можно использовать пару, созданную IP-адресом и файлами Cookies. Правда, последние могут быть легко удалены с компьютера-клиента, а значит, их нельзя считать надежным решением. В целом, самым простым вариантом будет разрешение оставлять сообщения лишь зарегистрированным пользователям. В противном случае необходимо усложнить систему безопасности сайта, что в свою очередь усложнит использование ресурса рядовыми пользователями [4, стр. 62-66].

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

1. После того, как пользователь отправил сообщение адрес посетителя, также как и текущее время сохраняются в таблице базы данных. Сохранять IP-адрес отправителя нужно именно на сервере, по той причине, что все то, что хранится на компьютере клиента, вполне может быть уничтожено буквально за пять секунд, а порой и быстрее. Для того чтоб определить адрес пользователя отправившего сообщение или запрос, вполне можно использовать переменную окружения REMOTE_ADDR:

$_SERVER[“REMOTE_ADDR”]

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

3. После отправки сообщения скрипту необходимо проверить, остался ли внесенный в базу данных IP-адрес. Если остался, значит, обрабатывать сообщение не следует. Вместо этого нужно выдать пользователю сообщение об ошибке, с текстом вроде «Нельзя отправлять несколько сообщений за интервал меньше, чем две минуты».

Практика показывает, что злоумышленники не станут «флудить» на сайте, который оснащен такого рода защитой. Дело в том, что в такой ситуации флуд займет слишком много времени, в то время как эффект от него будет минимален, ведь много сообщений подряд одному пользователю просто напросто не удастся отправить [8, стр. 180-181].

Одной из разновидностей злонамеренного флуда считается атака на отказ в обслуживании.

Большинство атак на отказ в обслуживании может быть отражено довольно просто. Программист должен предусмотреть возможность того, чтоб скрипт сайта автоматически контролировал и ограничивал количество запросов, исходящих от одного IP-адреса в определенный промежуток времени. Правда, подобный подход сможет защитить лишь от начинающих хакеров. Дело в том, что опытный взломщик без проблем сможет подделать собственный IP-адрес, после чего засыпать сервер многочисленными запросами, в которых указывается поддельный адрес их отправителя.

Наиболее сложным считается установка защиты от перегрузки пользовательского канала. Вся проблема в том, что когда на веб-сервер идет множество пакетов, то нет возможности отфильтровать их без получения. Иначе говоря, защититься от перегрузки канала можно лишь расширением канала. При этом канал должен быть настолько широк, чтоб его, одному компьютеру, просто невозможно было заполнить [4, стр. 35].

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

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

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

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

К примеру, синтаксис

User-agent: *

Crawl-delay: 10

говорит о том, что поисковый робот (принадлежащий любой поисковой системе) должен загружать страницы сайта с интервалом в 10 секунд. В такой ситуации нагрузка на веб-сервер, создаваемая поисковым роботом, окажется минимальной [2, стр. 138].

Кроме того, администратор веб-ресурса может создать файл Sitemap.xml. Ссылку на карту сайта необходимо поместить в файл robots.txt при помощи такой строки:

Sitemap: <sitemap_location>

В созданном, согласно XML-стандарту, файле Sitemap.xml может быть указана дата последней модификации определенной страницы, а также частота обновления информации для каждой из страниц сайта. Пример синтаксиса файла Sitemap.xml:

<?xml version="1.0" encoding="UTF-8"?>

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

<url>

<loc>http://example.com/</loc>

<lastmod>2011-01-01</lastmod>

<changefreq>monthly</changefreq>

<priority>0.8</priority>

</url>

</urlset>

Использование файла Sitemap.xml помогает поисковому роботу лучше ориентироваться в структуре сайта, а также не загружать в базу данных страницы, содержимое которых не изменилось. А это, в свою очередь, ведет к уменьшению количества запросов, исходящих от поисковых систем и, соответственно снижению уровня нагрузки на сайт [9, стр. 89-90].

2.3 Программные средства защиты сайта

Множество программ выявления вторжений (Instrusion Detection System или IDS) способно обнаружить процесс исследования сайта. Такого рода программы прослушивают весь сетевой трафик и, в случае, обнаружения чрезмерной активности, сигнализируют о ней администратору веб-сервера. Отдельно следует отметить, что системы IDS далеко не всегда выявляют атаки. Дело в том, что в большинстве своем системы IDS по умолчанию конфигурируются на обнаружение шумного и бурного сканирования сайта. Если чувствительность IDS не повысить, то огромный пласт атак останется незамеченным.

Большинство систем IDS легко определяют атаки направленные на выявление наличия различных уязвимостей в системе. Кроме того, установка подобной системы поможет в борьбе с атаками на отказ в обслуживании. Ведь система будет блокировать повторяющиеся запросы, если их частота превысит допустимую норму [3, стр. 291-300].

Системы обнаружения вторжений могут распознавать сигнатуры различных враждебных действий непосредственно в процессе их выполнения. После обнаружения сигнатуры враждебных действий, система либо будет использовать соответствующие контрмеры, которые либо устранят точку уязвимости, либо заблокируют выполнение враждебных действий в этой точке. [7, стр. 41].

Системы выявления вторжений предназначаются для выявления атак, а также уведомления о них в режиме реального времени. Чаще всего системы IDS состоят из трех частей: модуля мониторинга, модуля логического вывода, а также модуля оповещения. На модуль мониторинга возложена задача сбора данных о текущей деятельности (чаще всего подобные данные характеризуют различный сетевой трафик). Те данные, которые были собраны модулей мониторинга, после передаются модулю занимающемуся логическим выводом. Данный модуль анализирует полученную информацию и определяет, порождена ли сетевая активность нормальными или же злонамеренными действиями. Отметим, что с каждой атакой связана некая, характерная именно для нее сигнатура, т.е. шаблон, по которому система данную атаку распознает и классифицирует. Для выявления хакерских атак в большинстве существующих систем IDS используются сигнатуры. После того, как атака обнаружена, модуль оповещения генерирует некий ответ, который основывается на внесенных заранее конфигурационных параметрах системы. реакция IDS на атаку может быть либо пассивная, либо активная. Если система IDS в качестве ответного действия направляет сообщение администратору или же вносит запись в свой системный журнал, то подобную реакцию называют пассивной. А вот активная реакция системы представляет собой передачу сообщению брандмауэру о необходимости заблокировать сетевой трафик, который инициирован взломщиком.

Одной из ключевых проблем, связанных с системами IDS, можно считать необходимость обеспечить высокую точность результатов данной системы. Дело в том, что системы выявления вторжений далеко не всегда хорошо справляются с возложенными на них функциями. Выделяют два вида ошибок систем IDS: несрабатывание системы в случае атаки (false negative) или же ложное срабатывание (fake positive). Ложное срабатывание системы происходит в случае, если IDS расценивает обычные действий пользователей как атаку, хотя это не так. А вот несрабатывание системы в случае атаки происходит тогда, когда реальная атака остается неклассифицированной.

Идеальной системы IDS, которая смогла бы обеспечить отсутствие ложных срабатываний, а также идентификацию абсолютно всех атак, просто не существует. Если хакеру необходимо обойти систему IDS он либо маскирует атаку, делая ее незаметной для системы, либо при помощи автоматизированных средств генерирует массу ложных срабатываний, тем самым, заставляя администратора сервера принять меры по снижению чувствительности системы [1, стр. 334-336].

На системы обнаружения вторжений (IDS) возложена функция предупреждения администратора о возможной атаке или же попытке проникновения злоумышленника в сеть. Системы защиты от вторжений (Intrusion Prevention Systems или IPS) вполне могут быть настроены для противодействия большинству атак, например, для осуществления блокировки связи с источником атаки.

В целом, рекомендации по использованию как IDS, так и IPS систем одинаковы:

- оба типа систем могут стать эффективными дополнительными средствами защиты веб-сервера как от атак снаружи, так и от злонамеренных действий изнутри;

- IDS и IPS могут представлять собой программы, компьютерные системы или же специализированные устройства. В любом процессе обнаружения и противодействия вторжениям, системам необходимо производить анализ журналов процессов и безопасности [10, стр. 128].

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

Стоимость коммерческих систем IDS и IPS довольно высока. Кроме того, такого рода системы сложны в настройке и последующем использовании. Это очень громоздкие системы, потребляющие массу системных ресурсов. К тому же, как уже упоминалось, ни одна такая система не дает гарантии абсолютной защищенности, а значит высокий уровень затрат на приобретение и настройку подобной системы может просто не окупиться. В дополнение ко всему сказанному, отметим, что не следует забывать о множестве хакерских атак, направленных на ложное срабатывание подобных систем.

2.4 Разработка методов защиты сайта от сканирования и хаотичных интенсивных запросов

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

Таблица 2.2 - Виды хаотичных интенсивных запросов и методы защиты сайта от них

Виды хаотичных интенсивных запросов	Метод противодействия	Эффект от использования метода
Случайные интенсивные запросы	1. Установка временной задержки между запросами, исходящими от одного пользователя	1. Данная мера существенно снизит нагрузку на веб-сервер, правда, вполне может создать определенные неудобства для пользователей ресурса
Подбор пользовательских паролей	1. Установка временной задержки между запросами, исходящими от одного пользователя 2. Установка временной блокировки учетной записи пользователя в случае обнаружения нескольких подряд неудачных попыток авторизации 3. Принуждение пользователей менять свои пароли время от времени, а также предоставление им рекомендаций касательно длины нового пароля и, конечно же, его сложности	1. Возможность существенно замедлить процесс подбора паролей (или даже сделать его невозможным, в случае, если пользователь время от времени меняет свой пароль) 2. Эта мера еще больше замедлит процесс подбора пароля, правда, может создать некоторое неудобство для пользователя 3. Вкупе с предыдущими мерами сделает процесс подбора паролей невозможным, правда, может создать некоторое неудобство для пользователей
Флуд со стороны пользователей	1. Установка некоторой временной задержки между отправкой сообщений, исходящих от одного и того же пользователя 2. Запрет на отправку абсолютно одинаковых сообщений от одного пользователя 3. Предоставление возмож-	1. Существенно снизит эффективность флуда, а также очень замедлит данный процесс, что в свою очередь заставит злоумышленника отказаться от поставленных целей 2. Данная мера существенно снизит эффективность флуда
	ности отправки сообщений на страницы ресурса лишь зарегистрированным пользователям	сообщениями, а также замедлит этот процесс, ведь злоумышленнику придется переписывать сообщения для их отправки. Правда, такая мера может создать неудобства для простых пользователей любящих отправлять короткие сообщения, к примеру, вида «+1», или же сообщения, в которых используются лишь смайлы 3. Существенно снизит количество флуда на страницах ресурса, правда, сообщений в целом будет меньше, по той причине, что не все пользователи желают проходить процесс регистрации
Атака на отказ в обслуживании	1. Установка временной задержки между запросами, исходящими от одного пользователя 2. IP-адреса пользователей, постоянно отправляющих запросы к сайту необходимо блокировать	1. Данная мера существенно снизит нагрузку на веб-сервер, а это, в свою очередь, сделает проводимую пользователем атаку на отказ в обслуживании как минимум несостоявшейся 2. Подобная мера снизит нагрузку на сервер, а также запретит доступ к страницам сайта пользователям, имеющим IP-адреса, которые внесены в «черный список». В то же время, злоумышленник сможет воспользоваться помощью проки-серве-ра, в то время как простые пользователи, имеющие такой же IP-адрес, лишатся возможности получения доступа к содержимому веб-сайта
Индексация сайта поисковыми роботами	1. Установка в файле robots.txt временной задержки загрузки любой страницы	1. Данная мера поможет существенно снизить уровень нагрузки, создаваемой поис-
	сайта 2. Внесение в файл Sitemap.xml информации о частоте обновления страницы, а также о дате ее последней модификации	ковыми роботами на веб-сервер 2. Эта мера поможет лучше управлять индексацией сайта и снизить количество запросов к страницам от поисковых роботов

Анализируя информацию, приведенную в таблице 2.2 можно отметить, что наиболее эффективным методом противодействия всем видам хаотичных интенсивных запросов является установка некоторой временной задержки между различными запросами, исходящими от одного пользователя (следует делать привязку к IP-адресу пользователя). Иначе говоря, в определенный промежуток времени, одному пользователю удастся отправить небольшое ограниченное количество запросов, на создание сообщений или просмотр содержимого, к страницам сайта. Это, с одной стороны, позволит существенно замедлить (или даже сделать невозможным) создание хаотичных интенсивных запросов, к страницам сайта, а с другой стороны, данный метод не будет создавать существенных неудобств для многочисленных простых пользователей. Если, конечно, эти пользователи не ставят перед собой цель отправить максимальное количество сообщений в небольшой промежуток времени или же создать максимально высокий уровень нагрузки на веб-сервер.

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

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

3 Реализация системы защиты в виде php-скрипта

3.1 Данные о реализуемом php-скрипте

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

- наличием формализованных требований, как к набору, так и к параметрам всех механизмов защиты, которые регламентируются большинством современных требований к обеспечению общей компьютерной безопасности (иначе говоря, требованиями, определяющими, что именно должно быть предусмотрено разработчиками);

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

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

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

Данный метод защиты сайта следует реализовать путем написания php-скрипта. Использование такого рода скрипта поможет защитить содержимое сайта от сканирования проводимого при помощи программ-краулеров и, одновременно, поможет существенно замедлить проведение сканирования сайта «вручную». Кроме того, использование подобного скрипта обеспечит прекрасную защищенность абсолютно всех страниц сайта от различных видов хаотичных интенсивных запросов, что в свою очередь даст возможность снизить нагрузку на оборудование веб-сервера.

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

- наличие возможности настройки времени блокировки IP-адреса пользователя;

- наличие возможности задать интервал времени, в который будет проверяться активность пользователя, иначе говоря, время, в течение которого будет вестись учет количества запросов, поступивших от одного определенного пользователя;

- наличие возможности установки количества запросов, которые один пользователь сможет отправить на страницы сайта в течение заданного временного интервала;

- наличие возможности создания списка «всегда разрешенных IP-адресов». IP-адреса, внесенные в данный список, никогда не будут заблокированы;

- наличие возможности создания списка «всегда запрещенных IP-адресов», т.е. скрипт всегда будет блокировать IP-адреса, которые внесены в данный список.

Преимуществами создания и использования подобного php-скрипта можно считать:

- существенное снижение количества запросов, отправляемых к серверу баз данных;

- существенную экономию входящего и исходящего трафика на веб-сервере;

- наличие удобной и гибкой настройки наиболее важных параметров работы скрипта;

- возможность существенного снижения нагрузки на веб-сервер со стороны пользователей;

- копирование всей информации, размещенной на сайте, будет сильно затруднено или даже невозможно в случае, если страниц на данном ресурсе достаточно много.

Логика работы разрабатываемой системы защиты сайта, создаваемой в виде php-скрипта, приведена на рисунке 3.1.



Рисунок 3.1 - Логика работы скрипта

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

В одну из таких директорий скрипт будет помещать на хранение IP-адреса активных, на данный момент пользователей, эта директория будет носить название active. А в другую директорию мы будем вносить файлы, название которых будет включать IP-адреса временно заблокированных пользователей (директория block).

Кроме IP-адреса, в процессе работы скрипта, также понадобиться информация об активности пользователя. Для этого в название файла, содержащего IP-адрес пользователя, мы также будем вносить точное системное время, когда он проявил «первую», в заданный промежуток времени, активность, т.е. первый раз за определенный (заранее установленный) промежуток времени отправил запрос к странице сайта.

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

Таким образом, в директориях кэширования (active и block) будут временно сохраняться файлы с такими названиями как: 127.0.0.1_1302615293, 195.80.91.151_1302615389, 95.30.17.60_1302615457, 77.39.54.104_ 1302615504 и тому подобные.

В имени файла, до нижнего слеша, будет содержаться IP-адрес активного пользователя, а после нижнего слеша в имя файла будет вноситься точное системное время, в которое он проявил активность (т.е. отправил запрос к страницам ресурса или же был заблокирован).

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

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

Информацию о текущих пользователях (в частности, об их IP-адресах) мы будем брать из суперглобального массива $_SERVER[]. Данный массив создается веб-сервером. В нем содержатся значения разнообразных переменных окружения.

Для работы с IP-адресами пользователей нам понадобиться использовать такие переменные окружения, содержащиеся в суперглобальном массиве $_SERVER[]:

- $_SERVER['HTTP_X_FORWARDED_FOR'];

- $_SERVER['HTTP_CLIENT_IP'];

- $_SERVER['HTTP_X_CLUSTER_CLIENT_IP'];

- $_SERVER['HTTP_PROXY_USER'];

- $_SERVER['REMOTE_ADDR'].

Переменная окружения $_SERVER['HTTP_X_FORWARDED_FOR'] дает нам возможность определить IP-адрес клиента, если он использует для работы прокси-сервер.

Переменная окружения $_SERVER['HTTP_CLIENT_IP'] дает возможность получить IP-адрес клиента, если он не использует прокси-сервер, для работы в Интернете.

Переменная окружения $_SERVER['HTTP_X_CLUSTER_CLIENT_IP'] дает возможность получить IP-адрес клиента, в случае, если на сайте не используется криптографический протокол SSL, обеспечивающий безопасное соединение между сервером и клиентом.

Переменная окружения $_SERVER['HTTP_PROXY_USER'] дает возможность определить IP-адрес клиента, который использует в работе прокси-сервер.

Переменная окружения $_SERVER['REMOTE_ADDR'] дает возможность получить IP-адрес удаленного пользователя. Во время тестирования на локальной машине данный IP-адрес будет равен 127.0.0.1. В то же время в сети данная переменная вернет либо IP-адрес клиента, либо IP-адрес последнего используемого пользователем прокси-сервера (при помощи которого данный клиент попал на веб-сервер).

Таким образом, используя одновременно множество различных переменных окружения из массива $_SERVER[] (все используемые переменные приведены выше), у нас будет возможность определить реальный IP-адрес пользователя, даже в том случае, если он попытается его «замаскировать» при помощи какого-либо прокси-сервера.

Для устойчивой работы скрипта на любой из страниц сайта, вне зависимости от ее уровня вложенности, будем использовать возможность приведения к абсолютному виду путей к директориям кэширования (active и block). Использование такого подхода даст нам возможность запускать скрипт с любой страницы сайта и при этом не опасаться того, что изначально указанные в скрипте относительные пути к директориям кэширования на какой-то из страниц окажутся неверными.

Как уже упоминалось, разрабатываемый скрипт должен иметь возможность настройки. В частности необходимо заранее предусмотреть возможность изменения части параметров скрипта (времени блокировки IP-адреса пользователя, интервала времени, за который будет учитываться количество запросов отправляемых к страницам ресурса, а также количества разрешенных запросов в данный интервал времени).

Данные параметры изначально в скрипте будут задаваться при помощи констант.

В частности, подобными константами в скрипте будут указаны такие параметры:

- время блокировки IP-адреса пользователя указываемое в секундах (const blockSeconds);

- интервал времени, в который будут учитываться запросы от одного пользователя к страницам сайта. Данный интервал также будет указываться в секундах (const intervalSeconds);

- количество запросов к страницам веб-сайта, которые сможет отправить один пользователь за заданный временной промежуток (const intervalTimes).

Отдельно в скрипте следует определить такие массива, содержащие строчные данные:

- массив значений тех IP-адресов, которые внесены в «список всегда разрешенных IP-адресов» (объявление массива public static $alwaysActive = array(`'));

- массив значений тех IP-адресов, которые внесены в «список всегда запрещенных IP-адресов» (объявление массива public static $alwaysBlock = array(`')).

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

- флаг возможности подключения всегда активных пользователей (const isAlwaysActive);

- флаг возможности подключения всегда заблокированных пользователей (const isAlwaysBlock).

Разработанный скрипт содержит один класс TBlockIp. Данный класс включает такие методы:

- checkIp(). Данный метод реализовывает возможность произведения проверки IP-адреса пользователя на его блокировку или же на активность. При этом пропускаются IP-адреса, внесенные в список «всегда разрешенных IP-адресов», а IP-адреса внесенные в список «всегда запрещенных IP-адресов» наоборот блокируются. В случае, если пользовательский IP-адрес не найден в массиве возможных IP-адресов - скрипт создаст идентификатор нового активного IP-адреса;

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

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

Конечно же, IP-адрес пользователя также может быть изменен, к примеру, при помощи прокси-сервера. Для того чтоб исключить подобную возможность для злоумышленника, в скрипте используются переменные окружения, которые в свою очередь помогают выявить реальный IP-адрес пользователя. Именно этот IP-адрес, в случае превышения пользователем установленного лимита запросов к страницам сайта в определенный промежуток времени, окажется заблокированным.

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

3.2 Листинг программы

<?php

/**

* Класс проверки и блокировки ip-адреса.

*/

class TBlockIp {

/**

* Время блокировки в секундах.

*/

const blockSeconds = 60;

/**

* Интервал времени запросов страниц.

*/

const intervalSeconds = 15;

/**

* Количество запросов страницы в интервал времени.

*/

const intervalTimes = 3;

/**

* Флаг подключения всегда активных пользователей.

*/

const isAlwaysActive = true;

/**

* Флаг подключения всегда заблокированных пользователей.

*/

const isAlwaysBlock = true;

/**

* Путь к директории кэширования активных пользователей.

*/

const pathActive = 'active';

/**

* Путь к директории кэширования заблокированных пользователей.

*/

const pathBlock = 'block';

/**

* Флаг абсолютных путей к директориям.

*/

const pathIsAbsolute = false;

/**

* Список всегда активных пользователей.

*/

public static $alwaysActive = array(

'172.16.1.1',

);

/**

* Список всегда заблокированных пользователей.

*/

public static $alwaysBlock = array(

'172.16.1.1',

);

/**

* Метод проверки ip-адреса на активность и блокировку.

*/

public static function checkIp() {

// Получение ip-адреса

$ip_address = self::_getIp();

// Пропускаем всегда активных пользователей

if (in_array($ip_address, self::$alwaysActive) && self::isAlwaysActive) {

return;

}

// Блокируем всегда заблокированных пользователей

if (in_array($ip_address, self::$alwaysBlock) && self::isAlwaysBlock) {

echo '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">';

echo '<html xmlns="http://www.w3.org/1999/xhtml">';

echo '<head>';

echo '<title>Вы заблокированы</title>';

echo '<meta http-equiv="content-type" content="text/html; charset=utf-8" />';

echo '</head>';

echo '<body>';

echo '<p style="background:#ccc;border:solid 1px #aaa;margin:30px auto;padding:20px;text-align:center;width:700px">';

echo 'Вы заблокированы администрацией ресурса.<br />';

echo '</p>';

echo '</body>';

echo '</html>';

exit;

}

// Установка путей к директориям

$path_active = self::pathActive;

$path_block = self::pathBlock;

// Приведение путей к директориям к абсолютному виду

if (!self::pathIsAbsolute) {

$path_active = str_replace('\\' , '/', dirname(__FILE__) . '/' . $path_active . '/');

$path_block = str_replace('\\' , '/', dirname(__FILE__) . '/' . $path_block . '/');

}

// Проверка возможности записи в директории

if (!is_writable($path_active)) {

die('Директория кэширования активных пользователей не создана или закрыта для записи.');

}

if (!is_writable($path_block)) {

die('Директория кэширования заблокированных пользователей не создана или закрыта для записи.');

}

// Проверка активных ip-адресов

$is_active = false;

if ($dir = opendir($path_active)) {

while (false !== ($filename = readdir($dir))) {

// Выбирается ip + время активации этого ip

if (preg_match('#^(\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})_(\d+)$#', $filename, $matches)) {

if ($matches[2] >= time() - self::intervalSeconds) {

if ($matches[1] == $ip_address) {

$times = intval(trim(file_get_contents($path_active . $filename)));

if ($times >= self::intervalTimes - 1) {

touch($path_block . $filename);

unlink($path_active . $filename);

} else {

file_put_contents($path_active . $filename, $times + 1);

}

$is_active = true;

}

} else {

unlink($path_active . $filename);

}

}

}

closedir($dir);

}

// Проверка заблокированных ip-адресов

$is_block = false;

if ($dir = opendir($path_block)) {

while (false !== ($filename = readdir($dir))) {

// Выбирается ip + время блокировки этого ip

if (preg_match('#^(\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})_(\d+)$#', $filename, $matches)) {

if ($matches[2] >= time() - self::blockSeconds) {

if ($matches[1] == $ip_address) {

$is_block = true;

$time_block = $matches[2] - (time() - self::blockSeconds) + 1;

}

} else {

unlink($path_block . $filename);

}

}

}

closedir($dir);

}

// ip-адрес заблокирован

if ($is_block) {

header('HTTP/1.0 502 Bad Gateway');

echo '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">';

echo '<html xmlns="http://www.w3.org/1999/xhtml">';

echo '<head>';

echo '<title>502 Bad Gateway</title>';

echo '<meta http-equiv="content-type" content="text/html; charset=utf-8" />';

echo '</head>';

echo '<body>';

echo '<h1 style="text-align:center">502 Bad Gateway</h1>';

echo '<p style="background:#ccc;border:solid 1px #aaa;margin:30px auto;padding:20px;text-align:center;width:700px">';

echo 'К сожалению, Вы временно заблокированы, из-за частого запроса страниц сайта.<br />';

echo 'Вам придется подождать. Через ' . $time_block . ' секунд(ы) Вы будете автоматически разблокированы.';

echo '</p>';

echo '</body>';

echo '</html>';

exit;

}

// Создание идентификатора активного ip-адреса

if (!$is_active) {

touch($path_active . $ip_address . '_' . time());

}

}

/**

* Метод получения текущего ip-адреса из переменных сервера.

*/

private static function _getIp() {

// ip-адрес по умолчанию

$ip_address = '127.0.0.1';

// Массив возможных ip-адресов

$addrs = array();

// Сбор данных возможных ip-адресов

if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {

// Проверяется массив ip-клиента установленных прозрачными прокси-серверами

foreach (array_reverse(explode(',', $_SERVER['HTTP_X_FORWARDED_FOR'])) as $value) {

$value = trim($value);

// Собирается ip-клиента

if (preg_match('#^\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3}$#', $value)) {

$addrs[] = $value;

}

}

}

// Собирается ip-клиента

if (isset($_SERVER['HTTP_CLIENT_IP'])) {

$addrs[] = $_SERVER['HTTP_CLIENT_IP'];

}

// Собирается ip-клиента

if (isset($_SERVER['HTTP_X_CLUSTER_CLIENT_IP'])) {

$addrs[] = $_SERVER['HTTP_X_CLUSTER_CLIENT_IP'];

}

// Собирается ip-клиента

if (isset($_SERVER['HTTP_PROXY_USER'])) {

$addrs[] = $_SERVER['HTTP_PROXY_USER'];

}

// Собирается ip-клиента

if (isset($_SERVER['REMOTE_ADDR'])) {

$addrs[] = $_SERVER['REMOTE_ADDR'];

}

// Фильтрация возможных ip-адресов, для выявление нужного

foreach ($addrs as $value) {

// Выбирается ip-клиента

if (preg_match('#^(\d{1,3}).(\d{1,3}).(\d{1,3}).(\d{1,3})$#', $value, $matches)) {

$value = $matches[1] . '.' . $matches[2] . '.' . $matches[3] . '.' . $matches[4];

if ('...' != $value) {

$ip_address = $value;

break;

}

}

}

// Возврат полученного ip-адреса

return $ip_address;

}

}

// Проверка текущего ip-адреса

TBlockIp::checkIp();

4 Тестирование php-скрипта, внедренного в сайт