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...)
Me respondo a mi mismo, con algunas conclusiones... espero me corrijáis si me equivoco :P
El 21/08/07, Saúl Ibarra saghul@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 laruta 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."
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@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@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 laruta 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."
-- Saúl -- "Some people say why, other just say, why not."
El 21/08/07, Saúl Ibarra saghul@gmail.com escribió:
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.
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.
El 21/08/07, Saúl Ibarra saghul@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.
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@aliax.net escribió:
El 21/08/07, Saúl Ibarra saghul@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@aliax.net
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
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@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@aliax.net escribió:
El 21/08/07, Saúl Ibarra saghul@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@aliax.net
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
-- Saúl -- "Some people say why, other just say, why not."
El 23/08/07, Saúl Ibarra saghul@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.
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@aliax.net escribió:
El 23/08/07, Saúl Ibarra saghul@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@aliax.net
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
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
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?
Gracias por la información, había visto el de REGISTRAR pero no URI_DB
El 12/03/08, Iñaki Baz Castillo ibc@in.ilimit.es escribió:
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@in.ilimit.es
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Javier Allende Astigarraga -
Saúl Ibarra