Оглавление
19 июля 2007, 19:49
DDoS: Ваш сервер атакован миром
Наиболее успешной и грубой атакой в настоящее время остается
DDoS.
Он не требует от атакующего особых знаний. Достаточно иметь под контролем тысячу
зараженных компьютеров ничего не подозревающих мирных граждан нашей планеты для
того, чтобы “сбить с ног”
обычный сервер
подключенный к сети. Получить же доступ может любой подросток,
зарегистрировавшийся на одном из многочисленных хакерских форумов. Естественно,
что их находят и наказывают, а владельцы таких сетей, как правило, остаются
безнаказанными.
В более изощренных ситуациях, когда за дело берутся своего рода профессионалы,
создается не столь значительный по объему, но более “едкий” по содержанию
трафик, который способен, например, “сбить с толку”
DNS-сервис
или “съесть” все доступные подключения к ftp.
Более того, порой бывает так что DDos не причем, просто сервер настроен столь
неоптимизированно, что простой наплыв посетителей перегружает его настолько, что
владелец хостинга вынужден отказывать своему клиенту, мотивируя это тем, что он
сильно грузит сервер. В результате страдают обе стороны.
Или бывает так, что ничего не подозревающий клиент с широким каналом решил
выложить свои медиа-файлы и закачивает их в мультипоточном режиме, забирает себе
весь канал, а остальным пользователям сервера в этот момент
трафика нет, и сайты недоступны.
Для защиты сервера необходимо регулярно проводить аудит доступных ресурсов
сервера и устанавливать оптимальное ограничение для каждого сервиса. При этом
следует учитывать, что лимиты могут быть как встроенные в сервис, так и
системные. И самый лучший вариант - системный лимит “обгоняет” встроенный на
5-10%. Это необходимо на тот случай, если собственно сам сервис начнет врать и
не сможет вовремя остановить свой дочерний процесс.
Например, в веб-сервере apache есть встроенный ограничитель RlimitCPU, который
ограничивает время выполнения cgi/php скрипта. Однако замечено, что в случае
больших shtml страниц, включающих в себя результат работы скриптов, этот лимит
будет “растянут” на каждый скрипт, вызванный директивой include. Поэтому очень
полезно поставить системный лимит на apache, который бы четко ограничивал
потребление процессора. Например, если значение RlimitCPU 240, то, выполнив
перед запуском apache ulimit -t 250, время работы любого дочернего процесса
будет не более 250 секунд процессорного времени.
Естественно, что защита должна быть комплексной, и проверять на возможную
DDoS - атаку
следует весь сервер в целом, а не отдельные его части. Например, определив
максимальное число подключений к веб-серверу apache, не следует забывать о
загрузке, которую вызывают скрипты обращением к sql-серверу. Не ограничив mysql
системными или встроенными лимитами.
Адрес заметки: http://stakh.com/hosting/post_1184870992.html
Обязательные для заполнения поля выделены цыплячьим цветом.
1. Не более 50 знаков.
2. При указании будет опубликован. Спам-роботам недоступен.
3. Адреса, начинающиеся с http:// преобразуются в ссылки автоматически.
Для этого отделяйте их от текста ПРОБЕЛАМИ с обеих концов.
Теги запрещены.
|