Многоуровневая защита IP-АТС Asterisk - Зайцев Я - Флудилка
^ В верх

Зайцев.Я

Все самое интересное в разделе "Флудилка"


Войти
x
x

Кто на сайте

Флудилка

Обсуждение Joomla , Virtuemart 2 , Cisco IOS , Asterisk , PHP

  • Категории
    Категории Страница отображения списка категорий системы блогов сайта.
Добавлено : Дата: в разделе: АТС Asterisk

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

Настройка безопасности для системы IP-ATC в целом нужно понимать, что безопасность строится не только на безопасности самого Asterisk, так же необходимо обеспечить безопасность и окружения Asterisk (программы и приложения). 
Система защиты IP-ATС строится на нескольких уровнях:

  1. Сетевая защита.
  2. Дизайн сети. 
  3. Анализ логов.
  4. Конфигурация Asterisk.
  5. Защита планом маршрутизации звонков (dialplan).
  6. Конфигурация Linux.
  7. Защита периферийных устройств.
  8. Административные меры.

Если определить глобально в чем состоит проблема Asterisk в разрезе безопасности, то как оговаривалось выше – это проблема заключается в не компетентности администратора системы Asterisk. А в силу того, что есть «коробочные решения» — установил и заработало, мы получаем очень большое количество установленных серверов Asterisk без надлежащей полной настройки безопасности и необходимой квалификации администратора, следствием чего получаем взломанный Asterisk и потеря финансовых средств организации, ну и тень на бренд Asterisk Digium. Либо неграмотный интегратор не надлежащим образом установил сервер и после оплаты теряется от Заказчика. А клиент позже получает огромные счета по телефонии, либо оператор блокирует их направления.
Рассмотрим типичные ошибки, которые допускают начинающие молодые администраторы Asterisk:

  1. Слабые пароли на внутренних номерах (Отсутствие паролей, пароль такой же как номер 100, например пароль 100).
  2. Отсутствие сетевого экрана (Отсутствие iptables, либо выключен iptables, либо настроен не верно).
  3. Старые дистрибутивы и программное обеспечение (Старое ПО может содержать уязвимости в безопасности. Необходимы постоянные обновления системы. Как пример коробочное решение "trixbox" не поддерживается более, не обновляется – имеются уязвимости).
  4. Стандартные логины и пароли (Web интерфес, MySql и VoIP оборудование).
  5. Дизайн сети (Asterisk и оборудование, работающее с ним на внешнем адресе, но без защиты – это лакомый кусочек для хакеров).
  6. Ошибки в конфигурации.
  7. Отсутствие контроля за системой (Поставили и забыли, нет контроля логирования системы).

Сетевая защита

При установке системы важно использовать сетевой экран (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, согласно правилам пакеты направляются по своим цепочкам, где к ним принимаются соответствующие действия.

Дизайн сети

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

hack1

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

hack2

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

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

hack3

Анализ логов

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

hack4

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

Конфигурация 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 ; Выставляем ограничение на количество одновременных линий для абонента.

Защита планом маршрутизации звонков (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-коду.

Конфигурация 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 соединение.

Защита периферийных устройств

Одним из важных моментов является защита оборудования, которое тем или иным способом подключается к 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 на любой другой. Тем самым повышаем устойчивость к сканированию.

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

Административные меры

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

[1] PDCA (англ.«Plan-Do-Check-Act» - планирование-действие-проверка-корректировка) циклически повторяющийся процесс принятия решения, используемый вуправлении качеством. Также известен как Deming CycleShewhart cycleDeming Wheel или Plan-Do-Study-Act. Также известен как принцип Деминга-Шухарта, но Деминг предпочитал PDSA (Plan-Do-Study-Act) у Шухарта (Plan-Do-Сheck-Act)

Поставьте свой рейтинг этой записи блога:
0

Комментарии

  • Никаких комментариев пока не было создано. Будьте первым комментатором.

Оставить комментарий

Гость
Гость Вторник, 17 Сентябрь 2019
Яндекс.Метрика Рейтинг@Mail.ru