Cуть вкратце сводится к тому, что в систему до дискового свопа добавляется сжимаемый налету своп, размещенный в оперативной памяти (коэфициент сжатия при броузинге, если верить автору статьи, доходит до 1:10)
Для современного дистрибутива достаточно сделать

 sudo apt-get install zram-config

И все настраивается автоматически.

:~$ free

 total used free shared buffers cached
 Память: 4038764 3802184 236580 576944 10392 819764
 -/+ буферы/кэш: 2972028 1066736
 Swap: 8429272 236476 8192796

:~$ cat /proc/swaps

 Filename Type Size Used Priority
 /dev/sda7 partition 6409896 229180 -1
 /dev/zram0 partition 1009688 3656 5
 /dev/zram1 partition 1009688 3640 5

Для Debian все чуть сложнее, но как обычно достаточно просто решаемо. Дело в том что модуль zram собран и доступен по умолчанию. В этом легко убедиться выполнив

modprobe -nv zram

Единственное чего я не нашел в Debian так это скрипта автозапуска для этого модуля с передачей ему нужных параметров. (Аналог zram-config в ubuntu) Это не значит что его нет вовсе, но в репозиториях Debian я его отчего то найти не смог. А это значит, что мы напишем этот скрипт сами.

/etc/init.d/zram

 #!/bin/sh
  ### BEGIN INIT INFO
  # Provides: zram
  # Required-Start: $local_fs
  # Required-Stop: $local_fs
  # Default-Start: S
  # Default-Stop: 0 1 6
  # Short-Description: Use compressed RAM as in-memory swap
  # Description: Use compressed RAM as in-memory swap
  ### END INIT INFO

  # Author: Antonio Galea <antonio.galea@gmail.com>
  # Thanks to Przemysław Tomczyk for suggesting swapoff parallelization

  FRACTION=75

  MEMORY=`perl -ne'/^MemTotal:s+(d+)/ && print $1*1024;'  < /proc/meminfo`
  CPUS=`grep -c processor /proc/cpuinfo`
  SIZE=$(( MEMORY * FRACTION / 100 / CPUS ))

  start(){
  param=`modinfo zram|grep num_devices|cut -f2 -d:|tr -d ' '`
  #modprobe zram $param=$CPUS
# load dependency modules
 # kernels 3.4 onwards
 # if ! modprobe zram num_devices=$CPUS
 # kernels 3.1 - 3.3
 if ! modprobe zram $param=$CPUS
then
 echo -e "Your Kernel needs to be compiled with ZRAM support:"
 "nnDevice Drivers --> Staging Drivers --> Compressed RAM block device support (M)"
 "nDevice Drivers --> Staging Drivers --> Dynamic compression of swap pages and clean pagecache pages (*)"
 "nnThe Liquorix Kernel (http://liquorix.net) has ZRAM support built in."
 exit 1
 fi
 echo "zram devices probed successfully"
  for n in `seq $CPUS`;   do
   i=$((n - 1)) 
   echo $SIZE > /sys/block/zram$i/disksize
   mkswap /dev/zram$i
   swapon /dev/zram$i -p 10
   done
   }
 stop(){
   for n in `seq $CPUS`;  do
   i=$((n - 1))
   swapoff /dev/zram$i && echo "disabled disk $n of $CPUS" &
   done
   wait
   sleep .5
   modprobe -r zram
   }
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
  stop
  sleep 3
  start
  ;;
  *)
  echo "Usage: `basename $0` (start | stop| restart)"
  exit 1
  ;;
   esac

Как вы можете видеть, у ядер версии выше 3.4 немного изменилась опция указания количества ядер, так что я вписал в скрипт обе, что бы была возможность раскоментировать нужную строку в будущем. Итак теперь остается добавить скрипт в автозагрузку

chmod 755 /etc/init.d/zram
chmod +x /etc/init.d/zram
sudo update-rc.d zram defaults
sudo service zram start

Все теперь мы активировали модуль zram и можем почивать на лаврах.

В коллекции планигов 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'
 
# ----------------------------------------------------
 
# Проверяем наличие прав супер пользователя
 Continue Reading 

Виды 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