56
При использовании VAD возникает неравномерность скорости передачи
речи (во время пауз речь не передается), при этом коэффициент пачечности,
измеряемый отношением пиковой скорости передачи к средней скорости
передачи, может достигать значений:
К
пач
= V
пик
/V
ср
= 2…10. (5)
Использование такого класса обслуживания несколько снижает качество
передачи речи, однако при этом достигается более эффективное использование
выделенной пропускной способности за счет использования эффекта
статистического мультиплексирования в сетевом пакетном узле (шлюзе или
коммутаторе).
В этом случае К
пач
>1 и пропускная способность, которую надо выделить в
сетевом интерфейсе С
си
для N
сл
, гибко разделяется между несколькими
абонентами с учетом К
пач
:
С
си
= С
сл
* N
сл
/К
пач
, (кбит/с) (6)
где:
К
пач
– коэффициент пачечности, учитывающий эффект статистического
мультиплексирования (К
пач
=2…10);
С
сл
– пропускная способность одной соединительной линии, с учетом
скорости кодека и коэффициента избыточности.
N
сл
– число соединительных линии.
Рассчитаем пропускную способность при использовании аудиокодека
G.711, К
пач
возьмем равное 6:
С
си
= С
сл
* N
сл
/К
пач
=68,3*21/6=239,1(кбит/с)
Анализ угроз услугам VoIP.
При проектировании IP-телефонии нельзя не уделить внимание
безопасности предоставления услуг. Главная проблема в безопасности
заключается в том, что IP-телефония достаточно открыта, чем пользуются
злоумышленники, совершая атаки на ее компоненты.
Угрозы, которые могут быть применены к ТфОП, актуальны и для
составляющих IP-телефонии. Перечислим некоторые из них, часть из которых
рассмотрим более подробно:
- Перехват данных (подслушивание);
57
- Отказ от обслуживания (Denial of Service - DoS);
- Подмена номера;
- Кража сервисов;
- Неожидаемые вызовы;
- Несанкционированное изменение конфигурации;
- Мошенничество со счетом.
Рассмотрим некоторые угрозы услугам VoIP на примере схемы сети
проекта (Рисунок 15) [14]
Рис. 15 Схема возможных источников и объектов угроз
Рассмотрим детальнее эти объекты и источники.
В первую очередь следует обратить внимание на пограничный сервер
доступа в интернет и его программное обеспечение. В проектируемой сети он
выполняет функции фаерволла. Его задачи – предотвратить
58
несанкционированное проникновение из вне как в программное обеспечение
самого сервера, так и в ПО устройств, расположенных за ним и
поддерживающих протокол IP. Главным источником угроз является сеть
Интернет. Если не уделить достаточного внимания защите пограничного
сервера, то все угрозы, которые могут быть со стороны внешней сети, будут
направлены на устройства внутренней сети, которые поддерживают протокол IP.
Самая распространенная угроза – это DDoS-атака, которая заваливает
канал путем создания множества одновременных вызовов. Так же не исключены
целенаправленные вторжения в телефонную инфраструктуру. Проблема
обнаружение подобных атак состоит в том, что они обычно не являются
массовыми (за исключением DDoS-атак), и не создают аномальной нагрузки на
всю сетевую инфраструктуру. Обнаружить подобные явления могут только
специально установленное и настроенное программное обеспечение.
1. Коммутатор ЛВС (на рис. 15 SW1) может сам служить источникм
угроз, если его неправильно настроить. При грамотном конфигурировании он
способен предотвращать часть угроз с помощью ограничения и изоляции
трафика в данной сети с помощью виртуальных подсетей – VLAN и
правильно организованной защиты на базе списков доступа (ACL – Access
List Classes.
2. SIP-телефоны. Абонентские аппараты – одно из уязвимых мест
сети. К ним можно получить доступ как в следствие взлома паролей, так и
умышленных действий сотрудников. С таких телефонов можно совершать
телефонные звонки как через сеть Интернет, так и через сеть оператора ТфОП
по маршруту – SIP-телефон в сети организации, локальная сеть организации
VoIP, коммутатор ЛВС, сервер IP-телефонии, сервер доступа в интернет,
Интернет, сервер облачной телефонии Ростелеком, ТфОП.
3. Еще один из моментов, который может служить причиной дыры
в безопасности сети, это сервер IP-телефонии. Сервер производит
регистрацию телефонных абонентов в локальной сети и является основным
элементом сети VoIP, который управляет телефонными вызовами как в IP-
сети, так и в ТфОП. Именно он в первую очередь подвергается атакам из
внешней сети, таким как сканирование портов 5060 и 5061, подбор паролей к
59
веб-управлению сип-сервером. Если злоумышленник получает управление
сип-сервером, то он получает возможность регистрировать сторонних
абонентов, разрешая им вызовы в любую сеть, естественно, за счет
пострадавшей стороны. По этой причине следует уделять особое внимание
защите управления SIP-сервером.
Если сеть реализовывать по описанной схеме, то сервер в первую очередь
будет подвержен угрозам кражи трафика. Кражи реализуются через
множественные попытки регистрации на сервере. И если такая регистрация
окажется удачной, то будут осуществлены звонки за счет владельца.
Подразумевается перепродажа VoIP трафика через специальную биржу,
потому что именно в этом случае злоумышленник получает серьезную
экономическую выгоду.
Схема реализации данной атаки представлена на рисунке 16.
Рис. 16 Схема реализации кражи трафика
Так же стоит учесть, что при такой реализации возрастает риск атак,
направленных на отказ в обслуживании, что влечет за собой парализацию
выполнения процессов, связанных с использованием телефонной связи.
Так как атаки данного типа носят распространенный характер и
достаточно просты в реализации, необходимо предусмотреть методы защиты.
60
Перечисленные выше угрозы могут нанести серьезный материальный
ущерб организации в случае их удачных реализаций. Поэтому в первую
очередь необходимо продумать механизмы защиты от таких угроз.
ACL-списки на пограничном коммутаторе ЛВС являются
традиционным способом защиты, но не являются достаточно эффективным по
следующи причинам:
• Списки ACL обычно основаны на анализе информации в
заголовках уровня L2/L3/L4, не затрагивая анализа прикладных протоколов,
например – SIP.
• Значения IP-адресов, с которых производится проникновение в
сеть, не остаются постоянными и заранее неизвестны.
Поэтому лучшую защиту обеспечивают методы, основанные на более
глубоком анализе входящих пакетов, например, с использованием технологий
DPI.
Анализ SIP-запросов, который осуществляет ПО, поддерживающее DPI,
определяет адреса абонентов Б и частоту вызовов от абонента А. Эта
информация позволяет выстроить алгоритмы анализа аномалий во входящем
трафике.
Подобное ПО имеется на множестве специализированных для VoIP
сетей файрволлах, например, на базе SBC-контроллеров.
Однако, по причине высокой стоимости такого ПО в ООО «ЯМАЛ
МОТОРС» оно не используется.
Говоря о безопасности решения IP-ATC в целом нужно понимать, что
безопасность строится не только на безопасности самого Asterisk, так же
необходимо обеспечить безопасность и окружения Asterisk.
Система защиты IP-ATС строится на нескольких уровнях.
1.Сетевая защита.
2. Дизайн сети.
3. Анализ логов.
4. Конфигурация Asterisk.
5. Защита планом маршрутизации звонков (dialplan).
6. Конфигурация Linux.
61
7. Защита периферийных устройств.
8. Административные меры.
При развертывание системы важно использовать сетевой экран
(firewall). В Linux встроен мощный и гибкий инструмент IPTables, который
управляется командами.
При построении файервола предложено руководствоваться принципом
«все, что не разрешено — запрещено», поэтому политикой по умолчанию для
всех цепочек, в которых производится фильтрация трафика, будет сброс пакетов.
/sbin/iptables -P INPUT DROP
/sbin/iptables -P OUTPUT DROP
Цепочка FORWARD здесь не указана по той причине, что на сервере всего
один интерфейс, пересылка пакетов запрещена и отключена.
Для упрощения написания правил и обработки пакетов создадим
отдельные цепочки для обработки TCP, UDP и ICMP соединений.
/sbin/iptables -N tcp_packets_input
/sbin/iptables -N udp_packets_input
/sbin/iptables -N icmp_packets_input
Также создадим дополнительные цепочки для проверки TCP и ICMP
соединений.
/sbin/iptables -N allowed_tcp
/sbin/iptables -N allowed_icmp
Так для TCP соединений введем дополнительную проверку на то, что,
приходящий на сервер, ТCP пакет является SYN пакетом и одновременно
первым пакетом в соединении, в противном случае соединение просто
сбрасывается
/sbin/iptables -A allowed_tcp -p TCP --syn -j ACCEPT
/sbin/iptables -A allowed_tcp -p TCP -j REJECT --reject-with tcp-reset
Для ICMP соединений будем пропускать только определенные типы
пакетов, которые необходимы для работы утилит ping и traceroute.
/sbin/iptables -A allowed_icmp -p ICMP --icmp-type 8 -j ACCEPT
/sbin/iptables -A allowed_icmp -p ICMP --icmp-type 11 -j ACCEPT
Правила для цепочки INPUT выглядят следующим образом:
62
Пропускаем все пакеты уже установленных соединений, или соединений,
связанных с уже установленными, таким образом после прохождения этого
правила останутся только NEW и INVALID пакеты.
/sbin/iptables -A INPUT -p ALL -i enp4s0 -m state --state
ESTABLISHED,RELATED -j ACCEPT
Сортируем TCP, UDP, ICMP соединения по своим цепочкам.
/sbin/iptables -A INPUT -p tcp -i enp4s0 -s 172.16.0.0/24 -j tcp_packets_input
/sbin/iptables -A INPUT -p tcp -i enp4s0 -s 192.168.0.0/29 -j tcp_packets_input
/sbin/iptables -A INPUT -p udp -i enp4s0 -s 172.16.0.0/24 -j udp_packets_input
/sbin/iptables -A INPUT -p udp -i enp4s0 -s 192.168.0.0/29 -j
udp_packets_input
/sbin/iptables -A INPUT -p icmp -i enp4s0 -s 192.168.0.0/29 -j
icmp_packets_input
Принимаем все пакеты с loopback интерфейсa адресованных нам для
нормальной работы приложений.
/sbin/iptables -A INPUT -p ALL -i lo -s 127.0.0.1 -j ACCEPT
/sbin/iptables -A INPUT -p ALL -i lo -s 127.0.0.1 -j ACCEPT
Рассмотрим цепочки tcp_packets_input, udp_packets_input,
icmp_packets_input, в них указано каким устройствам на какие порты разрешено
производить соединение.
tcp_packets_input
В случае соответствия критерию правила пакет передается в цепочку
allowed_tcp, назначение которой описано выше.
Разрешаем sip через tcp для sip-устройств
/sbin/iptables -A tcp_packets_input -p TCP -m iprange --src-range <интервал
адресов sip устройств> --dport 5060 -j allowed_tcp
Разрешаем rtp через tcp для sip-устройств
/sbin/iptables -A tcp_packets_input -p TCP -m iprange --src-range <интервал
адресов sip устройств> --dport 10000:20000 -j allowed_tcp
Разрешаем ssh, sip для администраторов
/sbin/iptables -A tcp_packets_input -p TCP -m iprange --src-range <интервал
адресов администраторов> -m multiport --destination-port 22,5060 -j allowed_tcp
63
Разрешаем rtp через tcp для администраторов
/sbin/iptables -A tcp_packets_input -p TCP -m iprange --src-range <интервал
адресов администраторов> --dport 10000:20000 -j allowed_tcp
Сбрасываем TCP соединения, если они не подошли не под одно из правил
нашей цепочки.
/sbin/iptables -A tcp_packets_input -p TCP -j REJECT --reject-with tcp-reset
udp_packets_input
Разрешаем sip через udp для sip-устройств
/sbin/iptables -A udp_packets_input -p UDP -m iprange --src-range <интервал
адресов sip устройств> --dport 5060 -j ACCEPT
Разрешаем rtp через UDP для sip-устройств
/sbin/iptables -A udp_packets_input -p UDP -m iprange --src-range <интервал
адресов sip устройств> --dport 10000:20000 -j ACCEPT
Разрешаем sip для администраторов
/sbin/iptables -A udp_packets_input -p UDP -m iprange --src-range <интервал
адресов администраторов> --dport 5060 -j ACCEPT
Разрешаем rtp через udp для администраторов
/sbin/iptables -A udp_packets_input -p UDP -m iprange --src-range <интервал
адресов администраторов> --dport 10000:20000 -j ACCEPT
icmp_packets_input
Все пакеты, которые соответствуют критериям правил, переходят в
цепочку allowed_icmp, назначение которой также описано выше.
/sbin/iptables -A icmp_packets_input -p ICMP -m iprange --src-range
<интервал адресов администраторов> -j allowed_icmp
При проектирование и реализации системы необходимо обратить
внимание на дизайн сети.
При проектировании сети стоит учитывать, что если Asterisk будет
доступен из интернета, то это будет небезопасно для всей системы в целом.
Любая уязвимость в исходном коде Asterisk или простой пароль могут быть
запросто использованы злоумышленниками для получения доступа к серверу,
что, как говорилось ранее, позволит осуществлять звонки за счет компании. В
лучшем случае при таких атаках целью может быть отказ в обслуживании.
64
Регулярные установки обновлений Asterisk и стойкие пароли могут
снизить риски, но более эффективно будет использование специализированных
средств защиты, а именно – межсетевые экраны. Если подключать Asterisk так,
как это показано на рис. 15, то сервер будет безопасно закрыт за периметром
локальной сети.
Исходящий трафик от сервера Asterisk к SIP-провайдеру и обратно идет
через динамические правила NAT, настроенные на межсетевом экране. А VPN-
туннель обеспечит возможность подключения пользователей удаленных офисов.
Пользователь сначала подключается по VPN к сети предприятия, и уже потом,
по виртуальному каналу — к серверу Asterisk. Таким образом Asterisk больше не
доступен атакующим, так как не виден из внешней сети.
Еще один важный момент – разделение голоса и данных. Это позволяет
сделать Vlan. Компьютеры пользователей, сетевое оборудование, серверы,
находятся в одних Vlan-ах, а оборудование, работающее с Asterisk – в другом
влане.
Такое построение сети способствует тому, что возможные вирусы с
пользовательских машин, а так же сами пользователи, не могли навредить IP-
АТС и наоборот.
Asterisk и другие приложения журналируют свои действия в процессе
работы системы IP-АТС. Очень важно просматривать логи, так как в них
попадают абсолютно все действия: как штатного режима, так и
несанкционированного доступа. В логах имеется информация о подборе
паролей, попытках подключения, отслеживается контроль незапланированной
активности и множественных попыток подключений.
К сожалению, Asterisk не имеет встроенного анализатора логов, который
бы отслеживал определенные условия и предпринимал какие-либо действия над
соединением. Чтобы пресечь возможность взлома сервера Asterisk необходимо
отслеживать незапланированную активность. Одним из видов такой активности
является перебор паролей по словарю. Так как сам Asterisk не справится с этой
активностью и никаких действий не предпримет, предлагается использовать
внешнюю службы Fail2Ban, которая может работать со многими службами,
такие как Asterisk, Apache, ssh, ftp и другие. Обнаружить и ликвидировать –
65
основной принцип действия этой службы. Она читает логи, анализирует их и
если будут обнаружены множественные попытки входа, то данное соединение
будет заблокировано на уровне IPTables.
С помощью грамотно написанного dialplan (план маршрутизации звонков)
можно значительно повысить безопасность.
Поэтому было создано несколько отдельных контекстов для каждой
учетной записи, используемой для выхода не сеть оператора, а именно
[rtc<городской номер>_outgoing_local] — контекст для совершения
вызовов по городу;
[rtc<городской номер>_outgoing_free] — контекст для звонков на номера,
начинающиеся на 8800;
[rtc<городской номер>_outgoing_mobile] — контекст для совершения
вызовов на номера мобильных операторов;
[rtc<городской номер>_outgoing_long_distance] — контекст для
совершения междугородних звонков;
[rtc<городской номер>_outgoing_international] - контекст для совершения
международных звонков;
[rtc<городской номер>_outgoing_emergency] — контекст вызова
аварийных служб.
Все внутренние номера объединены в контекст [intern_phones_all].
Также внутренние абоненты разнесены по своим контекстам, что
позволяет гибко управлять правами доступа совершения вызовов при помощи
директивы include. Пример:
[direktor]
include => intern_phones_all
include => rtc<городской номер>_outgoing_local
include => rtc<городской номер>_outgoing_mobile
include => rtc<городской номер>_outgoing_free]
include => rtc<городской номер>_outgoing_long_distance
include => rtc<городской номер>_outgoing_emergency
include => bogus