Безопасность

Мы тратим свое время на поиски безопасности и

ненавидим ее, когда получаем.

-John Steinbeck

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

Сканирование действительных учетных записей

Если вы публикуете свою систему Asterisk в общедоступном Интернете, одна из вещей, которую вы почти наверняка увидите — это проверка действительных учетных записей. В Примере 26-1 содержатся записи журнала из одной из систем Asterisk, выпускаемых авторами.¹ Это сканирование началось с проверки различных общих имен пользователей, а затем продолжилось сканирование нумерованных учетных записей. Люди обычно называют SIP-аккаунты так же, как внутренние номера на АТС. Это сканирование использует этот факт. И всё это приводит к нашему первому вопросу безопасности Asterisk:

Совет № 1: Используйте нечисловые имена пользователей для своих учетных записей VoIP чтобы сделать сложнее их угадывание. Например, в некоторых частях этой книги мы используем MAC-адрес телефона SIP в качестве имени учетной записи в Asterisk.

Пример 26-1. Выдержка лога сканирования аккаунта

[Aug 22 15:17:15] NOTICE[25690] chan_sip.c: Registration from ‘»123″<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found²

[Aug 22 15:17:15] NOTICE[25690] chan_sip.c: Registration from

‘»1234″<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found

[Aug 22 15:17:15] NOTICE[25690] chan_sip.c: Registration from ‘»12345″<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found

[Aug 22 15:17:15] NOTICE[25690] chan_sip.c: Registration from ‘»123456″<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found

[Aug 22 15:17:15] NOTICE[25690] chan_sip.c: Registration from ‘»test»<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found

[Aug 22 15:17:15] NOTICE[25690] chan_sip.c: Registration from ‘»sip»<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found [Aug 22 15:17:15] NOTICE[25690] chan_sip.c: Registration from ‘»user»<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found

[Aug 22 15:17:16] NOTICE[25690] chan_sip.c: Registration from ‘»admin»<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found

[Aug 22 15:17:16] NOTICE[25690] chan_sip.c: Registration from ‘»pass»<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found

[Aug 22 15:17:16] NOTICE[25690] chan_sip.c: Registration from ‘»password»<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found

[Aug 22 15:17:16] NOTICE[25690] chan_sip.c: Registration from ‘»testing»<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found

[Aug 22 15:17:16] NOTICE[25690] chan_sip.c: Registration from ‘»guest»<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found

[Aug 22 15:17:16] NOTICE[25690] chan_sip.c: Registration from ‘»voip»<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found

[Aug 22 15:17:16] NOTICE[25690] chan_sip.c: Registration from ‘»account»<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found

…

[Aug 22 15:17:17] NOTICE[25690] chan_sip.c: Registration from ‘»100″<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found [Aug 22 15:17:17] NOTICE[25690] chan_sip.c: Registration from ‘»101″<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found [Aug 22 15:17:17] NOTICE[25690] chan_sip.c: Registration from ‘»102″<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found [Aug 22 15:17:17] NOTICE[25690] chan_sip.c: Registration from ‘»103″<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found [Aug 22 15:17:17] NOTICE[25690] chan_sip.c: Registration from ‘»104″<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found [Aug 22 15:17:17] NOTICE[25690] chan_sip.c: Registration from ‘»105″<sip:[email protected]>’ failed for ‘203.86.167.220:5061’ — No matching peer found

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

Совет № 2: Установите alwaysauthreject в yes в разделе [general] файла /etc/asterisk/sip.conf. Этот параметр указывает Asterisk отвечать так, как если бы каждая учетная запись была действительной, что делает сканирование на действительные имена пользователей бесполезным. К счастью, это параметр по умолчанию для этой опции. Не меняйте его.

Уязвимости аутентификации

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

По-умолчанию схема аутентификации для протоколов SIP и IAX2 слаба. Аутентификацию проводят с использованием механизма MD5 для запроса-и-ответа. Если злоумышленник способен фиксировать любой трафик вызова, например, SIP-вызов, сделанный с ноутбука в открытой беспроводной сети, гораздо проще работать с подбором пароля перебором, так как для этого не потребуются запросы проверки подлинности на сервере.

Совет № 3: используйте надежные пароли. В Интернете имеется бесчисленное количество ресурсов, которые помогут определить, что является надежным паролем. Есть также много надежных генераторов паролей. Используй их!

IAX2 предоставляет возможность использования проверки подлинности на основе ключа, а также полного шифрования вызова. Поддержка SIP в Asterisk включает поддержку TLS, которая обеспечивает шифрование для сигнализации SIP.

Совет № 4: Если вы используете IAX2, используйте аутентификацию на основе ключа. Это более сложный метод проверки подлинности, чем метод ответа на запрос по умолчанию на основе MD5. Для дальнейшего повышения безопасности с помощью IAX2 используйте параметр для шифрования всего вызова. Если вы пользуетесь SIP, используйте TLS для шифрования SIP-сигнализации. Это позволит предотвратить успешный захват запроса аутентификации у сервера.

Дополнительные сведения о настройке шифрования IAX2 или SIP см. в Главе 7.

Fail2ban

В последних двух разделах обсуждались атаки, включающие сканирование для действительных имен пользователей и подбора паролей перебором. Fail2ban — это приложение, которое может просматривать ваши журналы Asterisk и обновлять правила брандмауэра, чтобы блокировать источник атаки в ответ на большое количество неудачных попыток аутентификации.

Совет № 5: Используйте Fail2ban при размещении услуг Voice over IP в ненадежных сетях, чтобы автоматически обновлять правила брандмауэра для блокировки источников атак.

Установка

Fail2ban доступен как пакет во многих дистрибутивах. Кроме того, вы можете установить его из источника, загрузив с веб-сайта Fail2ban. Чтобы установить его на Ubuntu, используйте следующую команду:

$ sudo apt-get install fail2ban

Чтобы установить Fail2ban на RHEL, вы должны включить репозиторий EPEL. Дополнительные сведения о репозитории EPEL см. в разделе «Сторонние репозитории» в Главе 3. После того, как репозиторий включен, Fail2ban можно установить, выполнив следующую команду:

$ sudo yum install fail2ban

Установка Fail2ban из пакета будет включать скрипт инициализации, чтобы гарантировать запуск при загрузке машины. Если вы устанавливаете из исходных кодов, убедитесь, что вы предпринимаете необходимые шаги для обеспечения того, чтобы Fail2ban всегда работал.

iptables

Чтобы Fail2ban мог делать что-нибудь полезное после обнаружения атаки, вы также должны установить iptables. Чтобы убедиться что он установлен в Ubuntu, используйте следующую команду:

$ sudo apt-get install iptables

Чтобы убедиться, что iptables установлен на RHEL, используйте следующую команду:

$ sudo yum install iptables

Вы можете убедиться в том, что iptables установлен, запустив команду iptables. Опция -L запрашивает отображение текущих правил брандмауэра. В этом случае не отображаются сконфигурированные правила:

$ sudo iptables -L

Chain INPUT (policy ACCEPT)

target prot opt source destination

Chain FORWARD (policy ACCEPT)

target prot opt source destination

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

Отправка электронной почты

Это интересно и полезно разрешить Fail2ban отправлять по электронной почте системному администратору уведомления когда он блокирует IP-адрес. Для этого необходимо установить MTA. Если вы не знаете, какой из них использовать, во время тестирования для написания этой главы использовался Postfix. Чтобы установить Postfix на Ubuntu, используйте следующую команду. Вам может быть предложено ответить на пару вопросов установщиком:

$ sudo apt-get install postfix.

Чтобы установить Postfix на RHEL, используйте следующую команду:

$ sudo yum install postfix.

Чтобы протестировать установку вашего MTA, вы можете отправить быстрое письмо используя mutt. Чтобы установить его — используйте те же команды установки, которые указаны для установки Postfix, но замените имя пакета на mutt. Затем запустите следующие команды для проверки MTA:

$ echo «Просто тестирование.» > email.txt

$ mutt -s «Тестирование» [email protected] < mail.txt

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

Первым файлом, который необходимо настроить, является файл конфигурации ведения журнала Asterisk. Его содержимое в рабочей системе /etc/asterisk/logger.conf. Убедитесь, что у вас установлены хотя бы dateformat и messages, поскольку они необходимы для Fail2ban:

[general]

dateformat = %F %T

[logfiles]

console => notice,warning,error,debug

messages => notice,warning,error

Следующий файл конфигурации, который должен быть создан — это тот, который учит Fail2ban, что нужно отслеживать в файлах Asterisk. Поместите следующее содержимое в новый файл с именем /etc/fail2ban/filter.d/asterisk.conf:

[INCLUDES]

# Прочитайте префиксы common. Если какие-либо настройки доступны —

# прочитайте про них из common.local

# before = common.conf

[Definition]

#_daemon = asterisk

# Опция: failregex

# Примечание: regex соответствует сообщениям о сбоях паролей в файле

# журнала.

# Хост должен быть согласован группой названием «host».

# Тег «<HOST>» может использоваться для стандартного

# сопоставления IP/хостов и является только альясом для

# (?:::f{4,6}:)?(?P<host>\S+)

# Значения: TEXT

#

# *** Все строки ниже должны начинаться с NOTICE

# Некоторые строки должны быть обернуты двумя пробелами из-за

# требований книги. Все новые строки должны начинаться с NOTICE.

#

failregex = NOTICE.* .*: Registration from ‘.*’ failed for ‘<HOST>’

— Wrong password

NOTICE.* .*: Registration from ‘.*’ failed for ‘<HOST>’

— No matching peer found

NOTICE.* .*: Registration from ‘.*’ failed for ‘<HOST>’

— Username/auth name mismatch

NOTICE.* .*: Registration from ‘.*’ failed for ‘<HOST>’

— Device does not match ACL

NOTICE.* <HOST> failed to authenticate as ‘.*’$

NOTICE.* .*: No registration for peer ‘.*’ \(from <HOST>\)

NOTICE.* .*: Host <HOST> failed MD5 authentication for ‘.*’ (.*)

NOTICE.* .*: Failed to authenticate device .*@<HOST>.*

# Параметр: ignoreregex

# Примечание: регулярное выражение (regex) игнорируется. Если это

# выражение (regex) совпадает — строка игнорируется.

# Значение: TEXT

#

ignoreregex =

Затем вы должны включить новый фильтр Asterisk, который вы только что создали. Для этого добавьте следующее содержимое в /etc/fail2ban/jail.conf. Вам нужно будет изменить параметры dest и sender, чтобы указать соответствующие адреса электронной почты для заголовков To и From:

[asterisk-iptables]

enabled = true

filter = asterisk

action = iptables-allports [name = ASTERISK, protocol = all]

sendmail- whois [name = ASTERISK, dest=[email protected],

[email protected]]

logpath = /var/log/asterisk/messages

maxretry = 5

bantime = 259200

Наконец, есть несколько параметров раздела [DEFAULT] файла /etc/fail2ban/jail.conf, который должен быть обновлен. Опция ignoreip указывает список IP-адресов, которые никогда не должны блокироваться. Это хорошая идея, чтобы перечислить ваш(и) IP-адрес(а) здесь, чтобы вы никогда не блокировали себя если ошибетесь, например, при попытке настроить телефон.³ Вы также должны рассмотреть возможность добавления других IP-адресов, например вашего SIP-провайдера. Белый список хороших IP-адресов защищает вас от злоупотребления конфигурацией Fail2ban. Умный атакующий может вызвать отказ в обслуживании, создав серию пакетов, которые приведут к тому, что Fail2ban блокирует IP-адрес по своему выбору.

Параметр destemail также должен быть установлен. Этот адрес будет использоваться для сообщений электронной почты, не относящихся к фильтру Asterisk, например, по электронной почте Fail2ban уведомляет о первом запуске. Вот как вы настраиваете эти параметры:

[DEFAULT]

# Можно указать несколько адресов, разделенных пробелом.

ignoreip = 127.0.0.1 10.1.1.1

destemail = [email protected]

Asterisk Security Logfile

Формат записи журнала, используемый в нашем примере конфигурации для fail2ban, предназначен для чтения человеком. Анализ и автоматизация действий на основе результата несколько безобразны. В настоящее время предпринимаются усилия по созданию файла журнала событий, связанных с безопасностью, предназначенного для автоматической обработки. К сожалению, он не использовался нами активно и мы не видели примеров инструментов, которые обрабатывают записи из этого файла журнала.

Чтобы включить файл журнала безопасности, добавьте следующую строку в раздел [logfiles] файла /etc/asterisk/logger.conflogfiles:

[logfiles]

security => security

Asterisk 11 помещает записи в этот файл для событий, которые происходят в AMI, а также chan_sip (обозначается как SIP в записях журнала событий безопасности). Тело сообщения журнала представляет собой список пар ключ/значение, разделенный запятыми. Каждая пара ключ/значение представляет собой немного метаданных о событии безопасности. Вот пример записи журнала безопасности о попытки войти в AMI с недопустимым пользователем:

[13.12.08:46:09] SECURITY [995] res_security_log.c:

SecurityEvent = «InvalidAccountID», EventTV = «1355406369-716573» ,

Severity = «Error», Service = «AMI», EventVersion = «1»,

AccountID = «foo», SessionID = «0x7f793ac32220»,

LocalAddress = «IPV4/TCP/0.0.0.0/5038»,

RemoteAddress = «IPV4/TCP/127.0.0.1/58491», SessionTV=«0-0»

Некоторые события считаются ошибками, а другие просто информационными. Значение связанное с ключом Severity будет указать либо Error или Informational.

Значение, связанное с ключом SecurityEvent, определяет тип события, произошедшего в системе. Asterisk 11 (по крайней мере, от Asterisk 11.1.0) способен передавать следующие типы событий безопасности. Некоторые из них еще не используются ни в одной из частей Asterisk. Если вы работаете над инструментом, который использует эти события, стоит знать что они существуют если будут использоваться в будущем.

FailedACL

ACL, определенный параметрами конфигурации permit и deny, вызвал отказ в запросе. Это передается как для AMI, так и для SIP.

InvalidAccountID

Запрос был получен с недопустимым идентификатором учетной записи. Обычно это плохое имя пользователя. Это передается для AMI.

SessionLimit

Количество сеансов, разрешенных для данного пользователя, было превышено. Это передается как для AMI, так и для SIP.

MemoryLimit

Предел памяти превышен. Это событие определено, но не используется в настоящее время.

LoadAverageLimit

Лимит нагрузки превышен. Это событие определено, но не используется в настоящее время.

RequestNotSupported

Получен запрос, который не поддерживается. Это событие определено, но не используется в настоящее время.

RequestNotAllowed

Был получен запрос, который был административно запрещен. Это передается для AMI.

AuthMethodNotAllowed

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

RequestBadFormat

Получен плохо отформатированный запрос. Это событие передается для AMI.

SuccessfulAuth

Аутентификация прошла успешно. Это событие передается как для SIP, так и для AMI.

UnexpectedAddress

Сообщение было получено от неожиданного исходного адреса для сеанса уже выполняющегося. Это событие определено, но не используется в настоящее время.

ChallengeResponseFailed

Ошибка аутентификации на основе запроса-ответа. Это событие выбрано как для SIP, так и для AMI.

InvalidPassword

Для попытки аутентификации был предоставлен неверный пароль. Это событие передается как для SIP, так и для AMI.

ChallengeSent

Запрос был отправлен для проверки подлинности на основе запроса-ответа. Это событие передается для SIP.

InvalidTransport

Попытка использовать административно запрещенный транспорт (например, с использованием UDP, когда для этого пира разрешен только TCP). Это событие передается для SIP.

Зашифрованные медиаданные

Помните, что звук для VoIP обычно передается в незашифрованном формате. Любой, кто может перехватить трафик — может прослушивать телефонный звонок. К счастью, Asterisk поддерживает шифрование медиаданных вызовов VoIP. Если вы используете SIP, то можете зашифровать медиа с помощью SRTP. IAX2 также полностью поддерживает шифрование вызовов. Подробную информацию о шифровании медиаданных можно найти в Главе 7.

Совет № 6: Шифруйте медиаданные для вызовов в ненадежных сетях с использованием шифрования SRTP или IAX2.

Уязвимости диалплана

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

Совет № 7: Стройте контексты диалплана с большой осторожностью. Кроме того, избегайте размещения каких-либо номеров, которые могут стоить вам денег, в контексте [default].

Одна из последних уязвимостей диалплана Asterisk, которые были обнаружены и опубликованы — это идея инъекции диалплана. Уязвимость диалплан-инъекций начинается с номера, у которого есть шаблон, который заканчивается символом match-all — точкой. Возьмите это расширение в качестве примера:

exten => _X.,1,Dial(IAX2/otherserver/${EXTEN},30)

Шаблон для этого расширения соответствует всем номерам (любой длины), начинающимся с цифры. Подобные шаблоны довольно распространены и удобны. Номер затем посылает этот вызов на другой сервер, используя протокол IAX2, с таймаутом набора 30 секкунд. Обратите внимание на использование здесь переменной ${EXTEN}. Вот где существует уязвимость.

В мире VoIP нет причин, чтобы набираемое расширение было числовым. На самом деле, довольно часто использование SIP позволяет набирать кого-то по имени. Так как нечисловые символы могут быть частью набираемого номера, что произойдет, если кто-то отправит вызов этому расширению?

1234&DAHDI/g1/12565551212

Подобный вызов является попыткой использовать уязвимость, называемую диалплан-инъекцией. В предыдущем определении расширения, когда ${EXTEN} будет оценено, оператор Dial() выполнит:

exten => _X,1,Dial(IAX2/otherserver/1234&DAHDI/g1/12565551212,30)

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

Для избежания подобной проблемы существуют (по крайней мере) два подхода. Первый и самый простой подход — всегда использовать строгое сопоставление шаблонов. Если вы знаете длину внутренних номеров, которые ожидаете и ожидаете только числовые номера, используйте строгое сопоставление с числовым шаблоном. Например, этот пример будет работать, если вы ожидаете только четырехзначных числовых внутренних номеров:

exten => _XXXX,1,Dial(IAX2/otherserver/${EXTEN},30)

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

exten => _X.,1,Set(SAFE_EXTEN=${FILTER(0-9,${EXTEN})})

same => n,Dial(IAX2/otherserver/${SAFE_EXTEN},30).

Для получения дополнительной информации о синтаксисе функции диалплана FILTER() смотрите вывод core show function FILTER в командой строке Asterisk.

Совет № 8: Будьте осторожны с уязвимостями инъекцими диалплана. Используйте строгое сопоставление или шаблоны функции диалплана FILTER() чтобы избежать этих проблем.

Обеспечение безопасности сети Asterisk API

FastAGI и AMI — это два сетевых API, обычно используемых в развертываниях Asterisk. Более подробную информацию об AGI см. в Главе 21. Дополнительную информацию об AMI см. в Главе 20.

В случае с FastAGI нет доступа к шифрованию и аутентификации. Администратор должен решить, что единственное сообщение, разрешенное для сервера FastAGI — от Asterisk.

Протокол AMI включает аутентификацию, но она очень слаба. Кроме того, данные, которыми обмениваются через AMI часто являются конфиденциальными, с точки зрения приватности. Крайне важно обеспечить безопасность AMI. Лучше всего выставлять AMI только доверенным сетям. Если необходимо предоставить доступ в ненадежной сети, мы рекомендуем разрешать подключения только с использованием SSL.

Очень важно понять какую силу дает AMI. Если пользователю AMI предоставлены все доступные разрешения, он сможет выполнять произвольные команды в вашей системе. Если учетная запись имеет возможность обновлять файлы конфигурации, она сможет добавить расширение в диалплан, которое запускает приложение System(), позволяющее ему запускать любую команду, которую он захочет. Если он также имеет доступ к инициированию вызовов, то сможет инициировать вызов этого расширения, что приведет к выполнению этой команды. Будьте осторожны при открытии доступа администратора в вашей системе и ограничте разрешения, предоставляемые каждой учетной записи в /etc/asterisk/manager.conf.

Совет № 9: Безопасные сетевые API Asterisk. Используйте правила брандмауэра, для ограничения доступа к серверу FastAGI. Используйте шифрование в AMI. Максимально ограничте доступ к учетным записям AMI.

IAX2 отказ в обслуживании

Хотя протокол SIP является текстовым протоколом, IAX2 является бинарным протоколом. Стандарт IAX2 — это RFC 5456. Каждый пакет IAX2 содержит номер вызова, который используется для связывания пакета с активным вызовом. Это аналогично заголовоку Call-ID в SIP. Номер вызова IAX2 — это 15-битное поле. Оно достаточно велико, чтобы иметь дело с количеством вызовов, которые будут реальными в одной системе. К сожалению, оно также достаточно мало, что злоумышленнику достаточно легко отправить несколько маленьких пакетов, чтобы в течение короткого периода времени использовать все доступные номера вызовов в системе, что привело бы к атаке отказа в обслуживании.

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

По умолчанию, механизмы безопасности включены и никаких изменений конфигурации не требуется. Если по какой-либо причине вы хотите полностью отключить поддержку токена вызова, вы можете сделать это, используя следующую конфигурацию в /etc/asterisk/iax.conf:

[general]

calltokenoptional = 0.0.0.0/0.0.0.0

maxcallnumbers = 16382

При конфигурации по умолчанию хост, который может передавать обмен токенами вызовов, все еще может использовать таблицу номеров вызовов. Обмен токенами вызовов гарантирует, что номера вызовов будут назначены только после того, как мы узнаем, что не получили запрос с поддельным IP-адресом источника. Как только мы узнаем, что запрос является законным, принудительное ограничение ресурсов на хост становится достижимо. Рассмотрим следующие варианты в iax.conf:

[general]

; Установите ограничение числа вызовов по умолчанию на хост

maxcallnumbers = 16

[callnumberlimits]

; Установите другой номер вызова для всех хостов в указанном диапазоне.

192.168.1.0/255.255.255.0 = 1024

[some_peer]

; Адрес динамического пира неизвестен до тех пор, пока этот пир не

; будет зарегистрирован. Ограничение номера вызова может быть указано в

; разделе peer, а не в секции callnumberlimits.

type = peer

host = dynamic

maxcallnumbers = 512

Если пир еще не поддерживает проверку токенов вызовов, но вы хотели бы включить её, как только обнаружите что пир был обновлен для его поддержки, есть опция, которая позволяет это сделать:

[some_other_peer]

requirecalltoken = auto

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

[general]

maxcallnumbers_nonvalidated = 2048

[guest]

type = user

requirecalltoken = no

Если в любой момент вы захотите увидеть статистику использования номера вызова в своей системе, выполните команду iax2 show callnumber usage в Asterisk CLI.

Совет № 10: Будьте спокойны, зная, что IAX2 обновлен, чтобы обезопасить себя от отказа из-за исчерпания номера вызова. Если вы в некоторых случаях должны отключить эти функции безопасности, используйте предоставленные параметры, чтобы ограничить вашу атаку.

Другие меры по снижению риска

В Asterisk есть еще несколько полезных функций, которые могут быть использованы для снижения риска атак. Во-первых, использование опций permit (разрешить) и deny (запретить) для создания списков контроля доступа (ACL) для привилегированных учетных записей. Рассмотрим АТС с SIP-телефонами в локальной сети, но которая также принимает SIP-вызовы из общедоступного Интернета. Звонки, поступающие через Интернет, получают доступ только к главному меню компании, а местные SIP-телефоны имеют возможность делать исходящие звонки, которые стоят вам денег. В этом случае очень хорошая идея — установить ACL для обеспечения того, чтобы только устройства в вашей локальной сети могли использовать учетные записи для телефонов. Вот пример этого в /etc/asterisk/sip.conf:

[phoneA] ; Используйте лучшее имя учетной записи, чем это.

type = friend

; Начните с запрета всех.

deny = 0.0.0.0/0.0.0.0

; Разрешить соединения, созданные из 192.168.X.X, для попытки

; аутентификации от этой учетной записи.

permit = 192.168.0.0/255.255.0.0

Параметры permit и deny принимаются почти везде, где настроены подключения к IP-службам. Еще одно полезное место для ACL — в /etc/asterisk/manager.conf, чтобы ограничить использование учетной записи AMI на одном хосте, который должен использовать менеджерский интерфейс.

В Asterisk 11 был введен второй метод конфигурирования списков ACL. Если вы применяете одни и те же правила ACL в нескольких местах, вы найдете это очень полезным. Именованные ACL могут быть определены в /etc/asterisk/acl.conf.

[named_acl_1]

deny=0.0.0.0/0.0.0.0

permit = 10.1.1.50

permit = 10.1.1.55

[named_acl_2] ; Именованные ACL поддерживают IPv6.

deny=::

permit=::1/128

[local_phones]

deny=0.0.0.0/0.0.0.0

permit=192.168.0.0/255.255.0.0

Как только имена ACL определены в acl.conf Asterisk загрузит их, используя reload acl. После загрузки они должны быть доступны через CLI Asterisk:

* CLI> reload acl

* CLI> acl show

acl

—

named_acl_1

named_acl_2

local_phones

* CLI> acl show named_acl_1

ACL: named_acl_1

———— ———————————

0: deny — 0.0.0.0/0.0.0.0

1: allow — 10.1.1.50/255.255.255.255

2: allow — 10.1.1.55/255.255.255.255

Теперь вместо того, чтобы потенциально повторять одни и те же записи permit и deny в нескольких местах, вы можете применить ACL по его имени. Обновленная версия первого примера использования ACL теперь будет выглядеть следующим образом:

[phoneA]

type = friend

acl = local_phones

Совет № 11: Используйте ACL, если это возможно, во всех привилегированных учетных записях для сетевых служб.

Другим способом снижения риска безопасности является настройка лимитов вызовов. Рекомендованный метод реализации лимитов вызовов является использование функций диалплана GROUP() и GROUP_COUNT(). Вот пример, который ограничивает количество вызовов от каждого SIP-пира до двух раз:

exten => _X.,1,Set(GROUP(users)=${CHANNEL(peername)})

; *** Эта строка не должна иметь разрывов строки

same => n,NoOp(Существующий ${GROUP_COUNT(${CHANNEL((peername)})}

вызывает аккаунт ${CHANNEL(peername)}.)

same => n,GotoIf($[${GROUP_COUNT(${CHANNEL(peername)})} > 2]?denied:continue)

same => n(denied),NoOp(Слишком много звонков. Кладу трубку.)

same => n,HangUp()

same => n(continue),NoOp(продолжить обработку вызова как обычно).

Совет № 12: Используйте лимиты вызовов чтобы гарантировать, что в случае если учетная запись скомпрометирована, ее нельзя использовать для выполнения сотни телефонных звонков одновременно.

Разрешения CLI

У CLI Asterisk много мощи. Есть команды для изменения диалплана, инициирования вызовов и их отбоя, среди многих других. Asterisk имеет возможность предоставить локальному пользователю доступ к подмножеству доступных команд CLI. Это делается с помощью файла конфигурации /etc/asterisk/cli_permissions.conf.

По умолчанию любой локальный пользователь, имеющий доступ к CLI Asterisk, может запускать все команды CLI. Если вы хотите изменить это, начните с добавления опции default_perm в раздел [general] файла cli_permissions.conf:

[general]

;

; Установка default_perm=permit разрешает пользователям доступ ко всем

; командам по умолчанию, если в этом файле не указано иное.

;

default_perm = deny

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

[admin]

allow = all ; Предоставление полного доступа определенному пользователю.

Вы также можете установить разрешения для локальной группы. Например, вы можете создать локальную группу под названием asterisksupport. Вы можете предоставить доступ только к некоторым базовым диагностическим командам для всех пользователей этой группы. Префикс @ в названии раздела указывает Asterisk, что вы устанавливаете разрешения для локальной группы:

[@asterisksupport]

deny = all

allow = sip show ; Все команды, начинающиеся с «sip show»

allow = core show ; Все команды, начинающиеся с «core show»

Совет № 13: Установите разрешения CLI, если вы хотите предоставить доступ к CLI кому-то кроме администраторов системы.

Ресурсы

Некоторые уязвимости требуют модификации исходного кода Asterisk. Когда эти проблемы обнаружены — команда разработчиков Asterisk выпускает новые версии, которые содержат только исправления для проблем безопасности, что позволяет быстро и легко обновлять их. Когда это происходит, команда разработчиков Asterisk также публикует консультативный документ безопасности в котором обсуждаются детали уязвимости. Рекомендуем вам подписаться на список рассылки asterisk-announce чтобы вы eзнали об этих проблемах, когда они появляются.

Совет № 14: Подпишитесь на список рассылки asterisk-announce, чтобы оставаться в курсе уязвимостей безопасности Asterisk.

Одним из самых популярных инструментов для сканирования SIP-аккаунтов и взлома пароля является SIPVicious. Мы настоятельно рекомендуем вам взглянуть на него и использовать для аудита ваших собственных систем. Если ваша система находится в Интернете, найдутся те, кто, скорее всего, будут работать против вашей системы, поэтому убедитесь, что вы сделали это в первую очередь.

Другим ресурсом для всех вещей, связанных с безопасностью VoIP, является список рассылки VOIPSEC на VOIPSA.org. На сайте также есть дополнительные ресурсы.

Наконец, в проекте VoIP Blacklist Project есть полезная информация. Автор предоставляет список адресов, известных как источники атак VoIP, а также инструкции о том, как заблокировать все адреса в этом списке. Автор также предоставляет образец сценария под названием AntiToll, который блокирует все адреса за пределами США.

Заключение—лучший идиот

В технологической отрасли есть принцип: «Как только что-то сделается идиотским, природа будет изобретать лучшего идиота». Дело в том, что никакие усилия по развитию не могут считаться завершенными. Всегда есть место для улучшения.

Когда дело доходит до безопасности, вы всегда должны помнить что люди, которые хотят использовать вашу систему, очень мотивированы. Независимо от того, насколько безопасна ваша система, кто-то всегда будет искать брешь в безопасности.

Мы не выступаем за паранойю, но предполагаем кое-что, о чем мы здесь написали, отнюдь не последнее слово в безопасности VoIP. Хотя и старались быть настолько всеобъемлющими, как можем быть в этой книге, вы должны нести ответственность за безопасность своей системы.

Как бесплатная Интернет-телефония становится все более распространенной, преступники будут упорно работать, чтобы найти недостатки и использовать их.

1Реальный IP-адрес в записях журнала был заменен на 127.0.0.1.

2[22 авг. 15:17:15] УВЕДОМЛЕНИЕ [25690] chan_sip.c: Регистрация от ‘“123” <sip: [email protected]>’ не удалась для ‘203.86.167.220:5061’ — не найдено совпадения пира

3Лейф усвоил этот трудный путь. Он думал, что его АТС не работает, в то время как у Рассела и Джима не было проблем с подключением к конференц-мосту. Оказалось, что Fail2ban запретил ему пользоваться собственной АТС.