Защита Apache от DDOS-атак

Пару недель назад позвонил один знакомый и пожаловался, что плохо работает сайт и канал поменяли на FTTX с xDSL и тариф выбрали со скоростью повыше, но помогло мало — пользователи жалуются на HTTP/1.1 403 Forbidden. Сервер настраивал им не я, благо что установлена Ubuntu 10.04 LTS — люблю продукты семейства long time support — очень уж они хорошо. Получив доступ начал ковырять систему — первое что бросилось в глаза — практически пустой фаейр — десятка 2 правил на вход-выход ЛВС и сайта в мир. Набрав в консоли команду

— несколько секунд наблюдал строчки вида:

Сразу стало понятно — что сайт завален большим количеством syn-пакетов, потому так плохо и работает.


Удаленно ковырять файер не гут, потому ограничился минимумом — загнал в конфиг несколько дополнительных команд, заодно ограничил количество syn-пакетов до 500 в секунду, при превышении порога в 1500 — новые пакеты блокируются:

— выполняем с консоли и добавляем в /etc/rc.local на случай перезагрузки:

— добавляем в наш firewall-скрипт:

Портянка netstat стала существенно короче, но в логи все равно периодически выскакивала HTTP/1.1 403 Forbidden. Пришлось поковырять настройки apache2 — оказалось что подгружен mod_evasive — модуль для защиты от DOS/DDOS-атак, в принципе модуль неплохой, но для больших сайтов не годиться, потому решил что лучше его выключить и положиться на файер и настройки ядра, которые я сделал выше. Несколько дней понаблюдал за логами — HTTP/1.1 403 Forbidden выскочила раза 2-3, на том мы и остановились.

Вкратце о том что же за команды такие добавлены в настройки системы:

— tcp_syncookies — SYN cookies не использует очередь SYN, вместо этого ядро отвечает на каждый SYN пакет, как обычно SYN|ACK, но при этом в пакет будет включено специально сгенерированное число на основе IP адресов и портов источника и получателя, а также времени посылки пакета. Соответственно атакующий никогда не получит эти пакеты, а поэтому и не ответит на них. При реальном запросе, будет отправлен третий пакет, который содержащий число, а сервер проверит был ли это ответ на SYN cookie и, если да, то разрешит соединение даже в том случае, если в очереди SYN нет соответствующей записи. (З.Ы.: доступен только когда ядро собрано с CONFIG_SYNCOOKIES — тогда по умолчанию должен быть равен — 1)

— tcp_max_syn_backlog — размер очереди half-open connection (полуоткрытых соединений), по-умолчанию колеблется в диапазоне 1024-2048, лучше задавать от 15000 и выше.

— tcp_synack_retries — определяет сколько разрешено попыток повторной передачи пакетов SYNACK для пассивных соединений TCP. Не должно превышать 255. По-умолчанию значение 5 соответствует приблизительно 180 секундам на выполнение попыток организации соединения. Урезаем примерно до 9 секунд — присваиваем — 1.

— tcp_fin_timeout — определяет время сохранения сокета в состоянии FIN-WAIT-2 после его закрытия локальной стороной. Запрашивающая сторона может не закрыть это соединение никогда, поэтому следует закрыть его по своей инициативе по истечении тайм-аута. По умолчанию тайм-аут составляет 60 секунд, в некоторых старых ядрах linux — было 180 секунд. Если у WEB-сервера очень высокая нагрузкая смело поджимайте до 20-30.

— tcp_keepalive_probes — определяет keepalive-запросов, после которого соединение считается разорванным, По-умолчанию передается 9 запросов. Так как каналы у всех достаточно быстрые — жмем до 5, в принципе проблем не замечено и при 4, но когда из Нижних дыр юзеры лезут по диал-ап — могут быть проблемы.

— tcp_keepalive_intvl — определяет интервал передачи проб. Вычисляется как [tcp_keepalive_probes]*[tcp_keepalive_intvl] — результат дает нам время, по истечении которого соединение будет разорвано при отсутствии откликов. По умолчанию установлен интервал 75 секунд, таким образом разрыв соединения произойдет примерно через 675 секунд (больше 10 минут!!!!).

— netdev_max_backlog — определяет максимальное количество пакетов в очередь на обработку если интерфейс получает пакеты быстрее, чем ядро может их обработать. Для современного железа можно задавать высокие показатели, по-умолчанию 1000.

— somaxconn — определяет максимальное число открытых сокетов, ждущих соединения.

Источник: http://sysadminblog.ru/linux/2012/03/20/zaschita-ot-apache-ot-ddos-atak.html#comment921

Автоматическая перезагрузка Linux при kernel panic, перегрузке CPU или системном сбое

If you are a system administrator, you have probably wondered at least once ohw to configure your Linux server to automatically reboot itself if it crashes, is going through a mass CPU overload, e.g. the server load average “hits the sky”.

I just learned from a nice article found here that there is a kernel variable which when enabled takes care to automatically restart a crashed server with the terrible Kernel Panic message we all know.

The variable I’m taking about is kernel.panic for instance kernel.panic = 20 would instruct your GNU Linux kernel to automatically reboot if it experiences a kernel panic system crash within a time limit of 20 seconds.

To start using the auto-reboot linux capabilities on a kernel panic occurance just set the variable to /etc/sysctl.conf

Now we will also have to enable the variable to start being use on the system, so execute:

There you go automatic system reboots on kernel panics is now on.
Now to further assure yourself the linux server you’re responsible of will automatically restart itself on a emergency situation like a system overload I suggest you check Watchdog

You might consider checking out this auto reboot tutorial which explains in simple words how watchdog is installed and configured.

On Debian installing and maintaining watchdog is really simple and comes to installing and enabling the watchdog system service, right afteryou made two changes in it’s configuration file/etc/watchdog.conf

To do so execute:

Well that should be it, you might also need to load some kernel module to monitor your watchdog.

On my system the kernel modules related to watchdog are located in:

/lib/modules/2.6.26-2-amd64/kernel/drivers/watchdog/
If not then you should certainly try the software watchdog linux kernel module called softdog , to do so issue:

debian-server:~# /sbin/modprobe softdog

It’s best if you load the module while the softdog daemon is disabled.
If you consider auto loadig the softdog software watchdog kernel driver you should exec:

That should be all your automatic system reboots should be now on! :)