По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье мы разберем принцип работы и настройку IP-телефонии по Ethernet сетям.
В мире IP-телефонии телефоны используют стандартные порты Ethernet для подключения к сети, и поэтому для отправки и приема голосового трафика, передаваемого посредством IP-пакетов, они используют стек протоколов TCP/IP. Чтобы это работало, необходимо, чтобы порт коммутатора работал как порт доступа, но, в то же время, этот порт работал как магистраль для передачи другого трафика.
Принцип работы VLAN для передачи данных и голоса
До IP-телефонии компьютер и телефон располагались на одном рабочем месте. Телефон подключался по специальному телефонному кабелю (телефонный UTP-кабель). Причем этот телефон был подключен к специальному голосовому устройству (часто называемому voice switch или частной телефонной станцией private branch exchange [PBX]). ПК, конечно же, подключался с помощью Ethernet кабеля (UTP витой пары) к обычному коммутатору локальной сети, который находился в коммутационном шкафу - иногда в том же коммутационном шкафу, что и голосовой коммутатор (voice switch). На рисунке показана эта идея.
Предположим, что у нас есть три виртуальные сети VLAN1, VLAN2 и VLAN3. Виртуальные сети VLAN 1 и VLAN 3 содержат по две пары ПК, которые подключаются к коммутатору через отдельные интерфейсы. Для сети VLAN 1 отведены четыре интерфейса "fa0/12", "fa0/11", "fa0/22", и "fa0/21" соответственно. Аналогично, 4 интерфейса отведены для сети VLAN 3 - "fa0/15", "fa0/16", "fa0/23", и "fa0/24" соответственно. Сеть VLAN 2 состоит из двух ПК, которые подключаются к коммутатору через интерфейсы "Fa0/13" и " Fa0/14". Два коммутатора соединены между собой через магистраль, и интерфейсы "Gi0/1" и "Gi0/2".
Термин IP-телефония относится к отрасли сети, в которой телефоны используют IP-пакеты для передачи и приема голоса, представленного битами в части данных IP-пакета. Телефоны подключаются к сети, как и большинство других устройств конечных пользователей, используя либо кабель Ethernet, либо Wi-Fi. Новые IP-телефоны не подключаются непосредственно по кабелю к голосовому коммутатору, а подключаются к стандартной IP-сети с помощью кабеля Ethernet и порта Ethernet, встроенного в телефон. После чего телефоны связываются по IP-сети с программным обеспечением, которое заменило операции вызова и другие функции АТС.
Переход от использования стационарных телефонов, которые работали (некоторые работают по сей день) с использованием телефонных кабелей к новым IP-телефонам (которые нуждались в UTP-кабелях, поддерживающих Ethernet) вызвал некоторые проблемы в офисах.
В частности:
Старые, не IP-телефоны, использовали категорию UTP-кабелей, у которых частотный диапазон не поддерживал скорость передачи данных в 100-Mbps или 1000-Mbps.
В большинстве офисов был один кабель UTP, идущий от коммутационного шкафа к каждому столу. Теперь же на два устройства (ПК и IP-телефон) требовалось два кабеля от рабочего стола к коммутационному шкафу.
Прокладка нового кабеля к каждому рабочему месту вызовет дополнительные финансовые затраты, и плюс потребуется больше портов коммутатора.
Чтобы решить эту проблему, компания Cisco встроила небольшие трехпортовые коммутаторы в каждый телефон.
IP-телефоны включают в себя небольшой коммутатор локальной сети, расположенный в нижней части телефона. На рисунке показаны основные кабели, причем кабель коммутационного шкафа подключается напрямую к одному физическому порту встроенного коммутатора телефона, ПК подключается патч-кордом к другому физическому порту телефона, а внутренний процессор телефона подсоединяется к внутреннему порту коммутатора телефона.
Компании, использующие IP-телефонию, теперь могут подключать два устройства к одному порту доступа. Кроме того, лучшие практики Cisco, для проектирования IP-телефонии, советуют поместить телефоны в один VLAN, а ПК в другой VLAN. Чтобы это работало, порт коммутатора действует частично в режиме канала доступа (для трафика ПК) и частично как магистраль (для трафика телефона).
Особенности настройки VLAN’ов на этом порту:
VLAN передачи данных: та же идея настройки, что и VLAN доступа на access порту, но определенная как VLAN на этом канале для пересылки трафика для устройства, подключенного к телефону на рабочем месте (обычно ПК пользователя).
Voice VLAN: VLAN для пересылки трафика телефона. Трафик в этой VLAN обычно помечается заголовком 802.1 Q.
На рисунке изображена типичная конструкция локальной сети. Имеется коммутатор, подключенный к двум последовательным уровням сетей, VLAN 11 и VLAN 10, где сеть VLAN 11- Voice VLAN, содержащая 4 IP-телефона, и сеть VLAN 10 - Data VLAN, состоящая из 4 ПК.
Настройка и проверка работы Data и Voice VLAN
Для настройки порта коммутатора, который сможет пропускать голосовой трафик и информационные данные, необходимо применить всего несколько простых команд. Однако разобраться в командах, позволяющих просмотреть настройки режима работы порта, непросто, так как порт действует как access порт во многих отношениях.
Ниже показан пример настройки. В данном примере используются четыре порта коммутатора F0/1F0/4, которые имеют базовые настройки по умолчанию. Затем добавляются соответствующие VLAN’ы: VLAN 10 Data Vlan, VLAN 11- Voice Vlan. Далее все четыре порта настраиваются как порты доступа и определяется VLAN доступа (Vlan 10 Date Vlan). В конце настройки определяем на порт VLAN для передачи голосовых данных (Vlan 11- Voice Vlan). Данный пример иллюстрирует работу сети, изображенную на рисунке:
При проверке состояния порта коммутатора, из примера выше, увидим разницу в отображаемой информации выходных данных, по сравнению с настройками по умолчанию порта доступа и магистрального порта. Например, команда show interfaces switchport показывает подробные сведения о работе интерфейса, включая сведения о портах доступа. В примере 2 отображены эти детали (подчеркнуты) для порта F0/4 после добавления настроек из первого примера.
Первые три выделенные строки в выходных данных отображают детали настройки, соответствующие любому порту доступа. Команда switchport mode access переводит порт в режим порта доступа. Далее, как показано в третьей выделенной строке, команда switchport access vlan 10 определила режим доступа VLAN.
Четвертая выделенная строка показывает новый фрагмент информации: идентификатор Voice VLAN, активированная командой switchport voice vlan 11. Эта небольшая строка является единственной информацией об изменении состояния порта.
Такой большой и интересный инструмент - а разворачивать как?
В одной из предыдущих статей мы знакомились с таким инструментом разработчика, как ELK. Сегодня мы разберемся, как правильно подготовить этот комплекс для практической работы.
Для начала напомним, что ELK это один из наиболее удобных инструментов разработчика, предназначенный для быстрого выявления неполадок в работе объемных программ путем сбора и анализа логов. Этот комплекс состоит из трех приложений: поисковика Elasticsearch, сборщика данных Logstash и визуализатора Kibana. Весь комплекс разрабатывается компанией Elastic.
Ознакомимся с системными требованиями. На каждом из серверов в системе рекомендуется иметь не менее 8 физических ядер и не менее 48 Гб оперативной памяти. Кроме того, если данные планируется собирать с крупной системы, то объем внутренней памяти будем оценивать по принципу "чем больше тем лучше". 8 Тб это рекомендуемые требования, но этот показатель может варьироваться. Ну и, разумеется, чем выше скорость соединения между серверами - тем быстрее будет проводиться обработка информации. Рекомендуемый показатель - 1Гб/с. Система из трех таких серверов позволит обрабатывать до тысячи событий в секунду, собирать и отображать 95% данных за отдельные периоды времени (5 минут, сутки),хранить данные до 90 дней и обслуживать до 10 клиентов по протоколу HTTP одновременно.
Поскольку все элементы данного решения реализованы на Java, первым делом нужно установить актуальную версию Oracle Java. Также рекомендуется изучить дополнительную информацию о компонентах ELK на предмет совместимости версий.
Если на Вашей рабочей станции установлены Ubuntu или Debian, устанавливаем соединение с репозиторием для скачивания Oracle Java. Если вы пользуетесь CentOS то качаем программную среду на сервер с сайта разработчика. После того, как процесс установки завершится рекомендуется проверить актуальную версию с помощью соответствующей команды консоли. Если все хорошо, то это значит, что почва подготовлена, и можно переходить к следующему этапу
А им станет скачивание и установка поискового инструмента Elasticsearch. Это также не вызовет особой сложности достаточно скопировать в систему публичный ключ репозитория, установить с ним соединение (пользователи Debian и Ubuntu могут столкнуться с отсутствием загрузочного пакета apt-transport-https его нужно будет установить дополнительно), скачать актуальную версию Elasticsearch и запустить процесс установки. Чтобы работа приложения была корректной, его стоит добавить в автозагрузку. Затем проверяем, штатно ли прошла установка, запустив программу.
Итак, все запустилось нормально. Можно переходить к этапу конфигурирования Elasticsearch. Это не займет много времени нужно будет отредактировать пару строк в файле конфигурации /etc/elasticsearch/elasticsearch.yml. Во-первых, чтобы не собирать лишнюю информацию, указываем хост локального интерфейса, через который будет передавать данные Logstash (по умолчанию, данные собираются со всех сетевых интерфейсов), а во-вторых, указываем путь к хранилищу данных, откуда мы и будем с ними работать. Рекомендуется выделить под хранилище значительные объемы памяти чем сложнее проект, тем больше будут весить собираемые логи. После завершения процесса настройки перезапускаем и проверяем программу.
Далее нас ждет установка веб-панели Kibana. Этот процесс почти не отличается от установки Elasticsearch, ключи репозиториев будут одинаковыми. В целом, все то же самое устанавливаем соединение с репозиторием, скачиваем, устанавливаем, добавляем в автозагрузку, запускаем, проверяем. Стоит обозначить, что приложение загружается довольно долго, поэтому проверку лучше осуществить через пару минут после отдачи команды на запуск приложения.
Редактирование настроек Kibana можно осуществить через файл /etc/kibana/kibana.yml. Здесь нас интересует строка с указанием интерфейса, который будет "слушать" Kibana. Это могут быть все интерфейса, либо один определенный в данном случае нужно будет указать конкретный ip-адрес нужного сервера. Далее проверим сам веб-интерфейс, для этого указываем адрес - например, http://10.1.4.114:5601.
Наконец, перейдем к этапу установки Logstash. Здесь все то же самое, только перед проверочным запуском программу нужно настроить. Можно отредактировать основной файл настроек /etc/logstash/logstash.yml, но рациональнее будет создать несколько файлов конфигурации в директории /etc/logstash/conf.d, чтобы группировать настройки по назначению.
Создаем файлы input.conf и output.conf. В первом файле мы указываем порт, на который будем принимать информацию, а также параметры ssl, если в этом есть необходимость. Во втором файле указываем параметры передачи данных в Elasticsearch. Данные лучше передавать под указанным дополнительно индексом, также используя маску в виде даты. Также можно отключить функцию отправки данных в общий лог системы, чтобы не занимать место в хранилище дублированными фрагментами информации.
Кроме этого, потребуется создать файл с параметрами обработки данных. Дело в том, что не всегда удобно работать с полным объемом, и приходится делать выборку ключевых данных. Создаем файл filter.confи указываем параметры, на основании которых будут фильтроваться необходимые данные. Также при необходимости можно настроить, например, корректное отображение даты или географического местоположения сервера, с которого будет поступать информация. Завершив конфигурирование, можно проверить работу программы, запустив ее и просмотрев внутренний файл лога /var/log/logstash/logstash-plain.log.
Основной пакет программ установлен теперь осталось установить программы, которые будут отправлять данные, на сервера. Компания Elastic предлагает использовать Filebeat, но можно воспользоваться и альтернативными вариантами. Здесь процесс установки аналогичен предыдущим. Файл настроек по умолчанию позволяет сразу работать с программой, но можно и подредактировать его при необходимости.
Если все сделано правильно, программный комплекс уже начал собирать логи. Следующим шагом будет открытие веб-интерфейса Kibana и настройка паттерна индекса, чтобы лог открывался в веб-интерфейсе по умолчанию, а в сохраняемых данных не было путаницы.
Мы уже рассказывали об опасности атак на системы IP-телефонии, о том, как можно использовать скомпрометированную систему и кому это может быть выгодно.
В данной статье, подробно разберём один из способов атак на системы, работающие по протоколу SIP, через генерацию вредоносного пакета и последующую компрометацию учётной записи.
Вы убедитесь, что провести подобную атаку - совсем не сложно. Инструменты для её осуществления не являются какой-то сверхсекретной разработкой и находятся в свободном доступе.
Цель данной статьи - показать, к чему может привести недостаточное внимание, уделённое вопросам безопасности при настройке систем IP-телефонии и как просто это могут использовать злоумышленники.
Внимание! Информация, представленная в данной статье, носит исключительно ознакомительный характер. Компания Мерион Нетворкс не несёт ответственности за последствия применения техник и способов, описанных в данном материале. Напоминаем, что неправомерный доступ к компьютерной информации преследуется по закону и влечет за собой уголовную ответственность.
Атака, о которой мы поговорим, связана с процессом аутентификации по протоколу SIP, а именно - с получением информации из заголовков SIP пакета и её последующая обработка для извлечения учётных данных. Чтобы понять её суть и определить, какие системы уязвимы к данной атаке, нужно вспомнить как происходит SIP аутентификация.
Как показано на рисунке:
Клиент отправляет запрос регистрации на сервер;
Сервер сообщает о необходимости зарегистрироваться и запрашивает данные для аутентификации;
Клиент повторно отправляет запрос регистрации, но на этот раз со строкой Authorization, в которой указаны учётные данные;
Сервер проверяет учётные данные в локальной базе и если есть совпадения – разрешает регистрацию.
В стандартном процессе SIP аутентификации все запросы клиентов и ответы от сервера идут в строгой последовательности. Пользователь просто вводит учётные данные и клиент сам формирует пакеты для отправки на сервер, которые он может обработать. Если учётные данные не верны, то сервер не разрешит регистрацию и дальнейшее взаимодействие для осуществления звонков.
Однако, злоумышленник, используя специальные инструменты, может сам решать какие отправлять пакеты и более того - осуществлять их формирование.
Наверное, Вы догадались, что ключевым моментом процесса SIP аутентификации является отправка клиентом повторного запроса REGISTER, который также содержит учётные данные для регистрации на сервере. Как раз в этот момент, наш потенциальный злоумышленник и нанесёт свой удар.
Давайте рассмотрим, что из себя представляет строка Authorization в повторном запросе REGISTER.
Как видно на рисунке, заголовок Authorization включает в себя следующие поля:
Authentication Scheme - метод аутентификации;
Поскольку SIP многое унаследовал от протокола HTTP, то и схема аутентификации в нём основана на HTTP аутентификации, которая также называется Дайджест (Digest) аутентификация. Эта схема применяется серверами для обработки учётных данных от клиентов. При этом, часть учётных данных передаётся в виде хэш-сумм, которые сервер комбинирует с открытыми данными и вычисляет пароль для данного клиента. Это значительно повышает уровень безопасности, но как мы убедимся в дальнейшем – не помогает при некорректной настройке учётной записи.
Username - имя пользователя, заданное на сервере. В нашем случае – это внутренний номер 3354;
Realm - параметр, определяющий подключение к серверу телефонии;
Как правило, администратор VoIP сервера сам настраивает realm и транслирует его пользователю, который хочет осуществить подключение. Например, у провайдеров облачных услуг это может быть строка вида domain.com, в сервере Asterisk, по-умолчанию значение этой строки - asterisk.
Nonce Value - рандомно сгенерированная сервером, уникальная строка, при формировании ответа 401 в сторону клиента. В дальнейшем используется сервером в вычислениях после получения учетных данных от клиента, должна совпадать с тем, что пришло от сервера;
Authentication URI - унифицированный идентификатор ресурса. В нашем случае, ресурсом является сервер, расположенный по адресу 123.45.67.89, обращение к нему происходит по протоколу SIP, по порту 5060.
Digest Authentication Response - ответ от клиента, посчитанный на основании данных, полученных от сервера. На основании этого значения сервер в том числе сверяет пароль, который задан клиенту.
Согласно RFC 2069, который описывает HTTP дайджест аутентификацию, response вычисляется следующим образом:
HA1 = MD5(username:realm:password)
HA2 = MD5(method:digestURI)
response = MD5(HA1:nonce:HA2)
Как видите, на основании MD5 хэш-сумм полей: username, realm, password (да, это пароль клиента), method, digestURI и nonce высчитывается тот самый заветный response, от которого зависит регистрация клиента на сервере, а следовательно, и возможность осуществлять им вызовы.
Algorithm - алгоритм, по которому высчитывался response
Догадываетесь о чём идёт речь? О том, что если злоумышленник заполучит полную строку Authorization, то он может вычислить пароль клиента, зарегистрироваться на сервере и спокойно звонить куда ему вздумается.
Пространство для данной атаки достаточно обширное. Дело в том, что клиент может передавать строку авторизации в нескольких запросах – в уже известном нам REGISTER, INVITE или BYE.
Атакующему не составит труда притвориться “сервером” и затребовать от клиента аутентификации. Для этого, атакующий направит в сторону клиента, созданный с помощью специальной программы вредоносный SIP пакет с ответом 401 Unauthorized, который будет содержать строку, заставляющую клиента отправить учётные данные. Данная строка должна содержать realm и nonce . Выглядит эта строка следующим образом:
Таким образом, атака может выглядеть следующим образом:
С точки зрения атакуемого, это будет выглядеть как простой звонок, на другой стороне трубки которого будет тишина. Он даже не будет подозревать о том, что его учётные данные вот-вот утекут к злоумышленнику. Атакующий в нужный момент разорвёт соединение, отправив BYE и затем сформированный вредоносный пакет.
Нагляднее всего приводить в пример прямое взаимодействие между клиентами. Такой сценарий становится, когда есть возможность отправлять SIP запросы напрямую до оконечного клиента. Например, когда телефон выставлен в открытую сеть по SIP порту. Помимо этого, уязвимости подвержены сервера, разрешающие прямое взаимодействия между оконечными клиентами. Лучше всего, пропускать все запросы через Proxy-сервер.
Итак, данной атаке могут быть подвержены:
IP-телефоны с открытыми в интернет SIP-портами;
IP-телефоны, отвечающие на запросы INVITE от неизвестных серверов;
IP-АТС, разрешающие запросы INVITE напрямую до клиентов.;
Заполучив полную строку Authorization атакующий может в оффлайн режиме подобрать пароль к учётной записи. Для этого ему нужно подать на вход специального скрипта, который перебирает хэш-суммы по словарям, перехваченные данные: username, realm, method, digestURI, nonce и наконец - response. На выходе он получит пароль от учётной записи. Если пароль слабый или, ещё хуже, совпадает с username, то время перебора не превысит 1 секунды.
Чтобы этого не случилось, даже если злоумышленник перехватит необходимую информацию, используйте стойкие пароли к учётным записям, да и вообще везде, где только можно. В этом Вам может помочь наш генератор паролей.