Доброго времени суток, Вам, жители Хабра.
Случилось так, что я прошел курс дистанционного обучения по теме «Информационная Безопасность», по завершению которого необходимо было защитить выпускную работу. Темой для данной работы я выбрал «Безопасность Asterisk», касательно данной темы написано очень много статей и публикаций, но на мой взгляд они либо не полны, либо целиком не раскрывают данную тему, либо нет указаний на актуальность данного вопроса. Взял на себя смелость собрать «все» в один документ, что и вылилось в выпускную работу. Защитился успешно, диплом получен — решил поделится с сообществом данной работой. 


1. Риски, связанные с IP-АТС Asterisk

Всем известно, что в век информационных технологий, огромные убытки организациям приносят действия злоумышленников (хакеров). Как правило, наиболее болезненными являются атаки, направленные на причинение вреда организации или на прямое воровство средств. Не смотря на то, что Asterisk – это телефонная станция, базирующаяся на компьютерной платформе, но за счет того, что каналы связи идут через интернет (некоторые сервисы системы являются открытыми для внешнего мира), хакеры имеют возможность получить несанкционированный доступ к системе.
При построение системы безопасности для решений в области IP-телефонии важно осознавать возникающие риски. В общем случае их можно выделить следующим образом: 
1. Нарушение конфиденциальности и искажение содержимого. Перехват сессии.
2. Проникновение в сеть организации через уязвимости, появившиеся при разворачивание IP-телефонии.
3. Действия, направленные на ухудшения сервисов (Dos-атаки).
4. Перепродажа трафика (Toll-Fraud).
Перепродажа трафика — один из наиболее удобных способов зарабатывания денег хакерами. Взломав станцию и направив звонки на дорогие международные направления, хакер получает некое вознаграждение на свои электронные кошельки, далее которые обналичиваются и получаются реальные деньги. Рассмотрим более подробно типичную схему перепродажи трафика. 
Есть хакер, который хочет заработать денег путем перепродажи трафика. Он идет на биржу сливного трафика, регистрируется и получает какой-то пул номеров, которые могут его идентифицировать в дальнейшем. Далее через некие подставные сервера обнаруживаются и если, получается, взламываются сервера IP-ATC. Далее на номера, которые были предоставлены хакеру на бирже сливного трафика, начинают идти звонки. Звонки платные. Допустим, звонок стоит 10 руб. (оплата жертвы оператору). Звонок направляется, как правило за рубеж (как правило это Куба, Палестина, Румынию, Латвия итд.), в страны где не уделяется должного внимания кибер-преступности, то есть где есть возможность заниматься такого характера бизнесом. И так Жертва платит ОС (Оператор связи) 10 руб за минуту. ОС выходит на международные линии через ОМТ (оператор международного трафика), которому он платит в районе 8 руб. за минуту, далее ОМТ направляет звонок на местного оператора (Куба, Палестина, и др.), который занимается «отмывом» голосового трафика и платит ему уже 6 руб. за минуту, данный оператор находится в доле и он распределяет деньги следующим образом – часть денег идет ему в оплату за услуги (так скажем, зарабатывает эту сумму – оставляет у себя на счету), а честь денег направляет на биржу сливного трафика, где зарегистрирован хакер. Далее биржа, оставив себе один рубль, два платит хакеру. Наглядна, схема изображена на рис.1. 
Рис.1. Схема перепродажи Voip трафика


С учетом того, что направления выбираются дорогие и поток звонков интенсивный, хакер получает не плохую прибыль. А в связи с тем, что порой системы не защищены надлежащим образом, то взлом происходит быстро и без каких либо трудоемких и финансозатратных вещей — Asterisk становится «красной тряпкой». Ну и после всех манипуляций жертва получит большой счет (10-100 000 рублей) по телефонии. 
К сожалению такого рода проблемы, последнее время стали частыми. Поэтому многие считают, что Asterisk небезопасная система. Однако этот тезис хочется оспорить. Во-первых, если говорить о возможности самого Asterisk, то у него очень богат набор инструментов для обеспечения безопасности. Инструментарий зашиты Asterisk сильнее, чем у многих конкурентов. Тем не мение Asterisk очень часто подвергается взломам. Как же так? Почему так? Дело все в администраторе данной системы. Нет единой галочки для активации безопасности Asterisk. Безопасность Asterisk — это принятие ряда комплексных мер, про которые, как правило администраторы забывают, тем самым подвергают Asterisk угрозам. 

2. Многоуровневая защита IP-АТС Asterisk

Говоря о безопасности решения IP-ATC в целом нужно понимать, что безопасность строится не только на безопасности самого Asterisk, так же необходимо обеспечить безопасность и окружения Asterisk. 
Система защиты IP-ATС строится на нескольких уровнях.
1. Сетевая защита.
2. Дизайн сети. 
3. Анализ логов.
4. Конфигурация Asterisk.
5. Защита планом маршрутизации звонков (dialplan).
6. Конфигурация Linux.
7. Защита периферийных устройств.
8. Административные меры.
Если определить глобально в чем состоит проблема Asterisk в разрезе безопасности, то как оговаривалось выше – это проблема заключается в не компетентности администратора Asterisk.
В силу того, что есть «коробочные решения» — установил и заработало, мы получаем очень большое количество установленных серверов Asterisk без надлежащей настройки безопасности и необходимой квалификации администратора, следствием чего получаем взломанный Asterisk, потеря финансовых средств организации, ну и тень на имя Asterisk. Либо не грамотный интегратор не надлежащим образом установил сервер и после оплаты он исчезает. А клиент позже получает огромные счета по телефонии либо оператор блокирует их направления.
Рассмотрим типичные ошибки, которые допускают начинающие администраторы Asterisk.
1. Слабые пароли на внутренних номерах (Отсутствие паролей, пароль такой же как ext).
2. Отсутствие сетевого экрана (Отсутствие iptables, либо выключен iptables, либо настроен не верно).
3. Старые дистрибутивы и Программное обеспечение (Старое ПО может содержать уязвимости. Необходимы постоянные обновления системы. Как пример trixbox не поддерживается более, не обновляется – имеется уязвимости).
4. Стандартные логины и пароли (Web интерфес, Sql, оборудование).
5. Дизайн сети (Asterisk и оборудование, работающее с ним на внешнем адресе, но без защиты – это лакомый кусочек для хакеров).
6. Ошибки в конфигурации.
7. Отсутствие контроля за системой (Поставили и забыли, нет контроля логов). 

2.1 Сетевая защита
При развертывание системы важно использовать сетевой экран (firewall). В Linux встроен мощный и гибкий инструмент IPTables, который управляется командами. По умолчанию IPTables настроен следующим образом 
-A INPUT –m state --state ESTABLISHED,RELATED –j ACCEPT (разрешаем пакеты для уже установленных соединений)
-A INPUT –p icmp –j ACCEPT (разрешаем пакеты протокола icmp)
-A INPUT –i lo –j ACCEPT (разрешаем трафик с интерфейса lo)
-A INPUT –m state --state NEW –m tcp –p tcp –dport 22 –j ACCEPT (разрешаем новое соединение ssh)
-A INPUT –j REJECT --reject-with icmp-host-prohibited (запрещаем все остальные входящие соединения)
-A FORWARD –j REJECT — reject-with icmp-host-prohibited (запрещаем все транзитные соединения)
COMMIT
Данный «конфиг» определяет – Разрешаем инициируемые нами соединения, запрещаем все входящие соединения кроме ssh. Далее настраиваем под свои задачи. Конфиг находится здесь /etc/sysconfig/iptables. Для настройки IPTables главное понять философию данного инструмента. Суть написания правил заключается в создание «цепочек», в которые загоняется трафик согласно неким классификаторам (-s source, -p protocol, -i interface …..), где происходит действие над трафикам – либо разрешаем, либо запрещаем, либо пробрасываем в другую цепочку. Если трафик пробежал все цепочки и не попал не под какое правило – неопределенный трафик (не один классификатор не отработал), трафик запрещаем. То есть к примеру, для того чтобы к серверу Asterisk могли подключаться ip-телефоны, софтфоны из внутренней сети, нам необходимо прописать правило
-A INPUT –s xxx.xxx.xxx.xxx/24 –j ACCEPT 
Данным правилом мы разрешаем входящие соединения из сети xxx.xxx.xxx.xxx\24. Так как пакет по правилам проходит сверху вниз, надо понимать, что данное правило будет работать если мы его пропишем выше чем запрещающие правила. Таким образом, можно настроить сетевой экран, что Asterisk будет обслуживать только те направления и только те пакеты, которым мы заведомо доверяем, и злоумышленнику будет практически невозможно добраться до сервера. Можно более гибко настроить логику сетевого экрана – создаем на каждую группу пакетов свою цепочку (Admin, SIP, IAX2….) со своими правилами, а в основной цепочке INPUT, согласно правилам пакеты направляются по своим цепочкам, где к ним принимаются соответствующие действия.

2.2 Дизайн сети
При проектирование и реализации системы необходимо обратить внимание на дизайн сети. 
Часто без какой-либо нужды Asterisk подключают в сеть по самой уязвимой схеме, изображенной на рис. 2.
Рис.2. Не рекомендуемая схема подключения Asterisk на внешний адрес

Факт доступности Asterisk из Интернета — главная угроза безопасности всей системы. Любой слабый пароль или любая уязвимость в исходном коде Asterisk могут быть использованы атакующими чтобы получить несанкционированный доступ к АТС и звонить за счет компании-владельца сервера Asterisk. В лучшем случае целью атакующих может стать отказ в обслуживании.
Стойкие пароли и регулярные обновления, конечно же, снижают риск. Еще сильнее его можно снизить специализированными средствами защиты, а именно — межсетевыми экранами (МЭ). Если подключать Asterisk так, как это показано на рис. 3, то сервер будет безопасно закрыт за периметром локальной сети.
Рис. 3. Рекомендуемая схема подключения Asterisk с использованием МЭ

МЭ пропускает исходящий трафик от сервера Asterisk к SIP провайдеру и обратно через динамические правила NAT. А возможность подключения пользователей удаленных офисов обеспечивается через VPN-туннель. Пользователь сначала подключается по VPN к сети предприятия, и уже потом, по виртуальному каналу — к серверу Asterisk. Asterisk больше не виден из внешней сети, недоступен атакующим.
Так же отметим еще один важный аспект, на который необходимо обратить внимание – это разделение данных. Важно разделить голос и данные, посредством постройки Vlan. Компьютеры, сервера, другое сетевое оборудование должны находиться в одних Vlan-ах, а оборудование, работающее с Asterisk (сам сервер, gate, ip-телефоны…) в другом Vlan-е. Это делается для того чтобы сами пользователи, а так же возможные вирусы на пользовательских машинах не могли навредить IP-ATC и наоборот. Схема с Vlan представлена на рис. 4.

Рис. 4. Разделение голоса и данных в разные Vlan.


2.3 Анализ логов
В процессе работы системы IP-ATC сам Asterisk и другие приложения журналируют все свои действия. Так как в лог попадают данные, как о санкционированных действиях, так и о несанкционированных действиях, то очень важно периодически просматривать их на предмет инцидентов. Необходимо проводить контроль подключений, контроль подбора паролей, отслеживание множественных попыток подключений, контроль незапланированной активности. 
В инструментарии Asterisk нету такого инструмента как анализатор логов, который бы при определенных условиях принимал некие действия над соединением. Есть незапланированная активность, которую важно отслеживать, дабы пресечь возможность взлома сервер Asterisk, одной из таких активностей является подбор паролей (перебор паролей по словарю). Вот такого инструмента, который бы пресекал возможность перебора паролей у Asterisk нет, а поскольку это важный момент в безопасности – предлагается использовать внешнюю службу Fail2Ban, которая может работать со многими службами, такие как Asterisk, Apache, ssh, ftp и другие. Работа этой службы основывается на одном принципе «Обнаружить и ликвидировать», служба «читает» логи, анализирует их и при обнаружение множественных попыток входа, блокирует данное соединение на уровне IPTables. На рис.5 показана работа службы Fail2Ban.
Рис. 5. Принцип работы Fail2Ban

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

2.4 Конфигурация Asterisk
В данной главе рассмотрим защиту системы на уровне конфигурации Asterisk. И так, что мы должны настроить в самом Asterisk, что бы повысить безопаcность IP-ATC. 
В случае если Asterisk «сидит» на внешнем адресе и при этом нет возможности использовать IPTables (ситуация когда нужно подключить устройство с динамическим ip адресом), либо не используется vpn, то первое, что нужно сделать это изменить стандартный порт 5060 (sip) на любой другой. Тем самым мы отведем от себя подозрения, что наш сервер Asterisk и не будут его дальше атаковать. Обезопасимся от BruteForce-атаки снаружи.
Как это сделать. Правим файл sip.conf
[general]
;bindport=5060; Закомментировали стандартный параметр.
bindport=9060; Меняем port по умолчанию на другой свободный — в целях безопасности. 
Не забываем на оконеченных устройствах указывать порт, на который мы изменили стандартный. Так как по умолчанию устройства будут стремиться подключится к Asterisk по порту 5060, и ничего не получится. 
Чем еще мы можем повысить безопасность системы на уровне конфигурации sip.conf.
[general]
alwaysauthreject=yes ; Защищаем сервер от перебора по номерам. Если будет значение no, то сервер будет добросовестно отвечать, что нет такого абонента, до тех пор, пока злоумышленник не угадает существующий ext, тогда сервер ответит, что пароль не верен. Тем самым злоумышленник узнает о существование внутреннего номера, останется только подобрать пароль. Далее уже идет перебор по паролю для вполне конкретного внутреннего номера. Опция yes позволяет отклонять запросы об аутентификации для существующих пользователях с такой же причиной, как и для несуществующих. Тем самым усложняем мошенникам возможность выяснить существующие ext.
allowguest=no; Запрещаем подключения к серверу в режиме прямых sip звонков, так называемые гостевые звонки, когда можно вызвать абонента по его E-mail.
bindaddr=xxx.xxx.xxx.xxx; На каком адресе Asterisk будет слушать сетевые соединения по протоколу sip. Это если сервер подключен к различным сетям, то лучше явно указать из какой сети принимать sip.
[1000]
deny=0.0.0.0/0.0.0.0; Запрещаем подключение со всех адресов
permit =xxx.xxx.xxx.xxx/24; Разрешаем подключения из сети xxx.xxx.xxx.xxx
secret=bdDfg12312fc; Необходимы стойкие пароли, отличные от стандартных вещей (admin, ext,1000, password…)
call-limit=2 ; Выставляем ограничение на количество одновременных линий для абонента.

2.5 Защита планом маршрутизации звонков (dialplan)
С помощью грамотно написанного dialplan (план маршрутизации звонков) можно значительно повысить безопасность. Первое, что рекомендуется – это разделение абонентов на контексты со своими правилами маршрутизации. 
В sip.conf
[1000]
context=from_chef
[1001]
context=from_it
[1002]
context=from_fin
Разделение по контекстам дает нам возможность наделить разными правами абонентов на телефонную связь. Это важно, так как не всем нужно, допустим, звонить на международные направления. Далее контекстам назначаем правила. В extension. conf 
[allow]
exten =>_X.,n,Dial(SIP/operator/${EXTEN}) ; Разрешаем любые звонки через Оператора 
exten => _[12]XXX,n,Dial(SIP/${EXTEN}); Разрешаем внутренние соединения
[from_chef]
exten=> _X.,n,Goto(allow, ${EXTEN},1); Все звонки направляем в контекст [allow]
[from_it]
exten=> _9810.,n,Hungup(); Ограничиваем международные направления
exten=> _X.,n,Goto(allow, ${EXTEN},1); Все звонки направляем в контекст [allow]
[from_fin]
exten=> _9810.,n,Hungup(); Ограничиваем международные направления
exten=> _989.,n,Hungup(); Ограничиваем направления на сотовые направления.
exten=> _X.,n,Goto(allow, ${EXTEN},1); Все звонки направляем в контекст [allow]
Тем самым финансовому отделу запрещаем звонки на международные направления и на сотовые направления. It подразделению запрещены только международные направления. Ну а руководителю разрешаем любые соединения.
Для того чтобы получать информацию о запрещенных звонках на почту, научим Asterisk фискалить о нарушениях. Для это добавим еще один контекст [alarm].
[alarm]
exten => _9810X.,1,playback(zapresheno); Уведомляем абонента о том, что ему запрещено данное направление.
exten => _9810X.,n,System(echo «To» ${EXTEN} «Ext» ${CALLERID(num)} | mail -s «8-10 ALARM» it_admin@list.ru); Фискалит на почту если будут международные звонки. 
exten => _9810X.,n,Hangup() ; кладем трубку. 

И направляем в этот контекст запрещенные звонки
[allow]
exten =>_X.,n,Dial(SIP/operator/${EXTEN}); Разрешаем любые звонки через Оператора 
exten => _[12]XXX,n,Dial(SIP/${EXTEN}) ; Разрешаем внутренние соединения
[from_chef]
exten=> _X.,n,Goto(allow, ${EXTEN},1) ; Все звонки направляем в контекст [allow]
[from_it]
exten=> _9810.,n,Goto(alarm, ${EXTEN},1) ; Направляем международные звонки в контекст [alarm] 
exten=> _X.,n,Goto(allow, ${EXTEN},1); Все звонки направляем в контекст [allow]
[from_fin]
exten=> _9810.,n, Goto(alarm, ${EXTEN},1) ; Направляем международные звонки в контекст [alarm] 
exten=> _989.,n,Hungup() ; Ограничиваем направления на сотовые направления.
exten=> _X.,n,Goto(allow, ${EXTEN}) ; Все звонки направляем в контекст [allow]
Таким образом, не только блокируем запрещенные направления, но и в случае инцидента получаем сообщение кто (ext) пытается дозвониться. Тем самым вовремя сможем понять, что сервер взломан, а не тогда когда придут огромные счета за связь.
Вот чем и хорошо Asterisk, dilplan позволяет гибко настроить маршрутизацию. Можем запрещать направления по различным параметрам, можем разграничивать права абонентам, можем настроить уведомления о запрещенных звонках, так же можно настроить ограничение звонков по времени, можем настроить звонки по вводу pin-кода и многое другое, что позволяет повысить безопасность IP-ATC. Pin-код рекомендуется использовать для удаленных пользователей с динамическим ip-адресом, так как ограничение по permit/deny и по iptables невозможно, в данном случае желательно закрыть международные направления, изменить стандартный порт (5060) на что-то свое, ну и звонки маршрутизировать по pin-коду. 

2.6 Конфигурация Linux
Как в самом Asterisk так и в самой ОС Linux есть службы, которые по умолчанию запускаются, но они для работы не нужны. Поэтому одной из рекомендацией считается необходимость отключить не используемые службы (модули) как в Asterisk, так и в Linux.
Asterisk загружает большое количество модулей, которые в принципе могут никогда и не пригодится — различные кодеки, команды, средства для работы с БД, каналы. Отключение лишних модулей позволит не только освободить память, но и делать IP-ATC менее уязвимой. Чего мы и добиваемся. И так как это можно сделать. 
В файле /etc/asterisk/modules.conf прописан параметр autoload=yes, который заставляет Asterisk при загрузке инициализировать и запускать все службы, которые находятся в папке /usr/lib/asterisk/modules. Для того чтобы запретить запуск той или иной ненужной службы, необходимо в файле /etc/asterisk/modules.conf прописать следующие строки 
noload => chan_gtalk.so; Модуль канала Gtalk.
noload => app_morsecode.so; Передача заданной строки азбукой Морзе.
noload => cdr_pgsql.so ; Модуль для хранения данных CDR в БД PostgreSQL.
и другие в зависимости от того какие модули необходимы а какие нет.
Так же непосредственно в самом Linux есть службы, которые загружаются, но возможно не нужные для работы IP-ATC – их тоже желательно отключить. Командой chkconfig –list можно посмотреть, какие службы запускаются, и определится, какие службы лишние. Допустим, в CentOS 5 по умолчанию загружается служба bluetooth, на телефонной станции Asterisk эта служба не нужна, уберем ее из автозагрузки командой chkconfig bluetooth off. Так же поступим и с другими ненужными службами. Все эти манипуляции необходимо производить очень аккуратно и вдумчиво, иначе можно «положить» как саму ОС, так и сервер Asterisk.
Для администрирования ОС и Asterisk администратору IP-ATC необходим удаленный доступ. Не рекомендуется использовать протоколы для удаленного доступа без шифрования (например telnet) рекомендуется использовать SSH (Secure SHell). Служба SSH, используемая для удалённого входа на сервер — это главная дверь в центр управления АТС. Для повышения уровня безопасности администратору АТС рекомендуется выполнить следующие меры.
1. Смена порта. Порт по умолчанию SSH — 22-ой. Многие хакеры сканируют интернет в поисках серверов с открытым портом 22, чтобы затем попробовать взломать их. Необходимо придумать другой порт, в диапазоне 1-65535, и указать его в директиве Port настройке ssh.
Так же этот порт на забываем указать в клиенте при подключение к серверу.
2. Явное перечисление пользователей, имеющих доступ к системе по протоколу SSH, в директиве [AllowUsers]. В том случае, если все же необходимо предоставить доступ к системе ряду доверенных лиц, перечислите их.
3. Рекомендуется использовать только SSH протокол версии 2.
4. Запретите прямой доступ пользователя root. Это существенно затруднит и скорее сделает невозможной атаку на перебор пароля, так как пользователю root будет запрещен доступ в систему, даже если будет введен его корректный пароль. Используйте подсистему sudo для получения рутовского доступа при необходимости и только после удаленного входа в систему под непривилегированной учетной записью.
5. Используйте временное ограничение по вводу пароля или сертификаты. Установка минимально возможного времени для ввода пароля, например, 1 секунды, может хорошо сбить с толку злоумышленника.
Все указанные выше рекомендации отражаем в конфигурационном файле /etc/ssh/sshd_config
Port 30222
AllowUsers ats admin
Protocol 2
PermitRootLogin no
LoginGraceTime 1s
Так же является хорошей практикой – вход в SSH по сертификатам. Если вы часто используете SSH для подключения к удаленному хосту, одним из способов обеспечения безопасности соединения является применение открытого/закрытого SSH-ключа, так как при этом по сети не передается никакой пароль и система устойчива к атакам методом «грубой силы».
Создать открытый/закрытый SSH-ключ в Linux очень просто.
1. В консоле вводим ssh-keygen –t rsa В данном случае RSA – это ассиметричный алгоритм шифрования. Так же можно использовать и DSA (Digital Signature Algorithm).
2. Далее предлагается указать место для сохранения ключа. По умолчанию это папка .ssh в вашей домашней директории. Для того, чтобы согласиться с настройками по умолчанию, просто нажмите «Enter».
3. Далее нас просят ввести идентификационную фразу. Это не идентификационная фраза для соединения с удаленным хостом. Это идентификационная фраза для разблокировки закрытого ключа, поэтому она не поможет вам получить доступ к удаленному серверу, даже если на нем хранится ваш закрытый ключ. Ввод идентификационной фразы не является обязательным. Чтобы оставить ее пустой, нажимаем «Enter».
4. Наши ключи сгенерированы. Переходим в домашнюю директорию в папку .ssh, там должны находится сгенерированные наши ключи id_rsa и id_rsa.pub.
5. Далее правим конфигурационный файл /etc/ssh/sshd_config 
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no 
Тем самым мы разрешаем вход по ssh только с помощью сертификата. 
6. Содержимое файла id_rsa.pub копируем во вновь созданный файл authorized_keys 
Копируем и создаем файл командой cat id_rsa.pub >> authorized_keys
7. Устанавливаем на файл права на чтение и запись
chmod 600 authorized_keys 
8. Копируем приватный ключ id_rsa на компьютер, с которого будем подключаться к серверу по SSH.
9. Для того что бы клиент (Putty) понял этот приватный ключ, прогоним (load) его через программу puttygen. На выходе (Save private key) получаем приватный ключ (*.ppk).
10. Теперь добавим ключ в сеанс. Запускаем PuTTY, загружаем нужный сеанс или вводим данные для соединения и идём в «SSH — Auth», выбираем наш приватный ключ, который был получен через обработку «puttygen».
11. Идём в меню «Connection — Data» и в поле «Auto-login username» вводим логин под которым генерировали ключ.
12. Сохраняем сеанс, перезапускаем службу SSH на сервере /etc/init.d/ssh reload
13. Подключаемся.
Таким образом, мы повысили безопасность SSH соединение.

2.7 Защита периферийных устройств
Одним из важных моментов является защита оборудования, которое тем или иным способом подключается к Asterisk, таким оборудованием являются ip-телефоны, voip-gate и другие. Система IP-ATC не может быть безопасной, если не защищены периферийные устройства. Для защиты данного оборудования предлагается провести ряд мероприятий:
1. Это обновление ПО оборудования. Важно следить за данным аспектом и в случае выхода новой «прошивки», обновлять ее на соответствующем устройстве. Многие уязвимости устраняются с помощью обновлений.
2. Данный момент уже был обсужден выше. По возможности ip-оборудование поместить в отдельный от данных Vlan.
3. Оборудование размещать за сетевым экраном. Крайне не желательно давать ip-оборудованию внешние ip-адреса. 
4. Уязвимым местом является Web-интерфейс оборудования. Для того чтобы защитить оборудования от взлома через Web-интерфейс рекомендуется для ip-телефонов отключить его, так как большой смысловой нагрузки он не несет, либо как и для voip-gate установить стойкий пароль. 
5. Смена сервисных портов. Как и в случае с Astersik, на ip-телефонах и на voip-gate рекомендуется изменить порт sip с 5060 на любой другой. Тем самым повышаем устойчивость к сканированию.

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

2.8 Административные меры
Даже в случае выполнения всех рекомендаций, описанных выше, все равно система может быть взломанной – нет абсолютной безопасности. Поэтому административные меры важны. Рассмотрим их.
1. Если организации международные звонки не нужны, то тогда можно заблокировать международные направления на уровне оператора связи. Если таких звонков очень мало, то можно договорится с провайдером о неком мониторинге данного направления – в случае большого количества звонков на международные направления – блокировать эти соединения. 
2. Так же можно пойти на простой, но действенный метод — это на ограничение суммы счета за связь на уровне оператора. Можно попросить оператора связи установить лимит, который сами для себя определяем (среднегодовой ежемесячный платеж за связь + некий %), и в случае достижения лимита связь блокируется. Данная мера не даст уйти в глубокий минус в случае взлома IP-ATC.
3. Защита рабочих станций с софтфонами. 
4. Смена паролей при смене администратора. 
5. Повышение осведомленности персонала.
6. Один из самых важных моментов – не забывать, что нет абсолютной защиты. Необходим постоянный контроль и аудит системы на предмет новых уязвимостей, возникновения новых рисков и др. и в случае выявления чего-либо, учесть это в системе безопасности системы. То есть «цикл Деминга» обязателен в применение к данной системе. 

Заключение

Надеюсь, что данной работой раскрыт тезис, что при правильной настройке системы, Asterisk можно сделать одной из самых безопасных система с большим функционалом в области телефонии, и данная система по функционалу не уступает коммерческим решениям от ведущих вендоров, таких как Cisco, Avaya и др.
Ну а то, что по статистике взламывают чаще Asterisk, определяется тем, что у Asterisk горазда меньше порог вхождения, чем у других систем. То есть маломальский it-специалист, почитав пару статей в интернете, может развернуть Asterisk, ну а поскольку все же квалификации не хватает, то система, как правило, получается рабочей, но уязвимой. А для развертывания коммерческих решений необходимы специалисты своего дела, которые уделяют вопросам безопасности должное внимание. Вот по этой простой причине Asterisk взламывают чаще. 

IP-ATC Asterisk – это безопасная система при правильной настройке.

Список используемой литературы

1. Меггелен Дж., Мадсен Л., Смит Дж. Asteriskтм: будущее телефонии, 2-е издание. – Пер. с англ. – СПб: Символ-Плюс, 2009. – 656 с., ил.
2. Платов М. Asterisk и Linux – миссия IP-телефония [Текст] /М. Платов// Системный Администратор. -2005 г. -№ 31. – С. 12-19.
3. Платов М. Asterisk и Linux: миссия IP-телефония. Действие 2 [Текст] /М. Платов// Системный Администратор. -2005 г. -№ 32. – С. 32-38.
4. Платов М. Asterisk и Linux: миссия IP-телефония. Действие 3 [Текст] /М. Платов// Системный Администратор. -2005 г. -№ 33. – С. 10-19.
5. База знаний Asterisk [Электронный ресурс]. –режим доступа: asterisk.ru/knowledgebase 
6. База знаний Voxlink [Электронный ресурс]. — режим доступа: www.voxlink.ru/kb/
7. ХабрХабр. Безопасность в VoIP сетях [Электронный ресурс]. — режим доступа: habrahabr.ru/post/145206/ 
8. Росляков А.В., Самсонов М.Ю., Шибаева И.В. IP-телефония. –М.: Эко-Трендз, 2003. -252 с.: ил.
9. Гольдштейн Б.С., Пинчук А.В., Суховицкий А.Л. IP-телефония. –M.: Радио и связь, 2001. -336 с.: ил.
10. CITForum. Безопасность IP-телефонии – полевые зарисовки. А. Веселов [Электронный ресурс]. — режим доступа:citforum.ru/security/articles/ipsec/

P.S.
Отдельно спасибо за понимание данной проблематики генеральному директору Voxlink Грушко Сергею и его работам.
Понимаю, что тема избитая и вроде бы все все знают, но при этом взломанных IP-станций меньше не становится. Надеюсь, что статья будет хоть кому-то полезной.