Некоторые аспекты безопасности АТС

1. ОС

2. Сеть

3. Приложения системы

4. Астериск

ОС

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

• Ограничение пользовательских аккаунтов. Необходимо использовать меры по ограничению несанкционированного управления управления системой.

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

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

• Регулярное обновление ОС.

Сеть

Никогда не выставляйте Asterisk-систему полностью открытой извне — обязательно удостоверьтесь, что она находится за брандмауэром. Любой доступ к системным службам, таким как HTTP или SSH, должен быть сделан только через VPN или использование псевдо-VPN. Азы безопасности начинаются с того, чтобы выставить на доступ извне как можно меньше сервисов. Если будут сотрудники, работающие удаленно, которые не могут использовать VPN, и будет необходимость оставить SIP-порты открытыми, то необходимо обеспечить их безопасность.
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 30111
Protocol 2
LoginGraceTime 1s
PermitRootLogin no

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

Приложения системы

Выключение сервисов
Многие 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

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

Можно проверить все службы системы командой chkconfig —list

Чтобы убрать из автозапуска ненужные службы, используем команду chkconfig <имя службы> off:

chkconfig ircd off
chkconfig netfs off
chkconfig nfslock off
chkconfig openibd off
chkconfig portmap off
chkconfig restorecond off
chkconfig rpcgssd off
chkconfig rpcidmapd off
chkconfig vsftpd off

Также немедленно остановить службы без перезагрузки Asterisk:

service ircd stop
service netfs stop
service nfslock stop
service openibd stop
service portmap stop
service restorecond stop
service rpcgssd stop
service rpcidmapd stop
service vsftpd stop

Астериск

Конфигурация

Все настройки сервера Asterisk обычно хранятся в текстовых файлах, все файлы конфигурации Asterisk, располагаются в директории /etc/asterisk, при стандартной инсталляции. В стандартный дистрибутив входят файлы с примерами конфигураций, которые хорошо документируют использование почти всех параметров конфигурации.
Рассмотрим безопасность контекстов, экстеншенов, настройки каналов и пользовательских аккаунтов, команд диалплана и доступа к интерфейсу менеджера.
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})

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

CLI> dialplan show 2323956@users

На выводе будет точно указано, какая из строк плана набора вызовет совпадение. В нашем примере, если во второй строке указать не _XXXXXX, а _XXXXXX. (с точкой в конце), то все звонки будут попадать под маску _X. и уходить по SIP каналу, вместо Zap.
Особое предупреждение относится к маске _. – она совпадает со всеми возможными вариантами, включая служебные екстеншены h,s,i и другие.
Чтобы убедиться, что все набрано правильно, надо использовать команду 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 – это идентификатор абонента в виде «Имя абонента» <номер абонента>, например, «Иван Иванов» <701>. Многие цифровые и [VoIP] телефоны обладают дисплеем, на котором отражают Caller ID звонящего. Пользователи могут не догадываться о том, насколько просто поменять Caller ID, если он четко не приязан, и осуществить атаку по типу Caller ID spoofing (подмена caller id) для получения каких-либо преимуществ или нанесение вреда. Администратору АТС следует четко назначать абонентам Caller ID, как показано в примере ниже:

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

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

[709]  (user)
secret=secret
mailbox=709
callerid=  «Max» <709>
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=709
callerid=  «Max» <709>
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.

ACL

Access Control List или ACL — список контроля доступа, который определяет, кто или что может получать доступ к конкретному объекту, и какие именно операции разрешено или запрещено проводить над объектом.

Контексты

Диалпланы разбиты на разделы, называемые контекстами. Контексты – это именованные группы добавочных номеров, которые выполняют несколько функций.
Контексты изолируют разные части диалплана, предотвращая возможность их взаимодействия. Добавочный номер, определенный в одном контексте, полностью изолирован от добавочных номеров другого контекста, если только взаимодействие не разрешено специально.
Контексты различаются по именам. Имена контекстов заключаются в квадратные скобки ([ ]). Допустимыми символами для образования имени являются буквы от A до Z (верхнего и нижнего регистра), цифры от 0 до 9, дефис и символ подчеркивания. Например, контекст для входящих вызовов может выглядеть так:
[incoming]
Все инструкции, размещаемые после описания контекста и до описания следующего контекста, являются частью данного контекста. В начале диалплана находятся два специальных контекста, [general] и [globals].
Раздел [general] содержит список общих настроек диалплана (о которых, вероятно, вам никогда не придется беспокоиться), а о контексте [globals] мы поговорим в другой статье, когда речь пойдет о «Глобальных переменных». Пока что достаточно знать, что эти два контекста являются специальными. Созданные вами контексты можно называть как угодно, только не используйте имена [general] и [globals]!
При описании канала (а именно так выполняется подключение элементов к системе) одним из параметров этого описания является контекст. Иначе говоря, контекст – это точка диалплана, с которой будет начинаться обработка соединений, выполняемых через этот канал.
Другое важное применение контекстов (возможно, самое важное) – обеспечение безопасности. Правильно применяя контексты, определенным абонентам можно предоставить доступ к функциям (таким, как междугородная связь), которые недоступны для других. Если диалплан разработан неаккуратно, пользователи из-за ваших же косяков могут получить возможность мошенничать в вашей системе.
Контекст 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

[709]  (user)
secret=as09TYInbd873K
mailbox=709
callerid=  «User» <709>

[710]  (user)
secret=udFls34Dssd2
mailbox=710
callerid=  «User» <710>

В приведённом примере, если забыть указать наследование шаблона (user), пир создан не будет. Таким образом, можно избежать необходимости указывать контекст в каждом пире.
Разделение входящих и выходящих контекстов
Не следует определять в одном контексте как правила для входящих, так и для исходящих звонков. Типичный пример некорректной настройки – это использование одного контекста для исходящих звонков пользоваталей, внутренних звонков и звонков, поступающих по городским линиям. Например:

[default]
exten = > _7XX,1,Dial  (SIP/${EXTEN}) //внутренние звонки
exten = > _9XXX.,1,Dial  (SIP/g1/${EXTEN:1}) //внешние
// входящие по линии FXO
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] //внутренние
exten = > _7XX,1,Dial  (SIP/${EXTEN})

[numberplan] //внешние  exten = > _9XXX.,1,Dial  (Zap/g1/${EXTEN:1})

[fxo-in] //входящие FXO
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 включаются правила внутрениих и внешних звонков. В настройках линий (dahdi.conf) следует указать контекст fxo-in, в котром включается контекст local-users. Таким образом, из IVR компании можно будет связаться только с внутренними пользователями, что чаще всего и требуется.

Права пользователей

Запуск Asterisk из-под не — root пользователя. По умолчанию Asterisk запускается из-под root, что может быть небезопасно. Для изменения пользователя раскомментируйте строки в файле /etc/init.d/asterisk.

AST_USER=  «asterisk»
AST_GROUP=  «asterisk»

Создайте группу и пользователя asterisk.

/usr/sbin/groupadd asterisk 
/usr/sbin/useradd -d /var/lib/asterisk -g asterisk asterisk

Измените права на использование следующих файлов:

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
## Если Вы мспользуете Zaptel
chown --recursive asterisk:asterisk /dev/zap
## Если Вы используете DAHDI
chown --recursive asterisk:asterisk /dev/dahdi
#----------------------------------------------------
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
## Если Вы мспользуете Zaptel
chmod --recursive u=rwX,g=rX,o= /dev/zap
## Если Вы используете DAHDI
chmod --recursive u=rwX,g=rX,o= /dev/dahdi
#----------------------------------------------------
chown --recursive root:asterisk /etc/asterisk
chmod --recursive u=rwX,g=rX,o= /etc/asterisk 
/etc/init.d/asterisk restart