Оперативная реакция на 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.

Прозрачное проксирование с помощью netfilter, iproute2, ipchains и squid

Этот раздел написал Рэм Нарул (Ram Narula), из «Internet for Education» (Таиланд).

Прозрачное проксирование — это обычное перенаправление серверу squid трафика, отправляемого на порт 80 (web).

Существует 3 общеизвестных способа такого перенаправления:

Шлюз.
Вы можете настроить шлюз таким образом, что он будет перенапрвлять все пакеты, адресованные на порт 80, сереверу squid

НО

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

Layer 4 switch
Свичи выполняют такое перенаправление без особых проблем.

НО

Стоимость этого оборудования очень высока и может быть сопоставима с ценой связки «обычный роутер» + «Linux-сервер»

Использовать кэш-сервер в качестве шлюза.
Вы можете отправить ВЕСЬ трафик через кэш-сервер.

НО

Это довольно рисковано, поскольку squid довольно значительно нагружает CPU, что может привести к снижению производительности сети. Кроме того, squid может «рухнуть» и тогда никто из сети не сможет выйти в Интернет.

Мы предлагаем 4-й вариант:
Linux+NetFilter.
Эта методика предполагает установку меток на пакеты, с портом назначения равным числу 80, и дальнейшая маршрутизация помеченных пакетов, с помощью iproute2, на squid.

|—————-|
| Реализация |
|—————-|

Используемые адреса
10.0.0.1 naret (NetFilter)
10.0.0.2 silom (Squid)
10.0.0.3 donmuang (Router, соединенный с Интернет)
10.0.0.4 kaosarn (некий сервер в сети)
10.0.0.5 RAS
10.0.0.0/24 main network
10.0.0.0/19 total network

|—————|
|Структура сети |
|—————|

Internet
|
donmuang
|
————hub/switch———-
| | | |
naret silom kaosarn RAS etc.

Прежде всего — весь трафик должен идти через naret, для этого на всех компьютерах пропишем его в качестве шлюза по-умолчанию. Исключение составляет silom, для которого шлюз по-умолчанию — donmuang (в противном случае web-трафик зациклится).
(на всех компьютерах в моей сети был прописан шлюз по-умолчанию — 10.0.0.1, который ранее принадлежал donmuang, поэтому я изменил IP-адрес у donmuang на 10.0.0.3, а серверу naret присвоил адрес 10.0.0.1)

Silom
——
-настройка squid и ipchains

Настройте прокси-сервер squid на silom. Убедитесь, что он поддерживает прозрачное проксирование. Обычно прокси-серверу, для приема запросов от пользователей, назначают порт 3128, поэтому весь трафик, отправляемый на порт 80 будет перенаправлен на порт 3128. С помощью ipchains это делают следующие правила:
silom# ipchains -N allow1
silom# ipchains -A allow1 -p TCP -s 10.0.0.0/19 -d 0/0 80 -j REDIRECT 3128
silom# ipchains -I input -j allow1

iptables:
silom# iptables -t nat -A PREROUTING -i eth0 -p tcp —dport 80 -j REDIRECT —to-port 3128

За информацией по настройке сервера squid, обращайтесь на http://squid.nlanr.net/.
Убедитесь, что на этом сервере разрешен форвардинг, и заданный по умолчанию шлюз для него — donmuang (НЕ naret!).

Naret
——
-настройка iptables и iproute2
-запрет ICMP-сообщений о перенаправлении (если необходимо)

Пометить пакеты, с портом назначения 80, числовой меткой 2.

naret# iptables -A PREROUTING -i eth0 -t mangle -p tcp —dport 80 \
-j MARK —set-mark 2

Настроить маршрутизацию так, чтобы помеченные пакеты отправлялись на silom

naret# echo 202 www.out >> /etc/iproute2/rt_tables
naret# ip rule add fwmark 2 table www.out
naret# ip route add default via 10.0.0.2 dev eth0 table www.out
naret# ip route flush cache

Если donmuang и naret находятся в одной подсети, то naret не должен выдавать ICMP-сообщения о перенаправлении. Запрет можно наложить так:
naret# echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects

На этом настройку можно считать завершенной. Проверим конфигурацию

Для naret:

naret# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK tcp — anywhere anywhere tcp dpt:www MARK set 0x2

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

naret# ip rule ls
0: from all lookup local
32765: from all fwmark 2 lookup www.out
32766: from all lookup main
32767: from all lookup default

naret# ip route list table www.out
default via 203.114.224.8 dev eth0

naret# ip route
10.0.0.1 dev eth0 scope link
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1
127.0.0.0/8 dev lo scope link
default via 10.0.0.3 dev eth0

|——-|
|-КОНЕЦ-|
|——-|

15.5.1. Схема движения пакетов после настройки.

|——————————————|
| Схема движения пакетов |
|——————————————|

ИНТЕРНЕТ
/\
||
\/
———————donmuang————————
/\ /\ ||
|| || ||
|| \/ ||
naret silom ||
*destination port 80 ================>(cache) ||
/\ || ||
|| \/ \/
\\===================================kaosarn, RAS, и пр.

Обратите внимание, в данном случае сеть получилась асимметричной, т.е. добавился один лишний переход для исходящих пакетов.
Ниже приводится путь, проделываемый пакетами в/из Интернет для компьютера kaosarn.

Для web/http трафика:

kaosarn http request->naret->silom->donmuang->internet
http replies from Internet->donmuang->silom->kaosarn

Для прочего трафика:
kaosarn outgoing data->naret->donmuang->internet
incoming data from Internet->donmuang->kaosarn

http://docstore.mik.ua/manuals/ru/LARTC/x2540.html

Решение проблемы с Path MTU Discovery путем настройки MTU/MSS

Общеизвестно, что скорость передачи данных возрастает с увеличением размера пакета. Это вполне естественно, ведь для каждого пакета в потоке принимается решение о выборе маршрута. К примеру, файл, размером в 1 мегабайт, будет передан быстрее, если он будет разбит на 700 пакетов (при максимальном размере пакета), а не на 4000.

Однако, не все сегменты Интернет могут передавать пакеты, с максимальной полезной нагрузкой в 1460 байт. Поэтому необходимо найти такой размер, который будет максимально возможным для заданного маршрута.

Процесс поиска такого размера называется ‘Path MTU Discovery’ (Поиск Максимального Размера Пакета для выбранного Пути), где MTU означает ‘Maximum Transfer Unit’ (Максимальный Размер Блока передачи данных).

Когда на маршрутизатор поступает пакет, который не может быть передан по выбранному маршруту целиком (без фрагментации) И у него установлен флаг «Don’t Fragment» (Не фрагментировать), то в ответ отправляется ICMP-сообщение о том, что пакет был сброшен из-за невозможности «протолкнуть» его по выбранному маршруту. Компьютер, выполнивший посылку, начинает последовательно уменьшать размер пакетов до тех пор, пока они не смогут быть переданы по выбранному маршруту.

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

В результате таких действий процесс поиска оптимального размера пакета работает все хуже и хуже, а на некоторых маршрутизаторах вообще не работает, что в свою очередь порождает сеансы TCP/IP с весьма странным поведением, которые «умирают» спустя некоторое время.

Хотя у меня нет никаких доказательств, но я знаю по крайней мере два сайта, с которыми наблюдается подобная проблема и перед обоими стоит Alteon Acedirectors — возможно кто-то имеет более богатый опыт и сможет подсказать как и почему это происходит.

15.6.1. Решение

Если вы столкнетесь с подобной проблемой, то можно посоветовать отключить ‘Path MTU Discovery’ и установить MTU вручную. Koos van den Hout пишет:

У меня возникла следующая проблема: для арендованного мною канала, работающего через ppp, на скорости 33.6К, я установил величину MTU/MRU, равную 296. Это дает мне достаточно приемлемое время отклика.

Со моей стороны установлен роутер (с маскарадингом), работающий под управлением Linux.

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

После этого возникла масса проблем с авторизацией в irc. В процессе длительных поисков я установил, что само соединение проходит и даже показывается системой как ‘connected’, но я не получал motd от irc (motd — от англ. Message of The Day, которое демонстрируется после успешной авторизации, прим. перев.). Кроме того, помятуя о проблеме, связанной с MTU, я определил, что проблема исчезала только в том случае, когда MTU устанавливался равным 296. А так как серверы irc блокируют весь трафик, который напрямую не связан с их работой, то в числе блокируемых оказался и ICMP.

Мне удалось убедить администратора WEB-сервера в истинных причинах возникновения проблем, но администратор IRC-сервера отказался устранять их.

Таким образом, передо мной встала необходимость уменьшить MTU для внешнего трафика и оставить нормальное значение для локального.

Решение:

(10.0.0.1 — шлюз по-умолчанию, внутренний адрес маршрутизатора с маскарадингом)
Вообще, можно запретить ‘PMTU Discovery’ путем настройки специфических маршрутов. Например, если проблемы наблюдаются только с определенной подсетью, то это должно помочь:

Как уже говорилось выше, Path MTU Discovery не работает в Интернет должным образом. Если вам известны факты существования сегментов в вашей сети, где размер MTU ограничен, то вы уже не можете полагаться на безотказную работу Path MTU Discovery.

Однако, помимо MTU, есть еще один способ ограничения размера пакета — это, так называемый MSS (Maximum Segment Size — Максимальный Размер Сегмента). MSS — это поле в заголовке TCP-пакета SYN.

С недавних пор, ядра Linux и некоторые драйверы PPPoE, стали поддерживать такую особенность, как ‘clamp the MSS’ (ограничение размера MSS).

В этом есть свои плюсы и минусы. С одной стороны, устанавливая MSS, вы недвусмысленно извещаете удаленную сторону о том, что размер пакета не должен превышать заданную величину. Причем для этого не требуется передачи ICMP-сообщений.

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

Чтобы иметь возможность манипулировать размером сегмента, у вас должны быть установлены iptables, не ниже 1.2.1a и ядро Linux, не ниже 2.4.3. Основная команда iptables:

Она рассчитает правильный MSS для вашего соединения. Если вы достаточно уверены в себе и в своих знаниях, можете попробовать нечто подобное:

Это правило устанавливает MSS равным 128. Очень полезно, если вы наблюдаете разрывы при передаче голосовых данных, когда поток небольших пакетов VoIP прерывается «огромными» http-пакетами.

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