Hola, estoy terriblemente preocupado:
Estaba yo feliz con mi supuesta seguridad entre distintos dominios alojados en mi OpenSer cuando he caído en la cuenta de que dicha seguridad es muy fácilmente rebasable sin más que llamar al "Contact" final de cualquier usuario de cualquiera de estos dominios.
Es decir, supongamos dos dominios locales: dom_A y dom_B.
- Si un usuario_A@dom_A llama al AOR sip:usuario_B@dom_B entonces mi OpenSer aplica las reglas entre-dominios para ver quién puede llamar a quién y tal. Ok.
- Pero si por alguna llamada anterior se conoce el "Contact" final del usuario_B@dom_B (ej: sip:usuario_B@80.80.80.80:5061) entonces el usuario_A@dom_A puede llamar **directamente** a usuario_B@dom_B sin pasar por la política de seguridad de mi OpenSer sólo con tener predefinido su OpenSer como Outbound proxy y llamar directamente a sip:usuario_B@80.80.80.80:5061
Entonces la llamada es Outbound y se ruta directamente (t_relay). Además la llamada llega al destino desde su propio proxy por lo que no serviría ni una supuesta política de seguridad de firewall (impedir entrantes SIP desde IP's distintas a mi proxy).
Por supuesto que sólo permito outbound para dominios locales, pero el problema está en la seguridad entre ellos.
¿Y ahora qué hago? Sólo se me ocurre:
- Drástico: Eliminar la posibilidad de outbound proxy en mi OpenSer, así al menos doy pie a soluciones de firewall o NAT (la IP origen no sería el proxy así que NAT no lo deja pasar).
- Separar el outbound proxy a otro OpenSer en otra IP (para conseguir lo mismo que antes sin eliminar las llamadas Outbound).
En fin, me va a dar algo, ¿alguna otra alternativa más limpia y segura? ¿es realmente un proxy SIP que gestiona dominios separados? ¿o hay que poner necesariamente un B2BUA delante de cada entorno SIP?
Gracias por cualquier sugerencia.
El Martes, 23 de Octubre de 2007, Iñaki Baz Castillo escribió:
En fin, me va a dar algo, ¿alguna otra alternativa más limpia y segura? ¿es realmente un proxy SIP que gestiona dominios separados? ¿o hay que poner necesariamente un B2BUA delante de cada entorno SIP?
Quería decir: ¿puede realmente ser seguro un simple proxy SIP delante de los usuarios de sus dominios independientes? ¿o hay que poner necesariamente un B2BUA delante de cada entorno SIP para garantizar cierta seguridad?
Puede aún ser "peor": si el UA no tiene configurado outbound proxy y utiliza directamente IPs, la llamada se cursará sin que tu proxy vea un sólo paquete...así es cómo funciona SIP. Para evitarlo debes proporcionar a tus usuarios una razón para que pasen por tu proxy, generalmente solventando problemas de NAT, servicios extras,...
El "tema" aquí es que los usuarios raramente saben qué IP tienen los dispositivos y aunque lo sepan es más cómodo no indicar nombre de dominio. Aparte que si tus usuarios utilizan conversores PAP raramente podrán especificar dominio en el Req-URI...
Qué problema hay que los usuarios se llamen entre sí????
Samuel
2007/10/23, Iñaki Baz Castillo ibc@aliax.net:
Hola, estoy terriblemente preocupado:
Estaba yo feliz con mi supuesta seguridad entre distintos dominios alojados en mi OpenSer cuando he caído en la cuenta de que dicha seguridad es muy fácilmente rebasable sin más que llamar al "Contact" final de cualquier usuario de cualquiera de estos dominios.
Es decir, supongamos dos dominios locales: dom_A y dom_B.
- Si un usuario_A@dom_A llama al AOR sip:usuario_B@dom_B entonces mi
OpenSer aplica las reglas entre-dominios para ver quién puede llamar a quién y tal. Ok.
- Pero si por alguna llamada anterior se conoce el "Contact" final del
usuario_B@dom_B (ej: sip:usuario_B@80.80.80.80:5061) entonces el usuario_A@dom_A puede llamar **directamente** a usuario_B@dom_B sin pasar por la política de seguridad de mi OpenSer sólo con tener predefinido su OpenSer como Outbound proxy y llamar directamente a sip:usuario_B@80.80.80.80:5061
Entonces la llamada es Outbound y se ruta directamente (t_relay). Además la llamada llega al destino desde su propio proxy por lo que no serviría ni una supuesta política de seguridad de firewall (impedir entrantes SIP desde IP's distintas a mi proxy).
Por supuesto que sólo permito outbound para dominios locales, pero el problema está en la seguridad entre ellos.
¿Y ahora qué hago? Sólo se me ocurre:
- Drástico: Eliminar la posibilidad de outbound proxy en mi OpenSer, así
al menos doy pie a soluciones de firewall o NAT (la IP origen no sería el proxy así que NAT no lo deja pasar).
- Separar el outbound proxy a otro OpenSer en otra IP (para conseguir lo
mismo que antes sin eliminar las llamadas Outbound).
En fin, me va a dar algo, ¿alguna otra alternativa más limpia y segura? ¿es realmente un proxy SIP que gestiona dominios separados? ¿o hay que poner necesariamente un B2BUA delante de cada entorno SIP?
Gracias por cualquier sugerencia.
-- Iñaki Baz Castillo
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Martes, 23 de Octubre de 2007, samuel escribió:
Puede aún ser "peor": si el UA no tiene configurado outbound proxy y utiliza directamente IPs, la llamada se cursará sin que tu proxy vea un sólo paquete...así es cómo funciona SIP. Para evitarlo debes proporcionar a tus usuarios una razón para que pasen por tu proxy, generalmente solventando problemas de NAT, servicios extras,...
Sí, pero que no usen mi proxy como Outbound proxy en el fondo solucionaría mi problema en cuanto a que si están detrás de NAT no les podría contactar (sólo permiten entrantes desde la IP del proxy por puro tema de NAT y/o firewall).
El "tema" aquí es que los usuarios raramente saben qué IP tienen los dispositivos y aunque lo sepan es más cómodo no indicar nombre de dominio. Aparte que si tus usuarios utilizan conversores PAP raramente podrán especificar dominio en el Req-URI...
Qué problema hay que los usuarios se llamen entre sí????
Insisto en que son dominios diferentes albergados en el mismo proxy, pero independientes. Quiero la misma seguridad si llama un externo a uno de mis dominios que si se llaman entre ellos. Por ejemplo, puedo arrancar un SIPp y dejar medio seco a cualquier tfno IP si tengo acceso directo a él (sin pasar por el proxy, donde tengo instalado el módulo pike).
En el caso de llamada entre dominios locales (pero independientes, insisto) no me hace gracia que si por lo que sea, el dom_B decide impedir entrantes desde dom_A que un listillo de dom_A pueda llamar directamente a la IP de "Contact" de un tfno de dom_B saltándose lapolítica de seguridad entre dominios de mi proxy.
Por ello, y después de casi soñar con ello, he decidido que voy a enviar las llamadas outbound (por ejemplo las que irían directamente a IP's en vez de a mis dominios) a otro OpenSer. De esta forma, aunque dicho OpenSer trate de rutarla no podrá entrar a través de NAT o de reglas de firewall pues no es el proxy donde está registrado el llamado.
Saludos.
Hola Iñaki,
Hola, estoy terriblemente preocupado:
Estaba yo feliz con mi supuesta seguridad entre distintos dominios alojados en mi OpenSer cuando he caído en la cuenta de que dicha seguridad es muy fácilmente rebasable sin más que llamar al "Contact" final de cualquier usuario de cualquiera de estos dominios.
Es decir, supongamos dos dominios locales: dom_A y dom_B.
- Si un usuario_A@dom_A llama al AOR sip:usuario_B@dom_B entonces
mi OpenSer aplica las reglas entre-dominios para ver quién puede llamar a quién y tal. Ok.
- Pero si por alguna llamada anterior se conoce el "Contact" final del
usuario_B@dom_B (ej: sip:usuario_B@80.80.80.80:5061) entonces el usuario_A@dom_A puede llamar **directamente** a usuario_B@dom_B sin pasar por la política de seguridad de mi OpenSer sólo con tener predefinido su OpenSer como Outbound proxy y llamar directamente a sip:usuario_B@80.80.80.80:5061
No entiendo esto... ¿porqué no pasa por las políticas de seguridad que tengas definidas?.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Miércoles, 24 de Octubre de 2007, Jesus Rodriguez escribió:
- Pero si por alguna llamada anterior se conoce el "Contact" final del
usuario_B@dom_B (ej: sip:usuario_B@80.80.80.80:5061) entonces el usuario_A@dom_A puede llamar **directamente** a usuario_B@dom_B sin pasar por la política de seguridad de mi OpenSer sólo con tener predefinido su OpenSer como Outbound proxy y llamar directamente a sip:usuario_B@80.80.80.80:5061
No entiendo esto... ¿porqué no pasa por las políticas de seguridad que tengas definidas?.
Bien, la sección "outbound" está antes de la "inbound" y en ella simplemente compruebo si el llamante es "mío" y si es así le pido auth y suto la llamada directamente (t_relay) y aplico RtpProxy y corrección de NAT.
Y luego viene la sección inbound donde, en función del dominio del RURI se aplica la política de seguridad, que viene a ser el tema que hice [1] de ACL's pero ahora mucho más "poderoso" (comparo fechas, horarios, IP's de origen, expresiones regulares, si es un forwarding o no...).
[1] http://blog.aliax.net/2007/08/openser-acls-multidominio.html
Es decir, recalco que la política de seguridad es en función del dominio y sólo se aplica para llamadas a usuarios de mis dominios.
Pero si un usuario de uno de mis dominios (dom_A) conoce (por una llamada previa) el Contact exacto de otro usuario mío de un dominio distinto (dom_B) e, insisto, completamente independiente de dom_B, entonces el usuario puede llamar directamente a:
sip:user_B@IP_Contact_user_B
por lo que la llamada en mi OpenSer se considera outbound y puesto que la realiza un usuario "mío" se la permito... ¡¡pero se salta toda la política de seguridad!!
Además resulta que como dicho INVITE llegará desde el OpenSer el user_B lo aceptará de todas todas (ni siquiera hay una mínima protección de NAT o firewall posible).
He ahí el problema.
Por esa razón tengo ya decidido (salvo que me iluminéis) rutar TODAS las llamadas outbound a otro proxy, así al menos en el caso anterior el INVITE llegaría desde una IP distinta del proxy de mis usuarios, por lo que no habría nat_pinging ni nada y no atravesaría NAT. Y también podría haber una regla de firewall que sólo permitiese tráfico SIP desde el proxy.
Saludos.
El Wednesday 24 October 2007 15:45:08 Iñaki Baz Castillo escribió:
El Miércoles, 24 de Octubre de 2007, Jesus Rodriguez escribió:
- Pero si por alguna llamada anterior se conoce el "Contact" final del
usuario_B@dom_B (ej: sip:usuario_B@80.80.80.80:5061) entonces el usuario_A@dom_A puede llamar **directamente** a usuario_B@dom_B sin pasar por la política de seguridad de mi OpenSer sólo con tener predefinido su OpenSer como Outbound proxy y llamar directamente a sip:usuario_B@80.80.80.80:5061
No entiendo esto... ¿porqué no pasa por las políticas de seguridad que tengas definidas?.
Bien, la sección "outbound" está antes de la "inbound" y en ella simplemente compruebo si el llamante es "mío" y si es así le pido auth y suto la llamada directamente (t_relay) y aplico RtpProxy y corrección de NAT.
Y luego viene la sección inbound donde, en función del dominio del RURI se aplica la política de seguridad, que viene a ser el tema que hice [1] de ACL's pero ahora mucho más "poderoso" (comparo fechas, horarios, IP's de origen, expresiones regulares, si es un forwarding o no...).
[1] http://blog.aliax.net/2007/08/openser-acls-multidominio.html
Es decir, recalco que la política de seguridad es en función del dominio y sólo se aplica para llamadas a usuarios de mis dominios.
Pero si un usuario de uno de mis dominios (dom_A) conoce (por una llamada previa) el Contact exacto de otro usuario mío de un dominio distinto (dom_B) e, insisto, completamente independiente de dom_B, entonces el usuario puede llamar directamente a:
sip:user_B@IP_Contact_user_B
por lo que la llamada en mi OpenSer se considera outbound y puesto que la realiza un usuario "mío" se la permito... ¡¡pero se salta toda la política de seguridad!!
Umm, o yo me le liado siguiendo el hilo o no tiene sentido lo que comentas.
Aunque el usuario A conozca el contact del B, no le puede mandar un Invite usando de outbound proxy, SI y siempre SI, tu compruebas que no es un dialogo en curso.
Aunque te pongan como outbound proxy, A ha de enviar un Invite a B y lo hará a través de tu proxy, otra cosa distinta es que intente enviarlo directamente de A a B, entonces no puedes hacer nada.
Además resulta que como dicho INVITE llegará desde el OpenSer el user_B lo aceptará de todas todas (ni siquiera hay una mínima protección de NAT o firewall posible).
Creo que te has liado, el INVITE no llegará a B, porque desde que A te lo mande pasará por todas tus reglas, a no ser que el orden de las reglas esté mal.
El Wednesday 24 October 2007 19:44:25 Raúl Alexis Betancor Santana escribió:
por lo que la llamada en mi OpenSer se considera outbound y puesto que la realiza un usuario "mío" se la permito... ¡¡pero se salta toda la política de seguridad!!
Umm, o yo me le liado siguiendo el hilo o no tiene sentido lo que comentas.
No no, en serio, hablo de lo mismo ;)
Aunque el usuario A conozca el contact del B, no le puede mandar un Invite usando de outbound proxy, SI y siempre SI, tu compruebas que no es un dialogo en curso.
Sí que puede, y tiene todo el sentido. Yo permito que los usuarios de mis dominios (domA y domB) hagan llamadas outbound a dominos externos usando como outbound proxy mi OpenSer (para que ponga el RtpProxy y tal).
Entonces si userA@domA llama a la IP de contact de B (sip:userB@ip_contact_B) entonces esa llamada la interpretará mi OpenSer como outbound (no va dirigida a un dominio local) y la rutará directamente, por lo que llegará al userB directamente. Comprobado.
No entiendo porqué hablas ahora de diálogos en curso, no entiendo qué tiene que ver, yo hablo de un INVITE inicial pero que no va a @domB sino a @IP_contact_B (por lo que se ruta como Outbound) y en definitiva llega al usuario B ya que dicho usuario permite llamadas (nat pinging tras REGISTER) desde el proxy.
De ahí que la solución que veo es la de rutar las llamadas outbound a otro proxy y así ya no se pueden "colar" aprovechando el natpinging.
Además resulta que como dicho INVITE llegará desde el OpenSer el user_B lo aceptará de todas todas (ni siquiera hay una mínima protección de NAT o firewall posible).
Creo que te has liado, el INVITE no llegará a B, porque desde que A te lo mande pasará por todas tus reglas, a no ser que el orden de las reglas esté mal.
No es que las reglas estén mal, es que @IP_contact_B no es un dominio local luego es outbound y no se procesa por las reglas (que son para llamadas **entrantes** a los usuarios locales).
Saludos y gracias.
pos aplica un check en sección de outbound que no permita utilizar IPs directamente, únicamente nombres de dominios. Con un regexp podrías dormir tranquilo ;) samuel.
2007/10/25, Iñaki Baz Castillo ibc@in.ilimit.es:
El Wednesday 24 October 2007 19:44:25 Raúl Alexis Betancor Santana escribió:
por lo que la llamada en mi OpenSer se considera outbound y puesto que
la
realiza un usuario "mío" se la permito... ¡¡pero se salta toda la política de seguridad!!
Umm, o yo me le liado siguiendo el hilo o no tiene sentido lo que
comentas.
No no, en serio, hablo de lo mismo ;)
Aunque el usuario A conozca el contact del B, no le puede mandar un
Invite
usando de outbound proxy, SI y siempre SI, tu compruebas que no es un dialogo en curso.
Sí que puede, y tiene todo el sentido. Yo permito que los usuarios de mis dominios (domA y domB) hagan llamadas outbound a dominos externos usando como outbound proxy mi OpenSer (para que ponga el RtpProxy y tal).
Entonces si userA@domA llama a la IP de contact de B (sip:userB@ip _contact_B) entonces esa llamada la interpretará mi OpenSer como outbound (no va dirigida a un dominio local) y la rutará directamente, por lo que llegará al userB directamente. Comprobado.
No entiendo porqué hablas ahora de diálogos en curso, no entiendo qué tiene que ver, yo hablo de un INVITE inicial pero que no va a @domB sino a @IP_contact_B (por lo que se ruta como Outbound) y en definitiva llega al usuario B ya que dicho usuario permite llamadas (nat pinging tras REGISTER) desde el proxy.
De ahí que la solución que veo es la de rutar las llamadas outbound a otro proxy y así ya no se pueden "colar" aprovechando el natpinging.
Además resulta que como dicho INVITE llegará desde el OpenSer el
user_B
lo aceptará de todas todas (ni siquiera hay una mínima protección de
NAT
o firewall posible).
Creo que te has liado, el INVITE no llegará a B, porque desde que A te
lo
mande pasará por todas tus reglas, a no ser que el orden de las reglas
esté
mal.
No es que las reglas estén mal, es que @IP_contact_B no es un dominio local luego es outbound y no se procesa por las reglas (que son para llamadas **entrantes** a los usuarios locales).
Saludos y gracias.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Thursday 25 October 2007 10:53:03 samuel escribió:
pos aplica un check en sección de outbound que no permita utilizar IPs directamente, únicamente nombres de dominios. Con un regexp podrías dormir tranquilo ;)
No serviría. Nada te impide registrar un dominio que apunte a dicha IP del Contact.
Es más, toda IP pública tiene un registro PRT (inversa), por ejemplo (IP puesta a boleo):
$ host -t ptr 80.93.93.93 93.93.93.80.in-addr.arpa domain name pointer sd93093.ikoula.com.
El INVITE tendrá en el Req-URI el nombre de dominio y tu servidor hará un DNS sobre ese nombre de dominio para encontrar donde enviar el INVITE, lo que debes evitar es que el INVITE iniciando el dialogo SIP contenga IPs numéricas en el dominio del Req-URI
Es decir evitar que los usuarios pongan directamente IPs en el dominio del Req-URI de los INVITES...tiene otras contrapartidas pero eso son otros temas..
sam
2007/10/25, Iñaki Baz Castillo ibc@in.ilimit.es:
El Thursday 25 October 2007 10:53:03 samuel escribió:
pos aplica un check en sección de outbound que no permita utilizar IPs directamente, únicamente nombres de dominios. Con un regexp podrías
dormir
tranquilo ;)
No serviría. Nada te impide registrar un dominio que apunte a dicha IP del Contact.
Es más, toda IP pública tiene un registro PRT (inversa), por ejemplo (IP puesta a boleo):
$ host -t ptr 80.93.93.93 93.93.93.80.in-addr.arpa domain name pointer sd93093.ikoula.com.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Thursday 25 October 2007 11:15:32 samuel escribió:
El INVITE tendrá en el Req-URI el nombre de dominio y tu servidor hará un DNS sobre ese nombre de dominio para encontrar donde enviar el INVITE, lo que debes evitar es que el INVITE iniciando el dialogo SIP contenga IPs numéricas en el dominio del Req-URI
Es decir evitar que los usuarios pongan directamente IPs en el dominio del Req-URI de los INVITES...tiene otras contrapartidas pero eso son otros temas..
Insisto Samuel:
Imagina que conozco, por una llamada previa, la IP de Contact de un usuario, por ejemplo: 80.93.93.93
Ahora dices que mi OpenSer impida llamadas con RURI = IP. Vale, entonces hago esto:
$ host -t ptr 80.93.93.93 93.93.93.80.in-addr.arpa domain name pointer sd93093.ikoula.com
y llamo a:
INVITE sip:user_B@sd93093.ikoula.com
Ala, ya tiene forma de dominio.
Ahora imagina que, por lo que sea, esa IP del Contact no tuviese DNS inverso. Voy a dydns.org y creo un dominio dinámico:
mitrampa.dyndns.org => 80.93.93.93
y llamo a:
INVITE sip:user_B@mitrampa.dyndns.or
Y ya me he saltado la seguridad de nuevo. XD
On Thursday 25 October 2007 10:03:56 Iñaki Baz Castillo wrote:
El Thursday 25 October 2007 10:53:03 samuel escribió:
pos aplica un check en sección de outbound que no permita utilizar IPs directamente, únicamente nombres de dominios. Con un regexp podrías dormir tranquilo ;)
No serviría. Nada te impide registrar un dominio que apunte a dicha IP del Contact.
Hombre .. mira que eres revirao ... apunta:
- Tendría que registar un dominio - Tendría que tener una ip FIJA - A y B tendrían que ser usuarios tuyos de dominios diferentes (por la definición inicial del problema)
¿ No te parecen demasiadas cosas que han de coincidir, simplemente para que los tipos usen tu NAT-Solver ¿?, es que creo que les sale más barato redirigirse los puertos en sus routers .. XD
Es más, toda IP pública tiene un registro PRT (inversa), por ejemplo (IP puesta a boleo):
Esto es una afirmación falsa, no tiene porqué tener inversa. Puede no estar definida la zona de resolución inversa y ocurre bastante más veces de lo que te piensas.
$ host -t ptr 80.93.93.93 93.93.93.80.in-addr.arpa domain name pointer sd93093.ikoula.com.
El Thursday 25 October 2007 11:38:23 Raúl Alexis Betancor Santana escribió:
On Thursday 25 October 2007 10:03:56 Iñaki Baz Castillo wrote:
El Thursday 25 October 2007 10:53:03 samuel escribió:
pos aplica un check en sección de outbound que no permita utilizar IPs directamente, únicamente nombres de dominios. Con un regexp podrías dormir tranquilo ;)
No serviría. Nada te impide registrar un dominio que apunte a dicha IP del Contact.
Hombre .. mira que eres revirao ... apunta:
- Tendría que registar un dominio
No sí tiene inversa (y crear un dominio dinámico suele ser gratis).
- Tendría que tener una ip FIJA
No necesariamente. Si sé la IP del contact que tenía ayer posiblemente hoy tenga la misma (si no ha reiniciado el router y esas cosas).
- A y B tendrían que ser usuarios tuyos de dominios diferentes (por la
definición inicial del problema)
Sí.
¿ No te parecen demasiadas cosas que han de coincidir, simplemente para que los tipos usen tu NAT-Solver ¿?, es que creo que les sale más barato redirigirse los puertos en sus routers .. XD
Cierto, de acuerdo. Pero si alguien quiere fastidiar lo podría hacer. Y si puedo evitarlo por diseño, ¿por qué no hacerlo? ;)
Es más, toda IP pública tiene un registro PRT (inversa), por ejemplo (IP puesta a boleo):
Esto es una afirmación falsa, no tiene porqué tener inversa. Puede no estar definida la zona de resolución inversa y ocurre bastante más veces de lo que te piensas.
Entonces me remito a la otra "solución" que le comentaba a Samuel: crear un dominio dinámico para esa IP.
On Thursday 25 October 2007 09:08:11 Iñaki Baz Castillo wrote:
Aunque el usuario A conozca el contact del B, no le puede mandar un Invite usando de outbound proxy, SI y siempre SI, tu compruebas que no es un dialogo en curso.
Sí que puede, y tiene todo el sentido. Yo permito que los usuarios de mis dominios (domA y domB) hagan llamadas outbound a dominos externos usando como outbound proxy mi OpenSer (para que ponga el RtpProxy y tal).
Claro este punto.
Entonces si userA@domA llama a la IP de contact de B (sip:userB@ip_contact_B) entonces esa llamada la interpretará mi OpenSer como outbound (no va dirigida a un dominio local) y la rutará directamente, por lo que llegará al userB directamente. Comprobado.
Umm, ya claro, porque permites llamadas a dominios externos.
No entiendo porqué hablas ahora de diálogos en curso, no entiendo qué tiene que ver, yo hablo de un INVITE inicial pero que no va a @domB sino a @IP_contact_B (por lo que se ruta como Outbound) y en definitiva llega al usuario B ya que dicho usuario permite llamadas (nat pinging tras REGISTER) desde el proxy.
Umm, error de concepto, tu OpenSer no tiene porqué usar los mismos datos de contacto que tiene del register para hacer esta llamada Outbound, y sino usa los mimos el Invite saliente hacia B se estampará contra el NAT de B
De ahí que la solución que veo es la de rutar las llamadas outbound a otro proxy y así ya no se pueden "colar" aprovechando el natpinging.
Ahora mismo no tengo claro como .. pero estoy seguro de que no te hace falta otro proxy para esto.
No es que las reglas estén mal, es que @IP_contact_B no es un dominio local luego es outbound y no se procesa por las reglas (que son para llamadas **entrantes** a los usuarios locales).
Ya, después de pillar papel y boli he entendido donde tienes el problema.
El Thursday 25 October 2007 11:34:15 Raúl Alexis Betancor Santana escribió:
No entiendo porqué hablas ahora de diálogos en curso, no entiendo qué tiene que ver, yo hablo de un INVITE inicial pero que no va a @domB sino a @IP_contact_B (por lo que se ruta como Outbound) y en definitiva llega al usuario B ya que dicho usuario permite llamadas (nat pinging tras REGISTER) desde el proxy.
Umm, error de concepto, tu OpenSer no tiene porqué usar los mismos datos de contacto que tiene del register para hacer esta llamada Outbound, y sino usa los mimos el Invite saliente hacia B se estampará contra el NAT de B
No entiendo, yo mismo hice la prueba y la vulnerabilidad existe:
- Desde userA@domA llamo a userB@domB. - Me fijo en el Contact que envía el userB (que ha sido corregido por OpenSer con la IP pública y puerto por la que sale nateado).
Si yo más tarde llamo directamente a esa IP del contact (IP pública) mi OpenSer la identifica como outbound ($rd != dominio local) y la ruta directamente, es decir, la ruta a la IP pública nateada del userB, y como es el OpenSer quien lo envía atraviesa el NAT y llega al userB.
Insito en que todo esto lo tengo exaustivamente comprobado. Me puedes llamar paranoico (y acertarás) pero lo que describo insisto en que es real.
De ahí que la solución que veo es la de rutar las llamadas outbound a otro proxy y así ya no se pueden "colar" aprovechando el natpinging.
Ahora mismo no tengo claro como .. pero estoy seguro de que no te hace falta otro proxy para esto.
Si mi OpenSer reenvia las llamadas outbound a otro proxy2 entonces cuando dicho proxy2 encamine la llamada a la IP del Contact de userB se pegará el leñazo con el NAT ya que sl router NAT no conoce conoexiones salientes desde userB a proxy2.
Saludos y gracias de nuevo.
Podrias mirar si la IP destino a la que se dirige el mensaje (justo antes del t_relay en la ruta outbound) es alguna de las que tiene algun usuario registrado en el openser....
sam.
2007/10/25, Iñaki Baz Castillo ibc@in.ilimit.es:
El Thursday 25 October 2007 11:34:15 Raúl Alexis Betancor Santana escribió:
No entiendo porqué hablas ahora de diálogos en curso, no entiendo qué tiene que ver, yo hablo de un INVITE inicial pero que no va a @domB
sino
a @IP_contact_B (por lo que se ruta como Outbound) y en definitiva
llega
al usuario B ya que dicho usuario permite llamadas (nat pinging tras REGISTER) desde el proxy.
Umm, error de concepto, tu OpenSer no tiene porqué usar los mismos datos
de
contacto que tiene del register para hacer esta llamada Outbound, y sino usa los mimos el Invite saliente hacia B se estampará contra el NAT de B
No entiendo, yo mismo hice la prueba y la vulnerabilidad existe:
- Desde userA@domA llamo a userB@domB.
- Me fijo en el Contact que envía el userB (que ha sido corregido por
OpenSer con la IP pública y puerto por la que sale nateado).
Si yo más tarde llamo directamente a esa IP del contact (IP pública) mi OpenSer la identifica como outbound ($rd != dominio local) y la ruta directamente, es decir, la ruta a la IP pública nateada del userB, y como es el OpenSer quien lo envía atraviesa el NAT y llega al userB.
Insito en que todo esto lo tengo exaustivamente comprobado. Me puedes llamar paranoico (y acertarás) pero lo que describo insisto en que es real.
De ahí que la solución que veo es la de rutar las llamadas outbound a otro proxy y así ya no se pueden "colar" aprovechando el natpinging.
Ahora mismo no tengo claro como .. pero estoy seguro de que no te hace falta otro proxy para esto.
Si mi OpenSer reenvia las llamadas outbound a otro proxy2 entonces cuando dicho proxy2 encamine la llamada a la IP del Contact de userB se pegará el leñazo con el NAT ya que sl router NAT no conoce conoexiones salientes desde userB a proxy2.
Saludos y gracias de nuevo.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Thursday 25 October 2007 12:15:39 samuel escribió:
Podrias mirar si la IP destino a la que se dirige el mensaje (justo antes del t_relay en la ruta outbound) es alguna de las que tiene algun usuario registrado en el openser....
También lo había pensado, pero me parece demasiado aparatoso.
Gracias.
Estoy totalmente de acuerdo contigo. Estos parches, "generalmente", crean más molestías al usuario estándard que protegen de "malos usos"....
Samuel.
2007/10/25, Iñaki Baz Castillo ibc@in.ilimit.es:
El Thursday 25 October 2007 12:15:39 samuel escribió:
Podrias mirar si la IP destino a la que se dirige el mensaje (justo
antes
del t_relay en la ruta outbound) es alguna de las que tiene algun
usuario
registrado en el openser....
También lo había pensado, pero me parece demasiado aparatoso.
Gracias.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Thursday 25 October 2007 11:49:54 Iñaki Baz Castillo escribió:
De ahí que la solución que veo es la de rutar las llamadas outbound a otro proxy y así ya no se pueden "colar" aprovechando el natpinging.
Ahora mismo no tengo claro como .. pero estoy seguro de que no te hace falta otro proxy para esto.
Si mi OpenSer reenvia las llamadas outbound a otro proxy2 entonces cuando dicho proxy2 encamine la llamada a la IP del Contact de userB se pegará el leñazo con el NAT ya que sl router NAT no conoce conoexiones salientes desde userB a proxy2.
Otra solución que se me está ocurriendo es la de disponer de 2 IP's en el OpenSer y forzar a que las llamadas Outbound (y sólo esas) salgan por la segunda. Pero me da que me va a complicar la vida bastante...
Hola Iñaki,
El Miércoles, 24 de Octubre de 2007, Jesus Rodriguez escribió:
- Pero si por alguna llamada anterior se conoce el "Contact"
final del usuario_B@dom_B (ej: sip:usuario_B@80.80.80.80:5061) entonces el usuario_A@dom_A puede llamar **directamente** a usuario_B@dom_B sin pasar por la política de seguridad de mi OpenSer sólo con tener predefinido su OpenSer como Outbound proxy y llamar directamente a sip:usuario_B@80.80.80.80:5061
No entiendo esto... ¿porqué no pasa por las políticas de seguridad que tengas definidas?.
Bien, la sección "outbound" está antes de la "inbound" y en ella simplemente compruebo si el llamante es "mío" y si es así le pido auth y suto la llamada directamente (t_relay) y aplico RtpProxy y corrección de NAT.
Y luego viene la sección inbound donde, en función del dominio del RURI se aplica la política de seguridad, que viene a ser el tema que hice [1] de ACL's pero ahora mucho más "poderoso" (comparo fechas, horarios, IP's de origen, expresiones regulares, si es un forwarding o no...).
[1] http://blog.aliax.net/2007/08/openser-acls-multidominio.html
Es decir, recalco que la política de seguridad es en función del dominio y sólo se aplica para llamadas a usuarios de mis dominios.
Pero si un usuario de uno de mis dominios (dom_A) conoce (por una llamada previa) el Contact exacto de otro usuario mío de un dominio distinto (dom_B) e, insisto, completamente independiente de dom_B, entonces el usuario puede llamar directamente a:
sip:user_B@IP_Contact_user_B
por lo que la llamada en mi OpenSer se considera outbound y puesto que la realiza un usuario "mío" se la permito... ¡¡pero se salta toda la política de seguridad!!
¿Aceptas llamadas a dominios diferentes de los que gestionas?. El dominio del Contact: que tienes en el location nunca será ninguno de los dominios que gestionas por lo que si sólo aceptas llamadas para tus dominios tienes el problema solucionado.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Wednesday 24 October 2007 23:12:43 Jesus Rodriguez escribió:
¿Aceptas llamadas a dominios diferentes de los que gestionas?.
Claro, llamadas outbound, pero obviamente sólo se las permito a los usuarios de mis dominios tras autenticación.
El dominio del Contact: que tienes en el location nunca será ninguno de los dominios que gestionas por lo que si sólo aceptas llamadas para tus dominios tienes el problema solucionado.
Sí, pero esa solución es drástica en cuanto a que impide llamadas de mis usuarios a otros dominios externos. ¿Por qué un usuario de mi OpenSer user@dom_1 n opodría llamar a externo@dominio_externo.com pero sí podría llamar a userB@dom_B (siendo om_B también dominio de mi OpenSer). Insisto en que aunque dom_A y dom_B son dominios de mi OpenSer deben ser completamente independientes y no disponer de privilegios en llamadas entre ellos.
Gracias.
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jesus Rodriguez -
Raúl Alexis Betancor Santana -
samuel