Атаки на веб-сайты при помощи атак на отказ сетью зомбированных компьютеров прочно вошли в жизнь интернета в последние годы. Индустрия вывода из строя сайтов при помощи DDoS (Distributed Denial of Service - распределенная атака на отказ в обслуживании) активно развивается и имеет крупный денежный оборот. Если ранее зомбированные компьютеры злоумышленникам было выгоднее использовать для рассылки почтового спама, то теперь спрос на вывод сайтов из строя потребовал данные мощности для своего обеспечения. Наверняка многие вебмастеры, если и не сталкивались с этим явлениям на своем опыте, то наверняка слышали и читали. Мы рассмотрим лишь самый поверхностый способ противодействия таким атакам. Для более серьезной борьбы потребуется выделенный сервер и специальное оборудование, поэтому будем опираться на минимальные требования: скриптовый интерпретатор PHP и база данных MySQL. Этот "суповой набор" доступен на большинстве хостингов и является основной средой обитания сайтов самых разных габаритов. Безусловно, мы не сможем прикладными средствами отразить атаку, в которой задействованы сотни и тысячи атакующих машин. Каждая из них непрерывно генерирует запросы, ни чем не отличающиеся от запросов реальных пользователей. Однако наша основная задача - снизить нагрузку на сервер, минимизировав обработку таких запросов в движке. Подумаем: какие действия приходится выполнять серверу, получив один-единственный запрос от пользователя? считать файлы скриптов в память, запустив интерпретатор PHP; если файлы соединены включениями друг в друга (include, require), что чаще всего происходит, необходимо загрузить все эти скрипты; установить соединение с MySQL и выполнить все необходимые запросы, а их число обычно десятки и иногда сотни; сгенерированный код HTML вывести, предварительно собрав в буфер. На эти операции расходуются десятки мегабайт оперативной памяти, при этом, для каждого запроса зачастую выделяются дополнительные области памяти и ресурсы процессора. В случае наводнения сервера многочисленными запросами начинает катастрофически не хватать оперативной памяти, что приводит вначале к замедлению обработки запросов, а после и перехода системы в сомнамбулическое состояние. Этот переход чреват полным отказом сервера в обслуживании, в т.ч. и интерфейсов управления. Кроме того, будет установлено чрезмерное число соединений с сервером MySQL и он так же откажется обслуживать новые запросы. Вероятно, что и процессорного времени окажется недостаточно для работы с сервером и он потерпит крах. Но все же не все так печально. Мы можем здорово сократить затраты оперативной памяти и процессора, а также базы данных. Для этого рассмотрим два способа, которые можно использовать совместно: кэширование выводимых данных и введения механизма сессий для отсечения зазомбированных машин. Хорошей иллюстрацией может послужить пример реального случая большого числа единовременных соединений от биржи ссылок Sape.ru: [root@xxx ~]# netstat | grep 217.107.36.73 | wc -l 205 mysql CPU % usage: ~98. Как видим, число соединений от Sape.ru (217.107.36.73) превысило две сотни, из-за чего практически все процессорное время было съедено MySQL. Кэширование данных Для того, чтобы не совершать регулярных однообразных обращений к базе данных, а также ряда других действий, которые из запроса в запрос не меняют результата, будем сохранять результаты предыдущих вычислений. После первого запроса сохраним сгенерированную страницу и, если не настал срок ее обновления по объективным причинам, будем при очередном запросе возвращать сохраненную страницу. Чтение и запись файлов на порядки менее ресурсоемкая процедура, чем обработка модулей движка и обращение к базе данных. $hash="/var/www/html/cache/".md5($SERVER_NAME.$REQUEST_URI); if(file_exists($hash)&&(time()-filemtime($hash)<60*60*6)) { $code=join("",file($hash)); } else { // выполняем стандартные действия для отображения страницы, // сохраняя результат в переменной. Результат этот, кроме отображения, // запишем в файл ... $fd=fopen($hash,"w"); fputs($fd,$code); fclose($fd); } Кэшированные страницы будут храниться в директории /var/www/html/cache/, имена же будут закодированы при помощи алгоритма функции md5(). Это сделано для того, чтобы избежать использования запрещенных в файловой системе символов, а также иметь возможность достаточно точно сопоставлять имена. В переменной $hash содержится путь к кэшированной странице. Обратите внимание, что в данном случае алгоритм предусматривает шестичасовое хранение (60*60*6 секунд) кэшированной страницы. При каждом обращении к странице проверяется наличие ее в папке кэшированных страниц, а также дата ее изменения при помощи функции filemtime(). Однако это не лучшая идея для часто пополняемых файлов. Для эффективной работы с системой кэширования Вам потребуется выяснить, какие модули сайта требуют особой частоты обновления страницы. К примеру, модифицируйте систему администрированая сайта таким образом, чтобы при записи обновленной страницы в базу данных удалялись соответствующие страницы в кэше. В противном случае посетитель будет еще долгое время видеть старое содержимое сайта. Вариантом решения проблемы может послужить частичное кэширование отдельными модулями сайта. Например, информеры погоды и курса валют имеют период обновления один раз в сутки, поэтому могут самостоятельно воспользоваться написанной Вами функцией кэширования: require_once("./sklad.php"); $kras_file=iz_kesha("http://www.rp5.ru/town.php?id=4475", 60*60*24*1); Здесь функция iz_kesha() имеет 2 параметра: URL кэшируемой страницы и периодичность ее обновления. Механизм сессий Однако при шквальном обращении по протоколу HTTP даже кэширование может сказаться пагубно на живучести сервера. Необходимо как можно более достоверно отсечь ложного посетителя (а на деле машины-бота) от настоящего, чтобы не допустить лишней обработки данных. Для этого воспользуемся тем, что зомбированные компьютеры обычно не имеют столь продвинутой системы работы с сайтом, как сохранение результатов предыдущего запроса. Мы можем воспользоваться этим обстоятельством, заставляя машину посетителя сохранить некий код, чтобы после по этому коду проверять легальность запроса. Алгоритм следующий: проверить, имеет ли запрашиваемая машина в своем запросе код, а также наличие в базе IP этой машины; если IP в базе нет, сгенерировать код случайным образом и попросить запомнить этот код. Сохранить в базе IP и его код; если кода нет или код не совпадает с кодом из базы, соответствующим IP, занести в список блокировки данный IP. Для реализации этого алгоритма мы можем воспользоваться таким удивительно подходящим средством, как Cookie. При первом запросе потребуем сохранить некое значение заголовком HTTP: Set-Cookie: confirmcode=afe892fabcd При этом снесем в базу IP этого нового посетителя. Если же при очередном обращении мы не получим данного кода, то можно считать этого пользователя спам-ботом и заблокировать ему доступ к сайту. Обратите внимание, что при таком алгоритме нам нежелательно использовать столь требовательные к ресурсам средства, как MySQL. Поэтому лучшим вариантом хранения наших данных будет использование файловой системы, как мы это делали в варианте с кэшированием.
Очень познавательно для таких как я,новичков,спасибо почитал! Ну а так мне всё же кажется лучше всего хорошие серваки А кстати источник ?
Гдето в разделе это уже есть... пс.хоть бы оформил норм,выделил в теги кода то что нужно+ копирайт бы непомешал.. тьфу ты... в бане уже..... Ну если выдадут мне права модера на раздел,обязательно сделаю....
сейчас поправим),уежал бан был причина того что на нас с вернон коди,матерились и попали мы в бан а не они)
