По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Одним из важных компонентов установления соединения по протоколу SIP является протокол Session Description Protocol, или сокращенно SDP.
О протоколе SDP впервые заговорили в 1998 году в рамках опубликованного RFC2327. Спустя 8 лет, в 2006 году протокол претерпел некоторые изменения, которые были отображены в RFC4566.
Протокол SDP используется для установления соединения и согласования параметров передачи и приема аудио или видео потоков между оконечными устройствами. Наиболее важными параметрами обмена являются IP – адреса, номера портов и кодеки. Давайте разбираться?
Пример SDP
При установлении сессии SDP параметры передаются в рамках SIP – запросов. Давайте взглянем на один из таких запросов. В данном случае распарсим SIP INVITE, который прилетело на нашу IP – АТС Asterisk с помощью утилиты sngrep:
INVITE sip:74996491913@192.168.x.xxx:5061;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 80.xx.yy.zz:5060;branch=z9hG4bK-524287-1-MThkZjMzNzMyXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;rport
Via: SIP/2.0/UDP 80.xx.yy.zz:5077;branch=z9hG4bK-XXXXXXXXXXXXXXXX;rport=5077
Max-Forwards: 69
Record-Route: <sip:80.xx.yy.zz:5060;lr;transport=UDP>
Contact: <sip:80.xx.yy.zz:5077>
To: <sip:74996491913@80.xx.yy.zz>
From: <sip:7925XXXXXXX@80.xx.yy.zz>;tag=qdpxhe2avyyjcqfn.o
Call-ID: fb9909e8fYYYYYYYYYYYYYYYYYYYYYY
CSeq: 479 INVITE
Expires: 300
Allow: INVITE, ACK, BYE, CANCEL, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS, UPDATE
Content-Disposition: session
Content-Type: application/sdp
User-Agent: Sippy
P-Asserted-Identity: <sip:7925XXXXXXX@80.xx.yy.zz>
Remote-Party-ID: <sip:7925XXXXXXX@80.xx.yy.zz>;party=calling
h323-conf-id: 4133864240-4217115111-2706418710-XXXXXXXXX
Portasip-3264-action: offer 1
cisco-GUID: 4133864240-4217115111-2706418710-XXXXXXXXX
Content-Length: 278
v=0
o=Sippy 1011212504475793896 1 IN IP4 80.xx.yy.zz
s=-
c=IN IP4 80.xx.yy.zz
t=0 0
m=audio 57028 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
В приведенном примере можно увидеть, что основная часть SIP – сообщения отделена от SDP сегмента пустой строкой. Помимо прочего, поле Content-Type, что сообщение сопоставимо с SDP параметрами.
Про SDP поля
Каждый из параметров SDP сообщения можно отнести к одной из следующих категорий:
Имя сессии;
Время, в течении которого сессия активна;
Параметры медиа;
Информация о пропускной способности;
Контактная информация;
Поговорим об основных параметрах. Они всегда имеют следующее обозначение: <поле> = <значение>. Поле всегда обозначается 1 буквой.
Поле
Значение
Формат
v=
версия протокола
v=0
o=
инициатор сессии и соответствующие идентификаторы
o=<имя_пользователя> <идентификатор_сессии> <версия> <тип_сети> <тип_адреса> <адрес>. В нашем примере поле o=Sippy 1011212504475793896 1 IN IP4 80.xx.yy.zz (IN - тип сети, интернет, IP4 - тип адреса, IPv4;
s=
имя сессии
в нашем примере прочерк ("-"), имя сессии не указано;
c=
информация о подключении;
Синтаксис таков: c=<тип_сети> <тип_адреса> <адрес>. В нашем примере IN IP4 80.xx.yy.zz. Параметры IN/IP4 объяснены выше.
t=
время активности сессии
Синтаксис поля таков: t=<начальное_время> <конечное_время>. Это обязательное поле, но важно отметить, что оно весьма субъективно, так как невозможно предсказать точное время начала и окончания. В нашем примере t=0 0
m=
тип передачи медиа данных, формат и адресация
m=<тип_медиа> <порт> <транспорт> <формат_передачи>. Давайте разберемся - у нас m=audio 57028 RTP/AVP 0 8 18 101, это означает передачу аудио (может быть значение video, или передача обоих типов), порт передачи обозначен как 57028, транспорт, указанный как RTP/AVP, означает передачу по протоколу RTP в рамках стандарта Audio and Video Conferences with Minimal Control, который описан в RFC3551. После, первый 0 означает протокол G.711 uLaw, 8 означает G.711 ALaw, 18 означает G.729. То есть условно говоря, нам предложено предпочтение кодеков сначала G.711 uLaw, затем G.711 ALaw, и третьим приоритетом G.729. 101 означает поддержку динамического типа данных, например DTMF.
a=
параметры сессии
a=<параметр> или a=<параметр><значение>. SDP сессия может содержать несколько дополнительных атрибутов передачи. Более подробно мы рассмотрим далее.
Помимо указанных параметров, зачастую встречаются такие как k=, в рамках которого описывается метод шифрования, или i=, содержащий дополнительную информацию о сессии. Поговорим про параметры поля a=:
Параметр
Синтаксис и описание
rtpmap
a=rtpmap:<тип> <название_кодировки>/<частота_дискретизации> [/<параметры_кодирования>].
Данный параметр подсказывает имена кодеков, частоту и прочие параметры кодирования для данных, обозначенных в параметре m=. Например, у нас a=rtpmap:0 PCMU/8000, означает использование G.711 с импульсно - кодовой модуляцией по U - закону с частотой дискретизации 8000 Гц.
sendrecv
a=sendrecv
Данный параметр указывает на то, что мы собираемся отправлять и получать медиа - данные. Например, возможно опция отправки (sendonly), только получение (recvonly) и отключения медиа (inactive);
ptime
a=ptime:<длительность_пакета>
Продолжительность RTP - пакет (в миллисекундах). Условно говоря, какой длительности фрагмент голоса переносит один RTP - пакет;
fmtp
a=fmtp:<формат> <специальные_параметры>
Параметр описывает дополнительные параметры сессии, например, такие как режим подавления тишины (VAD) и прочие;
OpenSSH позволяет выполнять удаленное подключение к серверу, производить манипуляции с файлами и управлять системой. Сегодня хотим рассказать про лучшие методы, которые позволят увеличить безопасность системы на базе OpenSSH.
Конфигурационные файлы
/etc/ssh/sshd_config - файл конфигурации сервера OpenSSH;
/etc/ssh/ssh_config - файл конфигурации клиентской части OpenSSH;
~/.ssh/ - директория, в которой хранятся пользовательские SSH настройки;
~/.ssh/authorized_keys или ~/.ssh/authorized_keys - список ключей (RSA или DSA), которые используются для подключения к пользовательским аккаунтам;
/etc/nologin - если данный файл существует в системе, то sshd запретит подключаться всем пользователям кроме root в систему;
/etc/hosts.allow и /etc/hosts.deny - система запрета (часть безопасности). Работает по аналогии с ACL;
SSH порт по умолчанию - 22
Не нужен - выключай
Если вашему серверу не требуется удаленное подключение по SSH, то обязательно отключите его. В таких системах как CentOS/RHEL делается это так:
chkconfig sshd off
yum erase openssh-server
Используйте SSH второй версии
Протокол SSH первой версии имеет проблемы с безопасностью, которые закрыты во второй версии. Поэтому, используйте вторую версию. Убедитесь, что в файле /etc/ssh/sshd_config указана опция Protocol 2.
Ограничивайте SSH доступ
По умолчанию, все системные пользователи имеют возможность подключаться к системе по SSH. Рекомендуем ограничить SSH доступ в целях безопасности. Например, разрешить SSH для пользователей root, merion и networks:
AllowUsers root merion networks
С другой стороны, вы можете разрешить доступ всем пользователям, кроме указанных:
DenyUsers root merion networks
Время неактивности
Важно указывать время, в течение которого, неактивная сессия будет терминирована (завершена). Это можно сделать следующими опциями:
ClientAliveInterval 300
ClientAliveCountMax 0
В данной настройке мы указали время бездействия равным 300 секунд (5 минут).
Про файлы .rhosts
Дело в том, что данный файл содержит список хостов и пользователей. Если в данном файле содержится комбинация хоста и юзера, то данный пользователь сможет подключиться к системе по SSH без запроса пароля. Рекомендуем отключить эту «замечательную» фичу:
IgnoreRhosts yes
Никакой аутентификации на базе хоста!
Так называемая Host-Based Authentication позволяет пользователю с определенного хоста подключаться к серверу. Отключаем:
HostbasedAuthentication no
Прямое подключение через root
Не нужно открывать root. Максимум, советуем использовать прямое root подключение на время проведения работ. Затем отключать. Лучше давать su (sudo) доступ для некоторых категория пользователей. Закрыть можно вот так:
PermitRootLogin no
Сделайте баннер
Для каждого подключающегося сделайте баннер, в котором можно угрожать злоумышленникам, которые пытаются совершить несанкционированный доступ. За настройку баннера отвечает параметр Banner.
22 порт только изнутри!
Сделайте доступ к 22 порту системы только через цепочку фаервол правил. Лучше всего, оставить доступ только изнутри LAN. Например, в Iptables можно дать доступ для 192.168.11.0/24:
-A RH-Firewall-1-INPUT -s 192.168.11.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT
Где слушать
По умолчанию SSH слушает подключения на всех доступных интерфейсах. Мы рекомендуем сменить порт по умолчанию и указать IP – адрес, на котором необходимо ожидать подключения. Например, мы укажем порт 962 и IP – адрес 192.168.11.24
Port 962
ListenAddress 192.168.11.24
Криптостойкие пароли
Используйте устойчивые к защите пароли. В сети множество инструментов, которые сгенерируют криптостойкий пароль онлайн, бесплатно и без смс :)
Запретить пустые пароли
Бывают пользователи без паролей. Их доступ к SSH так же необходимо запретить с помощью опции:
Port 962
PermitEmptyPasswords no
Анализируйте логи
Установите логирование событий в режим INFO или DEBUG – это позволит иметь расширенный контроль над системой:
LogLevel INFO
В данной статье расскажем о модуле состояния присутствия (или доступности) Presence State Module, который позволяет контролировать какие состояния доступны пользователям в определенных приложениях. Состояние пользователя, в свою очередь, могут влиять на обработку звонков. Например, пользователь может выбрать состояние “Не беспокоить” (Do Not Disturb/ DND), и отправить входящий звонок сразу на голосовую почту.
Доступные состояния пользователь затем может выбирать в User Control Panel (UCP) в разделе Presence.
Настройка статусов присутствия
Рассмотрим как настраивается модуль состояния присутствия на примере FreePBX 13. Для того, чтобы попасть в модуль, из главной страницы необходимо перейти по следующему пути Admin -> Presence State. Если никаких других состояний не создавалось, то после перехода отразятся состояния, которые заданы в системе по умолчанию
Чтобы добавить новое состояние, необходимо нажать Add State
Далее нужно выбрать желаемый тип нового состояния, доступны следующие несколько типов:
Available, Chat, Away, DND, Extended Away, и Unavailable. Рассмотрим каждый:
Available - Пользователь на месте и готов принимать и обрабатывать звонки
Chat - Пользователь на месте, но предпочитает вести общение по средствам чата
Away - Пользователь отошел с рабочего места на короткий промежуток времени, например - на обед, перерыв или совещание
DND/ Do Not Disturb – Пользователь занят и не готов отвечать на звонки и чат
Extended Away - Пользователя нет на месте длительный период времени, например – отпуск, больничный или командировка
Unavailable - Пользователь может отвечать на звонки, но недоступен по чату
Далее необходимо задать сообщение, которое бы дополняло статус доступности пользователя. На примере ниже выбран статус Extended Away с сообщением “Vacation till 01/06/16”, значит, пользователь ушел в отпуск и до первого июня его не будет на рабочем месте.
Чтобы закончить создание нового состояния, необходимо нажать Submit. Готово, новое состояние отразится в меню.
Права на изменение статусов
Теперь необходимо дать пользователю возможность изменять свое состояние присутствия. Для этого с главной страницы переходим по следующему пути Admin -> User Management и выбираем из списка пользователя, которому нужно дать разрешение.
Далее открываем вкладки UCP - > Presence State и напротив опции Enable Presence выбираем Yes.
Готово, теперь этот пользователь может менять свой статус присутствия/доступности в User Control Panel