Оперативная реакция на DDoS-атаки

DDoS-network-mapОдин из ресурсов, за которым я присматриваю, вдруг стал неожиданно популярным как у хороших пользователей, так и у плохих. Мощное, в общем-то, железо перестало справляться с нагрузкой. Софт на сервере самый обычный — Linux, Nginx, PHP-FPM (+APC), MySQL, версии — самые последние. На сайтах крутится Drupal и phpBB. Оптимизация на уровне софта (memcached, индексы в базе, где их не хватало) чуть помогла, но кардинально проблему не решила. А проблема — большое количество запросов, к статике, динамике и особенно базе. Поставил следующие лимиты в Nginx:

на соединения

и скорость запросов на динамику (fastcgi_pass на php-fpm)

Сильно полегчало, по логам видно, что в первую зону никто не попадает, зато вторая отрабатывает по полной.

Но плохиши продолжали долбить, и захотелось их отбрасывать раньше — на уровне фаервола, и надолго.

Сначала сам парсил логи, и особо настырных добавлял через iptables в баню. Потом парсил уже по крону каждые 5 минут. Пробовал fail2ban. Когда понял, что плохишей стало очень много, перенёс их в ipset ip hash.

Почти всё хорошо стало, но есть неприятные моменты:
— парсинг/сортировка логов тоже приличное (процессорное) время отнимает
— сервер тупит, если началась новая волна между соседними разборками (логов)

Нужно было придумать как быстро добавлять нарушителей в черный список. Сначала была идея написать/дописать модуль к Nginx + демон, который будет ipset-ы обновлять. Можно и без демона, но тогда придётся запускать Nginx от рута, что не есть красиво. Написать это реально, но понял, что нет столько времени. Ничего похожего не нашёл (может плохо искал?), и придумал вот такой алгоритм.

При привышении лимита, Nginx выбрасывает 503-юю ошибку Service Temporarily Unavailable. Вот я решил на неё и прицепиться!

Для каждого location создаём свою страничку с ошибкой

И соответствующий именованный location

Дальше интересней.

Нам нужна поддержка CGI-скриптов. Ставим, настраиваем, запускаем spawn-fcgi и fcgiwrap. У меня уже было готовое для collectd.

Сам CGI-скрипт fc

Собственно всё очевидно, кроме, разве что, SQLite. Я его добавил пока просто для статистики, но в принципе можно использовать и для удаления устаревших плохишей из черного списка. Время 5 минут пока тоже не используется.

Черный список создавался вот так

Правило в iptables у каждого может быть своё, в зависимости от конфигурации и фантазии.

З.Ы.: Улыбнуло сообщение одного «хакера» на форуме, как быстро он положил сервер. Он и не догадывался, что это сервер положил на него.

Источник: http://habrahabr.ru/post/176119/

madWiMAX — использование Yota в Linux

madWiMAX — реверс-инжинированный Linux драйвер для устройств доступа к сетям mobile WiMAX (802.16e), выполненных на основе чипа Samsung CMC-730. На данный момент поддерживаются следующие устройства:

  • Samsung SWC-U200
  • Samsung SWC-E100
  • Samsung SWM-S10R

madWiMAX есть в официальном репозитории debian’а.

Настройка йоты проста.

После покупки йота-модема я зарегистрировал его из-под виндовс в личном кабинете, а потом уже сунул в дебиан. Регистрация элементарна и, думаю, что даже из lynx можно было её проделать.

Говорим спасибо Александру Гордееву и остальным разработчикам за madwimax. Говорим спасибо Петру Курышеву за сборку deb пакетов и качаем отсюда http://peter.infosreda.com/ru/2009/03/23/ubuntu-deb-madwimax-0_1_0 два пакета:

и устанавливаем их:

«Для того, чтобы модем автоматически соединялся с сетью Yota при включении в USB разъем, потребуется раскомментировать последние две строчки (их там всего четыре) файла /etc/udev/rules.d/z60_madwimax.rules»

Настроил NAT для людей в локальной сетке. Все вздохнули облегчённо, но было замечено, что многие сайты не открываются. Спасибо http://x4da.wordpress.com/articles/madwimaxiptablesdhcp/ за описание и разрешение проблемы:

«Пришлось добавить

Это правило просто отключает бит DF.»

Была засада — пропал интернет. Запустил на серваке lynx www.rambler.ru и увидел страницу йоты, где было написано про то, что «если вы видите эту страницу, то оплатите…, проверьте…, зарегистрируйте модем…, выньте и всуньте модем…».

Попробовал вынуть/всунуть — помогло. В первый раз, правда, слишком быстро вынул/всунул. Потом попробовал с пару-тройку секундным запозданием и всё заработало.

Вторая засада — при подключении к Йоте по DHCP назначаются новые йотовые DNS, которые прописываются в /etc/resolve.conf. А надо, чтобы доменные оставались, так как есть домен и второй провайдер.

Нагуглил  http://evilzipik.blogspot.com/2009/01/resolvconf-dhcp.html

Чтобы этого не происходило нужно:

в /etc/dhcp3/dhclient-enter-hooks.d/ создать пустой файл, например, nodnsupdate

сделать его исполняемым

в него занести:

И ещё. Когда запускаю madwimax -vv для поиска места с максимальным усилением сигнала, то сыпятся сообщения bulk write error. Поменял USB кабель на толстый экранированный. Эти ошибки пропали.

И ещё. Недавно переустановил на сервере debian x32 на debian amd64. Через какое-то время обнаружил, что не могу зайти в gmail почту через https. Не знаю связаны ли эти события. Уменьшил MTU на интерфейсе своей убунты до йотовских значений — 1386 байт. Почта заработала. (временно для проверки увеличил до 1387 байт — почта перестала работать) Примечательно, что под виндами спокойно вхожу в почту. Только одно предупреждающее сообщение и дальше можно работать. Видимо из-за автоматического определения размера MTU.

2010-09-10. С начала сентября 2010 года йота в ауте. Скорость мизерная. Работать невозможно. Ищу дешёвого проводного провайдера.

2010-11-02. Провайдера нашёл, но и с йотой более-менее разобрался. Запускаю:

и смотрю на значение CINR. Начинаю искать модемом на USB удлинителе максимальное значение CINR. Меньше пяти — плохо. Начиная с 6, 7 — более-менее. 9-10 — хорошо. Это пока максимальное значение достигнутое мной. Значение достигается поворотом модема вокруг вертикальной оси градусов на 45 от оконного стекла и сдвигом его на пару сантиметров влево — вправо около определённой точки на подоконнике.)) Если сигнал есть, но инет тормозной, то передвигаю модем в другую точку на подоконнике, где он цепляется к другой точке доступа. Есть вероятность, что через эту точку доступа инет будет более быстрым.

После испытаний и прерывания Ctrl-C запущенного madwimax -vv, необходимо переткнуть модем, чтобы модем переинициализировался.

Ссылки:

http://peter.infosreda.com/ru/2009/03/23/ubuntu-deb-madwimax-0_1_0
http://x4da.wordpress.com/articles/madwimaxiptablesdhcp/

Маршрутизатор на Debian

При наличии более одного компьютера возникает потребность в организации совместного доступа в интернет. В условиях небольшого офиса или домашней сети подойдут стандартные решения SOHO, но как только количество компьютеров переваливает за 5-10 уже необходимо находить другие решения. Один из вариантов программный роутер с возможностью расширения функций (таких как кэширование, учет трафика, разграничение доступа, резка рекламы и банеров и т.д.). Установка и настройка программного роутера задача не такая уж и сложная, если иметь представление из чего он состоит и как работает. Рассмотрим простейший вариант реализации шлюза.

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

  • операционная система — Debian
  • набор железа — подойдет любой старенький компьютер PIII и выше с двумя сетевыми картами;
  • данные на имеющуюся сеть (провайдер, поставьте свои данные) eth0:

IP адрес: 192.168.10.5
шлюз: 192.168.10.254
DNS: 192.168.10.1

  • данные на внутреннюю локальную сеть (куда будем раздавать интернет) eth1:

IP адрес: 10.0.60.254 (наш новый шлюз)

С параметрами определились, можно начинать устанавливать. Систему ставим минимальную, из задач на сервере нам понадобится только OpenSSH, остальное нет необходимости ставить. Первым делом настроим сетевые интерфейсы, чтоб не сидеть за косолью, а подключиться с рабочей машины и все делать удаленно. Настройки сетевых интерфейсов находятся в файле /etc/network/interfaces, приводим примерно в такой вид, напоминаю, данные необходимо подставить свои.

Перезапускаем сеть, чтоб сделанные изменения вступили в силу.

Немного отредактируем некоторые файлы, чтоб потом все заработало без лишних «танцов с бубнами»

С этого файла кэширующий сервер DNS будет брать настройки. Осталось совсем немного, настроить NAT и DNS. Это только слышать страшно, а делать просто. Для этого установим волшебный пакет — dnsmasq. Dnsmasq является простым в настройке кеширующим DNS и DHCP(опционально) сервером. Разработан специально для применения в небольших, в том числе и домашних сетях, использующих NAT и соединяющихся с Интернет посредством модема, ADSL и прочих вариантов.

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

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

Стоит предупредить, что это самый минимум для раздачи интернета в сеть в таком виде это использовать нельзя! Обязательно нужно защитить порты снаружи, об этом поговорим позже.

Восстановление IP-фона Cisco 7942G

Cisco 7942G мне подарили товарищи по работе, за что им огромное спасибо и уважение! Угораздило же меня прошивать телефон на SIP-прошивку именно в тот момент, как скакнуло напряжение в офисе.. 8(( Телефон сдох.

После различных попыток восстановления телефона, он замолчал и уже не подавал никаких признаков жизни — на экране по появлялось никаких сообщений. Ни по команде 123456789*0#, ни по 3491672850*# восстановить телефон, с помощью местного TFTP-сервера и прошивок на нем, не удалось. (((

Пришлось менять стратегию.

Был запущен отдельный TFTP-сервер на DHCP с раздачей файла по протоколу BOOTP на Debian 5.0.6. Использовалось редкое в России устройство Synertron CV860A, с процессором VIA C3:

  • CPU VIA Eden/C3 376 PIN 1GHz,
  • PLE133 chipset, PC133 SDRAM memory,
  • 3x LANs, 2x Serial ports, 3x USB ports,
  • 50-pin bootable Compact Flash Disk Socket,
  • 1x DOC,
  • 1x 44-pin IDE,
  • and 1x 40-pin IDE.
  •  

    Крайние правые порты (по порядку): eth0 и eth2.

    Решение нашел благодаря статье на официальном сайте — http://www.cisco.com/en/US/ts/fn/620/fn62949.html

    Вот содержание статьи:

    Workaround:

    Cisco recommends that customers stage their Cisco Unified IP Phones before deploying them to users. This allows Network Administrators to ensure:

    — Each phone is upgraded to appropriate firmware releases.

    — Properly configure the phone prior to deploying each phone

    — The phone is assembled with the appropriate cables, handsets and optional headsets.

    While staging the Network Administrator can perform additional activities such as factory resets, apply Dial Numbers and spot check phone functions.

    Solution:

    Cisco recommends the use of Firmware release 8.2(2)SR1 or later releases. This release and later versions are free of this defect. Registered users may obtain this release from the Cisco Unified IP Phone Firmware downloads (registered customers only) page. Select the proper load for your model of IP Phone.

    Recovery of the IP Phone:

    1. Make sure your phones are on a network with a valid DHCP server.
    2. Make sure the DHCP server on this network has a valid Option 150 setting pointing to a valid Cisco TFTP server.
    3. Make sure you have a valid term11.default.loads file from load 8.2(2)SR1 or higher on the TFTP server that is referenced in Option 150.
    4. Make sure you have all other needed image files present on this same TFTP server. * See note below.
    5. Change the timing on the network — the problem is related to timing. Toggle switch port settings between «Auto» and «100Mbps.» On a Cisco switch the command to toggle the switch port switch:

      Wait 10 minutes, or until all the phones have been updated, then issue the following command if desired to return to original configuration:

      Ensure that items 1 through 5 have been completed. If performing these five steps does not resolve the issue, continue with the remaining steps.
    6. Pull power on the phone (even if power is PoE).
    7. Hold down the # key on the phone.
    8. Continue holding down the # key and re-apply power.
    9. While still holding the # key wait for the Message Waiting Indicator (MWI) light on the handset to start flashing.
    10. Once the MWI light is flashing, release the # key and enter the following sequence exactly on the keypad:3491672850*#Once this sequence has been entered on the IP Phone, if all the network criteria above have been met, it should begin its recovery process. This process can take up to 15 minutes to finish. The phone may appear to be doing nothing during this time. However, if the phone does not recover after 20 minutes then it is possible that the recovery is stuck. In this case, re-examine your network and verify that steps 1-4 are in place, then re-issue the factory reset sequence.

    * Note: The factory reset sequence is a way for a phone to clear flash and still upload to a valid firmware image. This is facilitated by the termxx.default.loads file, but requires that the image files listed in the termxx.default.loads file are available in TFTP for the phone to download. Open the termxx.default.loads file in any text editor. This loads file is essentially just a packing list showing all the OS and application files the phone needs to function. The files include a cnu, cvm, dsp, app and jar files. Please make sure that these files as listed in the termxx.default.loads file are in TFTP. («xx» will be either «06» for the CP-7906G model, or «11» for the CP-7911G model.)

    Additional Diagnostic Steps:

    — Try a hard-coded IP address as a test to see if this resolves the upgrade failures. If it does, and the number of failing IP Phones is relatively few, this procedure may be the most expedient. After the IP Phone upgrades successfully, reconfigure the IP Phone to use DHCP.

    — Try putting the phone on a hub or a different switch and see if this helps change the startup timing enough so that the upgrade completes successfully.

    ***

    Основная проблема возникла в пунктах 1-4, — не сразу удалось подобрать подходящую конфигурацию и заставить ее работать, ниже описываю положительный опыт создания такой конфигурации.

    Первоначально пытался прописать DHCP option 150 на сервере Windows 2003 Server (позже подготовлю статью по этой теме), однако сразу не завелось, потому перешел на Debian.

    IP-фон с помощью порта 10/100SW был подключен к свитчу, свитч подключен к серверу в порт eth0 (192.168.100.0/24), порт eth2 сервера (192.168.0.0/24) через еще один роутер, был подключен к интернету.

    Итак, после установки операционной системы, был установлен TFTP-сервер:

    Устанавливаем DHCP-сервер:

     

    Настройки DHCP-клиента:

    Файл /etc/defaults/dhcp3-server:

    Настройки сети:

    Перезапуск сетевых настроек:

    Перезапуск DHCP-сервера:

    Для пропуска трафика из подсети 192.168.0.0 в сеть 192.168.100.0, настраиваем NAT на IPtables, делаем скрипт ~/fw.start:

    И запускаем его:

    После этого трафик из сети 192.168.0.0 будет доступен и в 192.168.100.0.

    Результаты работы проверяю с помощью tshark:

    После всех манипуляций перезагружаем IP-фон, как описано в статье в пункте 10:

    1. Зажимаем #.
    2. Отключаем питание.
    3. После того, как начинают мигать кнопки Line отжимаем #.
    4. Набираем комбинацию 3491672850*# и ждем, пока с TFTP-сервера пойдет трафик в телефон.

    На TFTP-сервере были размещены файлы одной из ранних прошивок:

    dialplan.xml:

    SEPB8BEBF22BE05.cnf.xml (конфиг-файл от более поздней прошивки):

    XMLDefault.cnf.xml:

    и пустой файл: CTLSEPB8BEBF22BE05.tlv

     

    🙂

    После всего этого, телефон восстановился.

    Предстоит еще обновить прошивку с 8.5.2 до минимум 8.5.4 (для благополучно работы Cisco 7942 с Asterisk 1.4.39 у нас в конторе). Но это уже другая история.

     

    iptables and kernel :) (for beginners)

    To quote the iptables homepage

    iptables is the userspace command line program used to configure the Linux 2.4.x and 2.6.x IPv4 packet filtering ruleset. It is targeted towards system administrators.

    In order to run iptables on the WARP, there are two things required. It must be enabled in the kernel and you need the user space libraries from www.netfilter.org. Both of these things must be completed to get it to run.

    iptables – kernel portion

    IP Tables is available in our kernel. You can enable it through the ‘Target Architecture Configuration (Custom Kernel Options)’ option in the main page of menuconfig. To invoke the ‘custom kernel’ selection menu when you run ‘make’ here is a little trick.

    1) go to the /build_warp/linux
    2) do a ‘ls- al’ —> you should see a ‘.configured’ file – please remove this file
    3) run ‘make menuconfig’ from your main PADS checkout directory > select the second item ‘Target Arch Configuration (Custom Kernel Options)’ from the menu. Select ‘Custom Kernel Options’ from the next menu. Save this configuration.
    4) Upon your next ‘make’ you should be presented with a new menu (’custom kernel’) where you can select which kernel modules you would like to add.
    Of interest to you will be:
    > Linux Kernel Configuration
    -> Networking
    –> Networking Options
    —> Network packet filtering framework (Netfilter)
    —-> IP: Netfilter Configuration

    You will also see there is many other available kernel options available however I would recommend being selective as each of this options has the potential to have undesirable consequences.

    iptables – user mode

    The package for the user mode libraries is available from the PIKA extra_packages SVN repository here. In order to compile this, just check it out into your packages directory in PADS and do a make iptables in the root of your PADS directory. There are sometimes issues with this cross compiled version not accepting all commands. If you run into this issue, you can try the precompiled version below.

    iptables – binary – user mode

    The package for the pre-compiled version of the user mode libraries is available from the PIKA extra_packages SVN repository here. In order to install this, just check it out into your packages directory in PADS and do a make iptables-binary in the root of your PADS directory.

    If you need assistance with configuring iptables, I suggest you read the man pages that come with it.

    ——

    Here is the kernel configuration suggested to me by a colleague of mine as a starting point (thanks Sean). It provides routing and firewall capabilities. Instead of selecting options through ‘menuconfig > Linux Kernel Configuration’ you can also simply modify the ‘/package/linux/linux-config’ file in PADS and rebuild.
    CONFIG_NETFILTER=y
    CONFIG_NETFILTER_ADVANCED=y
    CONFIG_NF_CONNTRACK=m
    CONFIG_NF_CONNTRACK_FTP=m
    CONFIG_NETFILTER_XTABLES=m
    CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
    CONFIG_NETFILTER_XT_MATCH_STATE=m
    CONFIG_NF_DEFRAG_IPV4=m
    CONFIG_NF_CONNTRACK_IPV4=m
    CONFIG_NF_CONNTRACK_PROC_COMPAT=y
    CONFIG_IP_NF_IPTABLES=m
    CONFIG_IP_NF_FILTER=m
    CONFIG_IP_NF_TARGET_REJECT=m
    CONFIG_IP_NF_TARGET_LOG=m
    CONFIG_IP_NF_TARGET_ULOG=m
    CONFIG_NF_NAT=m
    CONFIG_NF_NAT_NEEDED=y
    CONFIG_IP_NF_TARGET_MASQUERADE=m
    CONFIG_IP_NF_TARGET_REDIRECT=m
    CONFIG_NF_NAT_FTP=m
    CONFIG_IP_NF_MANGLE=m

    Защищаем сервер Asterisk с помощью fail2ban

    Итак, пришло время поговорить о защите. На написание поста меня сподвигла атака из США жестким брутом. Дело было так, я зашел на сервер оптимизировать конфиг users.conf(Об этом в следующей статье). После правки файла, я благополучно зашел в консоль Asterisk и увидел кучу сообщений (примерно 5 раз в секунду) о том, что с такого-то IP попытка зайти под пользователем 104. Меня это сначала смутило. А потом я решил поставить fail2ban, чтобы обезопасить себя. Итак, статья в моем стиле — поэтому никакой лишней инфы не будет, только то что нужно чтобы закрыть доступ для атакующего IP. Защищать будем Asterisk, ну и бонусом SSH.

    Шаг 1. Установка fail2ban.

    Шаг 2. Установка python и iptables. Возможно вам понадобиться установить эти пакеты, поэтому

    Шаг 3. Конфигурация fail2ban. Итак, займемся конфигурацией. Для этого перейдем в каталог /etc/fail2ban/filter.d.

    Создаем новый фильтр:

    Содержимое файла /etc/fail2ban/filter.d/asterisk.conf должно быть примерно таким:

    Шаг 4. Редактируем /etc/fail2ban/jail.conf. В конец файла добавляем следующее содержимое:

    Шаг 5. Логирование Asterisk. Открываем /etc/asterisk/logger.conf и раскомментируем:

    В консоли перегружаем сервис логирования:

    Шаг 6. Запуск.

    Проверим:

    Должно появиться что то типа этого:

    Шаг 7. Автозапуск fail2ban и iptables:

    http://www.fail2ban.org/wiki/index.php/Asterisk

    http://www.voip-info.org/wiki/view/Fail2Ban+%28with+iptables%29+And+Asterisk

    Force iptables to log messages to a different log file

    According to man page:
    Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. Several different tables may be defined. Each table contains a number of built-in chains and may also contain user defined chains.

    By default, Iptables log message to a /var/log/messages file. However you can change this location. I will show you how to create a new logfile called /var/log/iptables.log. Changing or using a new file allows you to create better statistics and/or allows you to analyze the attacks.

    Iptables default log file

    For example, if you type the following command, it will display current iptables log from /var/log/messages file:
    # tail -f /var/log/messages
    Output:

    Procedure to log the iptables messages to a different log file

    Open your /etc/syslog.conf file:
    # vi /etc/syslog.conf
    Append following line
    kern.warning /var/log/iptables.log
    Save and close the file.

    Restart the syslogd (Debian / Ubuntu Linux):# /etc/init.d/sysklogd restartOn the other hand, use following command to restart syslogd under Red Hat/Cent OS/Fedora Core Linux:# /etc/init.d/syslog restart

    Now make sure you pass the log-level 4 option with log-prefix to iptables. For example:
    # DROP everything and Log it
    iptables -A INPUT -j LOG --log-level 4
    iptables -A INPUT -j DROP

    For example, drop and log all connections from IP address 64.55.11.2 to your /var/log/iptables.log file:
    iptables -A INPUT -s 64.55.11.2 -m limit --limit 5/m --limit-burst 7 -j LOG --log-prefix '** HACKERS **'--log-level 4
    iptables -A INPUT -s 64.55.11.2 -j DROP

    Where,

    • —log-level 4: Level of logging. The level # 4 is for warning.
    • —log-prefix ‘*** TEXT ***’: Prefix log messages with the specified prefix (TEXT); up to 29 letters long, and useful for distinguishing messages in the logs.

    You can now see all iptables message logged to /var/log/iptables.log file:
    # tail -f /var/log/iptables.log

    Updated for accuracy.

    Iptables производительность

    Низкая производительность роутера может быть связанна с некорректными настройками iptables.

    Первое, что Вам необходимо сделать если на роутере нет NAT — отключить connection tracking делается это в таблице nat цепочка PREROUTING.

    *raw
    -A PREROUTING -j NOTRACK
    COMMIT

    Имейте ввиду, что если у Вас используются правила iptables с использованием модуля match, то Вам придется отказаться от их использования, также у Вас перестанут работать правила использующие conntrack таблицу.

    Следующее проверить какие правила iptables отрабатываются чаще всего, и поставить их первыми. Посмотреть какие правила срабатывают чаще всего можно так:

    iptables -L -n -v

    В iptables правила проверяются линейно по очереди и каждый сетевой пакет будет проходить через всю цепочку правил до первого срабатывания условия, если правил слишком много, то это будет сильно нагружать ЦП роутера. Один из выходов из данной ситуации приведен ниже.

    Пример:
    Допустим есть сеть домового провайдера. Количество клиентов порядка 10000. При блокировании клиента он блокируется в правилах iptables. На текущий момент заблокированно 2000 клиентов, т. е. в iptables 2000 правил для пакетного фильтра типа:

    -A FORWARD -s 192.168.0.1 -j DROP
    -A FORWARD -s 192.168.0.2 -j DROP
    -A FORWARD -s 192.168.0.3 -j DROP
    --/ И так дальше/--
    -A FORWARD -s 192.168.1.1 -j DROP
    -A FORWARD -s 192.168.1.2 -j DROP
    -A FORWARD -s 192.168.1.3 -j DROP
    --/ И так дальше/--
    -A FORWARD -s 192.168.2.1 -j DROP
    -A FORWARD -s 192.168.2.2 -j DROP
    -A FORWARD -s 192.168.2.3 -j DROP
    --/ И так дальше/--
    -A FORWARD -s 192.168.7.1 -j DROP
    -A FORWARD -s 192.168.7.2 -j DROP
    -A FORWARD -s 192.168.7.254 -j DROP
    # Всех остальных пропускаем
    -A FORWARD -j ACCEPT

    т.е. для того чтобы проверить пропустить или заблокировать пакеты от машины 192.168.8.254 будет произведено 2000 проверок в правилах iptables . ЭТО УЖАСНО. При интенсивном сетевом обмене ни о какой производительности речи быть не может.

    Перепишем данные правила следующим образом:

    -A FORWARD -s 192.168.0.0/24 -j NET-00
    -A FORWARD -s 192.168.1.0/24 -j NET-01
    -A FORWARD -s 192.168.2.0/24 -j NET-02
    -A FORWARD -s 192.168.3.0/24 -j NET-03
    -A FORWARD -s 192.168.4.0/24 -j NET-04
    -A FORWARD -s 192.168.5.0/24 -j NET-05
    -A FORWARD -s 192.168.6.0/24 -j NET-06
    -A FORWARD -s 192.168.7.0/24 -j NET-07
    //
    -A NET-00 -s 192.168.0.1 -j DROP
    -A NET-00 -s 192.168.0.2 -j DROP
    -A NET-00 -s 192.168.0.3 -j DROP
    --/ И так дальше/--
    -A NET-01 -s 192.168.1.1 -j DROP
    -A NET-01 -s 192.168.1.2 -j DROP
    -A NET-01 -s 192.168.1.3 -j DROP
    --/ И так дальше/--
    -A NET-07 -s 192.168.7.1 -j DROP
    -A NET-07 -s 192.168.7.2 -j DROP
    -A NET-07 -s 192.168.7.3 -j DROP
    -A FORWARD -j ACCEPT

    В наших новых правилах для аналогичной проверки необходимо 255 проверок, итак немного модифицировав правила для iptables мы сократили количество проверок в пакетном фильтре в 4 раза.

    Еще одним способом избавиться от узкого места в iptables – использовать ipset.

    http://centos.alt.ru/?p=32

    NAT производительность

    Решил выяснить сколько трафика сможет занатить один Linux сервер, какая нагрузка будет при этом на CPU.

    Выяснилось, что при одном и том, же сетевом трафике, но разном количестве пакетов нагрузка на CPU будет разная, что совершенно логично.

    Приведу тестовые данные:

    Итак тестовая система:
    Однопроцессорный четырехядерный сервер Intel(R) Xeon(R) CPU E5405 2.00GHz
    Сетевые адаптеры Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz
    ОС CentOS 5.4

    Правила для iptables простые /etc/sysconfig/iptables


    *filter
    :INPUT DROP [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT DROP [0:0]

    COMMIT

    *nat

    -A POSTROUTING -o eth0 -s 172.16.1.0/24 -j SNAT --to 192.168.0.1
    -A POSTROUTING -o eth0 -s 172.16.2.0/24 -j SNAT --to 192.168.0.2
    -A POSTROUTING -o eth0 -s 172.16.3.0/24 -j SNAT --to 192.168.0.3
    --//--
    -A POSTROUTING -o eth0 -s 172.16.254.0/24 -j SNAT --to 192.168.0.254

    COMMIT

    Пропустим через сервер трафик порядка 100 мегабит:

    Входящий 90-100 мбит/с
    Исходящий 50-60 мбит/с

    Посмотрим количество пакетов:

    vnstat -tr 15 -i eth0
    409452 packets sampled in 15 seconds
    Traffic average for eth0

    rx 11291.52 kB/s 14072 packets/s
    tx 5771.39 kB/s 13223 packets/s

    Нагрузка на процессоры:

    Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 91.0%id, 0.0%wa, 1.7%hi, 7.3%si, 0.0%st
    Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 88.3%id, 0.0%wa, 3.7%hi, 8.0%si, 0.0%st

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

    sysctl -a | grep ip_conntrack_count
    net.ipv4.netfilter.ip_conntrack_count = 65405

    Как видим нагрузка на каждый из процессоров всего в районе 7-8 процентов.

    Увеличим трафик проходящий через сервер трафик до 200 мбит/с посмотрим как изменится картина

    Трафик на обоих сетевых интерфейсах:
    Входящий 200-230 мбит/с
    Исходящий 130-150 мбит/с


    vnstat -tr 15 -i eth0
    873819 packets sampled in 15 seconds
    Traffic average for eth0

    rx 22922.61 kB/s 29719 packets/s
    tx 14199.36 kB/s 28535 packets/s

    Нагрузка на CPU

    Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 68.0%id, 0.0%wa, 2.3%hi, 29.7%si, 0.0%st
    Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 60.0%id, 0.0%wa, 4.7%hi, 35.0%si, 0.0%st

    Увеличим трафик проходящий через сервер трафик до 350 мбит/с посмотрим как изменится картина

    Трафик на обоих сетевых интерфейсах:
    Входящий 350-370 мбит/с
    Исходящий 190-210 мбит/с


    vnstat -tr 15 -i eth0
    1475987 packets sampled in 15 seconds
    Traffic average for eth0

    rx 37181.86 kB/s 49891 packets/s
    tx 20991.49 kB/s 48507 packets/s

    Нагрузка на CPU

    Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 37.9%id, 0.0%wa, 1.7%hi, 60.5%si, 0.0%st
    Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 19.5%id, 0.0%wa, 5.3%hi, 75.2%si, 0.0%st

    Количество сетевых соединений

    sysctl -a | grep ip_conntrack_count
    net.ipv4.netfilter.ip_conntrack_count = 215402

    Ну вот в принципе и все, как видим, даже обычный сервер в состоянии «заNATить» порядка 400 мегабит трафика.

    Использование ipset

    Появилась задача: блокировать доступ некоторому списку пользователей доступ в сеть Internet, трафик пользователей проходит через софтварный (программный) Linux маршрутизатор (роутер).

    Первая мысль — блокировать в iptables. Мысль это безусловна верная, но при большом количестве правил, это будет создавать излишнюю нагрузку на CPU. Так например линейный список из 1000 правил убьет производительность роутера под нуль.

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

    Выход был найден – ipset.

    Установка ipset для CentOS i386 занимает 1 минуту:

    Подключаем CentALT:

    rpm -ihv http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
    rpm -ihv http://centos.alt.ru/repository/centos/5/i386/centalt-release-5-3.noarch.rpm

    Устанавливаем нужные пакеты:

    yum install ipset kmod-ipset

    Обновляем iptables — пересобран штатный для CentOS iptables, только добавлен модуль SET.

    yum update iptables

    Создаем файл /etc/ipset.conf в который будем писать ip которым запрещен доступ следующего содержания

    #!/bin/bash

    # Создаем новую цепочку правил
    ipset -N access iphash
    # добавляем список доступа
    ipset -A access 192.168.0.2
    ipset -A access 192.168.0.3
    ipset -A access 192.168.0.4

    добавляем в автоматический запуск в файл /etc/rc.d/rc.local
    добавляем последней строку
    /bin/bash /etc/ipset.conf

    Затем добавляем в /etc/sysconfig/iptables единственную строку которая закроет доступ всем ip адресам из выше приведенного списка

    -A FORWARD -m set --set access src -j DROP

    перегружаем правила iptables

    service iptables restart

    Все.

    Переход от блокировки в iptables на блокировку в ipset снизил нагрузку на систему более чем в 2 раза при количестве правил >1000, сетевой трафик проходящий через роутер в районе 100 kpps.

    Подобным образом можно успешно защищаться от простейших DDOS атак.

    http://centos.alt.ru/?p=402