sr-users-es October 2007

sr-users-es@lists.kamailio.org

11 participants
25 discussions

[OpenSER-Users-ES] [Users-es] Mensajes que requieren autenticación

by Saúl Ibarra

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/

16 years, 9 months

[OpenSER-Users-ES] aplicar o no RtpProxy si llamante y llamado tras misma IP pública

by Iñaki Baz Castillo

Hola, estaba yo super contento con mi decisión de no aplicar RtpProxy si el llamante y llamado están tras la misma IP pública. Realmente es más eficiente que si ambos usasen STUN ya que STUN obligaria a que el RTP pasase por el router innecesariamente. Este tema lo he hablado en algún hilo de la lista de OpenSer versión inglesa y a todo el mundo le había parecido residual la posibilidad de encontrar casos en los que llamante y llamado apareciesen tras mismo NAT pero no tuviesen comunicación directa. Estaba yo feliz hasta que Raúl Alexis me ha lanzado este bombazo de correo que casi me deprime. Me gustaría escuchar más opiniones al respecto. Por otra parte, una solución a los problemas que me plantea Raúl Alexis sería que los clientes, en esas circunstancias tan malvadas, usasen STUN. Ya, ¿y si tienen NAT simétrico? bufff, bueno, pues es como si tienen ALG's malvados, nada pueden hacer. ¿Qué opináis? ---------- Mensaje reenviado ---------- Asunto: [Asterisk-ES] Re: Recomedación proveedores VoIP IAX2 Fecha: Martes, 30 de Octubre de 2007 De: Raúl Alexis Betancor Santana <rabs(a)dimension-virtual.com> Para: asterisk-es(a)googlegroups.com El Tuesday 30 October 2007 13:58:14 Iñaki Baz Castillo escribió: > Creo que las ventajas de asumir que están tras el mismo NAT (permitir > tráfico directo en la LAN) supera, con creces, los casos aislados y > particulares en los que dos usuarios en los que se detecta NAT salen con > misma IP pública y resulta que no son accesibles directamente entre ellos. IMHO cometes un error tamaño catedral asumiendo eso. Además no son "casos aislados y particulares", es el caso típico de un complejo de apartamentos con distintas zonas de cobertura WiFi o peor aún, es EL CASO en la 3G en España. > Si una empresa X se monta un pollo de red local con una IP pública y hace > separaciones en la LAN con VLAN's, distintos rangos de red bloqueados por > firewall o no rutables entre sí, etc... es su problema. No confundas cosas, yo no he hablado de como tenga la empresa configurado su routing interno. Te voy a poner un ejemplo (valdría cualquier otro) sobre como tu suposición del NAT tras la misma IP falla estrepitosamente si lo intentas resolver de la forma que tu planteas: Usuario A en habitación x del hotel J, IP asignada por el hotel: 172.26.1.A Usuario B en habitación y del hotel J, IP asignada por el hotel: 172.26.1.B Central SIP oficina: IP pública (o mapeada, que pal caso es lo mismo), AAA.BBB.CCC.DDD Red LAN oficina: 172.26.0.0/23 Ahora el escenario ... Usuario A llega a su habitación, enciende el portatil, se engancha a la red VPN de la oficina para trabajar en la intranet (IP asignada intranet: 172.26.2.A) y va a su bola currando Usuario B llega a su habitación, enciente el portatil, se pone a navegar por internet y se le ocurre llamar a A, porque lo ve por el precense del sotfphone ¿Resultado con tu planteamiento de "ignorar el NAT existente"? que A recibe la señalización pero jamás recibirá el RTP y te dejo como ejercicio averiguar porqué. Y te adelanto que este escenario es más que normal, a la par de muchos otros donde no puedes ignorar el tema del NAT a la lijera. > > La única solución que SIEMPRE funciona cuando hay un NAT de por medio en > > SIP es hacer de proxy del RTP, no hay más tutia. > > Vale, imagina una centralita en internet con un proxy RTP y una > oficina/delegación muy remota con usuarios SIP. ¿Obligarías a que una > llamada entre ellos origine tráfico hasta el proxy RTP de ida y vuelta? > Recuerda que STUN no funciona tras NAT simétrico (por desgracia abundante > hoy en día) y que aún funcionando, dos usuarios tras el mismo NAT > configurados con STUN se enviarían el tráfico de audio a través de su > router (y no directamente). A ver, a ver .. no confundas ... si es una oficina remota, la solución MAS simple es que el router de salida de esa oficina soporte VPN, enchangas un tunel a la central y metes la señalización por el tunel, de esa forma la red es "plana" y no te preocupas del NAT. En caso de no soportar VPN tienes 2 opciones: A) la que tu propones, que ya te digo tiene muchas lagunas y IMHO genera más dolores de cabeza de los que resuelve. B) abrir puertos en el router y fijar en los dispositivos SIP los puertos para que no sean dinámicos. -- Saludos. Raúl Alexis Betancor Santana Dimensión Virtual S.L. -------------------------------------------------------------------------------------------------------------- -- Iñaki Baz Castillo ibc(a)in.ilimit.es

17 years, 1 month

[OpenSER-Users-ES] ¿Puedo hacer algo SIP que sólo hable TCP?

by Iñaki Baz Castillo

Hola, ¿podría programar "algo" SIP que sólo hable TCP o necesariamente tiene que hablar también UDP? Lo digo porque por lo que veo hay muchas más facilidades para programar servidores TCP que UDP (clases, helpers, threads...). Ya sé que UDP es "mandatory" según RFC 3261, pero como mi intención es usarlo contra OpenSer (incluso como OutBound proxy) y registrarlo como un usuario más entiendo que no habría problema, ¿es así? Gracias. -- Iñaki Baz Castillo

17 years, 1 month

[OpenSER-Users-ES] ¿modparam ("usrloc", "db_mode", 3) es una locura?

by Iñaki Baz Castillo

Hola, el modo modparam("usrloc", "db_mode", 3) consume más en cuanto a que cada segundo hace una petición SQL para encontrar contactos con nat_bflag y otras peticiones por cada "lookup(location)". Pero también tiene sus ventajas en cuanto a que permite meter entradas a mano (así tengo hecho yo el tema delos forwardings paralelos o secuenciales con el módulo LCR y tal). Pero claro, ¿cómo de perjudicial es usar modparam("usrloc", "db_mode", 3) respecto de usar modparam("usrloc", "db_mode", 1/2) en un entorno en producción? Sé que depende de la carga de usuarios y llamadas, pero ¿puede el modo "3" saturar un servidor que en modo "2" funciona holgadamente? PD: ¿Qué significa esto? http://www.openser.org/docs/modules/devel/usrloc.html#AEN285 1.3.20. db_mode (integer) 3 - DB-Only scheme. ... The lack of memory caching also disable the location watcher registration (in will not work with PA module) El módulo PA está obsoleto así que asumo incumbe también al módulo "presence", pero ¿qué significa "disable the location watcher registration"? En principio a mí me funciona bien la presencia en modo "3". Gracias por cualquier explicación y un saludo. -- Iñaki Baz Castillo

17 years, 1 month

[OpenSER-Users-ES] t_relay(), "location" -> "socket" y TCP

by Iñaki Baz Castillo

Hola, con "usrloc" modo 3 cambio el campo "socket" para una entrada de la tabla "location" y sustituyo "udp" por "tcp", pero al hacer el t_relay() el mensaje se envía por UDP. Me refiero a un INVITE hecho desde otro cliente UDP. ¿Por qué? entiendo que ese campo "socket" se corresponde precisamente con el socket que OpenSer debe usar para contactar con el usuario final. ¿Por qué razón "t_relay()" usa el protocolo del origen en vez de el del destino? -- Iñaki Baz Castillo

17 years, 1 month

[OpenSER-Users-ES] autenticacion

by Arturo Miranda Vera

Como estan todos, espero bien. Disculpen que haga preguntan muy sencillas pero se me hace necesario , espero no causar alguna molestia. Bueno lo que pasa es que soy nuevo con OpenSER y tengo conocimiento internmedia en Linux SUSE, la version que utilizo es 10.2. he estado probando openser y nada me sale, la verdad he leido bastante del mensaje SIP, de los problemas que existe cuando hay NAT y cual es la solucion. pero a la hora de empezar a probar nisiquiera puedo registrar un usuario. espero me ayuden, ya no se donde esta mi error. la configuracion de mi openser.cfg es: # # $Id: openser.cfg 1827 2007-03-12 15:22:53Z bogdan_iancu $ # # simple quick-start config script # Please refer to the Core CookBook at http://www.openser.org/dokuwiki/doku.php # for a explanation of possible statements, functions and parameters. # # ----------- global configuration parameters ------------------------ debug=3 # debug level (cmd line: -dddddddddd) fork=no log_stderror=yes # (cmd line: -E) listen=udp:192.168.22.117 port=5060 children=4 dns=no rev_dns=no # Uncomment these lines to enter debugging mode #fork=no #log_stderror=yes # # uncomment the following lines for TLS support #disable_tls = 0 #listen = tls:your_IP:5061 #tls_verify_server = 1 #tls_verify_client = 1 #tls_require_client_certificate = 0 #tls_method = TLSv1 #tls_certificate = "//etc/openser/tls/user/user-cert.pem" #tls_private_key = "//etc/openser/tls/user/user-privkey.pem" #tls_ca_list = "//etc/openser/tls/user/user-calist.pem" # ------------------ module loading ---------------------------------- #set module path mpath="//lib/openser/modules/" # Uncomment this if you want to use SQL database #loadmodule "mysql.so" loadmodule "mysql.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "mi_fifo.so" loadmodule "textops.so" loadmodule "xlog.so" loadmodule "auth.so" loadmodule "auth_db.so" loadmodule "uri.so" loadmodule "uri_db.so" loadmodule "domain.so" loadmodule "presence.so" # Uncomment this if you want digest authentication # mysql.so must be loaded ! #loadmodule "auth.so" #loadmodule "auth_db.so" # ----------------- setting module-specific parameters --------------- # -- mi_fifo params -- #modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") # -- usrloc params -- #modparam("usrloc", "db_mode", 0) # Uncomment this if you want to use SQL database # for persistent storage and comment the previous line #modparam("usrloc", "db_mode", 2) # -- auth params -- # Uncomment if you are using auth module # #modparam("auth_db", "calculate_ha1", yes) # # If you set "calculate_ha1" parameter to yes (which true in this config), # uncomment also the following parameter) # #modparam("auth_db", "password_column", "password") # -- rr params -- # add value to ;lr param to make some broken UAs happy #modparam("rr", "enable_full_lr", 1) # ------------------------- request routing logic ------------------- # main routing logic modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") modparam("auth_db|uri_db|usrloc", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("auth_db", "calculate_ha1", no) modparam("auth_db", "password_column", "password") #modparam("auth_db", "password_column_2", "ha1b") modparam("usrloc", "db_mode", 2) modparam("rr", "enable_full_lr", 1) ## Tiempo para la llamada modparam("tm", "fr_inv_timer", 45) modparam("domain", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("domain", "db_mode", 1) ## Habilitamos la cache se la tabla domain modparam("presence", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("presence", "max_expires", 3600) modparam("presence", "force_active", 1) modparam("presence", "server_address", "sip:192.168.22.117:5060") route{ if(!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }; if(msg:len> max_len) { sl_send_reply("513","Message Overflow"); exit; } if (method!="REGISTER") { record_route(); }; if (loose_route()) { route(1); exit; }; if (!is_uri_host_local()) { if (is_from_local()) { route(4); } else { sl_send_reply("403", "Forbidden"); }; exit; } if (method=="ACK") { route(1); exit; } else if (method=="CANCEL") { route(1); exit; } else if (method=="REGISTER") { route(2); exit; } else if (method=="INVITE") { route(3); exit; } else if (method==”PUBLISH” || method==”SUBSCRIBE”) { route(5); exit; } else { lookup("aliases"); if (!is_uri_host_local()) { route(4); exit; }; if (!lookup("location")) { sl_send_reply("404", "Not Found"); exit; }; route(1); exit; }; } route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; exit; } route[2] { sl_send_reply("100", "Trying"); if (!www_authorize("","subscriber")) { www_challenge("","0"); exit; } else if (!check_to()) { sl_send_reply("401", "Unauthorized"); exit; }; consume_credentials(); if ($hdr(contact)=~";expires=0") || ($hdr(expires)=="0") { xlog("L_INFO","$Cbx*** UNREGISTER ***$Cxx\n"); } ## Guardamos la localización en la tabla "location". if (!save("location")) { sl_reply_error(); }; } # # route[3] { ## Es necesario autenticarse para poder llamar if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); exit; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); exit; }; consume_credentials(); lookup("aliases"); if (!is_uri_host_local()) { route(4); exit; }; if (!lookup("location")) { sl_send_reply("404", "User Not Found"); exit; }; route(1); } route[4] { route(1); exit; } route[5] { if (method==”PUBLISH”) { handle_publish(); t_release(); } else if (method==”SUBSCRIBE”) { handle_subscribe(); t_release(); } } onreply_route[1] { xlog("L_INFO","\n\n$Cbc[Respuesta][ $rs ($rr) desde $si:$sp Peticion: ($rm) ] $Cxx\n"); } el archivo de configuracion openserctlrc es como sigue # $Id: openserctlrc 1827 2007-03-12 15:22:53Z bogdan_iancu $ # # openser control tool resource file # # here you can set variables used in the openserctl ## your SIP domain SIP_DOMAIN=192.168.22.117 ## database type: MYSQL or PGSQL, by defaulte none is loaded DBENGINE=MYSQL ## database host DBHOST=localhost ## database name DBNAME=openser ## database read/write user DBRWUSER=openser ## database read only user DBROUSER=openserro ## password for database read only user DBROPW=openserro ## database super user DBROOTUSER="root" ## type of aliases used: DB - database aliases; UL - usrloc aliases ## - default: none ALIASES_TYPE="DB" ## control engine: FIFO or UNIXSOCK ## - default FIFO CTLENGINE="FIFO" ## path to FIFO file # OSER_FIFO="FIFO" ## check ACL names; default on (1); off (0) # VERIFY_ACL=1 ## ACL names - if VERIFY_ACL is set, only the ACL names from below list ## are accepted # ACL_GROUPS="local ld int voicemail free-pstn" ## presence of serweb tables - default "no" # HAS_SERWEB="yes" ## verbose - debug purposes - default '0' # VERBOSE=1 ## do (1) or don't (0) store plaintext passwords ## in the subscriber table - default '1' STORE_PLAINTEXT_PW=0 cuando empiezo correr mi servidor estas son los mensajes: voip:/home/artu # openser 0(3924) INFO:xl_parse_name: using hdr type (7) instead of 0(3924) INFO:xl_parse_name: using hdr type (15) instead of ””””””””Listening on udp: 192.168.22.117 [192.168.22.117]:5060 Aliases: udp: voip:5060 udp: voip.site:5060 WARNING: no fork mode 0(3924) init_tcp: using epoll_lt as the io watch method (auto detected) 0(0) INFO: statistics manager successfully initialized 0(0) StateLess module - initializing 0(0) TM - initializing... 0(0) Maxfwd module- initializing 0(0) INFO:ul_init_locks: locks array size 512 0(0) TextOPS - initializing 0(0) AUTH module - initializing 0(0) AUTH_DB module - initializing 0(0) INFO: udp_init: SO_RCVBUF is initially 109568 0(0) INFO: udp_init: SO_RCVBUF is finally 219136 0(3924) INFO:mi_fifo:mi_child_init(1): extra fifo listener processes created cuando registro un usuario que ya existe en mi base de datos con X-lite me sale este mensaje Registration error: 408 - Request Timeout ese mensaje sale en el X-lite y cuando monitoreo con el NGREP mi servidor los mensajes es esta: # U 2007/10/27 10:59:59.084240 192.168.22.116:37284 -> 192.168.22.117:5060 REGISTER sip:192.168.22.117 SIP/2.0 Via: SIP/2.0/UDP 192.168.22.116:37284;branch=z9hG4bK-d87543-1b6fa5019f43b778-1--d87543-;rport Max-Forwards: 70 Contact: To: "arturo" From: "arturo";tag=a95d120b Call-ID: ZTJlZjUzZjcyNGRhMzUwYjJiN2NiMGM1YjZlNWMyYTQ. CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite release 1011s stamp 41150 Content-Length: 0 no se lo que pasa que no registra, si podria monitorear el openser.cfg de que forma lo hago, donde me salen los errores con el modulo XLOG en tiempo real, para ver verdaderamente lo que sucede paso a paso , espero me ayuden. los usuarios que tengo estan registrados en la tabla SUBSCRIBER como esta: mysql> select id,username,domain,password,first_name,email_address from subscriber; +----+----------+----------------+-----------+------------+--------------------------+ | id | username | domain | password | first_name | email_address | +----+----------+----------------+-----------+------------+--------------------------+ | 1 | admin | 192.168.22.117 | openserrw | Initial | root@localhost | | 2 | 100 | | 101 | arturo | arturo-mv(a)hotmail.com | | 3 | 200 | | 201 | romulo | romulo_bb(a)hotmail.com | | 4 | 300 | | 301 | arturo | arturitomvb(a)hotmail.com | | 5 | 400 | | 401 | arturo | amirandavera(a)hotmail.com | +----+----------+----------------+-----------+------------+--------------------------+ 5 rows in set (0.00 sec) en la tabla domain, tengo registrado el IP de mi servidor mysql> select * from domain; +----+----------------+---------------------+ | id | domain | last_modified | +----+----------------+---------------------+ | 1 | 192.168.22.117 | 0000-00-00 00:00:00 | +----+----------------+---------------------+ 1 row in set (0.00 sec) espero me den algunos alcances de como ordenar, quiza en la compilacion este un poco mal, he seguido los HOWTO de Saghul y tambien la ayuda en el paquete de instalacion, y nada. el MySQL que utilizo ya biene por defecto en SUSE y esta corriendo Muchas Gracias un abrazo a todos Arturo _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx

17 years, 1 month

Re: [OpenSER-Users-ES] help me

by Iñaki Baz Castillo

El Viernes, 26 de Octubre de 2007, Arturo Miranda Vera escribió: > he estado provando > openser y nada me sale, la verdad he leido bastante del mensaje SIP, de los > problemas que existe cuando hay NAT y cual es la solucion. pero a la hora > de empezar a probar nisiquiera puedo registrar un usuario. espero me ayude. > > la configuracion de mi openser.cfg es: > # -- auth params -- > # Uncomment if you are using auth module > # > #modparam("auth_db", "calculate_ha1", yes) > # > # If you set "calculate_ha1" parameter to yes (which true in this config), > # uncomment also the following parameter) > # > #modparam("auth_db", "password_column", "password") Ojo con esos parámetros, lee bien la doc del módulo "auth_db". Te pego mis apuntes al respecto: # -- auth_db -- # Modo "fácil": hacer que OpenSer tenga que calcular el ha1 en base a la columna "password": #modparam("auth_db", "calculate_ha1", 1) #modparam("auth_db", "password_column", "password") # Ya que por defecto es "ha1". # En entorno de producción habría que ponerlo a "0": modparam("auth_db", "calculate_ha1", 0) # OpenSer no conoce las contraseñas en plano. modparam("auth_db", "password_column", "ha1") # Para cuando se autentican con digest username. modparam("auth_db", "password_column_2", "ha1b") # Para cuando se autentican con digest username@dominio. En cambio lo que tú tienes me parece un poco "raro" y creo que por eso no consigues autenticarte (luego tampoco registrarte). -- Iñaki Baz Castillo

17 years, 1 month

[OpenSER-Users-ES] Compatibilidad RFC 2543 con OpenSer y parallel forking

by Iñaki Baz Castillo

Hola, ante todo disculpad el crossposting (he enviado una consulta similar a Asterisk-es). Necesitaría saber si el CISCO 7912 y 7940 pueden funcionar bien con OpenSer. Ambos son RFC 2543 y me preocupa el tema del parallel forking ya que en dicah versión de SIP no se usaban tags en el From y To, así que me imagino podría haber problemas. He encontrado una guía de Cisco sobre compatibilidad del 7940 con RFC3261: http://www.cisco.com/en/US/products/sw/voicesw/ps2156/products_administrati… y lo único que me preocupa un poco es: Basic Authentication Supported? Digest Authentication Yes Proxy Authentication No Me pierdo: la autenticación que pide OpenSer es digest, no sé lo que quiere decir con "Proxy Authentication" a secas. En fin, ¿alguna recomendación? Mil gracias. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

17 years, 1 month

[OpenSER-Users-ES] ¡¡ El "outbound" se carga toda la seguridad !!

by Iñaki Baz Castillo

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

17 years, 1 month

[OpenSER-Users-ES] Problemas reINVITE y check_from llamando con alias

by MAS

Hola Iñaki, Gracias por la rapidez de la respuesta. No acabo de enteder porque no es necesario verificar credenciales en el reINVITE y si en el INVITE, y solo es necesario verificar el has_totag(). Intentaré documentarme más sobre el uso del has_totag(). El caso es que en el inicio de una transferencia A->B->C: - A llama ALIAS_B (INVITE), y B llama-transfer a C (INVITE in-dialog=reINVITE) creo que es necesario que en el INVITE de B a C , B sea verificado (al igual que se hace en el INVITE de A a B incial), no ? Saludos, y gracias. Miguel A.

17 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sr-users-es October 2007