Мы переехали! Новый адрес: г. Челябинск, ул. Рубежная, 17"А"
Навигация
АТС Samsung
АТС Panasonic
АТС SoftPBX
АТС LG
ATC PicStar
GSM шлюзы
VoIP
Техническая поддержка
Телефонные аппараты
Устройства записи телефонных разговоров

Он-лайн консультация
Отдел продаж
ICQ 177921272

GSM шлюз, как экономия

gsm шлюз экономия на связи 


Расчет затрат на связь

Расчет затрат на связь


Безопасный Asterisk

 Можно выделить следующие уровни (слои) безопасности:

  • физический уровень (физический доступ к серверу)
  • уровень операционной системы (Linux)
  • уровень Asterisk (безопасная настройка)
  • сетевой уровень (топология и свойства сети)
  • мониторинг

Безопасность на физическом уровне

Комплекс мер по обеспечению безопасности АТС начинается именно с ограничения физического доступа к серверу. Мы рассмотрим те угрозы, которые возникают в этом аспекте и способы их устранения.

Вывод сервера из строя / похищение

Самый простой тип атаки типа Отказ в Обслуживании (DoS, Denial of Service) - это физическое выключение сервера или разрушение аппаратных частей. Также в случае несоблюдения мер строго доступа в серверную злоумышленники могут похитить сервер или носители информации - жесткие диски, ленты, компакт-диски и другие средства, на которых может находиться бэкап конфигурации сервера или конфиденциальная информация (записи разговоров). Для минимизации данного рода рисков необходимо размещать сервер в зоне ограниченного доступа и выработать регламент входа / выхода обслуживающего персонала. Дополнительной мерой может быть крепление сервера к стойке тросом с замком.

Защита загрузчика

Если сервер оказался в руках злоумышленников на короткий интервал времени, или в результате похищения, первым делом будут предприняты попытки получения доступа супер-пользователя для внесения изменений в системные файлы и скрытия следов взлома. Одним из способ получения пароля root является нарушение нормальной процедуры загрузки сервера путем редактирования параметров загрузчиков GRUB или LILO. Например, если в параметрах загрузки ядра передать init=/bin/bash, при загрузке сервер не будут выполняться скрипты инициализации системы и порождения процессов login. Вместо этого сразу после загрузки ядра и модулей процесс init передаст управление программе bash, которая будет выполнена с рутовкой привилегией. Чтобы исключить данную ситуацию, следует использовать специальные директивы загрузчиков, запрещающие изменения параметров загрузки ядра, или требующих авторизации доступа для их проведения. Например, для загрузчика lilo это опции password и restricted. Для grub это опция password. Смотрите Grub set password и LILO set password.

Загрузка с CD диска (защита BIOS)

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

Консоль Asterisk

По-умолчанию, многие дистрибутивы Asterisk в момент загрузки сервера запускаются при помощи скрипта safe_asterisk, который отслеживает работающие процессы и перезапускает Asterisk в случае случайного падения. В скрипте safe_asterisk есть параметр TTY, который равен 9 (TTY=9). Данная опция при старте астериска открывает консоль под номером 9 (Alt+F9, или CTRL+ALT+F9 чтобы в нее переключиться). Учитывая возможность запуска из консоли команд ОС при помощи восклицательного знака, и учитывая, что по-умолчанию Asterisk работает под учетной записью суперпользователя, только обладая доступом к 9-й консоли можно легко скомпрометировать систему:

*CLI> 
*CLI> !bash
explorer ~ # whoami 
root
explorer ~ # 

Необходимо выключить занятие 9-й консоли путем комментирования строки с TTY=9.

Безопасность на уровне Linux

Asterisk - это обычное приложение, работающее в операционной системе Linux, и уровень защищённости Linux определяет общий уровень безопасности АТС. Выделим наиболее существенные правила, снижающие риски компрометации АТС.

Ограничение пользовательских экаунтов

Так как Asterisk - весьма нетребовательное к ресурсам сервера приложение (при средних нагрузках), то часто возникает соблазн использовать сервер не только для телефонии, но и для других нужд IT, таких как почта, доступ в интернет, корпоративный WEB, VPN, и тд. При этом, доступ с серверу имеет не только администратор АТС, но и его коллеги (администраторы, программисты). Обладая возможностью скачивать и/или компилировать программы, такие пользователи потенциально могут получить полный доступ к системе в результате уязвимости ядра или других компонентов ОС, и далее внедрить программу для скрытия следов присутствия, и, таким образом, надолго сохранить несанкционированное управление системой. Чтобы исключить такую возможность, следует закрыть все пользовательские экаунты в системе или принять ряд мер по их ограничению (использовать окружения chroot, виртуальные сервера, специальный патчи типа GrSecuritySELinux и др.).

Ограничение привилегий

Большинство приложений не требует супер-привилегий, в том числе и Asterisk. Однако, по умолчанию Asterisk работает под привилегией root. Чтобы это исправить, необходимо сделать следующее:

  1. Настроить в asterisk.conf параметры runuser и rungroup (например, добавить группу asterisk и пользователя asterisk, и запускать Asterisk под таким экаунтом).
  2. Сделать владельцем файлов /dev/zap/* пользователя Asterisk. Самый простой способ - использовать программу chown:
    chown -R asterisk.asterisk /dev/zap
    
    Однако, современные дистрибутивы используют динамические системы устройста, такие как udev или devfs. Например, в системе Gentoo Linux при установке Zaptel в папку /etc/udev/rules.d/ будет скопирован файл zaptel.rules, имеющий следующее содержание:
    # udev rules to generate the /dev/zap device files (if not yet provided 
    # by your distribution):
    KERNEL=="zapctl", NAME="zap/ctl"
    KERNEL=="zaptranscode", NAME="zap/transcode"
    KERNEL=="zaptimer", NAME="zap/timer"
    KERNEL=="zapchannel", NAME="zap/channel"
    KERNEL=="zappseudo", NAME="zap/pseudo"
    KERNEL=="zap[0-9]*", NAME="zap/%n"
    
    # zaptel devices with ownership/permissions for running as non-root
    SUBSYSTEM=="zaptel",  OWNER="asterisk", GROUP="asterisk", MODE="0660"
    
    Надо обратить внимание на то, какая учетная запись используется в опциях OWNER и GROUP, а также на режим MODE файлов. В результате применения указанного файла при загрузке модулей zaptel будут созданы следующие устройства:
    explorer ru # modprobe zaptel
    explorer ru # ls -l /dev/zap/
    total 0
    crw-rw---- 1 asterisk asterisk 196, 254 2008-10-21 03:35 channel
    crw-rw---- 1 asterisk asterisk 196,   0 2008-10-21 03:35 ctl
    crw-rw---- 1 asterisk asterisk 196, 255 2008-10-21 03:35 pseudo
    crw-rw---- 1 asterisk asterisk 196, 253 2008-10-21 03:35 timer
    explorer ru # 
    
  3. Исправление разрешений на папки. Так как при первоначальной установке и запуске Asterisk из-под привилении root были созданы файлы и папки, после смены учетной записи работы Asterisk доступа к этим файлам и папкам уже нет. Чтобы это исправить, надо запустить следующий скрипт:
    #!/bin/bash
    
    chown --recursive asterisk:asterisk /var/lib/asterisk
    chown --recursive asterisk:asterisk /var/log/asterisk
    chown --recursive asterisk:asterisk /var/run/asterisk
    chown --recursive asterisk:asterisk /var/spool/asterisk
    chown --recursive asterisk:asterisk /usr/lib/asterisk
    chown --recursive asterisk:asterisk /dev/zap
    #----------------------------------------------------
    chmod --recursive u=rwX,g=rX,o= /var/lib/asterisk
    chmod --recursive u=rwX,g=rX,o= /var/log/asterisk
    chmod --recursive u=rwX,g=rX,o= /var/run/asterisk
    chmod --recursive u=rwX,g=rX,o= /var/spool/asterisk
    chmod --recursive u=rwX,g=rX,o= /usr/lib/asterisk
    chmod --recursive u=rwX,g=rX,o= /dev/zap
    #----------------------------------------------------
    chown --recursive root:asterisk /etc/asterisk
    chmod --recursive u=rwX,g=rX,o= /etc/asterisk
    #----------------------------------------------------
    # Asterisk needs to write to voicemail.conf for password change.
    chmod g+w /etc/asterisk/voicemail.conf
    chmod g+w,+t /etc/asterisk
    #----------------------------------------------------
    
    

Выключение сервисов

Многие Linux дистрибутивы по-умолчанию запускают многие ненужные АТС сервисы, такие как служба печати, FTP, NFS и другие. Чтобы увидеть, какие службы открывают сетевые соединения, необходимо выполнить команду netstat -atnup | grep LISTEN:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN 3155/rpc.statd
tcp 0 0 127.0.0.1:32769 0.0.0.0:* LISTEN 3279/xinetd
tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN 3279/xinetd
tcp 0 0 0.0.0.0:199 0.0.0.0:* LISTEN 3256/snmpd
tcp 0 0 0.0.0.0:8008 0.0.0.0:* LISTEN 4843/httpd
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 3438/smbd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 3136/portmap
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN 3516/X
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 3265/sshd
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 3907/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 3299/sendmail: acce
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 4843/httpd

Приведен пример очень плохой настройки АТС, так как при старте сервера запускается целая серия ненужных процессов, каждый из которых является потенциальной мишенью злоумышленника. Чтобы устранить такие риски, необходимо отключить все ненужные службы. В таких дистрибутивах, как RedHat?CentOs? и других есть утилита ntsysv, предназначенная для управления автозагрузкой.

Шифрование дисков

Записи разговоров

Бронирование SSH

Служба SSH (Secure SHell), используемая для удалённого входа на сервер - это главная дверь в центр управления АТС. Зачем кому-либо вообще знать, что он существует? Обязательное мерой администратора АТС является изменения выполнение следующих мер, существенно повышающих общий уровень защиты системы.

  • Смена порта. Порт по умолчанию SSH - 22-ой. Многие хакеры сканируют интернет в поисках серверов с открытым портом 22, чтобы затем попробовать взломать их. Придумайте другой порт, в диапазоне 1-65535, и укажите его в директиве Port.
  • Явное перечисление пользователей, имеющих доступ к системе, в директиве AllowUsers. В том случае, если все же необходимо предоставить доступ к системе ряду доверенных лиц, перечислите их.
  • Используйте только SSH протокол версии 2.
  • Запретите прямой доступ пользователя root. Это существенно затруднит и скорее сделает невозможной атаку на перебор пароля, так как пользователю рут будет запроещен доступ в систему, даже если будет введен его корректный пароль. Используйте подсистему sudo для получения рутовского доступа при необходимости и только после удаленного входа в систему под непривилегированной учетной записью.
  • Используйте временное ограничение по вводу пароля или сертификаты. Установка минимально возможного времени для ввода пароля, например, 1 секунды, может хорошо сбить с толку злоумышленника.

Пример настроек /etc/ssh/sshd_config:

/etc/ssh/sshd_config
AllowUsers  alexa mary admin
Port 30222
Protocol 2
LoginGraceTime 1s
PermitRootLogin no

Блокирование открытых портов

Оставив только необходимые службы, следует также ограничить возможность сетевых подключений к ним с использованием брандмауэра. Хорошей практикой является использование нескольких сетевых интерфейсов в сервере АТС, где SIP протокол доступен только на внутреннем сетевом адресе, а объединение офисов осуществляется по IAX2 протоколу, с явным открытие на firewall IP адресов офисов и фильтрацией для всех остальных. В такой конфигурации у злоумышленника отсутствует физическая возможность атаковать сервер Asterisk с использованием уязвимостей VoIP протоколов. Также, если существуют риски атаки типа Denial Of Service (DoS), следует установить специальное оборудование, распознающее такой тип атак и автоматические блокирующее атакующего с уведомлением системного администратора.

Централизованное логирование

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

Контроль конфигурации

Существует специальные программные пакеты типа Tripwire, создающие "слепок" (md5 хеш) каждого файла в системе. Периодически запуская сканирование файлов и сравнение их со старыми отпечатками позволяет выявить следы замены системных утилит и встраивания rootkit'ов. В идеальном случае база данных Tripwire находится на другом сервере. Благодаря

Регулярное обновление

Необходимо подписаться на извещения о найденных уязвимостях в Linux/Asterisk и оперативно обновлять свои сервера в случае появления таковых. Также следует периодически обновлять всю систему, чтобы она отражала самые последние стабильные версии всех пакетов. Самую актуальную информацию о найденных в Asterisk уязвимостях можно получить на официальном сайте Asterisk - Asterisk security advisory.

Безопасная настройка Asterisk

На этом уровне рассматривается безопасность контекстов, экстеншенов, настройки каналов и пользовательских экаунтов, комманд диалплана и доступа к интерфейсу менеджера. Рассмотрим их более подробно.

Контекст default

Наиболее распространённой ошибкой администраторов Asterisk является неправильное использование контекста default. Контекст default следует использовать только в одном случае - если надо разрешить анонимные (гостевые) звонки, например, на адрес домена компании (SIP domain dialing). Однако, в большинстве случаев в контексте default администраторы описывают своих пользователей, планы набора и другие правила обработки вызова. Эта практика чревата тем, что злоумышленник сможет использовать такой сервер, бесплатно и безнаказанно совершая МГ/МН звонки, осуществляя DoS атаки и хулиганские выходки по отношению к внутренним пользователям. При разрешении гостевого звонка следует принять меры предосторожности в отношении перечисленных вопросов. Каким должен быть контект default по умолчанию? Очень простым:

exten => _X.,1,Hangup

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

Контексты каналов

Каждый тип канала имеет как контексты по-умолчанию, так и явно указанные для разных групп линий или пользователей. Следует помнить простое правило: если контекст в настройке линий или пира не указан, звонок попадет в тот контект, который указан в опции context секции general. Хорошей практикой является использования шаблонов, например:

[user](!)
type=friend
host=dynamic
context=users
nat=yes
qualify=yes
callgroup=1
pickupgroup=1
dtmfmode=rfc2833

[701](user)
secret=as09TYInbd873K
mailbox=701
callerid="User" <701>

[702](user)
secret=udFls34Dssd2
mailbox=702
callerid="User" <702>

В приведённом примере, если забыть указать наследование шаблона (user), пир создан не будет. Таким образом, можно избежать необходимости указывать контекст в каждом пире.

Разделение входящих и выходящих контекстов

Не следует определять в одном контексте как правила для входящих, так и для исходящих звонков. Типичный пример некорректной настройки - это использование одного контекста для исходящих звонков пользоваталей, внутренних звонков и звонков, поступающих по городским линиям. Например:

[default]
; local calls
exten => _7XX,1,Dial(SIP/${EXTEN})
; out calls
exten => _9XXX.,1,Dial(Zap/g1/${EXTEN:1})
; incoming calls to menu from FXO lines
exten => s,1,Answer
exten => s,n,Background(hello-please-enter-number-you-wish-to-call)
exten => s,n,WaitExten(5)
exten => s,n,Queue(support|t)

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

[users]
include => local-users
include => numberplan

[local-users] ; local calls
exten => _7XX,1,Dial(SIP/${EXTEN})

[numberplan] ; out calls
exten => _9XXX.,1,Dial(Zap/g1/${EXTEN:1})

[fxo-in] ; incoming calls to menu from FXO lines
include => local-users
exten => s,1,Answer
exten => s,n,Background(hello-please-enter-number-you-wish-to-call)
exten => s,n,WaitExten(5)
exten => s,n,Queue(support|t)

Все SIP пользователи должны иметь контекст users, в котором при помощи директивы include включаются правила внутрениих и внешних звонков. В настройках линий (zapata.conf) следует указать контекст fxo-in, в котром включается контекст local-users. Таким образом, изIVR компании можно будет связаться только с внутренними пользователями, что чаще всего и требуется.

IAX2 аутентификация

Отдельного упоминания заслуживает алгоритм аутентификации IAX2 соединений. При входящем IAX2 звонке Asterisk выполняется следующие последовательности проверок.

  • Если пристутствует поле username:
    • Ищет в файле конфигурации iax.conf (и включенных из него файлов) секцию, имя которой совпадает с username, в котрой type=user. Если совпадений не найдено, произойдет закрытие канала.
    • В найденной секции проверяется наличие параметров allow/deny, и если IP адрес звонящего совпадает с deny, или не проходит цепочку allow, звонок завешается.
    • Проверяется пароль. Если пароли не совпадают, звонок завершается.
    • Если во входяшем звонке указан контекст назначения, Asterisk проверяет наличие в настройках пира записи context=требуемый контекст.
    • Если контекст не указан, звонок направляется на обработку в первую запись context=, наденную в настройках пира.
  • Если в заголовке сообщения нового звонка не содержится поле username, Asterisk выполняет следующее:
    • выполняет поиск секции type=user, в которой нет поля secret, и есть атрибуты allow/deny. Если такой пир найден, звонок принимается, и именем username звонящего становится название совпавшей секции.
    • Выполняет поиск секции type=user, где нет поля secret, и нет атрибутов allow/deny. Если такая секция найдена, звонок принимается, и именем username звонящего становится название этой секции.
    • Если совпадений выше найдено не было, Asterisk ищет секцию type=user, с указанным паролем secret или RSA ключем одновременно с allow/deny фильтром. Если такая секция найдена, и все проверки пройдены, астериск принимает звонок, и устанавливает именем username название секции.
  • Выполнеяет поиск секции type=user с установленным паролем secret (или RSA ключем), но без фильтров allow/deny. Если проверка по паролю проходит, звонок принимается, и значение username устанавливается равным названию совпавшей секции.
  • Asterisk отвергает звонок.

Какие возможные неожиданные последствия имеет такая схема аутентификации? Можно применять атаку типа brute force (грубой силы), перебирая пароли пользоваталей, даже не зная их username ! При достаточном количестве записей пиров в iax.conf, вероятность подброра пароля к одной из них весьма высока. Как снизить риски такой атаки?

  • Включить замедленную реакцию (delayreject=yes в [general] настройках iax.conf). Это позволит замедлить посылку негативного ответа сервера. снижая скорость перебора по словарю. Однако, злоумышленник может предположить о наличии данной опции, и перестроить атаку, не ожидая ответа, полагая, что положительный ответ придет быстро.
  • Использовать атрибуты-фильтры allow/deny.
  • Создать специальный гостевой экаунт без пароля и сетевых ограничений. Таким образом, алгоритм аутентификаии "сработает" до проверки пароля, и атака по словарю уже не имеет смысла, так как принимается звонок с любым паролем. Вот так выглядит гостевой экаунт: iax.conf
    [guest]
    type=user
    context=guest 
    
    extensions.conf
    [guest]
    exten => _X.,1,Hangup
    exten => i,1,Hangup
    
    Однако, открытие гостевого входа чревато другими последствиями - атаками по типу отказа в обслуживании. Поэтому наиболее сильной защитой IAX2 пользоваталей будет использование аутентификации по RSA ключам, так как подобрать такой ключ практически невозможно.

Примечение. type=friend покрывает type=user (включает его).

Шаблоны номера

Есть определённые тонкости в указании маски шаблона (extension pattern). Например, администратор настроил, чтобы локальные звонки проходили через собственные линии компании, а МГ/МН звонки шли на SIP провайдера. Какое из правил в примере совпадет с номером 2323956?

exten => _X.,1,Dial(SIP/${EXTEN}@provider)
exten => _XXXXXX,1,Dial(Zap/g1/${EXTEN})

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

snowflake*CLI> dialplan show 2323956@users
[ Included context 'numberplan-users' created by 'pbx_config' ]
  '_XXXXXXX' =>     1. _XXXXXX,1,Dial(Zap/g1/${EXTEN})   [pbx_config]

-= 1 extension (1 priority) in 1 context. =-

На выводе будет точно указано, какая из строк плана набора вызовет совпадение. В нашем примере, если во второй строке указать не _XXXXXX, а _XXXXXX. (с точкой в конце), то все звонки будут попадать под маску _X. и уходить по SIP каналу, вместо Zap.

Особое предупреждение относится к маске _. - она совпадает со всеми возможными вариантами, включая служебные екстены h,s,i и другие. И между тем, это одна из самых распространённых ошибок молодых администраторов. Более подробно о масках и правилах совпадения можно узнать на http://voip-info.org.

Другой частой ошибкой администратора АТС Asterisk является опечатка [Ad: :-)] Чтобы убедиться, что все набрано правильно, надо использовать команду Astersik

*CLI> dialplan show numberplan-users
[ Context 'numberplan-users' created by 'pbx_config' ]
  '_0X.' =>         1. Macro(trunkdial|${TRUNK_2}|${EXTEN:1)})    [pbx_config]
  '_[2-9]XXXXXXXXX' => 1. Macro(trunkdial|${TRUNK_1}|${EXTEN})       [pbx_config]
  '_XXXXXXX.' =>    1. Macro(trunkdial|${TRUNK_1}|${EXTEN})       [pbx_config]
  '_XXXXXXX' =>     1. Macro(trunkdial|${TRUNK_1}|${EXTEN})       [pbx_config]

-= 4 extensions (4 priorities) in 1 context. =-

Caller ID

Caller ID - это идентификатор абонента в виде "Имя абонента" <номер абонента>, например, "Иван Иванов" <701>. Многие цифровые и VoIP телефоны обладают дисплеем, на котором отражают Caller ID звонящего. Пользователи могут не догадываться о том, насколько просто поменять Caller ID, если он четко не приязан, и осуществить атаку по типу Caller ID spoofing (подмена caller id) для получения каких-либо преимуществ или нанесение вреда. Администратору АТС следует четко назначать абонентам Caller ID, как показано в примере ниже:

explorer asterisk # cat /etc/asterisk/sip_users.conf 
[701](user)
secret=secret
mailbox=701
callerid="Max" <701>

[710](user)
secret=secret
mailbox=710
callerid="Masha" <710>

В приведённом примере при каждом исходящем звонке Астериск будет "перебивать" Caller ID номер и имя. Также необходимо "перебивать" Caller ID на исходящих звонках на SIP провайдера. При терминации voip звонка в ТФОП провайдер все равно подставит свой номер. Если не скрывать свой номер перед посылкой звонка на SIP провайдера, он может получить полное представление о внутренних номерах компании, по которым сделать вывод об иерархии и активировать выборочную запись разговоров. Поэтому перед отправкой звонка рекомендуется делать следующие манипуляции:

exten => _X.,1,Set(CALLERID(all)="Anonymous" <000>); We do not reveal our users to ISPs! 
exten => _X.,n,Dial(SIP/${EXTEN}@provider)

Терминация VOIP трафика

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

Привязка пользователя к IP адресу

Чаще всего SIP пользователи находятся в локальной сети с постоянными IP адресами, или централизованно управляемыми при помощи DHCP. В качестве дополнительной меры безопасности можно явно указывать адрес для подключения конкретного пира, например:

[701](user)
secret=secret
mailbox=701
callerid="Max" <701>
host=192.168.7.1

[710](user)
secret=secret
mailbox=710
callerid="Masha" <710>
host=192.168.7.10

Если политикой безопасности Вашей компании разрешено удаленное подключение к системе, и вы используете директивы host=dynamic, можно повысить защищённость путем задания явно разрешенных или запроещенных хостов или сетей при помощи директив permit/deny, как показано в примере ниже:

[701](user)
secret=secret
mailbox=701
callerid="Max" <701>
host=dynamic
deny=0.0.0.0/0.0.0.0
permit=195.242.0.0/255.255.0.0

В данной настройке разрешается подключение только из сети 195.242.0.0/16.

Порты по умолчанию

Канала SIP, IAX2 и другие VOIP протоколы имеют зарезервированные IANA номера портов. Например, для SIP это порт 5060, для IAX2 - 4569. Однако, в целях укрепления безопасности АТС, следует в обязательном порядке менять все порты по умолчанию. В этих целях испольуются директива port.

Одновременное количество разговоров

Рассмотрим случай, когда по какой-либо причине SIP экаунт Вашего пользователя скомпрометирован. Например, в результате подключения с публичного компьютера отеля или интернет-кафе пользователь забыл удалить конфигурацию софтфона, и SIP username/password попал в руки злоумышленника, который продает полученную учётную запись SIP пира на "черном рынке" VOIP трафика. В этом случае, если не ограничить в Астериск количество максимально возможных одновременных разговоров на пользователя, через АТС может пройти большое количество звонков, до тех пор, пока это не заметят. Но даже после блокирования скомпрометированной учетной записи счет за переговоры предъявить будет некому. В подавляющем большинстве случаев пользователи делают один исходящий звонок. Исключение составляет приглашения в конференцию. В любом случае, администратору следует установить лимит в 1 одновременный звонок по-умолчанию для всех, явно увеличивая лимит там где это необходимо. Лимит на одновременные звонки устанавливается при помощи функции GROUP, а проверяется при помощи GROUP_COUNT.

; Check if peer is in use and call waiting is active
[check-simult]
exten => _X.,1,Set(GROUP()=${EXTEN})
exten => _X.,n,GotoIf($[ ${GROUP_COUNT()} > 1 ]?busy)
exten => _X.,n,Return
exten => _X.,n(busy),Goto(macro-stdexten,s-BUSY,1)

[numberplan]
exten => _X.,1,Gosub(check-sumult,${EXTEN},1)
exten => _X.,n,Dial(SIP/${EXTEN}@provider)

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

Протоколирование разговоров

Asterisk сохраняет всю информацию о сделанных звонках в CDR (Call Detail Record) файле Master.csv, расположенном в /var/log/asterisk/cdr-csv. Дополнительным средством контроля над объемом совершаемых пользователям переговоров является ведение индивидуальных CDR файлов по каждому пользователю. Чтобы этого добиться, необходимо задать параметр accountcode в настройках пира или линии пользователя. Asterisk будет сохранять информацию о звонках как в файле Master.csv, так и в файле с именем, равным accountcode. Параметр account коде может принимать любое значение, подходящее в качестве названия файла. Помимо записи CDR файлов, Asterisk обладает возможностью взаимодействия с базой данных. В случае, если злумышленник овладел серверов, и удалил в CDR файлы, записи в базе остануться (конечно же учетной записи астериска в базе надо давать только одну привилегию - INSERT).

Минимально необходимый план набора и конфигурации каналов

При установке Asterisk первый раз в документации рекомендуется выполнить команду make samples, которая скопирует примеры конфигурационных файлов в папку /etc/asterisk/. Данные примеры файлов не являются продуманными с точки зрения безопасности, поэтому рекомендуется удалить все, что не имеет отношения к конфигурации, и оставить только то, что требуется. В частности, обязательно надо удалять контекст demo.

=== Интерфейс менеджера (AMI)

  • bind,deny,permit + firewall
  • привилегии на команды
  • SSL

Сетевой уровень

Разделение сегментов

Физическое отделение данных от VoIP === Система DNS ====

DoS

RTP сниффинг

Шифрование разговоров

Материалы, использованные в процессе подготовки публикации


Расчет стоимости АТС

Заявка на расчет стоимости АТС


Заявка на выезд

 


Реализуем АТС Samsung
АТС SAMSUNG зарекомендовали себя на рынке телекоммуникационного оборудования как стабильная техника, полностью адаптированная под российские каналы передачи связи, с широкими техническими возможностями, что делает мини атс Samsung оптимальным выбором для организации корпоративной телефонной сети . Подробную информацию о наличии, стоимости и условиях приобретения мини АТС Samsung Вы можете получить у наших менеджеров.

Оборудование | Услуги | О компании | Контакты
Copyright © 2010-2015 АлександриД - Системы связи. Все права защищены.
Каталог Инфозавр.Ру Вся промышленность Челябинск