21 Aug
2007
21 Aug
'07
12:50 p.m.
Hoola!
En algún hilo se ha comentado el tema de qué mensajes deberían ir
autenticados o no, pero como no era el tema central, he decidido abrir
este otro hilo para comentar mi pregunta/cosa:
Según he leido por aqui (creo que lo comentó Iñaki), los mensajes que
tienen que autenticarse con el proxy_authorize y tal son:
-INVITE
-REGISTER
-MESSAGE
-SUBSCRIBE
-PUBLISH
-OPTIONS
Vale, si esta es la lista, entonces yo ahora mismo tengo un
problemilla de seguridad, así que quería verificar una cosa:
Los INVITE se suelen tratar en u route aparte, así como los REGISTER.
Aunque todavía no me he metido mucho con ello, PUBLISH y SUBSCRIBE
también irían aparte, porque están relacionados con la presencia.
Entonces me quedan MESSAGE y OPTIONS. Actualmente he estado probando
los mensajes sin autenticación y por supuesto iban OK. Ahora he
añadido este bloque para manejarlos:
# -----------------------------------------------------------------
# MESSAGE handler
# -----------------------------------------------------------------
route[8]
{
xlog("L_INFO","$Cbx-- Mandando un MESSAGE --$Cxx\n");
## Es necesario autenticarse
if (!proxy_authorize("","subscriber")) {
xlog("L_INFO","$CbxSe necesita autenticacion para el
MESSAGE$Cxx\n");
proxy_challenge("","0");
exit;
}
## Tienen que coincidir el nombre de usuario con el de la cabecera FROM
else if (!check_from()) {
xlog("L_INFO","$Crx*** check_from() = NO!! ***$Cxx\n");
sl_send_reply("403", "Use From=ID");
exit;
};
xlog("L_INFO","$Cbx*** MESSAGE correcto ***$Cxx\n");
consume_credentials();
# Puede que venga a nosotros pero tengamos definido un alias a fuera.
lookup("aliases") nos da la nueva URI que puede sea !=myself.
lookup("aliases");
if (!is_uri_host_local()) {
xlog("L_INFO","$CrxNot my URI after the alias lookup$Cxx\n");
## A las salientes
route(4);
exit;
};
## Miramos si existe el destino en nuestra tabla "location".
if (!lookup("location")) {
xlog("L_INFO","$Crx404 User Not Found$Cxx\n");
sl_send_reply("404", "Not Found");
exit;
};
## Si hemos llegado hasta aquí enrutamos el mensaje al destino por la
ruta por defecto.
route(1);
exit;
}
La pregunta es: podría utilizar este mismo bloque para los OPTIONS?
Entonces, llegados a este punto (sorry por la chapa) nos quedan por
tratar CANCEL, BYE, INFO, REFER, UPDATE, y PRACK?
Bien, entonces, asumiendo que tenemos esto en nuestro route principal:
if (!is_uri_host_local()) {
if (is_from_local()) {
route(4);
}
else {
sl_send_reply("403", "Forbidden");
};
exit;
}
Si un cuanlquiera nos manda algo pasaremos de ello. Entonces, para los
CANCEL y los BYE podemos hacer t_relay tranquilamente.
Los INFO solo ocurririan en loose_route no?Al igual que los UPDATE?
Ya solo nos quedan REFER, UPDATE y ese PRACK que no se yo... :P
Segun leo en el RFC3515, "REFER request MAY be placed outside the
scope of a dialog" entonces, deberia tratarlo fuera del loose_route?
Iria autenticado?
PD: Sorry por la "pesadilla mail", si aun os quedan fuerzas tras haber
llegado hasta aqui: que hacemos con el PRACK? (aunque no lo he visto
nunca...)
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
21 Aug
21 Aug
2:47 p.m.
New subject: [OpenSER-Users-ES] Re: [Users-es] Mensajes que requieren autenticación
Me respondo a mi mismo, con algunas conclusiones... espero me
corrijáis si me equivoco :P
El 21/08/07, Saúl Ibarra <saghul(a)gmail.com> escribió:
Hoola!
En algún hilo se ha comentado el tema de qué mensajes deberían ir
autenticados o no, pero como no era el tema central, he decidido abrir
este otro hilo para comentar mi pregunta/cosa:
Según he leido por aqui (creo que lo comentó Iñaki), los mensajes que
tienen que autenticarse con el proxy_authorize y tal son:
-INVITE
-REGISTER
-MESSAGE
-SUBSCRIBE
-PUBLISH
-OPTIONS
Vale, si esta es la lista, entonces yo ahora mismo tengo un
problemilla de seguridad, así que quería verificar una cosa:
Los INVITE se suelen tratar en u route aparte, así como los REGISTER.
Aunque todavía no me he metido mucho con ello, PUBLISH y SUBSCRIBE
también irían aparte, porque están relacionados con la presencia.
Todo esto OK.
Entonces me quedan MESSAGE y OPTIONS. Actualmente he
estado probando
los mensajes sin autenticación y por supuesto iban OK. Ahora he
añadido este bloque para manejarlos:
# -----------------------------------------------------------------
# MESSAGE handler
# -----------------------------------------------------------------
route[8]
{
xlog("L_INFO","$Cbx-- Mandando un MESSAGE --$Cxx\n");
## Es necesario autenticarse
if (!proxy_authorize("","subscriber")) {
xlog("L_INFO","$CbxSe necesita autenticacion para el
MESSAGE$Cxx\n");
proxy_challenge("","0");
exit;
}
## Tienen que coincidir el nombre de usuario con el de la cabecera FROM
else if (!check_from()) {
xlog("L_INFO","$Crx*** check_from() = NO!!
***$Cxx\n");
sl_send_reply("403", "Use From=ID");
exit;
};
xlog("L_INFO","$Cbx*** MESSAGE correcto ***$Cxx\n");
consume_credentials();
# Puede que venga a nosotros pero tengamos definido un alias a fuera.
lookup("aliases") nos da la nueva URI que puede sea !=myself.
lookup("aliases");
if (!is_uri_host_local()) {
xlog("L_INFO","$CrxNot my URI after the alias
lookup$Cxx\n");
## A las salientes
route(4);
exit;
};
## Miramos si existe el destino en nuestra tabla "location".
if (!lookup("location")) {
xlog("L_INFO","$Crx404 User Not Found$Cxx\n");
sl_send_reply("404", "Not Found");
exit;
};
## Si hemos llegado hasta aquí enrutamos el mensaje al destino por la
ruta por defecto.
route(1);
exit;
}
La pregunta es: podría utilizar este mismo bloque para los OPTIONS?
No se como generar un OPTIONS, xD pero por lo que he leido ese bloque
deberia servirme para los MESSAGE, OPTIONS y REFER, ya que pide el
auth y tal.
Entonces, llegados a este punto (sorry por la chapa)
nos quedan por
tratar CANCEL, BYE, INFO, REFER, UPDATE, y PRACK?
Bien, entonces, asumiendo que tenemos esto en nuestro route principal:
if (!is_uri_host_local()) {
if (is_from_local()) {
route(4);
}
else {
sl_send_reply("403", "Forbidden");
};
exit;
}
Si un cuanlquiera nos manda algo pasaremos de ello. Entonces, para los
CANCEL y los BYE podemos hacer t_relay tranquilamente.
No, los BYE solo deberian ocurrir dentro del dialogo, manejados por loose_route.
Los INFO solo ocurririan en loose_route no?Al igual
que los UPDATE?
Los INFO también los manejamos con loose_route.
Ya solo nos quedan REFER, UPDATE y ese PRACK que no se
yo... :P
Segun leo en el RFC3515, "REFER request MAY be placed outside the
scope of a dialog" entonces, deberia tratarlo fuera del loose_route?
Iria autenticado?
Si, deberia.
El tema es que en todos los ejemplos que he visto, en la seccion en la
que se van mandando a distintos routes dependiendo del metodo, como
asi por ejemplo:
## Los REGISTER los tratamos a parte (en la ruta 2)
else if (method=="REGISTER") {
route(2);
exit;
}
## Los INVITEs a la ruta 3 (autenticacion,...)
else if (method=="INVITE") {
route(3);
exit;
}
Luego al final, si no ha entrado por ninguno de los if se comprueba el
alias, el location, y se hace relay. Esa parte no me gusta, y quiero
tratar cada mensaje explicitamente, por lo tanto, que pasaria si no
dejo los UPDATE y PRACK? Parecen "opcionales"...
PD: Sorry por la "pesadilla mail", si aun os
quedan fuerzas tras haber
llegado hasta aqui: que hacemos con el PRACK? (aunque no lo he visto
nunca...)
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
22 Aug
22 Aug
11:03 a.m.
New subject: [OpenSER-Users-ES] Re: [Users-es] Mensajes que requieren autenticación
Bueno, finalmente lo he dejado como muestro a continuación. Trato
todos los tipos de mensajes en alguna ruta, y los que no interesan
pues error 405. Espero que esta sea la mejor manera...
## Mensajes con destino nuestro servidor (por ejemplo llamadas a
usuarios registrados aquí).
## Tenemos que tratar explicitamente el ACK
if (method=="ACK") {
xlog("L_INFO","$Cbx--- Procesando un ACK *not within a
dialog*$Cxx\n");
route(1);
exit;
}
## CANCEL messages can be safely processed with a simple call to
t_relay() because SER will automatically match the CANCEL message to
the original INVITE message (stateful).
## Para los CANCEL, con la ruta por defecto vale.
else if (method=="CANCEL") {
route(1);
exit;
}
## Los REGISTER los tratamos a parte (en la ruta 2)
else if (method=="REGISTER") {
route(2);
exit;
}
## Los INVITEs a la ruta 3 (autenticacion,...)
else if (method=="INVITE") {
route(3);
exit;
}
## Los MESSAGE, OPTIONS y REFER tienen que ir autenticados
else if (method=="MESSAGE" || method=="REFER" ||
method=="OPTIONS") {
route(8);
exit;
}
## Resto de casos?
else {
sl_send_reply("405", "Method Not Allowed");
xlog("L_INFO","\n\n$Cbc[$rm] -- 405 - Method Not Allowed$Cxx\n");
exit;
}
El 21/08/07, Saúl Ibarra <saghul(a)gmail.com> escribió:
Me respondo a mi mismo, con algunas conclusiones...
espero me
corrijáis si me equivoco :P
El 21/08/07, Saúl Ibarra <saghul(a)gmail.com> escribió:
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
Hoola!
En algún hilo se ha comentado el tema de qué mensajes deberían ir
autenticados o no, pero como no era el tema central, he decidido abrir
este otro hilo para comentar mi pregunta/cosa:
Según he leido por aqui (creo que lo comentó Iñaki), los mensajes que
tienen que autenticarse con el proxy_authorize y tal son:
-INVITE
-REGISTER
-MESSAGE
-SUBSCRIBE
-PUBLISH
-OPTIONS
Vale, si esta es la lista, entonces yo ahora mismo tengo un
problemilla de seguridad, así que quería verificar una cosa:
Los INVITE se suelen tratar en u route aparte, así como los REGISTER.
Aunque todavía no me he metido mucho con ello, PUBLISH y SUBSCRIBE
también irían aparte, porque están relacionados con la presencia.
Todo esto OK.
Entonces me quedan MESSAGE y OPTIONS. Actualmente
he estado probando
los mensajes sin autenticación y por supuesto iban OK. Ahora he
añadido este bloque para manejarlos:
# -----------------------------------------------------------------
# MESSAGE handler
# -----------------------------------------------------------------
route[8]
{
xlog("L_INFO","$Cbx-- Mandando un MESSAGE --$Cxx\n");
## Es necesario autenticarse
if (!proxy_authorize("","subscriber")) {
xlog("L_INFO","$CbxSe necesita autenticacion para el
MESSAGE$Cxx\n");
proxy_challenge("","0");
exit;
}
## Tienen que coincidir el nombre de usuario con el de la cabecera FROM
else if (!check_from()) {
xlog("L_INFO","$Crx*** check_from() = NO!!
***$Cxx\n");
sl_send_reply("403", "Use From=ID");
exit;
};
xlog("L_INFO","$Cbx*** MESSAGE correcto ***$Cxx\n");
consume_credentials();
# Puede que venga a nosotros pero tengamos definido un alias a fuera.
lookup("aliases") nos da la nueva URI que puede sea !=myself.
lookup("aliases");
if (!is_uri_host_local()) {
xlog("L_INFO","$CrxNot my URI after the alias
lookup$Cxx\n");
## A las salientes
route(4);
exit;
};
## Miramos si existe el destino en nuestra tabla "location".
if (!lookup("location")) {
xlog("L_INFO","$Crx404 User Not Found$Cxx\n");
sl_send_reply("404", "Not Found");
exit;
};
## Si hemos llegado hasta aquí enrutamos el mensaje al destino por la
ruta por defecto.
route(1);
exit;
}
La pregunta es: podría utilizar este mismo bloque para los OPTIONS?
No se como generar un OPTIONS, xD pero por lo que he leido ese bloque
deberia servirme para los MESSAGE, OPTIONS y REFER, ya que pide el
auth y tal.
Entonces, llegados a este punto (sorry por la
chapa) nos quedan por
tratar CANCEL, BYE, INFO, REFER, UPDATE, y PRACK?
Bien, entonces, asumiendo que tenemos esto en nuestro route principal:
if (!is_uri_host_local()) {
if (is_from_local()) {
route(4);
}
else {
sl_send_reply("403", "Forbidden");
};
exit;
}
Si un cuanlquiera nos manda algo pasaremos de ello. Entonces, para los
CANCEL y los BYE podemos hacer t_relay tranquilamente.
No, los BYE solo deberian ocurrir dentro del dialogo, manejados por loose_route.
Los INFO solo ocurririan en loose_route no?Al
igual que los UPDATE?
Los INFO también los manejamos con loose_route.
Ya solo nos quedan REFER, UPDATE y ese PRACK que
no se yo... :P
Segun leo en el RFC3515, "REFER request MAY be placed outside the
scope of a dialog" entonces, deberia tratarlo fuera del loose_route?
Iria autenticado?
Si, deberia.
El tema es que en todos los ejemplos que he visto, en la seccion en la
que se van mandando a distintos routes dependiendo del metodo, como
asi por ejemplo:
## Los REGISTER los tratamos a parte (en la ruta 2)
else if (method=="REGISTER") {
route(2);
exit;
}
## Los INVITEs a la ruta 3 (autenticacion,...)
else if (method=="INVITE") {
route(3);
exit;
}
Luego al final, si no ha entrado por ninguno de los if se comprueba el
alias, el location, y se hace relay. Esa parte no me gusta, y quiero
tratar cada mensaje explicitamente, por lo tanto, que pasaria si no
dejo los UPDATE y PRACK? Parecen "opcionales"...
PD: Sorry por la "pesadilla mail", si
aun os quedan fuerzas tras haber
llegado hasta aqui: que hacemos con el PRACK? (aunque no lo he visto
nunca...)
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
23 Aug
23 Aug
1:46 a.m.
New subject: [OpenSER-Users-ES] Re: [Users-es] Mensajes que requieren autenticación
El 21/08/07, Saúl Ibarra <saghul(a)gmail.com> escribió:
El tema de permitir o no REFER fuera de diálogo te comento que yo al
menos nunca lo he visto, salvo en un caso para implementar Click2Dial:
http://tech-invite.com/Ti-sip-service-19.html
Pero de todas formas eso ya lo consulté en esta lista y Jesús me
respondió que no lo había visto usar nunca así, y por supuesto está la
gran duda de cómo demonios va a responder un teléfono a un REFER sin
estar en una llamada. Es decir, ¿se va a poner a sonar para que tú lo
cojas y entonces hace el INVITE? apuesto lo que sea a que la gran
mayoría de teléfonos SIP pasarían olímpicamente de esos mensajes.
Así que yo, de momento y por simplificar, sencillamente deniego REFER
fuera de diálogo y a correr. XD
Pero, el REFER dentro de diálogo **sí** debe exigir autenticación o
sería realmente un riego.
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Me respondo a mi mismo, con algunas conclusiones...
espero me
corrijáis si me equivoco :P
Te comento mis opiniones.
> Según he leido por aqui (creo que lo comentó
Iñaki), los mensajes que
> tienen que autenticarse con el proxy_authorize y tal son:
>
> -INVITE
> -REGISTER
> -MESSAGE
> -SUBSCRIBE
> -PUBLISH
> -OPTIONS
Ahí te faltaría autenticar los REFER, aunque matizo abajo si dentro o
fuera de diálogo.
> Entonces me quedan MESSAGE y OPTIONS. Actualmente
he estado probando
> los mensajes sin autenticación y por supuesto iban OK.
Excepto si pruebas con clientes como Minisip o Linphone que "pasan" de
autenticarse para enviar MESSAGE.
> La pregunta es: podría utilizar este mismo bloque
para los OPTIONS?
Sí, lo que pasa es que te quedará bastante código repetido. Yo lo que
hago es dividir en bastantes "routes" y, por ejemplo, el MESSAGE me
queda así:
else if(method=="MESSAGE") {
route(10); # Aliases.
if (!route(4)) { # Trusted.
if (is_from_local()) {
route(6); # Auth.
}
route(7); # Grupos.
route(5); # ACL.
}
route(11); # Location.
}
Y el OPTIONS me queda muy parecido, pero añado la condición de no
permitirlo si el dominio destino $rd es diferente del origen $fd (por
nada en concreto).
No se como generar un OPTIONS
Con el Twinkle en el menú "Call" - "Terminal capabilities". ;)
pero por lo que he leido ese bloque
deberia servirme para los MESSAGE, OPTIONS y REFER, ya que pide el
auth y tal.
Los INFO también los manejamos con loose_route.
Sí, los INFO son (no sé si también para otras cosas) para enviar DTMF
(aunque haya otros métodos). Tienen sentido sólo en medio de una
llamada.
Ya solo nos
quedan REFER, UPDATE y ese PRACK que no se yo... :P
Segun leo en el RFC3515, "REFER request MAY be placed outside the
scope of a dialog" entonces, deberia tratarlo fuera del loose_route?
Iria autenticado?
Si, deberia.
1:59 a.m.
New subject: [OpenSER-Users-ES] Re: [Users-es] Mensajes que requieren autenticación
El 21/08/07, Saúl Ibarra <saghul(a)gmail.com> escribió:
Luego al final, si no ha entrado por ninguno de los if
se comprueba el
alias, el location, y se hace relay. Esa parte no me gusta, y quiero
tratar cada mensaje explicitamente, por lo tanto, que pasaria si no
dejo los UPDATE y PRACK? Parecen "opcionales"...
Desconozco de momento para qué sirven el UPDATE y PRACK (tengo cierta
idea pero no la suficiente), pero algo me dice que son mensajes
"in-dialog" en cuyo caso recuerda que no hay ni que comprobar
"alias",
ni "location", sólo hacer relay (o pedir auth en caso del REFER).
Es decir, te digo algo que seguro ya sabes, pero por si acaso:
Los mensajes fuera de diálogo van a la dirección "bonita" del usuario en plan:
INVITE sip:500@dominio.org
MESSAGE sip:500@dominio.org
SUBSCRIBE sip:dominio.org
PUBLISH sip:500@dominio.org
OPTIONS sip:500@dominio.org
Pero los mensajes dentro de diálogo van directamente a la URI indicada
previamente en la cabecera "Contact":
ACK sip:500@82.84.173.243:5080
REFER sip:800@82.84.173.243:5080
BYE sip:800@82.84.173.243:5080
INVITE sip:800@82.84.173.243:5080 <-- re-INVITE (poner en espera)
INFO sip:800@82.84.173.243:5080 (envío de un DTMF)
NOTIFY sip:800@82.84.173.243:5080 (para notificar el resultado de
una transferencia solicitada previamente con un REFER)
Es decir, estos mensajes dentro de diálogo ya van directamente a la
dirección exacta del destino y no hace falta investigar si son alias o
si están en location.
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
10:12 a.m.
New subject: [OpenSER-Users-ES] Re: [Users-es] Mensajes que requieren autenticación
Muchas gracias por las matizaciones xD voy a ver si "limpio" un poco
el cfg y quito lo del REFER, pruebo el OPTIONS... Thnx!
El 23/08/07, Iñaki Baz Castillo <ibc(a)aliax.net> escribió:
El 21/08/07, Saúl Ibarra <saghul(a)gmail.com>
escribió:
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
Luego al final, si no ha entrado por ninguno de
los if se comprueba el
alias, el location, y se hace relay. Esa parte no me gusta, y quiero
tratar cada mensaje explicitamente, por lo tanto, que pasaria si no
dejo los UPDATE y PRACK? Parecen "opcionales"...
Desconozco de momento para qué sirven el UPDATE y PRACK (tengo cierta
idea pero no la suficiente), pero algo me dice que son mensajes
"in-dialog" en cuyo caso recuerda que no hay ni que comprobar
"alias",
ni "location", sólo hacer relay (o pedir auth en caso del REFER).
Es decir, te digo algo que seguro ya sabes, pero por si acaso:
Los mensajes fuera de diálogo van a la dirección "bonita" del usuario en plan:
INVITE sip:500@dominio.org
MESSAGE sip:500@dominio.org
SUBSCRIBE sip:dominio.org
PUBLISH sip:500@dominio.org
OPTIONS sip:500@dominio.org
Pero los mensajes dentro de diálogo van directamente a la URI indicada
previamente en la cabecera "Contact":
ACK sip:500@82.84.173.243:5080
REFER sip:800@82.84.173.243:5080
BYE sip:800@82.84.173.243:5080
INVITE sip:800@82.84.173.243:5080 <-- re-INVITE (poner en espera)
INFO sip:800@82.84.173.243:5080 (envío de un DTMF)
NOTIFY sip:800@82.84.173.243:5080 (para notificar el resultado de
una transferencia solicitada previamente con un REFER)
Es decir, estos mensajes dentro de diálogo ya van directamente a la
dirección exacta del destino y no hace falta investigar si son alias o
si están en location.
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
_______________________________________________
Users-es mailing list
Users-es(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users-es
11:42 a.m.
New subject: [OpenSER-Users-ES] Re: [Users-es] Mensajes que requieren autenticación
He estado "limpiando" un poco el código, metiendo el auth, el alias y
el location en distintos routes, y ahora me queda más "legible" xD
Lo que no me ha quedado muy claro es la utenticación del REFER. Yo
actualmente hago esto:
## Con el has_totag sabemos si son "in-dialog"
if ((method=="INVITE" || method=="REFER") && !has_totag())
{
sl_send_reply("403", "Forbidden");
xlog("L_INFO","$Crx ** INVITE o REFER sin TO tag ** $Cxx\n");
exit;
}
Así vale? O debería añadir a continuación algo como:
if (method=="REFER") {
route(22);
route(1);
}
Donde route 22 es:
# -----------------------------------------------------------------
# Auth check
# -----------------------------------------------------------------
route[22]
{
## Es necesario autenticarse
if (!proxy_authorize("","subscriber")) {
xlog("L_INFO","$CbxSe necesita autenticacion para $rm $Cxx\n");
proxy_challenge("","0");
exit;
}
## Tienen que coincidir el nombre de usuario con el de la cabecera FROM
else if (!check_from()) {
xlog("L_INFO","$Crx*** check_from() = NO!! ***$Cxx\n");
sl_send_reply("403", "Use From=ID");
exit;
}
xlog("L_INFO","$Cbx*** Autenticacion Correcta para $rm ***$Cxx\n");
consume_credentials();
}
??
El 23/08/07, Saúl Ibarra <saghul(a)gmail.com> escribió:
Muchas gracias por las matizaciones xD voy a ver si
"limpio" un poco
el cfg y quito lo del REFER, pruebo el OPTIONS... Thnx!
El 23/08/07, Iñaki Baz Castillo <ibc(a)aliax.net> escribió:
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
El 21/08/07, Saúl Ibarra <saghul(a)gmail.com>
escribió:
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
Luego al final, si no ha entrado por ninguno de
los if se comprueba el
alias, el location, y se hace relay. Esa parte no me gusta, y quiero
tratar cada mensaje explicitamente, por lo tanto, que pasaria si no
dejo los UPDATE y PRACK? Parecen "opcionales"...
Desconozco de momento para qué sirven el UPDATE y PRACK (tengo cierta
idea pero no la suficiente), pero algo me dice que son mensajes
"in-dialog" en cuyo caso recuerda que no hay ni que comprobar
"alias",
ni "location", sólo hacer relay (o pedir auth en caso del REFER).
Es decir, te digo algo que seguro ya sabes, pero por si acaso:
Los mensajes fuera de diálogo van a la dirección "bonita" del usuario en plan:
INVITE sip:500@dominio.org
MESSAGE sip:500@dominio.org
SUBSCRIBE sip:dominio.org
PUBLISH sip:500@dominio.org
OPTIONS sip:500@dominio.org
Pero los mensajes dentro de diálogo van directamente a la URI indicada
previamente en la cabecera "Contact":
ACK sip:500@82.84.173.243:5080
REFER sip:800@82.84.173.243:5080
BYE sip:800@82.84.173.243:5080
INVITE sip:800@82.84.173.243:5080 <-- re-INVITE (poner en espera)
INFO sip:800@82.84.173.243:5080 (envío de un DTMF)
NOTIFY sip:800@82.84.173.243:5080 (para notificar el resultado de
una transferencia solicitada previamente con un REFER)
Es decir, estos mensajes dentro de diálogo ya van directamente a la
dirección exacta del destino y no hace falta investigar si son alias o
si están en location.
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
_______________________________________________
Users-es mailing list
Users-es(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users-es
1:31 p.m.
New subject: [OpenSER-Users-ES] Re: [Users-es] Mensajes que requieren autenticación
El 23/08/07, Saúl Ibarra <saghul(a)gmail.com> escribió:
He estado "limpiando" un poco el código,
metiendo el auth, el alias y
el location en distintos routes, y ahora me queda más "legible" xD
Lo que no me ha quedado muy claro es la utenticación del REFER. Yo
actualmente hago esto:
## Con el has_totag sabemos si son "in-dialog"
Humm, creo que no exactamente. Para saber si es en dialog es la función:
if (loose_route())
http://4z.com/people/emin-gabrielyan/public/070412-SIP-record-route/
El tema del "has_totag" se debe a que, una vez dentro de un diálogo
establecido, los mensajes in-dialog deben necesariamente tener un
parámetro "tag" dentro del campo "To". Es una medida de seguridad
aunque reconozco que tengo pendiente comprobar cómo de seguro es esto,
es decir, si yo genero a propósito un mensaje nuevo con un "tag" en el
"To" y le añado la cabecera "Route" para que pase por
"loose_route"
(in-dialog) ¿significa eso que OpenSer me permite el paso de es
mensaje "trampa" que en realidad no pertenece a ningún diálogo
establecido? Aquí hay que recordar que OpenSer no recuerda el estado
de diálogos, sólo de transacciones.
if ((method=="INVITE" ||
method=="REFER") && !has_totag()) {
sl_send_reply("403", "Forbidden");
xlog("L_INFO","$Crx ** INVITE o REFER sin TO tag
** $Cxx\n");
exit;
}
Así vale? O debería añadir a continuación algo como:
if (method=="REFER") {
route(22);
route(1);
}
Donde route 22 es:
# -----------------------------------------------------------------
# Auth check
# -----------------------------------------------------------------
route[22]
{
## Es necesario autenticarse
if (!proxy_authorize("","subscriber")) {
xlog("L_INFO","$CbxSe necesita autenticacion para $rm
$Cxx\n");
proxy_challenge("","0");
exit;
}
## Tienen que coincidir el nombre de usuario con el de la cabecera FROM
else if (!check_from()) {
xlog("L_INFO","$Crx*** check_from() = NO!!
***$Cxx\n");
sl_send_reply("403", "Use From=ID");
exit;
}
xlog("L_INFO","$Cbx*** Autenticacion Correcta para $rm
***$Cxx\n");
consume_credentials();
}
??
Sí, en efecto, es necesario ese Auth para REFER. Piensa en el caso de
que llames desde un PAP2 (por ejemplo) a un número SIP
"ajeno"/exterior. Una vez en el diálogo, si no pides auth para el
REFER la otra parte podría enviarte un REFER para que tu teléfono haga
una llamada al número que sea, lo que podría ocasionar llamada vía
PSTN con el coste económino asociado (y es una llamada que ha hecho tu
PAP2).
Pongo el ejemplo del PAP2 porque, que o sepa, ningún deskphone pide
confirmación al usuario cuando recibe un REFER. En cambio, con Twinkle
al recibir un REFER te saca un pop-up preguntando al usuario si desea
aceptar el REFER a la URI que sea. Ah, y todo esto yo he leído en
algún RFC que es lo correcto por obvia seguridad, en cambio parece
como si la mayoría de dispositivos SIP delegasen en su proxy SIP la
seguridad del REFER.
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
1:38 p.m.
New subject: [OpenSER-Users-ES] Re: [Users-es] Mensajes que requieren autenticación
OK, entendido, pero lo del hastotag en realidad lo tengo asi:
if (loose_route()) {
xlog("L_INFO","*** Estamos en loose_route() ***\n");
## Con el has_totag sabemos si son "in-dialog"
if ((method=="INVITE" || method=="REFER") && !has_totag())
{
sl_send_reply("403", "Forbidden");
xlog("L_INFO","$Crx ** INVITE o REFER sin TO tag ** $Cxx\n");
exit;
}
if (method=="INVITE") {
## Es un re-INVITE
route(7);
}
route(1);
exit;
}
Ahora voy a añadir la comprobación para el auth del REFER...
Thnx Iñaki!!
El 23/08/07, Iñaki Baz Castillo <ibc(a)aliax.net> escribió:
El 23/08/07, Saúl Ibarra <saghul(a)gmail.com>
escribió:
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
He estado "limpiando" un poco el
código, metiendo el auth, el alias y
el location en distintos routes, y ahora me queda más "legible" xD
Lo que no me ha quedado muy claro es la utenticación del REFER. Yo
actualmente hago esto:
## Con el has_totag sabemos si son "in-dialog"
Humm, creo que no exactamente. Para saber si es en dialog es la función:
if (loose_route())
http://4z.com/people/emin-gabrielyan/public/070412-SIP-record-route/
El tema del "has_totag" se debe a que, una vez dentro de un diálogo
establecido, los mensajes in-dialog deben necesariamente tener un
parámetro "tag" dentro del campo "To". Es una medida de seguridad
aunque reconozco que tengo pendiente comprobar cómo de seguro es esto,
es decir, si yo genero a propósito un mensaje nuevo con un "tag" en el
"To" y le añado la cabecera "Route" para que pase por
"loose_route"
(in-dialog) ¿significa eso que OpenSer me permite el paso de es
mensaje "trampa" que en realidad no pertenece a ningún diálogo
establecido? Aquí hay que recordar que OpenSer no recuerda el estado
de diálogos, sólo de transacciones.
if ((method=="INVITE"
|| method=="REFER") && !has_totag()) {
sl_send_reply("403", "Forbidden");
xlog("L_INFO","$Crx ** INVITE o REFER sin TO tag
** $Cxx\n");
exit;
}
Así vale? O debería añadir a continuación algo como:
if (method=="REFER") {
route(22);
route(1);
}
Donde route 22 es:
# -----------------------------------------------------------------
# Auth check
# -----------------------------------------------------------------
route[22]
{
## Es necesario autenticarse
if (!proxy_authorize("","subscriber")) {
xlog("L_INFO","$CbxSe necesita autenticacion para $rm
$Cxx\n");
proxy_challenge("","0");
exit;
}
## Tienen que coincidir el nombre de usuario con el de la cabecera FROM
else if (!check_from()) {
xlog("L_INFO","$Crx*** check_from() = NO!!
***$Cxx\n");
sl_send_reply("403", "Use From=ID");
exit;
}
xlog("L_INFO","$Cbx*** Autenticacion Correcta para $rm
***$Cxx\n");
consume_credentials();
}
??
Sí, en efecto, es necesario ese Auth para REFER. Piensa en el caso de
que llames desde un PAP2 (por ejemplo) a un número SIP
"ajeno"/exterior. Una vez en el diálogo, si no pides auth para el
REFER la otra parte podría enviarte un REFER para que tu teléfono haga
una llamada al número que sea, lo que podría ocasionar llamada vía
PSTN con el coste económino asociado (y es una llamada que ha hecho tu
PAP2).
Pongo el ejemplo del PAP2 porque, que o sepa, ningún deskphone pide
confirmación al usuario cuando recibe un REFER. En cambio, con Twinkle
al recibir un REFER te saca un pop-up preguntando al usuario si desea
aceptar el REFER a la URI que sea. Ah, y todo esto yo he leído en
algún RFC que es lo correcto por obvia seguridad, en cambio parece
como si la mayoría de dispositivos SIP delegasen en su proxy SIP la
seguridad del REFER.
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
_______________________________________________
Users-es mailing list
Users-es(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users-es
12 Mar
12 Mar
5:55 p.m.
New subject: [OpenSER-Users-ES] [Users-es] Mensajes que requieren autenticación
Retomando este tema , me surgen un par de dudas con la implementación
de la autenticación de los invites.
Ya he conseguido probar que no haya un número superior de AOR,
utilizando 2 máquinas virtuales.
Ahora mis dudas van en lo siguiente :
1º Se tratar que no me pueda llamar yo mismo y según lo que pienso yo
habría que tratarlo dentro del INVITE, si tener en cuenta la
autenticación.
2º Tras comprobar que no me llamo a mi mismo tengo que comprobar que
esta autenticado
Con esto debería valer
proxy_authorize verifica las credenciales enviadas
if (!proxy_authorize("", "subscriber)) {
xlog("Hay que autenticarse para $rm");
proxy_challenge("", "0");
xlog("El usuario esta autenticado");
exit;
}
o me falta algo
Lo que no entiendo en el method REGISTER del openser.cfg por que
realiza lo siguiente
if(!check_to())
{
}
if(!save(location))
{
}
un saludo y gracias
--
=====================================================
Legolas_Bilbao[ID2006][GKR]
Dios creo un equipo Perfecto a los demas los lleno de extranjeros
http://www.forosindicedonkey.com
http://usuarios.lycos.es/ligaforo/
=====================================================
---------- Forwarded message ----------
From: Saúl Ibarra <saghul(a)gmail.com>
Date: 23-ago-2007 11:38
Subject: Re: [OpenSER-Users-ES] Re: [Users-es] Mensajes que requieren
autenticación
To: Lista de usuarios de OpenSER <users-es(a)openser.org>
OK, entendido, pero lo del hastotag en realidad lo tengo asi:
if (loose_route()) {
xlog("L_INFO","*** Estamos en loose_route() ***\n");
## Con el has_totag sabemos si son "in-dialog"
if ((method=="INVITE" || method=="REFER") &&
!has_totag()) {
sl_send_reply("403", "Forbidden");
xlog("L_INFO","$Crx ** INVITE o REFER sin TO
tag ** $Cxx\n");
exit;
}
if (method=="INVITE") {
## Es un re-INVITE
route(7);
}
route(1);
exit;
}
Ahora voy a añadir la comprobación para el auth del REFER...
Thnx Iñaki!!
El 23/08/07, Iñaki Baz Castillo <ibc(a)aliax.net> escribió:
El 23/08/07, Saúl Ibarra <saghul(a)gmail.com>
escribió:
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
_______________________________________________
Users-es mailing list
Users-es(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users-es
--
=====================================================
Legolas_Bilbao[ID2006][GKR]
Dios creo un equipo Perfecto a los demas los lleno de extranjeros
http://www.forosindicedonkey.com
http://usuarios.lycos.es/ligaforo/
=====================================================
He estado "limpiando" un poco el
código, metiendo el auth, el alias y
el location en distintos routes, y ahora me queda más "legible" xD
Lo que no me ha quedado muy claro es la utenticación del REFER. Yo
actualmente hago esto:
## Con el has_totag sabemos si son "in-dialog"
Humm, creo que no exactamente. Para saber si es en dialog es la función:
if (loose_route())
http://4z.com/people/emin-gabrielyan/public/070412-SIP-record-route/
El tema del "has_totag" se debe a que, una vez dentro de un diálogo
establecido, los mensajes in-dialog deben necesariamente tener un
parámetro "tag" dentro del campo "To". Es una medida de seguridad
aunque reconozco que tengo pendiente comprobar cómo de seguro es esto,
es decir, si yo genero a propósito un mensaje nuevo con un "tag" en el
"To" y le añado la cabecera "Route" para que pase por
"loose_route"
(in-dialog) ¿significa eso que OpenSer me permite el paso de es
mensaje "trampa" que en realidad no pertenece a ningún diálogo
establecido? Aquí hay que recordar que OpenSer no recuerda el estado
de diálogos, sólo de transacciones.
if ((method=="INVITE"
|| method=="REFER") && !has_totag()) {
sl_send_reply("403", "Forbidden");
xlog("L_INFO","$Crx ** INVITE o REFER sin TO tag
** $Cxx\n");
exit;
}
Así vale? O debería añadir a continuación algo como:
if (method=="REFER") {
route(22);
route(1);
}
Donde route 22 es:
# -----------------------------------------------------------------
# Auth check
# -----------------------------------------------------------------
route[22]
{
## Es necesario autenticarse
if (!proxy_authorize("","subscriber")) {
xlog("L_INFO","$CbxSe necesita autenticacion para $rm
$Cxx\n");
proxy_challenge("","0");
exit;
}
## Tienen que coincidir el nombre de usuario con el de la cabecera FROM
else if (!check_from()) {
xlog("L_INFO","$Crx*** check_from() = NO!!
***$Cxx\n");
sl_send_reply("403", "Use From=ID");
exit;
}
xlog("L_INFO","$Cbx*** Autenticacion Correcta para $rm
***$Cxx\n");
consume_credentials();
}
??
Sí, en efecto, es necesario ese Auth para REFER. Piensa en el caso de
que llames desde un PAP2 (por ejemplo) a un número SIP
"ajeno"/exterior. Una vez en el diálogo, si no pides auth para el
REFER la otra parte podría enviarte un REFER para que tu teléfono haga
una llamada al número que sea, lo que podría ocasionar llamada vía
PSTN con el coste económino asociado (y es una llamada que ha hecho tu
PAP2).
Pongo el ejemplo del PAP2 porque, que o sepa, ningún deskphone pide
confirmación al usuario cuando recibe un REFER. En cambio, con Twinkle
al recibir un REFER te saca un pop-up preguntando al usuario si desea
aceptar el REFER a la URI que sea. Ah, y todo esto yo he leído en
algún RFC que es lo correcto por obvia seguridad, en cambio parece
como si la mayoría de dispositivos SIP delegasen en su proxy SIP la
seguridad del REFER.
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
_______________________________________________
Users-es mailing list
Users-es(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users-es
6:09 p.m.
New subject: [OpenSER-Users-ES] [Users-es] Mensajes que requieren autenticación
El Wednesday 12 March 2008 16:55:52 Javier Allende Astigarraga escribió:
Lo que no entiendo en el method REGISTER del
openser.cfg por que
realiza lo siguiente
if(!check_to())
{
}
if(!save(location))
{
}
¿Has leído primero la documentación de esas funciones del módulo "uri_db"
y "registrar" respectivamente?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
6:25 p.m.
New subject: [OpenSER-Users-ES] [Users-es] Mensajes que requieren autenticación
Gracias por la información, había visto el de REGISTRAR pero no URI_DB
El 12/03/08, Iñaki Baz Castillo <ibc(a)in.ilimit.es> escribió:
El Wednesday 12 March 2008 16:55:52 Javier Allende
Astigarraga escribió:
--
=====================================================
Legolas_Bilbao[ID2006][GKR]
Dios creo un equipo Perfecto a los demas los lleno de extranjeros
http://www.forosindicedonkey.com
http://usuarios.lycos.es/ligaforo/
=====================================================
Lo que no entiendo en el method REGISTER del
openser.cfg por que
realiza lo siguiente
if(!check_to())
{
}
if(!save(location))
{
}
¿Has leído primero la documentación de esas funciones del módulo "uri_db"
y "registrar" respectivamente?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users-es mailing list
Users-es(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
6128
days inactive
6332
days old
sr-users-es@lists.kamailio.org
11 comments
4 participants
participants (4)
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Javier Allende Astigarraga -
Saúl Ibarra