Freeswitch: Аутентификация по ip-адресу с использованием ACL

http://pro-voip.com.ua freeswitchДанный пост посвящен вопросам аутентификации пользователей c использованием acl при регистрации и совершении исходящих вызовов.

Хочу обратить внимание на 3 параметра в sip-профиле

<param name=»auth-calls» value=»true»/>
<param name=»apply-register-acl» value=»customers»/>
<param name=»apply-inbound-acl» value=»customers»/>

apply-register-acl — разрешать регистрацию пользователям, которые прошли проверку acl customers
apply-inbound-acl — разрешать совершать вызовы пользователям, которые прошли проверку acl customers
auth-calls — вкл/выкл аутентифицикацию c использованием acl

если auth-calls=true — apply-register-acl и apply-inbound-acl проверяются
если auth-calls=false — apply-register-acl и apply-inbound-acl игнорируются

Далее разные варианты настройки данных параметров и действия FS и клиента при разных комбинациях и исходах проверки acl

 

На что влияет auth-calls без apply-register-acl и apply-inbound-acl

auth-calls=true/false
apply-register-acl — не указан
apply-inbound-acl — не указан

Здесь аутенфицикация по логину-паролю действует! auth-calls на это никак не влияет.

Процесс регистрации пользователя (Client <-> FS):

REGISTER ->
<- SIP/2.0 401 Unauthorized
REGISTER ->
<- SIP/2.0 200 OK

… как и на входящие инвайты

Процесс совершения исходящего вызова (Client <-> FS):

INVITE ->
<- SIP/2.0 100 Trying
<- SIP/2.0 407 Proxy Authentication Required
ACK ->
INVITE ->
Proxy-Authorization: Digest username=»11″,realm=»10.10.10.10″,nonce=»8898………
<- SIP/2.0 100 Trying

 

На что влияет apply-register-acl

auth-calls=true
apply-register-acl — указан в sip-профиле
apply-inbound-acl — не указан

 

acl: allow

Если ip-пользователя проходит проверку acl (allow):

REGISTER ->
<- SIP/2.0 200 OK

логин-пароль не проверяются
пользователь попадает в тот домен, который укажет сам при подключении, и в соответствующий контекст.
Если у нас на профиле несколько доменов, пользователь при желании может попасть во все, не зная ни логинов, ни паролей!

acl: deny

Если ip-пользователя не проходит acl (deny):

REGISTER ->
<- SIP/2.0 403 Forbidden

в регистрации отказано

fs_cli

 

На что влияет apply-inbound-acl

auth-calls=true/false
apply-register-acl = не указан
apply-inbound-acl — указан в sip-профиле

 

apply-inbound-acl на регистрацию никак не влияет, пользователь проходит проверку логин-пароль, как положено:

REGISTER ->
<- SIP/2.0 401 Unauthorized
REGISTER ->
<- SIP/2.0 200 OK

 

А вот здесь с исходящими вызовами интересная история:

acl: allow

Если при совершении исходящего вызова ip пользователя проходит apply-inbound-acl(allow):
пользователь попадает в контекст public (указаный в sip-профиле)

INVITE ->
<- SIP/2.0 100 Trying
<- SIP/2.0 480 Temporarily Unavailable

acl: deny

Если при совершении исходящего вызова ip пользователя не проходит apply-inbound-acl (deny):
попадает в контекст company1 (указаный в домене)

INVITE ->
<- SIP/2.0 100 Trying
<- IP/2.0 407 Proxy Authentication Required
ACK ->

INVITE->
Proxy-Authorization: Digest username=»11″,realm=»10.10.10.10.»,nonce=»c52788bc………..
<- SIP/2.0 100 Trying

 

Что же за беда с этими контекстами? Пользователь проверку то прошел. Тут вопрос в «месте проведения» этой самой проверки. Поскольку проверка на айпи прошла успешно в sip-профиле! , то к пользователю применились все параметры sip-профиля! , а не домена, к которому подключается клиент.

Когда пользователь не прошел проверку по ip-адресу, FS запросил digest-аутентификацию, которая перекинула его в его домен и в его нужный контекст.

 

Выводы

Будьте аккуратны в использовании аутентификации по acl, особенно если у вас мультидоменная система. Если все же нуждаетесь в apply-register-acl и apply-inbound-acl, то лучше их ставить как можно ближе к клиенту (например, в настройке домена).

И еще… acl в FS не призван защищать, пользуйтесь для защиты фаерволом.