Файл: «Проектирование защищенной системы.pdf

iax.conf
[guest]
type=user
context=guest
extensions.conf
 [guest]
exten = > _X.,1,Hangup
exten = > i,1,Hangup

Однако, открытие гостевого входа чревато другими последствиями – атаками по типу отказа в обслуживании. Поэтому наиболее сильной защитой IAX2 пользоваталей будет использование аутентификации по RSA ключам, так как подобрать такой ключ практически невозможно. Есть определённые тонкости в указании маски шаблона (extension pattern). Например, администратор настроил, чтобы локальные звонки проходили через собственные линии компании, а МГ/МН звонки шли на SIP провайдера.

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

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

CLI> dialplan show 2323956@users

На выводе будет точно указано, какая из строк плана набора вызовет совпадение. В нашем примере, если во второй строке указать не _XXXXXX, а _XXXXXX. (с точкой в конце), то все звонки будут попадать под маску _X. и уходить по SIP каналу, вместо Zap.
Особое предупреждение относится к маске _. – она совпадает со всеми возможными вариантами, включая служебные extension h,s,i и другие.
Чтобы убедиться, что все набрано правильно, надо использовать команду Asterisk:

*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)

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

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

[709] (user)
secret=secret
mailbox=709
callerid= «Max» <709>
host=172.16.3.10

[710] (user)
secret=secret
mailbox=710
callerid= «Masha» <710>
host=172.16.3.11

Если политикой безопасности компании разрешено удаленное подключение к системе, и  используется директива 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=176.241.0.0/255.255.0.0

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

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

Контексты различаются по именам. Имена контекстов заключаются в квадратные скобки ([ ]). Допустимыми символами для образования имени являются буквы от A до Z (верхнего и нижнего регистра), цифры от 0 до 9, дефис и символ подчеркивания. Например, контекст для входящих вызовов может выглядеть так:

[incoming]

Все инструкции, размещаемые после описания контекста и до описания следующего контекста, являются частью данного контекста. В начале диалплана находятся два специальных контекста, [general] и [globals]. Раздел [general] содержит список общих настроек диалплана (о которых, вероятно, вам никогда не придется беспокоиться), а о контексте [globals] мы поговорим в другой статье, когда речь пойдет о «Глобальных переменных». Пока что достаточно знать, что эти два контекста являются специальными. Созданные вами контексты можно называть как угодно, только не используйте имена [general] и [globals]!
При описании канала (а именно так выполняется подключение элементов к системе) одним из параметров этого описания является контекст. Иначе говоря, контекст – это точка диалплана, с которой будет начинаться обработка соединений, выполняемых через этот канал.
Другое важное применение контекстов (возможно, самое важное) – обеспечение безопасности. Правильно применяя контексты, определенным абонентам можно предоставить доступ к функциям (таким, как междугородная связь), которые недоступны для других. Если диалплан разработан неаккуратно, пользователи из-за ваших же косяков могут получить возможность мошенничать в вашей системе.

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

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

• Во-первых самое важное и основное в работе администратора это всегда менять логины и пароли на всех сетевых устройствах особенно на IP-телефонах, VOIP шлюзах и так далее;
• Во-вторых использовать не стандартные порты SIP, IAX, SSH, чем больше он будет не похож на стандартный тем больше возможность обезопасить себя и свою сеть от вражеских и хакерских атак;
• В-третьих создать пользователя с правами доступа по протоколу SSH;
• В-четвертых задать лимит звонков, то есть ограничить количество одновременных соединений внутреннего абонента, но это актуально на случай если все же подверглись атаке;
• В-пятых отключить ответ о неверно введенном пароле. По умолчанию Asterisk выдает ошибку о неверном пароле для несуществующего аккаунта и для существующего. Обычно злоумышленники методом подбора находят правильный пароль аккаунта. После изменений в файле sip.conf Asterisk выдает лишь одну ошибку “401 Unauthorized” и больше подробностей не сообщает.
• В-шестых задать разрешенные адреса для внутренних абонентов (deny/permit). Данной настройкой мы ограничиваем возможность регистрации внутренних абонентов только с доверенных IP адресов

Следуя этим простым и обычным правилам профилактики безопасности телефонной сети, мы обезопасим компанию от нежелательных растрат и

атак злоумышленников.

ЗАКЛЮЧЕНИЕ

По итогам реализации данного проекта была создана сеть на предприятии ОАО “НИИМЭ и Микрон”. Был сделан обзор обеспечения сети и выбраны наиболее оптимальные. Была разработана схема сети, проанализированы и выбраны топологии и технологии, настроены сетевые устройства, компьютеры, проверка сети которая показала ее работоспособность.

Подняты протоколы доступа, показаны возможности настройки Asterisk сервера в качестве IP-PBX. Был сделан обзор протоколов SIP, VoIP, показана возможность работы телефонии с помощью данных протоколов. Настроена трансляция сетевых адресов. Созданы VLAN, настроена динамическая раздача IP-адресов, настроено ограничение доступа к сетевым устройствам и серверу. Была проанализирована система защиты PBX сервера от атак злоумышленников, профилактические методы и рекомендации для эффективности сети в результате которой сеть была признана эффективной в плане безопасности и защищенности от вражеских атак.

СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

Литература:

1. Гольдштейн Б.С., Соколов Н.А., Яновский Г.Г. Сети связи: Учебник для ВУЗов. СПб.: БХВ-Петербург, 2010 г.;

2. Епанешников А. М., Епанешников В. А. «Локальные вычислительные сети» Диалог-МИФИ - ,2013 г.;

3. Колбин Р. В. «Глобальные и локальные сети. Создание, настройка и использование» Бином. Лаборатория знаний - Москва, 2011 г.;

4. Ларионов, А.М.; Майоров, С.А.; Новиков, Г.И. «Вычислительные комплексы, системы и сети» Л.: Энергоатомиздат - Москва, 2014 г.;

5. Джесси Рассел. «Виртуальные локальные сети», 2011 г.

6. В. Олифер, Н. Олифер «Компьютерные сети. Принципы, технологии, протоколы», 2012 г.

7. Э. Таненбаум, Т. Остин «Архитектура компьютера», 2015 г.

8. Н. Максимов, И. Попов «Компьютерные сети», 2015г.

Web-ресурсы:

9. www.cisco.com/ – официальный сайт производителей фирмы CISCO (дата обращения 9.06.2018);

10. www.wikipegia.org/ – всемирная справочная энциклопедия (дата обращения 9.06.2018);

11. www.mikron.ru/ – официальный сайт предприятия (дата обращения 9.06.2018);

12. www.shop.nag.ru/ - полное описание сетевого и прочего оборудования (дата обращения 10.06.2018);

13. http://habrahabr.ru – сайт, посвященный работе с компьютерным оборудованием (дата обращения 11.06.2018);

14. https://technet.microsoft.com - удаленный доступ, вся информация, возможности (дата обращения 10.06.2018);

15. http://system-administrators.info – информация по настройке DHCP, SSH/Telnet, Asterisk (дата обращения 8.06.2018);