Имеется веб-сервер на Апаче. Как правильно организовать защиту от DDOS атак?
Ответы
Ответ 1
Ниже написаны советы и рекомендации по вопросам безопасности в настройке веб-сервера. Некоторые советы общие, а некоторые специфичные для Apache.
Используйте актуальную версию ПО
Сообщество разработчиков Apache HTTP Server очень серьезно относится к вопросам безопасности,
однако невозможно выловить все ошибки до выпуска ПО.
Часть из них, разной степени критичности, будет обнаружена только после релиза.
Именно поэтому крайне важно следить за выходом новых версий используемого программного обеспечения.
В случае с Apache можно подписаться на рассылку Apache HTTP Server Announcements List,
откуда вы можете узнать о новых релизах и обновлениях безопасности.
Конечно, в большинстве случаев причина компрометации веб-сервера кроется отнюдь не в коде HTTP Server.
Скорее проблема будет обнаружена в коде плагина, CGI-скриптах или самой ОС.
Именно поэтому вы должны следить за обновлениями и исправлениями безопасности всего установленного ПО.
Атаки типа «отказ в обслуживании» (DoS)
Любой сервер сети может стать целью DoS-атаки, целью которой является предотвратить своевременный ответ сервера
на запрос клиента, путем истощения его ресурсов.
Невозможно полностью предотвратить атаки этого типа, но можно смягчить вызываемые ими последствия.
В большинстве случаев самым эффективным средством защиты от DoS-атак является корректно настроенный брандмауэр
или сама операционная система. Например, в большинстве брандмауэров можно ограничить количество одновременных соединений
с отдельного IP-адреса или целой подсети, таким образом предотвращая ряд простых атак.
Конечно, это не поможет против распределенных атак типа «отказ в обслуживании» (DDoS).
Существуют определенные параметры конфигурации Apache HTTP Server, которые позволяют снизить негативный эффект от таких атак:
Директива RequestReadTimeout
позволяет ограничить время, в течение которого клиент может отправить запрос.
Значение директивы TimeOut
должно быть снижено на сайтах, подвергающихся DoS-атакам. Может быть целесообразным установить ее значение
равным нескольким секундам.
Значение директивы TimeOut определяет количество времени, которое Apache будет ожидать три вещи:
Общее количество времени, которое набежит за GET запрос.
Количество времени между получением TCP пакетов на POST или PUT запросе.
Количество времени между ACK на передачах TCP пакетов в ответах.
Держите в уме, что установка низкого значения может вызвать проблемы при использовании тяжелых CGI-скриптов.
Значение директивы KeepAliveTimeout
тоже следует снизить на сайтах, подвергающихся DoS-атакам. Она ответственна за то, какое число секунд Apache будет
ждать следующий запрос перед закрытием соединения. Некоторые сайты полностью отключают поддержку keep-alive соединений
с помощью директивы KeepAlive, но это решение
вызывает другие проблемы с производительностью.
Следует внимательно проверить значение всех timeout директив, поставляемых с другими модулями.
Следует тщательно подобрать значения для директив
LimitRequestBody,
LimitRequestFields,
LimitRequestFieldSize,
LimitRequestLine
и LimitXMLRequestBody, чтобы снизить
затраты ресурсов на обработку данных с клиента.
Используйте директиву AcceptFilter
если она поддерживается вашей ОС, чтобы переложить часть трудозатрат на обработку запроса на плечи операционной системы.
Директива по умолчанию активна в Apache httpd, однако может потребоваться изменение конфигурации вашего ядра.
Настройте директиву MaxRequestWorkers,
чтобы позволить серверу обрабатывать максимальное количество одновременных подключений без исчерпания доступных ресурсов.
Читайте документацию по настройке производительности.
Использование модулей мультипроцессинга (multi-processing modules, MPM)
может позволить вам обрабатывать большее количество одновременных соединений, тем самым смягчая последствия DoS-атаки.
Далее цитата из статьи Apache vs Nginx: практический взгляд:
mpm_worker — этот модуль создает процессы, каждый из которых может управлять несколькими потоками.
Каждый поток может обрабатывать одно соединение. Потоки значительно более эффективны чем процессы, что означает,
что mpm_worker масштабируется значительно лучше чем mpm_prefork. Так как потоков больше, чем процессов,
это означает, что новое соединение может быть сразу обработано свободным потоком, а не ждать пока освободится процесс.
mpm_event — этот модуль похож на mpm_worker, но оптимизирован под работу с keep-alive соединениями.
Когда используется mpm_worker соединение будет удерживать поток вне зависимости от того, активное это соединение или keep-alive.
mpm_event выделяет отдельные потоки для keep-alive соединений и отдельные потоки для активных соединений.
Это позволяет модулю не погрязнуть в keep-alive соединениях, что необходимо для быстрой работы.
Конец цитаты.
Из-за особенностей библиотеки OpenSSL mpm_event
на текущий момент несовместим с mod_ssl и другими
входными фильтрами. В этом случае он возвращается к поведению
mpm_worker.
Есть множество сторонних модулей, доступных на http://modules.apache.org/
с помощью которых можно контролировать поведение клиента и смягчить последствия DoS-атаки.
Разрешения для корневого каталога сервера (ServerRoot)
По умолчанию Apache запускается из-под пользователя root и только потом переключается на пользователя, определенного директивой User.
Вы сами должны следить за тем, чтобы корневой каталог сервера был защищен от изменения непривелегированными (non-root) пользователями.
И файлы, и папки, и родительские каталоги всех уровней должны быть доступны на запись только пользователю root.
Допустим, вы решили назначить корневым каталогом сервера папку /usr/local/apache. В этом случае, вам следует создать
эту директорию с помощью следующих комманд:
mkdir /usr/local/apache
cd /usr/local/apache
mkdir bin conf logs
chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin conf logs
Предполагается, что /, /usr и /usr/local могут быть изменены только пользователем root. Во время установки
httpd удостоверьтесь, что все защищено должным образом:
cp httpd /usr/local/apache/bin
chown 0 /usr/local/apache/bin/httpd
chgrp 0 /usr/local/apache/bin/httpd
chmod 511 /usr/local/apache/bin/httpd
Создайте поддиректорию htdocs. Она должна быть доступна для изменения другими пользователями.
Пользователь root никогда не должен ни исполнять, ни создавать файлы в этой директории.
Если непривилегированным пользователям разрешается изменять файлы, которые запускаются или создаются из-под суперпользователя, считайте, что ваша система скомпрометирована.
Примеры плохого развития событий:
Бинарники доступны для изменения непривилегированными пользователями. Кто-то заменил httpd. При его следующем запуске выполнен вредоносный код.
Папка с логами доступна на запись для непривилегированных пользователей. Кто-то заменил файл с логами
символической ссылкой на один из системных файлов. Суперпользователь перезаписа
этот файл левыми данными.
Файлы с логами доступны на запись для непривилегированных пользователей. Кто-то подменил информацию в файле на фиктивную.
Включения на стороне сервера (SSI)
При использование SSI следует держать в уме несколько потенциальных проблем с безопасностью.
Во-первых, при использовании SSI увеличивается нагрузка на сервер. Все файлы, дл
которых включен SSI, сначала проверяются Apache на наличие в них SSI-директив. Несмотря на то, что нагрузка небольшая, на shared хостингах она может стать критичной.
Во-вторых, при использовании SSI файлов следует помнить о тех же рисках, что и пр
использовании CGI скриптов. С помощью элемента exec cmd в SSI файлах можно запустить любой CGI скрипт или программу с теми же привелегиями, которыми обладает пользователь и группа, от имени которых запущен Apache, согласно настройке в httpd.conf.
Есть несколько снизить риски без ущерба удобству от использования SSI файлов.
Чтобы изолировать возможные повреждения, можно включить suexec, как это описано в пункте Общая информация о CGI этого руководства.
Потенциально опасно включать поддержку SSI для файлов с расширениями .htm или .html
Особенно, если используется shared хостинг. Если необходимо включить поддержку SSI дл
HTML файлов, то для таких файлов следует использовать отдельное расширение, например, устоявшееся .shtml. Это позволяет свести к минимуму нагрузку на сервер и упрощает управление рисками.
Еще одним из возможных решений может стать запрет на выполнение программ и скрипто
из SSI файлов. Для этого необходимо заменить значение Includes на IncludesNOEXEC в директив
Options. Помните о том, что пользователи все еще смогут использовать вставку для запуска CGI скриптов из директории, указанной внутри директивы ScriptAlias.
Общая информация о CGI
Прежде всего, вы должны использовать CGI скрипты/программы только из доверенных источников
В противном случае, вы должны быть уверены в том, что сможете выявлять потенциальны
дыры в безопасности в CGI скриптах. CGI скрипты могут выполнять произвольные команды от имени и с правами пользователя веб-сервера, поэтому их следует расценивать как источник повышенной опасности и со всей внимательностью относится к проверке их содержимого.
Все CGI скрипты запускаются из-под одного и того же пользователя, поэтому есть рис
возникновения конфликтов между скриптами. Например, пользователь А ненавидит пользовател
Б, поэтому пишет скрипт, который удаляет всю базу скриптов пользователя Б. С помощью программы suEXEC можно запускать CGI скрипты из-под разных пользователей. Она включена в состав Apache, начиная с версии 1.2. Как вариант можно использовать CGIWrap. Этот способ тоже пользуется популярностью.
Запуск CGI скриптов из произвольной директории
Разрешать запуск CGI скриптов из произвольной директории пользователям можно только если:
Вы доверяете своим пользователям и уверены, что они случайно или намеренно не откроют вашу систему для атаки.
Вы считаете, что с безопасностью вашего сайта настолько все плохо, что еще одна потенциальная дыра в безопасности погоды не сделает.
На сервере нет пользователей и никто на него не заходит.
Запуск CGI скриптов из директории, указанной в ScriptAlias
Ограничение CGI скриптов на запуск только из определенной директории позволяет администратор
лучше контролировать, что там происходит. Это намного безопаснее запуска CGI скрипто
из произвольной директории, с той оговоркой, что администратор предоставит доступ на запись в эту директорию только доверенным пользователям и будет проверять содержимое всех новых CGI скриптов или программ на наличие потенциальных дыр в безопасности.
Большинство сайтов предпочитает этот вариант варианту с запуском CGI скриптов и
произвольной директории.
Другие источники динамического содержимого
Варианты включений, которые исполняются как часть серверного кода (mod_php, mod_perl
mod_tcl и mod_python) запускаются от имени серверного пользователя (см. директиву User)
поэтому эти скрипты имеют доступ ко всему, к чему имеет доступ упомянутый пользователь. Внутри некоторых из этих скриптовых движков есть определенные ограничения, но безопаснее предполагать, что никаких ограничений нет.
Безопасность динамического содержимого
Во время настройки динамического содержимого, например, mod_php, mod_perl или mod_python
следует обращаться к документации этих модулей, поскольку вопросы безопасности эти
модулей выходят за рамки настройки httpd. Например, в PHP есть Безопасный режим (Safe Mode), который обычно отключен по умолчанию. Для большей безопасности можно установить патч безопасности к PHP Suhosin. За дополнительной информацией о проектах обратитесь к их соответствующей документации.
На уровне Apache можно настроить mod_security в качестве файерволла. При должно
настройке он повысит безопасность динамического содержимого.
Защита системных настроек
Если вы хотите организовать монолитную защиту, вам следует запретить пользователя
использование .htaccess файлов, которые могут перезаписывать прописанные вами значения системных настроек. Вот один из способов это сделать.
Используйте следующие строки в httpd.conf
AllowOverride None
Так сервер будет игнорировать .htaccess внутри любых директорий, кроме специально разрешенных. Данная опция по умолчанию активна в Apache, начиная с версии 2.3.9.
Защита файлов сервера по умолчанию
При использовании Apache очень часто формируется ложное чувство безопасности, вызванно
непониманием того, как работает доступ к файлам по умолчанию. Пока вы не настроите доступ к файлам должным образом, сервер может выдать их содержимое в ответ на хитро сформированный url.
Рассмотрим следующий пример:
# cd /; ln -s / public_html
Accessing http://localhost/~root/
Этот позволит посетителям сайта свободно "гулять" по всей файловой системе. Чтобы исправить это поведение, нужно добавить следующий блок правил в httpd.conf:
Require all denied
Это по умолчанию запретит доступ к файловой системе сервера. Добавьте соответствующие блоки Directory для каждой из директории, куда следует разрешить доступ. Например:
Require all granted
Require all granted
Обратите особое внимание на взаимодействие директив Location и Directory.
Даже если вы запретили доступ к каталогу с помощью директивы , директива может отменить этот запрет.
Будьте осторожны при использовании директивы UserDir. Если вы зададите ей значени
равное ./, то получите тот же эффект, что и в самом первом примере. Настоятельно рекомендуется прописать следующую строчку в httpd.conf:
UserDir disabled root
Отслеживание логов
Чтобы быть в курсе того, что происходит на сервере, вы должны регулярно просматриват
свои логи (Log Files). Несмотря на то, что в логах хранится только информация об уже произошедших событиях, они позволят определить, какой тип атаки используется против сервера и проверить, защищены ли вы от этого типа атаки.
Парочка примеров:
grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
Этот пример покажет количество атак, пытающихся эксплуатировать уязвимость Apache Tomcat Source.JSP Malformed Request Information Disclosure Vulnerability.
grep "client denied" error_log | tail -n 10
Этот пример покажет список из последних десяти запрещенных соединений. Содержимое этих записей будет примерно таким:
[Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied by server configuration: /usr/local/apache/htdocs/.htpasswd
Как видите, в логах хранится только информация об уже произошедших событиях, та
что если бы клиент смог получить доступ к .htpasswd файлу, вы бы наблюдали в логах такие строчки:
foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
в своем Access Log. Если вы наблюдаете подобные строчки в своих логах, то, скорее всего, у вас закомментирован или полностью отсутствует следующий блок в httpd.conf:
Require all denied
Слияние блоков настроек
Слияние блоков настроек достаточно сложное и зависит от того, для каких директи
оно производится. Всегда проверяйте работу сервера после внесения изменений по созданию зависимостей между блоками настроек.
Для модулей, в которых не представлена логика слияния (например, mod_access_compat)
поведение последующих блоков настроек зависит от того, используются ли в них директивы из такого модуля. Настройки наследуются, пока не встречается измененная директива. После этого настройки заменяются полностью, а не сливаются вместе.
От себя
Это перевод статьи Security Tips - Apache HTTP Server Version 2.5.
В случае обнаружения ошибок или неточностей, пожалуйста, отредактируйте это сообщение.
Использована информация из следующих статей:
Параметры конфигурации Apache
Apache vs Nginx: практический взгляд
Ответ 2
Стоит почитать вот это: Security Tips.
А ещё есть модуль называется mod_evasive, его стоит покопать.
Ответ 3
Защиту от DDOS обычно делают многоступенчатой. Начинают средствами FIREWALL. Во FreeBSD для этого есть ipfw.
Фильтруются мусорные потоки и соединение дропается. При фильтрации валидных запросов необходимо использовать дополнительные механизмы.
Ответ 4
PHP + Cookies + Iptables
Cookie must be on');
}
if (empty($_COOKIE['ddos']))
{
$counter = @file($dir . $_SERVER["REMOTE_ADDR"]);
if(count($counter) > 5) ban();
setcookie('ddos', $cook, time() + 9800);
$f = @fopen($dir . $_SERVER["REMOTE_ADDR"], "a");
fwrite($f, "Antiddos by xeka.ru\r\n");
fclose($f);
header('Location: ' . $_SERVER['PHP_SELF']);
die();
}
if ($_COOKIE['ddos'] !== $cook)
{
ban();
die();
}
if ($_COOKIE['ddos'] == $cook)
{
system("/bin/sudo pfctl -t dl -T del " . $_SERVER["REMOTE_ADDR"]);
@unlink($dir . $_SERVER["REMOTE_ADDR"]);
}
}
?>
Ответ 5
Для начала уточните от каких DDOS-аттак собираетесь защищаться?
Ориентированных на забивание канала? или на отказ в обслуживании самого сервера?
Если первый вариант то поможет увеличение пропускной способности канала на врем
атаки(syn-пакетов будет много) и какая-нить сетевая железка которая будет фильтровать трафик.
Если второй и атака идет еще и правильными HTTP-запросами то поможет настройка файрволл
на сервере, тонкая настройка параметров ОС, разделение на фронт-энд (для статики, лучшее решение на сегодняшний день nginx) и бек-энд (для скриптов и прочего, это ваш Apache).
Но все же лучше воспользоваться специальными сервисами защиты от DDOS.
Ответ 6
Создайте файл .htaccess и в него поместите код:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?site.ru/.*$ [NC]
RewriteRule \.(gif|png|jpg|jpeg|js|css|zip|rar|ico|html|php)$ - [F]
Измените урл на свой, а в RewriteRule указывается, какие расширения файлов не отображать на других сайтах.
Ответ 7
К сожалению одним апачем здесь не обойтись :(
Если тебя заDDoSят, то сайт свой ты не откроешь, т.к. он просто будет не доступен.
Защищаться нужно железом на границе между интернетом и сетью, где установлен у тебя апач, а потом уже защищаться на софтовом уровне.
Комментариев нет:
Отправить комментарий