Увеличиваем размер conntrack таблицы в CentOS Linux

Многие системные администраторы сталкивались с проблемой, когда количество сетевых соединений с сервером велико, происходит переполнение conntrack таблицы, из-за чего новые соединения не обрабатываются сервером.

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

localhost kernel: ip_conntrack: table full, dropping packet.

Увеличить размер conntrack таблицы можно через sysctl.

Размер conntrack таблицы во многих дистрибутивах составляет всего 65536 записей.

В CentOS 5 посмотреть текущее значение можно так:

sysctl -a|grep net.ipv4.netfilter.ip_conntrack_max

Увеличить значение можно через файл /etc/sysctl.conf внеся туда строку:

net.ipv4.netfilter.ip_conntrack_max = НОВОЕ_ЗНАЧЕНИЕ

и заставив систему перечитать изменения:
sysctl -p

Посмотреть сколько в данный момент записей в conntrack таблице можно так:
sysctl -a|grep net.ipv4.netfilter.ip_conntrack_count

В литературе нигде не указываются рекомендованные параметры данной переменной, мои рекомендации следующие:

Если у Вас нет нехватки оперативной памяти на сервере, то установите значение переменой net.ipv4.netfilter.ip_conntrack_max в 1 миллион записей, и отслеживайте значения количества соединений, постепенно уменьшая значение даной переменной до значения (Максимльное количество соединений) +30%.

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

localhost kernel: Out of Memory:

и получить в итоге неуправляемую систему.

P.S.В дистрибутивах с новыми ядрами (>2.6.20) параметры задающие максимальное количество записей в conntrack таблице называются
net.netfilter.nf_conntrack_max и net.nf_conntrack_max

Исчерпывающая информация о conntrack находится здесь

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

BGP4+Zebra

Версия 4 Протокола Пограничных Маршрутизаторов (BGP4) — это протокол динамический маршрутизации, описанный в RFC 1771. Он предназначен для обмена информацией (т.е. таблицами маршрутизации) между маршрутизаторами, с целью обеспечить согласующееся представление о данной Автономной Системе (Autonomous System — AS). Может использоваться в режиме EGP (от англ. Exterior Gateway Protocol — Протокол Внешних Маршрутизаторов) или IGP (от англ. Interior Gateway Protocol — Протокол Внутренних Маршрутизаторов). В случае EGP — требуется, чтобы каждый из узлов сети имел свой собственный номер Автономной Системы (AS). BGP4 поддерживает Безклассовую Внутридоменную Маршрутизацию (Classless Inter Domain Routing — CIDR) и объединение маршрутов (объединение нескольких маршрутов в один).

Конфигурация сети (пример)

Последующие примеры будем рассматривать на основе конфигурации сети, которая приведена ниже. AS 1 и 50 имеют еще ряд «соседей», но мы будем рассматривать только эти две Автономные Системы, в качестве своих «соседей». Взаимодействие между сетями, в данном примере, производится через туннели, но в общем случае это не обязательно.

В данном примере используются зарезервированные номера AS, поэтому вы должны будете подставить свои собственные числа.
          --------------------
          | 192.168.23.12/24 |
          |    AS: 23        |
          --------------------
            /             \
           /               \
          /                 \
------------------       ------------------
| 192.168.1.1/24 |-------| 10.10.1.1/16   |
|    AS: 1       |       |    AS: 50      |
------------------       ------------------

Конфигурирование (пример)

Следующая конфигурация написана для узла 192.168.23.12/24, но может быть с легкостью адаптирована и для других узлов.

Начинается с установки некоторых общих параметров, таких как: имя хоста, пароль и ключи отладки:

! имя хоста
hostname anakin

! пароль
password xxx

! разрешить пароль (режим суперпользователя)
enable password xxx

! путь к файлу журнала
log file /var/log/zebra/bgpd.log

! отладка: выводить отладочную информацию (этот раздел позднее может быть удален)
debug bgp events
debug bgp filters
debug bgp fsm
debug bgp keepalives
debug bgp updates

Список доступа, используемый для ограничения перераспределения в локальных сетях (RFC 1918).

! RFC 1918 networks
access-list local_nets permit 192.168.0.0/16
access-list local_nets permit 172.16.0.0/12
access-list local_nets permit 10.0.0.0/8
access-list local_nets deny any

Следующий шаг — настройка каждой из AS:

! Собственный номер AS
router bgp 23

    ! IP-адрес маршрутизатора
    bgp router-id 192.168.23.12

    ! наша сеть, для оповещения "соседей"
    network 192.168.23.0/24

    ! объявлять о всех подключенных маршрутах (= непосредственно подключенных интерфейсах)
    redistribute connected

    ! объявлять о корневых маршрутах (= подставленных вручную)
    redistribute kernel

Блок «router bgp» должен содержать сведения о своих «соседях»:

neighbor 192.168.1.1 remote-as 1
neighbor 192.168.1.1 distribute-list local_nets in
neighbor 10.10.1.1   remote-as 50
neighbor 10.10.1.1   distribute-list local_nets in

Проверка конфигурации

vtysh — это мультиплексор, соединяющий все интерфейсы Zebra.
anakin# sh ip bgp summary 

BGP router identifier 192.168.23.12, local AS number 23
2 BGP AS-PATH entries
0 BGP community entries

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.0.1       4    50      35      40        0    0    0 00:28:40        1
192.168.1.1     4     1   27574   27644        0    0    0 03:26:04       14

Total number of neighbors 2
anakin#
anakin# sh ip bgp neighbors 10.10.0.1
BGP neighbor is 10.10.0.1, remote AS 50, local AS 23, external link
  BGP version 4, remote router ID 10.10.0.1
  BGP state = Established, up for 00:29:01
  ....
anakin#

А теперь посмотрим — какие маршруты были полученв от «соседей»:

anakin# sh ip ro bgp
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       B - BGP, > - selected route, * - FIB route

B>* 172.16.0.0/14 [20/0] via 192.168.1.1, tun0, 2d10h19m
B>* 172.30.0.0/16 [20/0] via 192.168.1.1, tun0, 10:09:24
B>* 192.168.5.10/32 [20/0] via 192.168.1.1, tun0, 2d10h27m
B>* 192.168.5.26/32 [20/0] via 192.168.1.1, tun0, 10:09:24
B>* 192.168.5.36/32 [20/0] via 192.168.1.1, tun0, 2d10h19m
B>* 192.168.17.0/24 [20/0] via 192.168.1.1, tun0, 3d05h07m
B>* 192.168.17.1/32 [20/0] via 192.168.1.1, tun0, 3d05h07m
B>* 192.168.32.0/24 [20/0] via 192.168.1.1, tun0, 2d10h27m
anakin#

OSPF+Zebra

Пожалуйста, дайте мне знать — насколько верна следующая информация, а так же присылайте ваши предложения, комментарии. Zebra — большой программный пакет динамической маршрутизации, который разработали Кунихиро Ишигуро (Kunihiro Ishiguro), Тошиаки Такеда (Toshiaki Takada) и Ясахиро Охара (Yasuhiro Ohara). С помощью Zebra вы легко и быстро сможете настроить OSPF, но на практике, при настройке протокола под весьма специфические потребности, вы столкнетесь со значительным числом параметров. Ниже приводятся некоторые из характеристик протокола OSPF:

Иерархичность
Сети объединяются в иерархические области (area) — группу смежных сетей, которые находятся под единым управлением и совместно используют общую стратегию маршрутизации. Взаимодействие между областями осуществляется посредством стержневой части (backbone), которая обозначается как область 0 (area 0). Все стержневые маршрутизаторы обладают информацией о маршрутах ко всем другим областям.

Быстрая сходимость
Алгоритм поиска кратчайшего пути (SPF) обеспечивает быструю сходимость, а отсюда и более быстрый, в сравнении с протоколом RIP, выбор маршрута.

Эффективное использование пропускной способности
Использование групповых сообщений, вместо широковещательных, предотвращает «затопление» информацией о маршрутах посторонних узлов сети, которые могут быть не заинтересованы в получении этих сведений, что значительно снижает нагрузку на каналы связи. Кроме того, Внутренние Маршрутизаторы (т.е. те, которые не имеют интерфейсов за пределами своей области) не обладают информацией о маршрутах в других областях, за счет чего так же достигается уменьшение трафика маршрутизации. Роутеры, имеющие несколько интерфейсов в более чем одной области, называются Пограничными Маршрутизаторами (Area Border Routers), они поддерживают отдельные топологические базы данных для каждой из областей, с которыми соединены.

Ресурсоемкость
Протокол OSPF основан на алгоритме Shortest Path First, предложенном Е.В.Дейкстрой (E.W.Dijkstra), который требует больших вычислительных затрат, нежели иные алгоритмы маршрутизации. Но в действительности он не так уж и плох, поскольку кратчайший маршрут рассчитывается только в пределах одной области, причем для сетей малого и среднего размеров — это вообще не проблема, так что вы не будете даже обращать внимания на это обстоятельство.

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

Открытость и наличие программного обеспечения под GPL.
OSPF — это открытый протокол, а Zebra выпускается под GPL, что дает дополнительные преимущества перед проприетарными протоколами и программными продуктами.

Предварительные условия

Ядро Linux:
Собранное с CONFIG_NETLINK_DEV и CONFIG_IP_MULTICAST (я не вполне уверен, возможно требуется еще что-то)

Iproute
Zebra
Пакет может входить в состав вашего дистрибутива. Если нет, обращайтесь на http://www.zebra.org/.

Конфигурирование

Рассмотрим конфигурирование Zebra на примере сети:

----------------------------------------------------
| 192.168.0.0/24                                   |
|                                                  |
|      Area 0    100BaseTX Switched                |
|     Backbone     Ethernet                        |
----------------------------------------------------
  |           |                |              |
  |           |                |              |
  |eth1       |eth1            |eth0          |
  |100BaseTX  |100BaseTX       |100BaseTX     |100BaseTX
  |.1         |.2              |.253          |
 ---------   ------------   -----------      ----------------
 |R Omega|   |R Atlantis|   |R Legolas|      |R Frodo       |
 ---------   ------------   -----------      ----------------
  |eth0         |eth0             |             |          |
  |             |                 |             |          |
  |2MbDSL/ATM   |100BaseTX        |10BaseT      |10BaseT   |10BaseT
------------   ------------------------------------       -------------------------------
| Internet |   | 172.17.0.0/16        Area 1      |       |  192.168.1.0/24 wlan  Area 2|
------------   |         Student network (dorm)   |       |       barcelonawireless     |
               ------------------------------------       -------------------------------

Пусть вас не пугает эта схема — дело в том, что большую часть работы Zebra выполнит самостоятельно и вам не потребуется вручную «поднимать» все маршруты. Самое главное, что вы должны уяснить из этой схемы — это топология сети. И особое внимание обратите на область 0 (area 0), как самую важную часть. Для начала сконфигурируем zebra под свои потребности (поправим файл zebra.conf):

hostname omega
password xxx 
enable password xxx
!
! Описание интерфейсов.
!
!interface lo
! пример описания интерфейса.
!
interface eth1
multicast
!
! Статический маршрут по-умолчанию
!
ip route 0.0.0.0/0 212.170.21.129
!
log file /var/log/zebra/zebra.log

В дистрибутиве Debian, кроме того необходимо подредактировать файл /etc/zebra/daemons, чтобы обеспечить запуск демонов во время загрузки системы.

zebra=yes
ospfd=yes

Затем нужно внести соответствующие изменения в ospfd.conf (для случая IPv4) или в ospf6d.conf (для случая IPv6). Мой ospfd.conf выглядит так:

hostname omega
password xxx
enable password xxx
!
router ospf
  network 192.168.0.0/24 area 0
  network 172.17.0.0/16 area 1
!
! направить вывод на stdout в журнал
log file /var/log/zebra/ospfd.log

Здесь размещены инструкции, описывающие топологию сети.Запуск Zebra

Теперь запустим Zebra. Сделать это можно вручную — дав прямую команду zebra -d, либо с помощью сценария начальной загрузки — /etc/init.d/zebra start. После запуска, в журнале ospfd.log, появятся строки, примерно с таким содержанием:

2002/12/13 22:46:24 OSPF: interface 192.168.0.1 join AllSPFRouters Multicast group.
2002/12/13 22:46:34 OSPF: SMUX_CLOSE with reason: 5   
2002/12/13 22:46:44 OSPF: SMUX_CLOSE with reason: 5
2002/12/13 22:46:54 OSPF: SMUX_CLOSE with reason: 5   
2002/12/13 22:47:04 OSPF: SMUX_CLOSE with reason: 5   
2002/12/13 22:47:04 OSPF: DR-Election[1st]: Backup 192.168.0.1
2002/12/13 22:47:04 OSPF: DR-Election[1st]: DR     192.168.0.1
2002/12/13 22:47:04 OSPF: DR-Election[2nd]: Backup 0.0.0.0
2002/12/13 22:47:04 OSPF: DR-Election[2nd]: DR     192.168.0.1
2002/12/13 22:47:04 OSPF: interface 192.168.0.1 join AllDRouters Multicast group.
2002/12/13 22:47:06 OSPF: DR-Election[1st]: Backup 192.168.0.2
2002/12/13 22:47:06 OSPF: DR-Election[1st]: DR     192.168.0.1
2002/12/13 22:47:06 OSPF: Packet[DD]: Negotiation done (Slave).
2002/12/13 22:47:06 OSPF: nsm_change_status(): scheduling new router-LSA origination
2002/12/13 22:47:11 OSPF: ospf_intra_add_router: Start

Не обращайте внимания на строки «…SMUX_CLOSE…», поскольку они относятся к SNMP и не представляют интереса для нас. Из приведенного листинга видно, что 192.168.0.1 — это Выделенный Маршрутизатор (Designated Router), а 192.168.0.2 —Резервный Выделенный Маршрутизатор (Backup Designated Router).

И zebra, и ospfd допускают возможность интерактивного взаимодействия с ними через telnet:

$ telnet localhost zebra
$ telnet localhost ospfd

Попробуем посмотреть список установленных маршрутов, залогировавшись в zebra:

root@atlantis:~# telnet localhost zebra
Trying 127.0.0.1...
Connected to atlantis.
Escape character is '^]'.

Hello, this is zebra (version 0.92a).
Copyright 1996-2001 Kunihiro Ishiguro.

User Access Verification

Password: 
atlantis> show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       B - BGP, > - selected route, * - FIB route

K>* 0.0.0.0/0 via 192.168.0.1, eth1
C>* 127.0.0.0/8 is directly connected, lo
O   172.17.0.0/16 [110/10] is directly connected, eth0, 06:21:53
C>* 172.17.0.0/16 is directly connected, eth0
O   192.168.0.0/24 [110/10] is directly connected, eth1, 06:21:53
C>* 192.168.0.0/24 is directly connected, eth1
atlantis> show ip ospf border-routers
============ OSPF router routing table =============
R    192.168.0.253         [10] area: (0.0.0.0), ABR
			   via 192.168.0.253, eth1
				 [10] area: (0.0.0.1), ABR
			   via 172.17.0.2, eth0

или напрямую, с помощью iproute:

root@omega:~# ip route
212.170.21.128/26 dev eth0  proto kernel  scope link  src 212.170.21.172 
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.1 
172.17.0.0/16 via 192.168.0.2 dev eth1  proto zebra  metric 20 
default via 212.170.21.129 dev eth0  proto zebra 
root@omega:~#

Отсюда видно, что zebra добавила ряд маршрутов, которых в таблице раньше не было. Новые маршруты появляются спустя несколько секунд после того, как были запущены zebra и ospfd. Теперь вы можете попробовать ping-ануть некоторые из узлов сети.Zebra выставляет маршруты автоматически, все что от вас требуется — прописать маршрутизаторы в конфигурационный файл и этого будет достаточно!

Для захвата и анализа OSPF-пакетов можно воспользоваться командой:

tcpdump -i eth1 ip[9] == 89

где число 89 — это номер протокола OSPF, а 9 — это номер октета в ip-заголовке, где хранится номер протокола.

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

Пример подключения локальной сети к Интернет через NAT, с организацией QoS

Меня зовут Педро Ларрой (Pedro Larroy) <piotr%member.fsf.org>. Здесь я расскажу об общих принципах настройки соединения локальной сети, в которой имеется большое число пользователей, к Интернет через маршрутизатор, работающий под управлением Linux. Маршрутизатор имеет реальный IP-адрес и производит Трансляцию Сетевых Адресов (NAT). Я живу в университетском общежитии, где проложена локальная сеть на 198 пользователей. Эта сеть соединена с Интернет через маршрутизатор, который я администрирую. Пользователи очень интенсивно работают в пиринговых сетях, что требует соответствующего управления трафиком. Надеюсь, что этот пример будет интересен читателям lartc.

Прежде всего я опишу процесс настройки своего маршрутизатора шаг за шагом, и в заключение расскажу, как сделать этот процесс автоматическим, выполняющимся в процессе загрузки системы. Сеть, к которой относится этот пример, является локальной (LAN). Она подключена к Интернет через маршрутизатор, который имеет единственный реальный IP-адрес. Разделение единственного реального IP-адреса между всеми пользователями в локальной сети осуществляется с помощью нескольких правил iptables. Для этого необходимо:

Ядро Linux 2.4.18 или выше
На ядро нужно наложить заплату, для поддержки HTB.
iproute
Убедитесь, что tc поддерживает HTB. Скомпилированная версия распространяется вместе с HTB.
iptables

Начнем с оптимизации пропускной способности.

Для начала создадим несколько дисциплин (qdiscs), которые будут обслуживать трафик. Первой создается htb qdisc с 6-ю классами и различными приоритетами. Каждому классу назначена определенная пропускная способность, но при этом они могут задействовать неиспользуемую пропускную способность, если она не занята другими классами. Напомню, что классы с более высоким приоритетом (т.е. с более низким числом prio) будут получать «излишек» канала первыми. Подключение к Интернет осуществляется через модем ADSL, с пропускной способностью для входящего трафика 2 Мбит/сек, исходящего — 300 Кбит/сек. Я ограничиваю исходящую пропускную способность величиной в 240 Кбит/сек по той простой причине, что это максимальное значение, при котором время ожидания отклика остается минимальным. Величина этот параметра может быть определена экспериментально, путем наблюдения за изменением времени отклика при изменении величины пропускной способности.

Для начала, присвойте переменной CEIL величину, составляющую 75% от общей пропускной способности для исходящего трафика. Там, где я использую eth0 — назначьте свой интерфейс, который «смотрит» в Интернет. Сценарий (на языке командной оболочки), выполняющий настройку, начинается со следующих строк:

CEIL=240
tc qdisc add dev eth0 root handle 1: htb default 15
tc class add dev eth0 parent 1: classid 1:1 htb rate ${CEIL}kbit ceil ${CEIL}kbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 80kbit ceil 80kbit prio 0
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 80kbit ceil ${CEIL}kbit prio 1
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 20kbit ceil ${CEIL}kbit prio 2
tc class add dev eth0 parent 1:1 classid 1:13 htb rate 20kbit ceil ${CEIL}kbit prio 2
tc class add dev eth0 parent 1:1 classid 1:14 htb rate 10kbit ceil ${CEIL}kbit prio 3
tc class add dev eth0 parent 1:1 classid 1:15 htb rate 30kbit ceil ${CEIL}kbit prio 3
tc qdisc add dev eth0 parent 1:12 handle 120: sfq perturb 10
tc qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10
tc qdisc add dev eth0 parent 1:14 handle 140: sfq perturb 10
tc qdisc add dev eth0 parent 1:15 handle 150: sfq perturb 10

Эти строки создают одноярусное дерево HTB:

+---------+
| root 1: |
+---------+
     |
+---------------------------------------+
| class 1:1                             |
+---------------------------------------+
  |      |      |      |      |      |
+----+ +----+ +----+ +----+ +----+ +----+
|1:10| |1:11| |1:12| |1:13| |1:14| |1:15|
+----+ +----+ +----+ +----+ +----+ +----+
classid 1:10 htb rate 80kbit ceil 80kbit prio 0
Это класс с наивысшим приоритетом. Пакеты, попадающие в этот класс, будут иметь самую низкую задержку и получат избыток канала в первую очередь. Сюда будет направляться интерактивный трафик: sshtelnetdnsquake3irc, а так же пакеты с установленным флагом SYN.
classid 1:11 htb rate 80kbit ceil ${CEIL}kbit prio 1
Это первый класс, через который будет проходить довольно объемный трафик. В моем случае — это трафик от локального WEB-сервера и запросы к внешним WEB-серверам, исходящий порт 80 и порт назначения 80, соответственно.
classid 1:12 htb rate 20kbit ceil ${CEIL}kbit prio 2
В этот класс помещаются пакеты, с установленным битом Maximize-Throughput в поле TOS, а так же иной трафик, который генерируется локальными процессами на маршрутизаторе, отправляемый в Интернет. Таким образом, все последующие классы будут иметь дело только с перенаправляемым трафиком.
classid 1:13 htb rate 20kbit ceil ${CEIL}kbit prio 2
Высокоприоритетный класс, обслуживающий объемный трафик, поступающий от компьютеров из локальной сети.
classid 1:14 htb rate 10kbit ceil ${CEIL}kbit prio 3
Этот класс обслуживает почтовый трафик (SMTP,pop3…) и пакеты, с установленным битом Minimize-Cost в поле TOS.
classid 1:15 htb rate 30kbit ceil ${CEIL}kbit prio 3
Последний класс. Он обслуживает прочий трафик, поступающий от компьютеров из локальной сети. Сюда попадает все, что относится к работе в пиринговых сетях, т.е. kazaa, edonkey и пр.

Классификация пакетов.

Мы создали различные классы обработки трафика, но классификация пока отсутствует, поэтому, к настоящему моменту, весь трафик пойдет через класс 1:15 ( который назначен классом по-умолчанию: tc qdisc add dev eth0 root handle 1: htb default 15 ). Теперь самое главное — нужно распределить трафик по имеющимся классам.

Устанавим фильтры, которые будут выполнять классификацию пакетов, основываясь на метках iptables. Мне нравятся iptables за их чрезвычайную гибкость и за возможность подсчитывать количество пакетов, пропущенных тем или иным правилом. Добавим в сценарий следующие строки:

tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10
tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:11
tc filter add dev eth0 parent 1:0 protocol ip prio 3 handle 3 fw classid 1:12
tc filter add dev eth0 parent 1:0 protocol ip prio 4 handle 4 fw classid 1:13
tc filter add dev eth0 parent 1:0 protocol ip prio 5 handle 5 fw classid 1:14
tc filter add dev eth0 parent 1:0 protocol ip prio 6 handle 6 fw classid 1:15

Здесь задаются соответствия между специфическими значениями FWMARK ( handle x fw ) и классами (classid x:x). Теперь рассмотрим процесс установки меток на пакеты.

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

        +------------+   принятие     +---------+               +-------------+
Вход ---| PREROUTING |--- решения о --| FORWARD |-------+-------| POSTROUTING |- Выход
        +------------+  маршрутизации +---------+       |       +-------------+
                             |                          |
                        +-------+                    +--------+
                        | INPUT |-Локальные процессы-| OUTPUT |
                        +-------+                    +--------+

Далее я буду исходить из предположения, что всем таблицам назначена политика по-умолчанию -P ACCEPT. Наша локальная сеть относится к классу B, с адресами 172.17.0.0/16. Реальный IP-адрес — 212.170.21.172

Добавим правило iptables, которое будет выполнять SNAT, что позволит пользователям локальной сети общаться с внешним миром, и разрешим форвардинг пакетов:

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 172.17.0.0/255.255.0.0 -o eth0 -j SNAT --to-source 212.170.21.172

Проверим, что пакеты уходят через класс 1:15:

tc -s class show dev eth0

Добавим в цепочку PREROUTING, таблицы mangle, правила для установки меток на пакеты:

iptables -t mangle -A PREROUTING -p icmp -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -p icmp -j RETURN

Теперь вы должны наблюдать увеличение значения счетчика пакетов в классе 1:10, при попытке ping-ануть из локальной сети какой-нибудь сайт в Интернете.

tc-s класс показывают dev eth0

Действие -j RETURN предотвращает движение пакетов по всем правилам. Поэтому все ICMP-пакеты будут проходить только это правило. Добавим еще ряд правил, которые будут изменять биты в поле TOS:

iptables -t mangle -A PREROUTING -m tos --tos Minimize-Delay -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -m tos --tos Minimize-Delay -j RETURN
iptables -t mangle -A PREROUTING -m tos --tos Minimize-Cost -j MARK --set-mark 0x5
iptables -t mangle -A PREROUTING -m tos --tos Minimize-Cost -j RETURN
iptables -t mangle -A PREROUTING -m tos --tos Maximize-Throughput -j MARK --set-mark 0x6
iptables -t mangle -A PREROUTING -m tos --tos Maximize-Throughput -j RETURN

Поднимем приоритет для ssh-пакетов:

iptables -t mangle -A PREROUTING -p tcp -m tcp --sport 22 -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -p tcp -m tcp --sport 22 -j RETURN

а так же для пакетов, с которых начинается TCP-соединение, т.е. SYN-пакетов:

iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j MARK --set-mark 0x1
iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j RETURN

И так далее. После того, как в цепочку PREROUTING, таблицы mangle, будут внесены все необходимые правила, закончим ее правилом:

iptables -t mangle -A PREROUTING -j MARK --set-mark 0x6

Это заключительное правило отправит оставшиеся немаркированные пакеты в класс 1:15. Фактически, это правило можно опустить, так как класс 1:15 был задан по-умолчанию, но тем не менее, я оставляю его, чтобы сохранить единство настроек и кроме того, иногда бывает полезно увидеть счетчик пакетов для этого правила.

Нелишним будет добавить те же правила в цепочку OUTPUT, заменив имя цепочки PREROUTING на OUTPUT (s/PREROUTING/OUTPUT/). Тогда трафик, сгенерированный локальными процессами на маршрутизаторе, также будет классифицирован по категориям. Но, в отличие от вышеприведенных правил, в цепочке OUTPUT, я устанавливаю метку -j MARK —set-mark 0x3, таким образом трафик от маршрутизатора получает более высокий приоритет.

Дополнительная оптимизация

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

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

tc qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10
tc qdisc add dev eth0 parent 1:14 handle 140: sfq perturb 10
tc qdisc add dev eth0 parent 1:15 handle 150: sfq perturb 10

Выполнение настроек во время загрузки системы.

Уверен, что можно найти множество способов, чтобы произвести настройку маршрутизатора во время загрузки. Для себя я создал скрипт /etc/init.d/packetfilter, который принимает команды [start | stop | stop-tables | start-tables | reload-tables]. Он конфигурирует дисциплины (qdiscs) и загружает необходимые модули ядра. Этот же сценарий загружает правила iptables из файла /etc/network/iptables-rules, которые предварительно могут быть сохранены утилитой iptables-save и восстановлены —iptables-restore.

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

Защита от SYN flood

Пример взят из документации к iproute, написанной Алексеем и адаптирован для совместной работы с netfilter. Если этот пример заинтересует вас, измените числовые значения на наиболее подходящие для вашей системы.

Этот сценарий был написан для защиты отдельного хоста, а не сети. Учитывайте это обстоятельство.

Для его работы желательно иметь самую последнюю версию iproute2.

#! /bin/sh -x
#
# демонстрация возможностей по управлению входящим (ingress) трафиком
# здесь приводится пример ограничения пропускной способности для входящих SYN-пакетов
# Может оказаться полезным для защиты от TCP-SYN атак.
#
#пути к различным утилитам;
#укажите правильные значения.
#
TC=/sbin/tc
IP=/sbin/ip
IPTABLES=/sbin/iptables
INDEV=eth2
#
# пометить все SYN-пакеты, пришедшие через $INDEV, числом 1
############################################################
$iptables -A PREROUTING -i $INDEV -t mangle -p tcp --syn \
-j MARK --set-mark 1
############################################################
#
# установить ingress qdisc на входящий интерфейс
############################################################
$TC qdisc add dev $INDEV handle ffff: ingress
############################################################

#
#
# SYN-пакет имеет размер 40 байт (320 бит), отсюда -- три пакета
# имеют размер 960 бит (примерно 1 Кбит); ограничим скорость поступления
# 3-мя пакетами в секунду ( точнее -- 1 Кбит/сек )
############################################################
$TC filter add dev $INDEV parent ffff: protocol ip prio 50 handle 1 fw \
police rate 1kbit burst 40 mtu 9k drop flowid :1
############################################################

#
echo "---- qdisc parameters Ingress ----------"
$TC qdisc ls dev $INDEV
echo "---- Class parameters Ingress ----------"
$TC class ls dev $INDEV
echo "---- filter parameters Ingress ----------"
$TC filter ls dev $INDEV parent ffff:

#Удаление ingress qdisc
#$TC qdisc del $INDEV ingress

 

Ограничение пропускной способности для ICMP-пакетов, с целью предотвращения DDoS-атак

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

Прежде, чем приступить к делу, нарисуем схему подключения локальной сети к Интернет:

[Интернет] —— [Linux router] — [Офис]
eth1 eth0

Зададим начальные условия:

# tc qdisc add dev eth0 root handle 10: cbq bandwidth 10Mbit avpkt 1000
# tc class add dev eth0 parent 10:0 classid 10:1 cbq bandwidth 10Mbit rate \
10Mbit allot 1514 prio 5 maxburst 20 avpkt 1000

Если у вас более высокоскоростное подключение — измените эти цифры соответствующим образом. Теперь необходимо определиться с «шириной» канала для ICMP-трафика. Чтобы найти типовое значение для вашей сети, можно воспользоваться утилитой tcpdump, запустив ее с перенаправлением вывода в файл. Затем, с помощью этого файла, вы сможете подсчитать количество ICMP-пакетов, отправляемых вашей сетью в единицу времени.

Если вариант подсчета экспериментальным путем вам не подходит, попробуйте ограничиться 10% общей пропускной способности. Построим наш класс:

# tc class add dev eth0 parent 10:1 classid 10:100 cbq bandwidth 10Mbit rate \
100Kbit allot 1514 weight 800Kbit prio 5 maxburst 20 avpkt 250 \
bounded

Он ограничивает пропускную способность канала величиной 100 Кбит/сек. А теперь подключим к нему фильтр для ICMP-пакетов:

# tc filter add dev eth0 parent 10:0 protocol ip prio 100 u32 match ip
protocol 1 0xFF flowid 10:100

 

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

Управление приоритетами для трафика различных типов

Если канал практически полностью забит отправляемыми/получаемыми данными, то работа через telnet или ssh становится практически невозможной. Как было бы здорово, если бы интерактивный трафик не блокировался другими пакетами. Linux поможет вам в этом!

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

Стандартный планировщик pfifo_fast имеет три различных «полосы». В первую очередь обслуживается полоса 0, а затем полосы 1 и 2. Поэтому, необходимо весь интерактивный трафик отправить в полосу 0!

Отталкиваясь от «Ipchais HOWTO» (уже довольно устаревшего):

В IP-заголовке имеется 4 редко используемых бита — TOS (Type of Service — Тип Обслуживания). Они задают способ обслуживания пакета: «Minimum Delay» (минимальная задержка), «Maximum Throughput» (максимальная пропускная способность), «Maximum Reliability» (максимальная надежность) и «Minimum Cost» (минимальная стоимость канала). Причем одновременно может быть установлен только один из этих битов. Роб ван Ньюкерк (Rob van Nieuwkerk), автор кода ipchains TOS-mangling, дает следующее пояснение:

Наиболее важным для меня, является флаг «Minimum Delay» (минимальная задержка). Я включаю его в пакетах интерактивного трафика на моем роутере, работающем под управлением Linux. Я подключен к сети через модем 33.6. Linux «раскидывает» пакеты по 3-м очередям. Таким образом я получаю вполне приемлемую скорость обслуживания интерактивного трафика при большой загрузке канала.

Как правило, флаг «Minimum Delay» устанавливается в пакетах для telnet и ftp-control, а в пакетах ftp-data — «Maximum Throughput». Делается это следующим образом:

# iptables -A PREROUTING -t mangle -p tcp --sport telnet \
-j TOS --set-tos Minimize-Delay
# iptables -A PREROUTING -t mangle -p tcp --sport ftp \
-j TOS --set-tos Minimize-Delay
# iptables -A PREROUTING -t mangle -p tcp --sport ftp-data \
-j TOS --set-tos Maximize-Throughput

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

# iptables -A OUTPUT -t mangle -p tcp --dport telnet \
-j TOS --set-tos Minimize-Delay
# iptables -A OUTPUT -t mangle -p tcp --dport ftp \
-j TOS --set-tos Minimize-Delay
# iptables -A OUTPUT -t mangle -p tcp --dport ftp-data \
-j TOS --set-tos Maximize-Throughput

 

Защита Asterisk или кубинская эпидемия

В последнее время началась большая волна взломов Asterisk с последующим прогоном через них траффика на кубу.

Поскольку минута звонка на кубу стоит в среднем от 1$ в минуту это может привести к печальным последствиям (за 17 часов на одном из транков баланс опустили до -8000$).
Схема работает так:

  1. Ищется в сети Asterisk сервер
  2. Подбирается список его пиров
  3. Подбираются пароли к пирам
  4. Аккаунт ставится в систему перебирающую транки при звонке.
  5. Набегает множество кубинцев звонящих через эту систему

Если купить доступ к такой системе и позвонить, то можно по задержке до гудка понять, что в этой схеме участвует огромное количество взломанных Asterisk серверов.

Подбор пиров

При подборе пиров используется метод реализованный в Sipvicious. Для сканирования перебираются пиры и анализируется ответ Asterisk. Например:

./svwar.py sip.somewhere
| Extension | Authentication |
-------------------------------
| 607 | reqauth |
| 606 | reqauth |
| 601 | reqauth |
| 600 | reqauth |
| 300 | reqauth |
| 900 | reqauth |
| 100 | reqauth |

Для продиводействия этому нужно включить директиву alwaysauthreject в sip.conf, которая при любых ошибках авторизации отвечает 401 Unauthorized.
После этого тот-же сервер при попытке сканирования будет отвечать 401 и утилита выдаст ошибку:

./svwar.py sip.somewhere
ERROR:TakeASip:SIP server replied with an authentication request for an unknown extension. Set --force to force a scan.
WARNING:root:found nothing

 

Кубинская проблема

Если ваши абоненты не собираются звонить на кубу, то ее надо закрыть в extensions.conf
Например:

;cuba
exten => _53.,1,Answer()
exten => _53.,n,PlayBack(vm-goodbye)
exten => _53.,n,Hangup()
;somali
exten => _252.,1,Answer()
exten => _252.,n,PlayBack(vm-goodbye)
exten => _252.,n,Hangup()

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

P.S. Для проверки на то, что вы правильно прописали отклонение звонков на кубу можно попробовать позвонить по номеру +53997970. Это военная база и там всегда отвечает автоответчик.

Взято с Хабра — http://habrahabr.ru/blogs/voip/103341/

SipSak

sipsak is a small comand line tool for developers and administrators of SIP applications. It can be used for some simple tests on SIP applications and devices.

Features

  • sending OPTIONS request
  • sending text files (which should contain SIP requests)
  • traceroute (see section 11 in RFC3261)
  • user location test
  • flooding test
  • random character trashed test
  • interpret and react on response
  • authentication with qop supported
  • short notation supported for receiving (not for sending)
  • string replacement in files
  • can simulate calls in usrloc mode
  • uses symmetric signaling and thus should work behind NAT

Available for Linux, BSD & Win32

http://sipsak.org/

Asterisk SNMP

We needed a better way to monitor and track performance of RF.com‘s Asterisk 1.6 boxes.  We learned quickly that the scarce documentation for configuring Asterisk to use Simple Network Management Protocol (SNMP) is conflicting and outdated.  So we decided to share our configuration and hopefully save others a lot of time and head-scratching.

Downloading the Asterisk 1.6 source code

Enabling SNMP support in Asterisk requires a rebuild of Asterisk.

If you already have the Asterisk source code on your Asterisk server, open a terminal session with the Asterisk box and navigate to the Asterisk source code directory, then skip to Installing Net-SNMP.

If you don’t have the Asterisk source code on your Asterisk server, open a terminal session with the Asterisk box and copy these instructions to the command line:

#get asterisk source
# create source dir
mkdir -p /usr/src/digium
cd /usr/src/digium/
wget http://downloads.digium.com/pub/asterisk/asterisk-1.6-current.tar.gz tar xzvf asterisk-1.6-current.tar.gz
cd asterisk-1.6.*

Installing Net-SNMP

Asterisk SNMP support is provided by the res_snmp module.  To build this module, you need to install the following packages:

  • net-snmp
  • net-snmp-devel
  • net-snmp-utils
  • bzip2
  • bzip2-devel
  • lm_sensors
  • lm_sensors-devel
  • newt
  • newt-devel

On a CentOS or Fedora box you can use the following command to install all the packages at once:

yum -y install net-snmp net-snmp-devel net-snmp-utils bzip2-devel newt-devel lm_sensors-devel ; # snmp support – res_snmp

Preparing the Asterisk box

Once the necessary packages are installed, run the following commands from the Asterisk source code directory:

./configure
make menuselect

Running make menuselect will launch a menu that looks something like the image below.

Asterisk Module and Build Options Selection

Select the Resource Modules option from the menu and press the Return key.  Then scroll down to res_snmp, if res_snmp is not selected, press the spacebar to enable res_snmp.  The selection should now look like the image below.

Asterisk resource modules

If you are unable to select res_snmp, it means the Net-SNMP package was not installed properly or the Asterisk configure tool was unable to find the Net-SNMP package. Try running .configure -with-netsnmp from the command line and then re-run make menuselect.

Press x to save your configuration changes.

Now we can build Asterisk with SNMP support and install it by runing the following commands:

make /etc/init.d/asterisk stop ; # make sure asterisk is stopped before installing
make install

Configuring the SNMP daemon

There are three versions of SNMP, but two are insecure and should not be used over an untrusted network.  We chose SNMPv3, which requires authentication and encryption from the asteriskUser when it connects to the server.

To create an SNMPv3 user account and to configure it to require authentication and encryption, run the commands below, replacing change_this_password with your own password.

echo '# Asterisk user
rwuser asteriskUser priv
createUser asteriskUser SHA change_this_password AES
' >> /etc/snmp/snmpd.conf

Asterisk uses AgentX to communicate with the SNMP daemon.  Run the command below to configure the SNMP daemon for AgentX.  If your Asterisk daemon, does not run as a member of the asterisk group, replace asterisk in the agentXPerms command with an asterisk daemon group.

echo '
# Asterisk configuration
master agentx
agentXSocket /var/agentx/master
agentXPerms 0660 0550 nobody asterisk
' >> /etc/snmp/snmpd.conf

The commands below will install the Asterisk and Digium MIB files, configure the snmp daemon to start on boot, and launch the snmp daemon.

# copy asterisk mib files
cp doc/*-mib.txt /usr/share/snmp/mibs/

#start the snmpd daemon
chkconfig snmpd on
/etc/init.d/snmpd start

Let’s verify that the configuration is working so far by verifying that the snmp daemon set the file permissions correctly, run the following command:

ls -al /var/agentx

Your permissions must look like:

total 8
drwxr-xr-x  2 root   root     4096 Jan 31 18:01 .
drwxr-xr-x 20 root   root     4096 Jan 31 14:30 ..
srw-rw----  1 nobody asterisk    0 Jan 31 18:01 master

If the file permissions on /var/agentx and /var/agentx/master don’t allow the asterisk daemon group to write tomaster, Asterisk will not be able to communicate with the SNMP daemon. We had problems with the /var/agentx directory permissions, you may need to run the following command to fix the permissions.

chmod 755 /var/agentx

You can also check the logs to confirm that AgentX is running.

more /var/log/messages | grep snmpd

You should see lines like the following:

Jan 31 14:30:15 domU-12-31-39-00-55-E7 snmpd[27048]: Creating directory: /var/agentx
Jan 31 14:30:15 domU-12-31-39-00-55-E7 snmpd[27048]: Turning on AgentX master support.

Configuring the Asterisk res_snmp module

Now we configure Asterisk to use SNMP by running the following commands:

# configure res_snmp.conf
sed -e ‘s/;\(subagent\)/\1/’ -e ‘s/;\(enabled\)/\1/’ <configs/res_snmp.conf.sample >/etc/asterisk/res_snmp.conf

Start Asterisk from the command line:

asterisk -cvvvvvvvvvv

and look for the following Asterisk console output:

NET-SNMP version 5.4.1 AgentX subagent connected

The line above means that Asterisk is configured correctly and the res_snmp module has loaded.

You can now exit the asterisk console and then launch the Asterisk daemon, with the command below:

/etc/init.d/asterisk start

Final testing

You can now use the snmpwalk command to test that everything is configured correctly.  Replacechange_this_password with the password you created above for the snmp daemon configuration and run the commands below:

export MIBS=+ASTERISK-MIB
snmpwalk -v 3 -u asteriskUser -n “” -l authPriv -a SHA -A change_this_password -x AES -X change_this_password localhost asterisk

You should get a result like:

ASTERISK-MIB::astVersionString.0 = STRING: 1.6.0.5
ASTERISK-MIB::astVersionTag.0 = Gauge32: 10600
ASTERISK-MIB::astConfigUpTime.0 = Timeticks: (60776) 0:10:07.76
ASTERISK-MIB::astConfigReloadTime.0 = Timeticks: (60777) 0:10:07.77
...

Congratulations, you’ve finished and your Asterisk server is now configured to use SNMP.