воскресенье, 28 февраля 2010 г.

Acme Packet - это просто. Часть II.

Защита от DOS атак.

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

Итак, если вы купили пакет DDOS, то у вас появляется возможность настраивать защитные механизмы системы Acme Packet.

В системе Acme Packet можно найти следующие ограничения:
- системные ограничения - максимальное число сообщений в секунду, которое может обработать система;
- максимальная длина SIP пакета;
- максимальная длина UDP пакета;
- ограничения по IP адресам и портам;
- ограничения по протоколам;
- ограничения полезного трафика (основаны на понятиях trusted and untrusted traffic).

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

Уровень SIP Config

Ограничения на длину пакета:
sip-message-len = 2000
max-udp-length = 2000
Название параметров говорит само за себя, параметр max-udp-length изменяется в поле option.

Уровень Session Agent

Ограничение на количество сессий, налагаемое на конкретное устройство.
max-sessions = 8 - количество сессий для 8-портового шлюза, равно количеству портов на шлюзе

Для контроля за колличеством сессий нужно включить опцию:
constraints enabled


Уровень Media Manager

Если на SBC включена возможность приема ICMP пакетов, то на уровне Media Manager существует системное ограничение в 8Kbs.

max-signaling-bandwidth = 1720000 - максимальное количество сообщений, которое сможет обработать SD, значение приведено для NN3800, это значение аппаратнозависимое и отличается для других SD.

Аппаратнозависимые параметры определяющие емкость ACL.
Меняются лишь при изменении аппаратной платформы.
min-media-allocation = 2000
min-trusted-allocation = 4000
deny-allocation = 64000

arp-msg-bandwidth - полоса разрешенная для ARP запросов (по умолчанию 32000) без необходимости изменять, наверное, не надо.

flow-time-limit = 28800 - 8 часов непрерывной работы сессии (по умолчанию 24 часа)

initial-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
subsq-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
tcp-initial-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
tcp-subsq-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
Эти таймеры срабатывают при пропадании RTP потока, но также могут сработать, если передача идет лишь в одном направлении, например, при передаче факсимильного сообщения.

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

При описании модели поведения нужно описать те характеристики и ограничения, в соответствии с которыми она и будет формироваться.
- Если вызов принадлежит доверенному пользователю, этот вызов должен состояться.
- Часть злонамереннных сообщений пройдет через SD.
- Система обеспечивает обе схемы: и peer, и access.
- Схема peer запрещает любой трафик, и для разрешения требуется прописать исключение.
- Контроль за схемой access возложен на сервер регистраций.
- Переход из состояния UNTRUSTED в состояние TRUSTED происходит при удачной регистрации, либо при установлении соединения.
- Расчеты производим для протокола SIP.
- Для схемы peer расчет производится для входящего на шлюз вызова, а для схемы access - для исходящего, при этом учитывается максимальный сигнальный трафик.
- Каждый абонентский порт шлюза может генерировать или получать 1 вызов в секунду при максимальной нагрузке (установка сервиса автодозвон).

Весь трафик, входящий в SBC, делится на TRUSTED, UNTRUSTED и FRAGMENTED.

fragment-msg-bandwidth - полоса для фрагментированных пакетов, если fragment-msg-bandwidth = 0, то все фрагментированные пакеты идут как UNTRUSTED, и только при сборе всего пакета переходит в TRUSTED.
Предположим, что количество фрагментированных пакетов велико, для расчета предположим, что величина этого трафика может достигать половины максимально возможного, результат для NN3800: fragment-msg-bandwidth = 1720000/2 = 860000

Следующие два параметра образуют плавающее окно для UNTRUSTED трафика, окно обеспечивает прохождение сообщений, которые используются для идентификации трафика и перевода его в TRUSTED, например, Register.

max-untrusted-signaling = 6% от max-signaling-bandwidth, это максимальное значение окна в процентах от максимальной полосы, UNTRUSTED трафик не может превышать этого значения. Рекомендуемые значения для схемы peer - 1%, access - 5%, в сумме 6%.
min-untrusted-signaling = 5% от max-signaling-bandwidth, это минимальное значение окна в процентах от максимальной полосы, эта полоса всегда выделена для UNTRUSTED трафика, даже если нагрузка TRUSTED трафика приближается к 100%. Рекомендуемые значения для схемы peer - 1%, access - 4%, в сумме 5%.

Уровень Access Control & Realm

Схема peer

Пример параметров для 8-портового шлюза.
access = permit
average-rate-limit = 45600
trust-level = low
invalid-signal-threshold = 0
maximum-signal-threshold = 2400
untrusted-signal-threshold = 2400

average-rate-limit - ограничение на величину сигнального трафика, расчитывается как
сумма сигнальных сообщений для одного вызова в байтах * количество вызовов с одного порта в течении окна измерения * количество портов на шлюзе + сумма дополнительных сервисных сообщений в байтах * количество портов на шлюзе, и все это поделить на величину окна измерения (по умолчанию 30 секунд)

В установлении вызова участвуют следующие сообщения:
INVITE - 1150
PRACK - 517
ACK for Invite with Authentication - 555
BYE - 495

Сервисные сообщения:
SUBSCRIBE - 916
NOTIFY - 790
OPTIONS - 344
REFER - 977

Допущение - каждый абонентский порт шлюза может генерировать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
Расчет для 8-портового шлюза:
((1150+517+555+495)*30+916+790+344+977)*8/30= 22543.2 byte/sec
или
(2717*30+3027)*8/30= 22543.2 byte/sec
но такая точность нам ни к чему, несколько вольно округлим и упростим:
(2750+100)*8=2850*8= 22800 byte/sec
Учитывая, что это предельное значение, уножим на 2. Результат для 8-портового шлюза average-rate-limit = 45600 byte/sec.

В результате получаем формулу расчета
average-rate-limit = 5700 * Количество портов

invalid-signal-threshold - порог пакетов с ошибками, устанавливаем 0.

maximum-signal-threshold - максимально возможное количество сигнальных сообщений от пользователя в течении окна измерения (по умолчанию 30 секунд), расчитывается, как максимально возвожное количество вызовов в секунду (max CPS) * окно измерения (tolerance-window) * количество сигнальных сообщений, полученых от внешнего устройства (100 Trying, 183 Session Progress, 200 OK for PRACK, 200 OK for INVITE, 200 OK for BYE), так как при входящем вызове на шлюз генерируется больше сообщений, чем при исходящем, то и рассматриваем этот вариант.
Расчет для 8-портового шлюза:
Допущение - каждый абонентский порт может получать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
8*1*30*5=1200
Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 2400, тем самым будут учтены возможные дополнительные сообщения.

Окончательный вариант расчета для окна 30 секунд:
maximum-signal-threshold = 300 * Количество портов

untrusted-signal-threshold - количество сигнальных сообщений от абонентского устройства до перевода в TRUSTED. Переход из состояния UNTRUSTED в состояние TRUSTED происходит при ответе абонента и установлении первого разговора, то есть по Invite, приходящему на SD. Но, схема peer подразумевает, что абонент является доверенным и переход в TRUSTED не нужен, поэтому, этот параметер приравняем к maximum-signal-threshold. При этом значении не произойдет блокировки абонентского устройства при большом колличестве вызовов на занятого абонента.

Результат для схемы peer:
untrusted-signal-threshold = maximum-signal-threshold

Схема access

Пример параметров для 8-портовой PBX.
access = permit
average-rate-limit = 81600
trust-level = low
invalid-signal-threshold = 0
maximum-signal-threshold = 2880
untrusted-signal-threshold = 4

В этой схеме верны все допущения схемы peer, кроме изменения состояния; переход из UNTRUSTED в состояние TRUSTED происходит при удачной регистрации. Расчет производится для одного зарегистрированного пользователя, но так как этот пользователь может представлять из себя многопортовое устройство (например IP PBX), то и расчет производится по той же методике. Но для расчета нужно определиться с устройством, у которого будет максимальное количество портов во всей сети, скрытое за одной регистрацией, и все расчеты произвести для него.

average-rate-limit - ограничение на величину сигнального трафика, рассчитывается как
сумма сигнальных сообщений для одного вызова в байтах * количество вызовов с одного порта в течении окна измерения * количество портов на PBX + сумма дополнительных сервисных сообщений в байтах * количество портов на PBX, и все это поделить на величину окна измерения (по умолчанию 30 секунд)

В установлении вызова участвуют следующие сообщения:
INVITE - 1150
ACK - 555
INVITE with Authentication - 1400
PRACK - 517
ACK for Invite with Authentication - 815
BYE - 495

Сервисные сообщения:
REGISTER - 564
REGISTER with Authentication - 870
SUBSCRIBE - 916
NOTIFY - 790
OPTIONS - 344
REFER - 977

Допущение: каждый абонентский порт PBX может генерировать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
Расчет для 8-портовой PBX:
((1150+555+1400+517+815+495)*30+564+870+916+790+344+977)*8/30= 40645.6 byte/sec
или
(4932*30+4461)*8/30= 40645.6 byte/sec
такая точность опять же ни к чему, округлим и упростим:
(4950+150)*8=5100*8= 40800 byte/sec
Учитывая, что это предельное значение, уножим на 2. Результат для 8-портовой PBX average-rate-limit = 81600 byte/sec.

Формула для расчета
average-rate-limit= 10200 * Количество портов

maximum-signal-threshold - максимально возможное количество сигнальных сообщений от пользователя в течении окна измерения (по умолчанию 30 секунд), расчитывается как максимально возвожное количество вызовов в секунду (max CPS) * окно измерения (tolerance-window) * количество сигнальных сообщений, полученых от внешнего устройства (INVITE, ACK, INVITE, PRACK, ACK, BYE).
Допущение: каждый абонентский порт PBX может генерировать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
Расчет для 8-портовой PBX:
8*1*30*6=1440
Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 2880, тем самым будут учтены возможные дополнительные сообщения.

Окончательный вариант расчета для окна 30 секунд -
maximum-signal-threshold = 360 * Количество портов

untrusted-signal-threshold - количество сигнальных сообщений от абонентского устройства до перевода в TRUSTED. Переход из состояния UNTRUSTED в состояние TRUSTED происходит при удачной регистрации, для удачной регистрации требуется лишь два SIP сообщения Register. Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 4. Но как показывает практика VoIP абонент может генерировать больше сообщений до момента удачной регистрации. Методом проб и ошибок остановились на значении 8.
Результат для схемы access:
untrusted-signal-threshold = 8

1 комментарий:

  1. Этот комментарий был удален администратором блога.

    ОтветитьУдалить