В коллекции планигов Munin, безусловно, есть огромное количество плагинов для получения статистики с самых разных сервисов и системных параметров. В дистрибутиве CentOS они располагаются в директории /usr/share/munin/plugins/. Однако есть потрясающая возможность создавать свои плагины, которые будут подключены к общей системе статистики, и анализиоровать практически всё, что угодно.

В именовании файлов плагинов Munin принято однообразные плагины (относящиеся к одной подсистеме или сервису) начинать с одного префикса. Например, mysql_bytes, mysql_innodb, mysql_queries и т.д. Впрочем, название файла не обязано соответствовать категоризации плагина. Категория и всевозможные параметры задаются внутри скрипта.

Плагины Munin представляют из себя обычные скрипты, чаще всего написанные на shell, которые принимают параметры config и autoconf, а также возвращают текущие значения для наблюдаемых параметров. При вызове с параметром config должны быть выданы настройки модуля (об этом ниже).
Создание плагина для мониторинга сетевых соединений
Возьмём в качестве основы модуль netstat. Здесь приводить его содержание не буду; содержание скрипта может отличаться от версии к версии. Скопируем его в свой файл, например, в файл my_connections:

[root@saytostroy.ru]# cd /usr/share/munin/plugins/
[root@saytostroy.ru]# cp netstat my_connections

И откроем его на редактирование. Для начала нам потребуется заменить текстовое описание head1 NAME, head1 CONFIGURATION, head1 AUTHOR и т.д., хотя в нашем случае их содержание не играет роли.

Перейдём непосредственно к коду. Ветка, отрабатывающая autoconf нас так же не интересует — там проверяется наличие исполнительной программы файрвола iptables. Поскольку мы заимствуем аналогичный модуль, то менять там ничего не требуется. Перейдём сразу к config, где и содержатся основные параметры. Все они выводятся через оператор echo. Рассмотрим их подробнее:

  • graph_title определяет отображаемое в статистике название плагина;
  • graph_vlabel — название раздела плагина. Будет отображаться в виде списка в просмотре готовой статистики;
  • graph_category — принадлежность к категории всей системы Munin. В нашем случае здесь сохраняется network. Нужен для правильного распределение по категориям Munin. Таким образом все сетевые данные оказываются в одном месте:
    munin_cat
  • graph_period — период измерений, отображаемый на графиках. Оставим по умолчанию second, чтобы значения приводились из масштаба «число значений в секунду». Важное замечание: несмотря на то, что скрипт будет запускаться значительно реже (5 раз в минуту по умолчанию через планировщик заданий), значения будут приводиться исходя из секундного интервала;
  • graph_info — описание, которое отображается в системе статистики в раскрытой вкладке выбранного плагина;
  • graph_scale — производить ли масштабирование графика. Наш выбор: no.

Итак, в нашем случае будет следующая «шапка» конфигурационной части плагина:

echo 'graph_title MyConnections'
echo 'graph_vlabel TCP connections'
echo 'graph_category network'
echo 'graph_period second'
echo 'graph_info This graph shows the number of TCP connections.'
echo 'graph_scale no'

Далее идёт непосредственно наш измеряемый параметр. Для примера я выбрал отображение числа SYN-пакетов протокола TCP. Эта статистика может быть полезна для обнаружение SYN-flood-атак. Мы наглядно увидим лавинообразное увеличение числа таких пакетов и получим уведомление, если правильно настроим Munin. Наш параметр будет называться syn и получит следующие значения:

echo 'syn.label SYN'
echo 'syn.type ABSOLUTE'
echo 'syn.max 1000000'
echo 'syn.min 0'
echo 'syn.info The number of SYN TCP packets.'
print_warning syn
print_critical syn

Здесь мы казали метку нашей кривой на графике (label), тип значений (ABSOLUTE — т.е., скрипт будет возвращать актуальные значения и их не нужно аккумулировать), минимальное и максимальное значение параметра и пояснение для графика (info). Так же будут высылаться уведомления в случае крайних значений параметра (значения для warning и critical задаются в общей конфигурации Munin или в конфиге модуля через параметры my_connections.syn.warning и my_connections.syn.critical).

Теперь нужно перейти к получению непосредственных значений, но вначале немного разберёмся с iptables, из которого мы их планируем извлекать.
Получение параметров из файрвола iptables
Для того, чтобы получать статистику по конкретным интересующим нас параметрам из файрвола, необходимо задать дополнительные правила. Нас интересуют пакеты с флагом SYN, поэтому мы добавляем такое правило:

iptables -I INPUT 1 -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG SYN -j ACCEPT

Мы добавили его первым номером, чтобы гарантировать обработку любого поступившего пакета. Если добавить правило в конец, возможно, пакет уже будет отброшен.

Теперь посмотрим, что показывает статистика файрвола:

[root@saytostroy.ru]# iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x02
...

В поле pkts отображено текущее число пакетов по данному правилу, а bytes — суммарный объём наших пакетов с флагом SYN. Пока что они нулевые.

Для наших нужд потребуется каждый раз обнулять статистику файрвола, чтобы при вызове iptables собранные данные не суммировались (мы ведь выбрали type ABSOLUTE в параметрах модуля). Для этого будем использовать параметр вызова -x, который будет обнулять статистику при каждом вызове. Кроме того, нас интересуют несокращённые значения (без обозначения K для килобайтов и т.д.), пожтому мы используем параметр -Z. Чтобы разгрузить программу от лишнего обращения к DNS для разрешения IP-адресов, зададим параметр -n. Итак, итоговый вызов будет следующим:

iptables -L -x -n -v -Z

Теперь вернёмся к нашему новоиспечённому плагину и завершим работу над ним, задав вывод актуального значения параметра syn.
Отображение значений параметра
Из вывода iptables по команде выше мы должны выбрать только ту цепочку, за которой мы хотим наблюдать, а именно — за нашим правилом. Для этого воскользуемся следующей цепочкой команд:

iptables -L -x -n -v -Z | awk '/tcp flags:0x3F/0x02/ { print "syn.value " $1 }'

Сохраним наш модуль и проверим его вывод при помощи программы munin-run

[root@saytostroy.ru]# /usr/sbin/munin-run my_connections
syn.value 32

Уже успели пробежать три десятков пакетов, инициирующих сетевые соединения, поэтому мы увидели value больше нуля.

Отлично. Теперь остаётся только подключить наш модуль к Munin и перезапустить сервис:

[root@saytostroy.ru]# sudo ln -s /usr/share/munin/plugins/my_connections /etc/munin/plugins/my_connections
[root@saytostroy.ru]# service munin-node restart

Мы установили символическую ссылку на наш модуль в папку /etc/munin/plugins/, где «лежат» модули, задействованные в системе.

Для удобства использования лучше подвесить статистику на поддомен, ведь согласитесь нам не за чем иметь директорию с отчетами в документрут от сайта, или копить директории на домене сервера [если такой есть], хотя тут кому как удобно. Решил делать именно на поддомене munin.site.com, добавил запись «А» в DNS чтобы создать этот самый поддомен, а пока обновляется информация, можно приступить к настройке.

NOTE: работа с munin-node, для сбора статистики с разных серверов, рассмотрена не будет.

Установка munin (серверная часть) и munin-node (клиентская часть)

Ставим

# apt-get install munin munin-node munin-plugins-extra libwww-perl -y

libwww-perl — все равно ставить нужно будет позже, поэтому поставим сразу, чтобы незаморачиваться.

Раскомментируем строки и укажем нужные пути в munin.conf

# nano /etc/munin/munin.conf

конфиг

dbdir   /var/lib/munin
htmldir /usr/local/hosting/stat.adminunix.ru/www
logdir /usr/local/hosting/stat.adminunix.ru/log
rundir  /var/run/munin
tmpldir /etc/munin/templates

создадим каталоги для логов и html-отчетов

# mkdir -p /usr/local/hosting/stat.adminunix.ru/www
# mkdir -p /usr/local/hosting/stat.adminunix.ru/log

Сменим владельца, иначе munin не сможет писать статистику и логи

# chown -R munin:munin /usr/local/hosting/stat.adminunix.ru
# chmod 770 /usr/local/hosting/stat.adminunix.ru/www

Предоставим доступ пользователю site.com к файлам пользователя munin. Это делать необязательно, но в моем случае nginx наотрез отказывался показывать статистику, если расположить каталог где-то в /var/www будет все чин-чином и это делать не надо

# usermod -a -G nginx munin

Запустим первую индексацию

# su - munin --shell=/bin/bash
$ /usr/share/munin/munin-update
$ exit

Теперь можно проверить, появились ли файлы в/usr/local/hosting/stat.adminunix.ru/www

# ls -la /usr/local/hosting/stat.adminunix.ru/www

Есть все хорошо, продолжаем.

Настройка nginx

Для начала скопируем уже готовый виртулхост, можно скопировать и defalt

# cp /etc/nginx/sites-available/stat.adminunix.ru /etc/nginx/sites-available/stat.adminunix.ru

Редактируем его под свои нужды

# nano /etc/nginx/sites-available/stat.adminunix.ru

Изменим пути и впишем простую http-авторизацию. У меня получилось что-то вроде

server {
        listen   80;
        server_name  stat.adminunix.ru www.adminunix.ru; #домен по которому будет откликаться наш новый хост

        access_log  /usr/local/hosting/stat.adminunix.ru/log/nginx.access.log; #расположение логов данного хоста
        error_log  /usr/local/hosting/stat.adminunix.ru/log/nginx.error.log; #расположение логов данного хоста

        location / {
                root   /usr/local/hosting/stat.adminunix.ru/www; #расположение корневой директории, тут у нас будут отчеты

                #редирект
                if ($http_host != "stat.adminunix.ru") {
                 rewrite ^ http://stat.adminunix.ru$request_uri permanent;
                }

                index index.html; #файлы которые будут загружаться по умолчанию
                auth_basic  "restricted"; #http-авторизация
                auth_basic_user_file    /usr/local/hosting/stat.adminunix.ru/www/.htpasswd; #http-авторизация
        }
        #...

Теперь в /etc/nginx/sites-available/default

# nano /etc/nginx/sites-available/default

Добавим в секцию server {} новый локейшен

#...
        location /nginx_status {
            stub_status on;
            access_log  off;
            allow       127.0.0.1;
            deny        all;
        }
        #...

Создадим access.log и error.log в log

# touch /usr/local/hosting/stat.adminunix.ru/log/nginx.access.log
# touch /usr/local/hosting/stat.adminunix.ru/log/nginx.error.log

Активируем виртуальный хост munin.site.com путем создания симлинка в директорию /etc/nginx/sites-enabled

# ln -s /etc/nginx/sites-available/stat.adminunix.ru /etc/nginx/sites-enabled/stat.adminunix.ru

Перезагружаем nginx

# /etc/init.d/nginx restart

Создаем .htpasswd где у нас будет зашифрованный пароль и пользователь «admin».

# htpasswd -c  /usr/local/hosting/stat.adminunix.ru/www/.htpasswd admin

Проверяем работу зайдя через браузер по URL

http://stat.adminunix.ru/

В общем то статистика отобразилась, все хорошо. Проверим работу /nginx_status

# lynx localhost/nginx_status
# wget -qO - http://127.0.0.1/nginx_status

Установка плагинов Munin для Nginx

Плагинов у этой штуки много. Я дополнительно ставил только для мониторинга nginx. Переходим в каталог доступных плагинов munin

# cd /usr/share/munin/plugins/

Скачиваем в него плагины для nginx

# wget -nd http://debianuser.org/nginx/nginx_{memory,status,traffic,request}
# wget -nd http://munin-monitoring.org/browser/munin-contrib/plugins/nginx/nginx_{memory,error,upstream,vhost_traffic,connection_request}
#wget -nd http://munin-monitoring.org/export/munin-contrib/plugins/nginx/nginx_vhost_traffic
  • request — мониторинг запросов
  • status — мониторинг статуса сервера
  • memory — мониторинг занимаемой памяти
  • traffic — мониторинг трафика

Даем права

# chmod +x nginx_memory
# chmod +x nginx_status
# chmod +x nginx_request
# chmod +x nginx_traffic

# chmod +x nginx_error
# chmod +x nginx_upstream
# chmod +x nginx_vhost_traffic
# chmod +x nginx_nginx-cache-multi_
# chmod +x nginx_connection_request

# chmod +x mysql_connections
# chmod +x mysql_connections_per_user
# chmod +x mysql_qcache
# chmod +x mysql_qcache_mem
# chmod +x mysql_report
# chmod +x mysql_size_
# chmod +x mysql_size_ondisk
# chmod +x mysql_slave
# chmod +x mysql_slave_threads
# chmod +x mysql_aggregate_

Включаем плагины сделав симлинки на них в директорию /etc/munin/plugins/

# ln -s /usr/share/munin/plugins/nginx_memory /etc/munin/plugins/nginx_memory
# ln -s /usr/share/munin/plugins/nginx_status /etc/munin/plugins/nginx_status
# ln -s /usr/share/munin/plugins/nginx_traffic /etc/munin/plugins/nginx_traffic
# ln -s /usr/share/munin/plugins/nginx_request /etc/munin/plugins/nginx_request
# ln -s /usr/share/munin/plugins/nginx_error /etc/munin/plugins/nginx_error
# ln -s /usr/share/munin/plugins/nginx_upstream /etc/munin/plugins/nginx_upstream
# ln -s /usr/share/munin/plugins/nginx_cache_multi_ /etc/munin/plugins/nginx_cache-multi_
# ln -s /usr/share/munin/plugins/nginx_vhost_traffic /etc/munin/plugins/nginx_vhost_traffic
# ln -s /usr/share/munin/plugins/nginx_connection_request /etc/munin/plugins/nginx_connection_request
# ln -s /usr/share/munin/plugins/mysql_connections /etc/munin/plugins/mysql_connections
# ln -s /usr/share/munin/plugins/mysql_connections_per_user /etc/munin/plugins/mysql_connections_per_user
# ln -s /usr/share/munin/plugins/mysql_qcache /etc/munin/plugins/mysql_qcache
# ln -s /usr/share/munin/plugins/mysql_qcache_mem /etc/munin/plugins/mysql_qcache_mem
# ln -s /usr/share/munin/plugins/mysql_report /etc/munin/plugins/mysql_report
# ln -s /usr/share/munin/plugins/mysql_size_ /etc/munin/plugins/mysql_size_
# ln -s /usr/share/munin/plugins/mysql_size_all /etc/munin/plugins/mysql_size_all
# ln -s /usr/share/munin/plugins/mysql_size_ondisk /etc/munin/plugins/mysql_size_ondisk
# ln -s /usr/share/munin/plugins/mysql_slave /etc/munin/plugins/mysql_slave
# ln -s /usr/share/munin/plugins/mysql_slave_threads /etc/munin/plugins/mysql_slave_threads
# ln -s /usr/share/munin/plugins/mysql_aggregate_ /etc/munin/plugins/mysql_aggregate_
или
cd /etc/munin/plugins/
ln -sf /usr/share/munin/plugins/nginx_* .
ln -sf /usr/share/munin/plugins/mysql_* .

Теперь нужно указать куда ходить за статистикой. Можно ручками добавить

# nano /etc/munin/plugin-conf.d/munin-node

В конце файла

[nginx*]
env.url http://localhost/nginx_status

А можно так для разнообразия

# echo "" | tee -a /etc/munin/plugin-conf.d/munin-node
# echo "[nginx*]" | tee -a /etc/munin/plugin-conf.d/munin-node
# echo "env.url http://localhost/nginx_status" | tee -a /etc/munin/plugin-conf.d/munin-node

Все, проверяем работу плагинов

# munin-run nginx_memory
# munin-run nginx_status
# munin-run nginx_memory
# munin-run nginx_traffic

Если ругани в виде ошибок и замечаний нет, все отлично, перезагружаем munin-node, ждем какое-то время чтобы «первая» статистика собралась

# /etc/init.d/munin-node restart

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

# munin-node-configure --suggest

#ln -s /var/cache/munin/www /usr/local/hosting/munin/

Можно принудительно запустить опрос нод, так же поможет для отладки

Shell

class="crayon-plain-wrap">#root@Debian~# su -munin --sheel=/bin/bash
class="crayon-plain-wrap">#root@Debian~# /usr/share/munin/minin-update --nofork --debug
class="crayon-plain-wrap">#exit
  root@Debian ~ # su - munin --shell=/bin/bash
munin@Debian:~$  /usr/share/munin/munin-update --nofork --debug
exit

Если все ок то вскоре появятся файлики с графиками в /var/cache/munin/www а тем временем в браузере

#!/bin/bash
#
 
LAN_ADAPTER=p1p1
INET_ADAPTER=p4p1
LOCAL_NET=192.168.0
LOCAL_IP=192.168.0.1
DHCP_RANGE='192.168.0.2 192.168.0.254'
SAMSDB_PASS='mypass'
 
# ----------------------------------------------------
 
# Проверяем наличие прав супер пользователя
 
if [ "$(whoami &2>/dev/null)" != "root" ] && [ "$(id -un &2>/dev/null)" != "root" ] ; then
  echo "Please, run this as root!"
  exit 1
fi
 
# Обновляемся
apt-get -q -y update
apt-get -q -y upgrade
apt-get -q -y dist-upgrade
 
# Устанавливаем все необходимые пакеты
apt-get -y install unzip make g++ libtool build-essential autoconf automake
apt-get -y install apache2 apache2-doc apache2-utils mysql-server mysql-client libmysqlclient-dev
apt-get -y install bind9 ssl-cert libpcre3 libpcre3-dev isc-dhcp-server squid
apt-get -y install php5 php5-cli php5-common php5-dev php5-mcrypt php5-imagick php5-mysql php5-gd php5-ldap php-fpdf libapache2-mod-php5
 
# опционально
apt-get -y install phpmyadmin
 
# Настроим Apache
sed -i -e '1s/.*/ServerName localhost/' /etc/apache2/apache2.conf
# sed -i -e 's/80/8080/' /etc/apache2/ports.conf
# sed -i -e 's/80/8080/' /etc/apache2/sites-available/default
 
apache2ctl restart
 
# ---------------------------------------------------- Замарочки PHP
 
# Настраиваем сеть
echo "
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
" >> /etc/sysctl.conf
 
echo "
auto $LAN_ADAPTER
iface $LAN_ADAPTER inet static
address $LOCAL_IP
netmask 255.255.255.0" >> /etc/network/interfaces
 
iptables -t nat -A PREROUTING -i $LAN_ADAPTER -p tcp --dport 80 -j DNAT --to-destination $LOCAL_IP:3128
iptables -t nat -A POSTROUTING -o $INET_ADAPTER -j MASQUERADE
iptables -A FORWARD -i $LAN_ADAPTER -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $INET_ADAPTER -m state --state RELATED,ESTABLISHED -j ACCEPT
 
echo '#!/bin/sh
iptables-restore < /etc/firewall.conf ' >> /etc/network/if-up.d/00-iptables
chmod +x /etc/network/if-up.d/00-iptables
iptables-save > /etc/firewall.conf
 
# Настраиваем DHCP
 
echo '
subnet '$LOCAL_NET'.0 netmask 255.255.255.0 {
       option routers '$LOCAL_IP';
       option subnet-mask 255.255.255.0;
       option domain-name-servers '$LOCAL_IP';
       range '$DHCP_RANGE';
}
' >> /etc/dhcp/dhcpd.conf
sed -i -e 's/INTERFACES=""/INTERFACES="'$LAN_ADAPTER'"/' /etc/default/isc-dhcp-server
 
# ------------------------------------------------------
 
mv /etc/squid3/squid.conf /etc/squid3/squid.conf-old
grep -v "^#" /etc/squid3/squid.conf-old | sed -e '/^$/d' >> /etc/squid3/squid.conf
sed -i -e '/acl localhost/ aacl localnet src '$LOCAL_NET'.0/24' /etc/squid3/squid.conf
sed -i -e '/http_access allow localhost/ ahttp_access allow localnet' /etc/squid3/squid.conf
sed -i -e 's/http_port 3128/http_port '$LOCAL_IP':3128 transparent/' /etc/squid3/squid.conf
echo "
visible_hostname serv
always_direct allow all
 
access_log /var/log/squid3/access.log squid
cache_log /var/log/squid3/cache.log
pid_filename /var/run/squid3.pid
 
cache_dir ufs /var/spool/squid3 4096 32 512
coredump_dir /var/spool/squid3
maximum_object_size_in_memory 50 MB
maximum_object_size 50 MB
" >> /etc/squid3/squid.conf
 
/etc/init.d/squid3 stop
squid3 -z
ln -s /usr/sbin/squid3 /usr/sbin/squid
 
# Скачиваем собираем и устанавливаем SAMS2
cd /usr/src
wget http://sams2.googlecode.com/files/sams-2.0.0-rc2.tar.bz2
tar xvjf sams-2.0.0-rc2.tar.bz2
cd sams-2.0.0-rc2
 
make -f Makefile.cvs
./configure
 
sed -i -e '6000s/absdir=.*/absdir="/usr/lib"/' libtool
 
make
make install
 
# Настраиваем SAMS2
 
sed -i -e 's/DB_USER=/DB_USER=sams/' /usr/local/etc/sams2.conf
sed -i -e 's/DB_PASSWORD=/DB_PASSWORD='$SAMSDB_PASS'/' /usr/local/etc/sams2.conf
sed -i -e 's/squid/squid3/' /usr/local/etc/sams2.conf
sed -i -e 's|SQUIDCACHEDIR=/usr/local/apache2|SQUIDCACHEDIR=/var/spool/squid3|' /usr/local/etc/sams2.conf
 
# ------------------------------------------------------------------------------------------------------
 
sed -i -e 's/AllowOverride.*/ /' /etc/apache2/conf.d/doc4sams2.conf
sed -i -e 's/AllowOverride.*/ /' /etc/apache2/conf.d/sams2.conf
 
echo '#!/bin/sh -e
 
### BEGIN INIT INFO
# Provides:             sams
# Required-Start:       $local_fs $network $time $remote_fs
# Required-Stop:
# Should-Start:         $named $mysql $squid
# Should-Stop:
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    Starting sams daemon
# Description:          Squid Account Management System (SAMS)
#  Starting sams management daemon - sams2daemon
### END INIT INFO
#
# Author:       Pavel Vinogradov <Pavel.Vinogradov@nixdev.net>
#
# /etc/init.d/sams2: start and stop the sams daemon
 
SAMSPATH=`cat /usr/local/etc/sams2.conf | grep SAMSPATH | tr "SAMSPATH=" ""`
NAME="sams"
DAEMON=$SAMSPATH/bin/sams2daemon
LOCKFILE=/var/lock/samsd
PIDFILE=/var/run/sams2daemon.pid
RETVAL=0
SAMS_ENABLE=true
test -x $DAEMON || exit 0
if ! [ -x "/lib/lsb/init-functions" ]; then
        . /lib/lsb/init-functions
else
        echo "E: /lib/lsb/init-functions not found, lsb-base (>= 3.0-6) needed"
        exit 1
fi
 
. /etc/default/rcS
case "$1" in
        start)
                if "$SAMS_ENABLE"; then
                        log_daemon_msg "Starting $NAME daemon" "$NAME"
                        if [ -s $PIDFILE ] && kill -0 $(cat $PIDFILE) >/dev/null 2>&1; then
                                log_progress_msg "apparently already running"
                                log_end_msg 0
                                exit 0
                        fi
 
                        start-stop-daemon --start --quiet --background
                                --pidfile $PIDFILE
                                --exec $DAEMON
                        RETVAL=$?
                        [ $RETVAL -eq 0 ] && touch "$LOCKFILE"
                        log_end_msg $RETVAL
                else
                        [ "VERBOSE" != no ] && log_warning_msg "$NAME daemon not enabled, not starting. Please read /usr/share/doc/sams2/README.Debian"
                fi
        ;;
 
        stop)
                if "$SAMS_ENABLE"; then
                        log_daemon_msg "Stopping $NAME daemon" "$NAME"
                        start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE
                        RETVAL=$?
                        [ $RETVAL -eq 0 ] && rm -f "$LOCKFILE"
                        log_end_msg $RETVAL
                else
                        [ "VERBOSE" != no ] && log_warning_msg "$NAME daemon not enabled, not stoping..."
                fi
 
        ;;
 
        restart|force-reload)
                /etc/init.d/sams2 stop
                /etc/init.d/sams2 start
        ;;
 
        *)
                echo "Usage: ${0##*/} {start|stop|restart}"
                RETVAL=1
        ;;
esac' >> /etc/init.d/sams2
 
chmod -R 777 /etc/init.d/sams2
chmod +x /etc/init.d/sams2
update-rc.d sams2 start 99 2 3 4 5 . stop 1 0 1 6 .
 
chown -R www-data:www-data /usr/local/share/sams2/
chown -R www-data:www-data /usr/local/etc/sams2.conf
chmod -R 777 /usr/local/share/sams2
 
/etc/init.d/apache2 restart
/etc/init.d/squid3 restart
 
exit 0

Виды DDoS-атак (условия для DOS/DDos атак)

1. Недостаточная фильтрация данных может привести повышенному потреблению ресурсов, к длительному или бесконечному циклу, выделению огромного объема оперативной памяти.

2. Недостаточная фильтрация данных

3. Атака второго рода — подобные атаки приводят к срабатыванию системы защиты, что приводит к недоступности сервера

4. Флуд — Думаю тут все ясно. Большое количество ресурсоемких запросов, обращенных к серверу.

В интернете были найдены полезные команды для проверки нагрузки на сервер, а так же для анализа и определения ДДОС (DDoS) атаки.

Что делать?

Во-первых, посмотрим число процессов Апача:
ps aux | grep apache | wc -l

Либо в случае ОС CentOS5/RHEL:

ps aux | grep httpd | wc -l

Если их более 20-30, то это уже повод для беспокойства.

Далее обязательно просмотреть глобальные логи Апача на предмет наличия аномалий (например, запросов без указания вихоста):

/var/log/apache2/error.log
/var/log/apache2/access.log
 И для CentOS:
/var/log/httpd/error.log
/var/log/httpd/access.log
 Далее, стоит просмотреть логи всех сайтов и обратить особое внимание на самые большие из них.

Если «большой» лог найден, то его стоить проанализировать на предмет аномалий следующим образом:

cat log_type.log | awk '{print $1}' | sort | uniq -c

Эта команда укажет число запросов до сайта с уникальных айпи, вывод ее будет в виде:

14 95.67.xx.xx
21 95.68.xx.xx
25 95.68.xx.xx
15 95.68.xx.xx
15 95.68.xx.xx
1 95.69.xx.xx
15 95.70.xx.xx
1 95.70.xx.xx
21 95.70.xx.xx
24 95.70.xx.xx
22 95.70.xx.xx
15 95.70.xx.xx
17 95.70.xx.xx
1 95.70.xx.xx
Таким образом, если какой-то IP / блок айпи заваливает сайт запросами, это будет видно по резко уходящим в верх значениям запросов для IP злоумышленников.

Полезные команды:

Число процессов Apache:

 ps aux | grep httpd |wc -l

Число коннектов на 80 порт:

 netstat -na | grep :80 | wc -l

То же, в статусе SYN

 netstat -na | grep :80 | grep syn

Пример SYN-флуда:

 netstat -na | grep :80 | grep SYN | wc -l 767

Посмотреть много ли разных IP:

 netstat -na | grep :80 | grep SYN | sort -u | more

На какой домен чаще всего идут запросы:

 tcpdump -npi eth0 port domain

Статус Apache:

 apachectl status

Посмотреть откуда IP или Domain:

 whois xxx.xxx.xxx.xxx

или

 jwhois xxx.xxx.xxx.xxx

С какого IP сколько запросов:

 netstat -na | grep :80 | sort | uniq -c | sort -nr | more

Количество соединений с сервером:

 cat /proc/net/ip_conntrack | wc -l

Вывод информации в реальном времени, IP которые соединены с сервером и какое количество соединений по каждому IP

 netstat -antu | awk '$5 ~ /[0-9]:/{split($5, a, ":"); ips[a[1]]++} END {for (ip in ips) print ips[ip], ip | "sort -k1 -nr"}'

позволяет узнать сколько одновременных подключений на порт с 1 айпи

# netstat -plan | grep :80 | awk '{print $5}' | awk -F: '{print $1}' | sort | uniq -c
# netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

# устанавливаем максимальное количество подключений с одного айпи.
# В браузерах эта количество подключений к серверу ограничено 16 соединениями,
# но стоит учитывать тех, кто сидит за NAT, а также что пользователь
# может открыть 2 сайта на разных айпишниках одного и того же сервера.
# Данный параметр подбирается оптимально с помощью предыдущей команды.

iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 32 -j DROP
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# то же для DNS

iptables -A INPUT -p udp --dport 53 -m connlimit --connlimit-above 8 -j DROP
iptables -A INPUT -p udp --dport 53 -j ACCEPT

# будет препятствовать спуфингу от нашего имени.
# Ведь если мы получаем пакет с установленными флагами SYN и ACK
# (такой комбинацией флагов обладает только ответ на SYN-пакет) по еще не открытому соединению,
# это означает, что кто-то послал другому хосту SYN-пакет от нашего имени, и ответ пришел к нам.
# Конечно, злоумышленнику предстоит еще угадать номер последовательности.
# Согласно приведенному правилу, наш хост ответит RST-пакетом, после получения которого
# атакуемый хост закроет соединение.

iptables -I INPUT -m conntrack --ctstate NEW,INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK -j REJECT --reject-with tcp-reset

# Для защиты от SYN атак включаем SYN-cookies

sysctl -w net.ipv4.tcp_syncookies=1

# Увеличиваем размер очереди полуоткрытых соединений (также полезно при SYN флуде) (default 512)

sysctl -w net.ipv4.tcp_max_syn_backlog=4096

# Проверять TCP-соединение каждую минуту. Если на другой стороне — легальная машина,
# она сразу ответит. Дефолтовое значение — 2 часа.

sysctl -w net.ipv4.tcp_keepalive_time=60

# Повторить пробу через десять секунд

sysctl -w net.ipv4.tcp_keepalive_intvl=10

# Количество проверок перед закрытием соединения

sysctl -w net.ipv4.tcp_keepalive_probes=5

# Фильтр обратного пути, защита от спуфинга (подмены адресов)

sysctl -w net.ipv4.conf.default.rp_filter=1

# Уменьшение времени удержания «полуоткрытых» соединений
# Сделаем так, чтобы перепередача осуществлялась на 3 секунде
# и полное время хранения полуоткрытых соединений в очереди составило 9 секунд

sysctl -w net.ipv4.tcp_synack_retries=1

# Изменяем время ожидания приема FIN до полного закрытия сокета

sysctl -w net.ipv4.tcp_fin_timeout=10

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

  • Добавьте в конфигурационный файл nginx следующий раздел location:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    http {
    ...
    server {
    listen SOME.IP.ADD.RESS;
    ...
    location /nginx_status {
    stub_status on;
    access_log   off;
    allow SOME.IP.ADD.RESS;
    deny all;
    }
    ...
    }
    ...
    }
  • Проверьте свою конфигурацию следующей командой:
    1
    2
    3
    4
    # /your/installation/sbin/nginx -t
    2006/04/29 04:24:36 [info] 31676#0: the configuration file /opt/nginx/conf/nginx.conf syntax is ok
    2006/04/29 04:24:36 [info] 31676#0: the configuration file /opt/nginx/conf/nginx.conf was tested successfully
    #
    Если вы получите сообщение о том, что директива stub_status неизвестна, то проверьте включена ли опция ----with-http_stub_status_module при компиляции nginx.
  • Если проверка конфигурации прошла успешно, перезапустите nginx и проверьте статистику:
    1
    2
    3
    4
    5
    6
    croesus:~# GET http://your-domain.com/nginx_status
    Active connections: 1492
    server accepts handled requests
    2124355 2124355 8278635
    Reading: 6 Writing: 405 Waiting: 1081
    croesus:~#
  • Скачайте скрипт генерации графиков: rrd_nginx.pl и сделайте его исполнимым:
    1
    # chmod +x rrd_nginx.pl
  • Измените настройки в файле rrd_nginx.pl, чтобы дать скрипту знать, куда складывать rrd-базу и картинки со статистикой:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    #!/usr/bin/perl
    use RRDs;
    use LWP::UserAgent;# определите путь к базам для rrdtool
    my $rrd = '/opt/rrd';
    # определите путь к картинкам
    my $img = '/opt/rrd/html';
    # определите URL для статистики nginx
    my $URL = «http://your-domain.com/nginx_status»;
    ...
  • Последний шаг в настройке – добавление следующей команды в файл /etc/crontab и перезапуск демона cron:
    * *     * * *   root    /some/path/rrd_nginx.pl
    

Когда все приготовления будут завершены, Вы получите в каталоге $img следующие графики:

https://gist.github.com/mattrude/4362399

Выделенный Web-сервер на основе nginx – отличный способ повышения производительности Web-сайтов. В скорости обработки статического контента ему просто нет равных: он легко выдерживает несколько тысяч одновременных соединений и может быть легко оптимизирован и подогнан под любую конфигурацию. Однако? выступая в качестве фронт-энда для Apache, nginx оказывается наиболее уязвимым местом всей Web-инфраструктуры, поэтому безопасности nginx необходимо уделить особое внимание.

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

Установка

Пакет nginx доступен в прекомпилированном виде для любого дистрибутива. Однако собрав сервер самостоятельно, ты сможешь сделать его более компактным и надежным, а также получишь возможность изменить строку приветствия Web-сервера, чтобы отбить несмышленых скрипт-кидди.

Измени строку приветствия Web-сервера

Скачай исходники nginx, открой файл src/http/ngx_http_header_filter_module.c и найди следующие две строки:

static char ngx_http_server_string[] = "Server: nginx" CRLF;
static char ngx_http_server_full_string[] = "Server: " NGINX_VER CRLF;

Замени их на что-то вроде этого:

static char ngx_http_server_string[] = "Server: ][ Web Server" CRLF;
static char ngx_http_server_full_string[] = "Server: ][ Web Server" CRLF;

Удали все неиспользуемые тобой nginx-модули

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

Выполни сборку с помощью следующих команд:

# ./configure --without-http_autoindex_module --without-http_ssi_module
# make

# make install

Так ты получишь nginx с заранее отключенными (и в большинстве случаев бесполезными) модулями SSI (Server Side Includes) и Autoindex. Чтобы узнать, какие модули можно безболезненно выбросить из Web-сервера, запусти скрипт configure с флагом ‘–help’.

Препарируем nginx.conf

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

Отключи показ версии сервера на всех ошибочных страницах

Добавь в файл nginx.conf строку «server_tokens off». Это заставит nginx скрывать информацию о типе и версии Web-сервера на страницах, генерируемых в ответ на ошибочный запрос клиента.

Настрой защиту от срыва стека

Добавь в секцию server следующие строки:

# vi /etc/nginx/nginx.conf

# Максимальный размер буфера для хранения тела запроса клиента
client_body_buffer_size 1K;
# Максимальный размер буфера для хранения заголовков запроса клиента
client_header_buffer_size 1k;
# Максимальный размер тела запроса клиента, прописанный в поле Content-Length заголовка. Если сервер должен поддерживать загрузку файлов, это значение необходимо увеличить
client_max_body_size 1k;
# Количество и размер буферов для чтения большого заголовка запроса клиента
large_client_header_buffers 2 1k;

Обрати внимание на директиву large_client_header_buffers. По умолчанию, для хранения строки URI nginx выделяет четыре буфера, размер каждого из которых равен размеру страницы памяти (для x86 это 4 Кб). Буферы освобождаются каждый раз, когда по окончанию обработки запроса соединение переходит в состояние keep-alive. Два буфера по 1 Кб могут хранить URI длиной только 2 Кб, что позволяет бороться с ботами и DoS-атаками.

Для повышения производительности добавь следующие строки:

# vi /etc/nginx/nginx.conf

# Таймаут при чтении тела запроса клиента
client_body_timeout 10;
# Таймаут при чтении заголовка запроса клиента
client_header_timeout 10;
# Таймаут, по истечению которого keep-alive соединение с клиентом не будет закрыто со стороны сервера
keepalive_timeout 5 5;
# Таймаут при передаче ответа клиенту
send_timeout 10;

Контролируй количество одновременных соединений

Для защиты Web-сервера от перегрузки и попыток осуществить DoS-атаку добавь в конфиг следующие строки:

# vi /etc/nginx/nginx.conf

# Описываем зону (slimits), в которой будут храниться состояния сессий. Зона размером 1 Мб может хранить около 32000 состояний, мы устанавливаем ее размер равным 5 Мб
limit_zone slimits $binary_remote_addr 5m;
# Задаем максимальное количество одновременных соединений для одной сессии. По сути, это число задает максимальное количество соединений с одного IP
limit_conn slimits 5;

Первая директива должна находиться в секции HTTP, вторая – в секции location. Когда количество соединений выйдет за пределы лимитов, клиент получит сообщение «Service unavailable» с кодом 503.

Разреши коннекты только к своему домену

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

# vi /etc/nginx/nginx.conf

if ($host !~ ^(host.com|www.host.com)$ ) {
return 444;
}

Ограничь количество доступных методов обращения к Web-серверу

Некоторые боты используют различные методы обращения к серверу для попытки определения его типа и/или проникновения, однако в документе RFC 2616 четко сказано, что Web-сервер не обязан реализовывать их все, и неподдерживаемые методы могут просто не обрабатываться. Сегодня используемыми остаются только методы GET (запрос документа), HEAD (запрос заголовков сервера) и POST (запрос на публикацию документа), поэтому все остальные можно безболезненно отключить с помощью помещения следующих строк в секцию server конфигурационного файла:

# vi /etc/nginx/nginx.conf

if ($request_method !~ ^(GET|HEAD|POST)$ ) {
return 444;
}

Отшивай ботов

Другой способ блокирования ботов, сканеров и прочей нечисти основан на определении типа клиента (user-agent). Он не слишком эффективен, потому как большинство ботов косят под вполне легитимные браузеры, но в ряде случаев остается полезным:

# vi /etc/nginx/nginx.conf

# Блокируем менеджеры загрузки
if ($http_user_agent ~* LWP::Simple|BBBike|wget) {
return 403;
}
# Блокируем некоторые типы ботов
if ($http_user_agent ~* msnbot|scrapbot) {
return 403;
}

Блокируй Referrer-спам

Если твой сайт публикует Web-логи в общедоступном виде, ты легко можешь стать жертвой Referrer-спама (когда спам-боты обращаются к твоему серверу, указывая в заголовке referrer – адрес рекламируемого сайта). Такой вид спама может легко испортить SEO-рейтинги интернет-страницы, поэтому его необходимо блокировать в обязательном порядке. Один из способов сделать это – занести наиболее частые слова, встречающиеся в адресах рекламируемых сайтов, в черный список.

# vi /etc/nginx/nginx.conf

# Секция server
if ( $http_referer ~* (babes|forsale|girl|jewelry|love|nudit|organic|poker|porn|sex|teen) )
{
return 403;
}

Блокируй хотлинк

Хотлинк – это включение в страницу изображения (или иного контента) с другого сайта. По сути, это воровство, потому как изображение, на которое ты потратил не один час своего свободного времени, не только свободно используется другими, но и создает нагрузку на твой Web-сервер, не приводя на него посетителей. Для борьбы с хотлинками достаточно сделать так, чтобы изображения отдавались клиенту только в том случае, если он запросил их, уже находясь на сайте (другими словами, заголовок referrer-запроса должен содержать имя твоего сайта). Добавь в секцию server конфигурационного файла nginx.conf следующие строки (host.com – это адрес твоего сайта):

# vi /etc/nginx/nginx.conf

location /images/ {
valid_referers none blocked www.host.com host.com;
if ($invalid_referer) {
return 403;
}
}

В качестве альтернативы ты можешь настроить сервер на отдачу специального баннера с сообщением о воровстве вместо запрашиваемого изображения. Для этого замени строку «return 403» на строку:

rewrite ^/images/uploads.*.(gif|jpg|jpeg|png)$ http://www.host.com/banned.jpg last

Защищай важные каталоги от посторонних

Как и любой другой Web-сервер, nginx позволяет регулировать доступ к каталогам на основе IP-адресов и паролей. Эту возможность можно использовать для закрытия некоторых частей сайта от посторонних глаз. Например, для отрезания URI от внешнего мира:

# vi /etc/nginx/nginx.conf

location /uploads/ {
# Разрешаем доступ только машинам локальной сети
allow 192.168.1.0/24;
# Отшиваем всех остальных
deny all;
}

Теперь к документам каталога uploads будут иметь доступ только пользователи локальной сети. Для установки пароля придется проделать более сложные действия. Сначала необходимо создать приватный для nginx-файл паролей и добавить в него необходимых пользователей (в качестве примера добавим пользователя admin):

# mkdir /etc/nginx/.htpasswd
 # htpasswd -c /etc/nginx/.htpasswd/passwd admin

Далее открой файл nginx.conf и впиши в него следующие строки:

# vi /etc/nginx/nginx.conf
location /admin/ {
 auth_basic "Restricted";
 auth_basic_user_file /etc/nginx/.htpasswd/passwd;
 }

Новых пользователей можно добавить с помощью следующей команды:

# htpasswd -s /etc/nginx/.htpasswd/passwd пользователь

Используй SSL

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

Для настройки SSL-шифрования средствами nginx достаточно выполнить несколько простых шагов. Сначала ты должен создать сертификат с помощью следующей последовательности команд:

# cd /etc/nginx
 # openssl genrsa -des3 -out server.key 1024
 # openssl req -new -key server.key -out server.csr
 # cp server.key server.key.org
 # openssl rsa -in server.key.org -out server.key
 # openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Затем описать сертификат в конфигурационном файле nginx:

# vi /etc/nginx/nginx.conf
server {
 server_name host.com;
 listen 443;
 ssl on;
 ssl_certificate /etc/nginx/server.crt;
 ssl_certificate_key /etc/nginx/server.key;
 access_log /etc/nginx/logs/ssl.access.log;
 error_log /etc/nginx/logs/ssl.error.log;
 }

После этого можно перезагрузить Web-сервер:

# /etc/init.d/nginx reload

Естественно, без поддержки со стороны самого Web-сайта это делать бессмысленно.

Другие способы

Установи правильные значения системных переменных

Открой файл /etc/sysctl.conf и помести в него следующие строки:

# vi /etc/sysctl.conf
# Защита от smurf-атак
 net.ipv4.icmp_echo_ignore_broadcasts = 1
 # Защита от неправильных ICMP-сообщений
 net.ipv4.icmp_ignore_bogus_error_responses = 1
 # Защита от SYN-флуда
 net.ipv4.tcp_syncookies = 1
 # Запрещаем маршрутизацию от источника
 net.ipv4.conf.all.accept_source_route = 0
 net.ipv4.conf.default.accept_source_route = 0
 # Защита от спуфинга
 net.ipv4.conf.all.rp_filter = 1
 net.ipv4.conf.default.rp_filter = 1
 # Мы не маршрутизатор
 net.ipv4.ip_forward = 0
 net.ipv4.conf.all.send_redirects = 0
 net.ipv4.conf.default.send_redirects = 0
 # Включаем ExecShield
 kernel.exec-shield = 1
 kernel.randomize_va_space = 1
 # Расширяем диапазон доступных портов
 net.ipv4.ip_local_port_range = 2000 65000
 # Увеличиваем максимальный размер TCP-буферов
 net.ipv4.tcp_rmem = 4096 87380 8388608
 net.ipv4.tcp_wmem = 4096 87380 8388608
 net.core.rmem_max = 8388608
 net.core.wmem_max = 8388608
 net.core.netdev_max_backlog = 5000
 net.ipv4.tcp_window_scaling = 1

Размести корневой каталог Web-сервера на выделенном разделе

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

/dev/sda5 /nginx ext4 defaults,nosuid,noexec,nodev 1 2

Помести nginx в chroot/jail-окружение

Любая современная *nix-система позволяет запереть приложение в изолированной среде исполнения. В Linux для этого можно использовать технологии KVM, Xen, OpenVZ и VServer, во FreeBSD – Jail, в Solaris – Zones. Если ни одна из этих технологий не доступна, ты можешь поместить nginx в классический chroot, который хоть и намного более хрупок, но большинство взломщиков остановить сможет.

Установи правила SELinux для защиты nginx

Хорошей альтернативой изолированным средам исполнения являются локальные системы обнаружения и предотвращения вторжений, такие как SELinux или AppArmor. Будучи правильно настроенными, они смогут предотвратить попытки взлома Web-сервера. По дефолту ни одна из них не настроена для работы в связке с nginx, однако в рамках проекта SELinuxNginx(http://sf.net/projects/selinuxnginx/) были созданы правила для SELinux, которые может использовать любой желающий. Остается только скачать и установить:

# tar -zxvf se-ngix_1_0_10.tar.gz
# cd se-ngix_1_0_10/nginx
# make
# /usr/sbin/semodule -i nginx.pp

Настрой брандмауэр

Обычно nginx устанавливают на выделенных машинах, готовых к высокой нагрузке, поэтому зачастую он остается единственным сетевым сервисом, работающим на сервере. Чтобы обезопасить сервер, достаточно создать совсем небольшой набор правил, которые будут открывать 80, 110 и 143-й порты (если, конечно, nginx должен работать еще и как IMAP/POP3-прокси) и закрывать от внешнего мира все остальное.

Ограничь количество соединений с помощью брандмауэра

Для не слишком нагруженного Web-сайта хорошей идеей будет ограничить количество попыток соединений с одного IP-адреса в минуту. Это сможет уберечь тебя от некоторых типов DoS-атак и брутфорса. В Linux это можно сделать с помощью стандартного iptables/netfilter-модуля state:

# iptables -A INPUT -p tcp --dport 80 -i eth0
 -m state --state NEW -m recent --set
 # iptables -A INPUT -p tcp --dport 80 -i eth0
 -m state --state NEW -m recent --update
 --seconds 60 --hitcount 15 -j DROP

Правила урезают лимит на количество подключений с одного IP в минуту до 15. То же можно сделать и с помощью pf:

# vi /etc/pf.conf
webserver_ip="1.1.1.1"
 table <abuse> persist
 block in quick from <abuse>
 pass in on $ext_if proto tcp to $webserver_ip
 port www flags S/SA keep state
 (max-src-conn 100, max-src-conn-rate 15/60,
 overload <abusive_ips> flush)

Кроме лимита на количество последовательных подключений (15 в минуту), данное правило устанавливает дополнительный лимит на количество одновременных подключений равный 100.

Настрой PHP

Если ты используешь nginx в связке с PHP, не забудь настроить и его. Вот как должен выглядеть конфигурационный файл /etc/php/php.ini защищенного сервера:

# vi /etc/php/php.ini

# Отключаем опасные функции
disable_functions = phpinfo, system, mail, exec
# Максимальное время исполнения скрипта
max_execution_time = 30
# Максимальное время, которое может потратить скрипт на обработку данных запроса
max_input_time = 60
# Максимальное количество памяти, выделяемое каждому скрипту
memory_limit = 8M
# Максимальный размер данных, отсылаемых скрипту с помощью метода POST
post_max_size = 8M
# Максимальный размер загружаемых файлов
upload_max_filesize = 2M
# Не показывать ошибки PHP-скриптов пользователям
display_errors = Off
# Включаем Safe Mode
safe_mode = On
# Включаем SQL Safe Mode
sql.safe_mode = On
# Позволяем выполнять внешние команды только в этом каталоге
safe_mode_exec_dir = /путь/к/защищенному/каталогу
# Защищаемся от утечки информации о PHP
expose_php = Off
# Ведем логи
log_errors = On
# Запрещаем открытие удаленных файлов
allow_url_fopen = Off

Выводы

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

https://xakep.ru/2010/12/15/54168/