По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Новый, и безусловно интересный модуль Calendar позволяет гибко управлять временной сегментацией вызова. Что это значит? Теперь маршрутизация вызова и привычные time – conditions и time – group, которые строго настраиваются через графический интерфейс FreePBX, могу быть сконфигурированы простой синхронизацией с календарем!
В статье расскажем о возможностях модуля и настройке интеграции с Google календарями.
Настройка с Google
Модуль уютно расположился в разделе Applications → Calendar.
Собственно, давайте попробуем прикрутить Google Calendar к FreePBX? Логинимся в наш календарь:
Слева, в разделе Мои календари выбираем нужный. Наводим на него курсор мыши и в разделе редактирования отмечаем Настройки и общий доступ. В разделе настроек листаем вниз и находим URL в опции Закрытый адрес в формате iCal:
Проще простого. А теперь прыгаем в настройку модуля Calendar и выбираем опцию Add Remote iCal Calendar. Указываем следующие опции:
Name - имя для календаря;
Description - описание для календаря;
Remote URL - ссылка на ical, о которой мы говорили ранее;
Synchronization Time - как часто синхронизировать календарь? Гиперактивность нашего эвент – менеджера навела на мысль сделать 10 минут;
Сохраняем.
Сохранил, что дальше?
А дальше все гораздо интереснее. Теперь можно настроить временную сегментацию с помощью календаря! Прыгаем в Applications и далее во вкладку Time Conditions:
Time Zone - временная зона для этого календаря;
Mode - в каком режиме работать этому временному условию: мы выбираем в режиме календаря;
Calendar - какой календарь использовать? В случае, если на время работы этого временного условия есть отметка в календаре, то временная кондиция отработает (по аналогии с Time Group);
Calendar Group - группа календарей. Работает так же по схеме сопоставления событий;
Круто, да? Но подождите удивляться. Календарь можно интегрировать с Follow Me! То есть менеджер автоматически по событию в календаре включать переадресацию на мобильный! Прыгаем в Applications → Extensoins и выбираем Follow Me:
Enable Calendar Matching - включаем режим календаря;
Calendar - какой календарь использовать? В случае, если на время работы этого временного условия есть отметка в календаре, то временная кондиция отработает (по аналогии с Time Group);
Calendar Group - группа календарей. Работает так же по схеме сопоставления событий;
Calendar Match Inverse - когда установлено в положение Yes, то Follow Me будет отрабатывать когда есть событие в календаре, а когда выставлено в положение No, то когда события нет;
Мы уже рассказывали об опасности атак на системы 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 секунды.
Чтобы этого не случилось, даже если злоумышленник перехватит необходимую информацию, используйте стойкие пароли к учётным записям, да и вообще везде, где только можно. В этом Вам может помочь наш генератор паролей.
Всем привет! Сегодня в статье рассмотрим установку MySQL Server на CentOS 7. MySQL – популярная реляционная СУБД с открытым кодом, и, её популярность означает огромное количество информации в интернете и большое количество хорошо документированных библиотек. MySQL поддерживает множество стандартных функций, присущих СУБД – репликацию, триггеры и прочие.
В большинстве дистрибутивов по умолчанию присутствуют репозитории, в которых есть нужный нам пакет MySQL – однако, на примере CentOS 7 Minimal я хотел бы показать процесс добавления официального YUM репозитория от Oracle, в котором всегда доступна последняя версия.
Процесс установки
Предварительно нам необходимо установить wget чтобы скачивать файлы – для этого выполните команду yum install wget.
Далее, для начала процесса установки необходимо зайти на сайт MySQL по следующему линку: http://dev.mysql.com/downloads/repo/yum/ , выбрать необходимый дистрибутив (в нашем случае - Red Hat Enterprise Linux 7 / Oracle Linux 7) и нажать Download. Ссылка для скачивания может быть получена без регистрации, для этого нужно найти слова «No thanks, just start my download»
Скопируем адрес ссылки и выполним команду wget с этим адресом:
wget https://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm
Без каких-либо модификаторов команда wget скачает файл в каталог, в котором вы находитесь в данный момент, далее необходимо выполнить команду rpm –Uvh mysql57-community-release-el7-11.noarch.rpm - для более простого ввода имени пакета воспользуйтесь табуляцией (нажать Tab).
Теперь подключен официальный репозиторий Oracle, настала очередь установки непосредственно самого MySQL сервера:
yum –y install mysql-community-server
Процесс скачивания и установки пакета займёт какое-то время.
Далее необходимо разрешить автозапуск демона MySQL при загрузке:
/usr/bin/systemctl enable mysqld
И запустить сам MySQL сервер:
/usr/bin/systemctl start mysqld
Настройка безопасности
После старта сервера, необходимо настроить политики безопасности – для этого служит скрипт mysql_secure_installation - но предварительно нам понадобится случайно сгенерированный пароль для root – его можно выяснить с помощью команды grep 'temporary password' /var/log/mysqld.log. Пример на скриншоте ниже:
Далее нужно ввести команду /usr/bin/mysql_secure_installation и вам будет предложено ввести данный пароль на рут, поменять его на нечто вроде E+FW4tz8$?/7$dCm и ответить на несколько вопросов:
Set root password? [Y/n] Y - установка пароля на root;
Remove anonymous users? [Y/n] Y - удаление анонимных пользователей;
Disallow root login remotely? [Y/n] Y - запрет удаленного логина;
Remove test database and access to it? [Y/n] Y - удаление тестовых баз данных и доступа к ним;
Reload privilege tables now? [Y/n] Y - перезагрузка привилегированных таблиц;
Очень советую пароль придумать максимально сложный – кроме того, по дефолту, у вас не получится поставить простой пароль.
Создание тестовой базы данных и манипуляции с пользователями
Когда вам понадобится дать доступ какому-нибудь приложению доступ к вашей БД, ни в коем случае нельзя этого делать от пользователя root – для каждого приложения должен быть создан свой пользователь. Для создания, сначала необходимо зайти в MySQL от имени администратора с помощью команды mysql -u root -p mysql . Далее я приведу пример создания БД testdb и открытия полного доступа к этой БД для пользователя testuser (имя пользователя и пароль соответственно необходимо скорректировать относительно вашей непосредственной задачи):
create database testdb;
grant all on appdb.* to 'testuser'@'localhost' identified by 'password';
quit
Для проверки доступа нужно использовать команду mysql -u testuser -p -h localhost testdb , а для выводы всех имеющихся БД – команду SHOW DATABASES;
Рассмотрим пример создания пользователя для MySQL и просмотра списка всех пользователей. MySQL содержит информацию о пользователях в своей собственной базе данных под названием mysql, внутри которой информация о пользователях находится в виде таблицы под названием user. Если вы хотите вывести весь список пользователей, то необходимо выполнить следующую команду:
SELECT User, Host, Password FROM mysql.user;
Это стандартный MySQL синтаксис. Давайте разберемся с ним:
SELECT - запрос информации;
User, Host, Password - конкретизация полей, из которых информация должна быть извлечена. В данном случае мы ищем информацию о пользователе, хостнейме и зашифрованном пароле;
FROM mysql.user - запрашиваем информацию мы из БД mysql и таблицы user;
; - точка с запятой означают конец команды, в MySQL все запросы должны кончаться точкой с запятой;