Hola, el RFC 3261 dice, en alguna parte que no recuerdo, que es aconsejable que un proxy/server no cree una transacción hasta que no se haya autenticado el request (si procede). El argumento es que una transacción consume recursos y que un atacante malicioso podría enviar una burrada de requests en paralelo para saturar el proxy/server. Es decir:
1 - Llega un request (req1). 2 - El proxy comprueba que no tiene cabecera de autenticación y lo rechaza, stateless, con un 401/407. 3 - El UAC repite el request con autenticación (req2). 4 - El proxy lo recibe y calcula el digest y tal y da por buena la autenticación. 5 - Entonces el proxy crea la transacción. 6 - Llega una retransmisión de req2 y el proxy responde lo último que se le respondió ("matchea" la transacción).
Pero en un hilo en la lista de OpenSIPS, Bogdan me comenta que crear la transacción antes de autenticar puede ser positivo ya que evita el proceso de autenticación en retransmissiones del request. Es decir:
1 - Llega un request (req1). 2 - El proxy crea la transacción. 3 - El proxy comprueba que no tiene cabecera de autenticación y lo rechaza, stateful, con un 401/407. 4 - El UAC repite el request con autenticación (req2). 5 - El proxy lo recibe y se pone a calcular el digest, pero le lleva un rato. 6 - Llega una retransmisión de req2 y como ya existe la transacción no se procesa de nuevo la autenticación (BIEN). 7 - El proxy da por buena la autenticación previa. 6 - Llega una retransmisión de req2 y el proxy responde lo último que se le respondió ("matchea" la transacción).
Ambas formas tienen sus inconvenientes, ¿cuál creéis que es mejor?
Saludos.
On Monday 13 October 2008 09:46:21 Iñaki Baz Castillo wrote:
Hola, el RFC 3261 dice, en alguna parte que no recuerdo, que es aconsejable que un proxy/server no cree una transacción hasta que no se haya autenticado el request (si procede). El argumento es que una transacción consume recursos y que un atacante malicioso podría enviar una burrada de requests en paralelo para saturar el proxy/server. Es decir:
1 - Llega un request (req1). 2 - El proxy comprueba que no tiene cabecera de autenticación y lo rechaza, stateless, con un 401/407. 3 - El UAC repite el request con autenticación (req2). 4 - El proxy lo recibe y calcula el digest y tal y da por buena la autenticación. 5 - Entonces el proxy crea la transacción. 6 - Llega una retransmisión de req2 y el proxy responde lo último que se le respondió ("matchea" la transacción).
Pero en un hilo en la lista de OpenSIPS, Bogdan me comenta que crear la transacción antes de autenticar puede ser positivo ya que evita el proceso de autenticación en retransmissiones del request. Es decir:
1 - Llega un request (req1). 2 - El proxy crea la transacción. 3 - El proxy comprueba que no tiene cabecera de autenticación y lo rechaza, stateful, con un 401/407. 4 - El UAC repite el request con autenticación (req2). 5 - El proxy lo recibe y se pone a calcular el digest, pero le lleva un rato. 6 - Llega una retransmisión de req2 y como ya existe la transacción no se procesa de nuevo la autenticación (BIEN). 7 - El proxy da por buena la autenticación previa. 6 - Llega una retransmisión de req2 y el proxy responde lo último que se le respondió ("matchea" la transacción).
Ambas formas tienen sus inconvenientes, ¿cuál creéis que es mejor?
Saludos.
Yo creo que es mejor la opción de no crear la transacción hasta que llegue autenticada, lo que comenta Bogan me parece una soberana estupidez.
En el escenario 1 es muy dificil (o directamente imposible) agotar los recursos del servidor, en el segundo caso es tremendamente fácil agotar los recursos del servidor, de hecho con el segundo escenario no se evita el potecial problema de DoS que per sé genera.
El día 13 de octubre de 2008 13:16, Raúl Alexis Betancor Santana rabs@dimension-virtual.com escribió:
Yo creo que es mejor la opción de no crear la transacción hasta que llegue autenticada, lo que comenta Bogan me parece una soberana estupidez.
En el escenario 1 es muy dificil (o directamente imposible) agotar los recursos del servidor, en el segundo caso es tremendamente fácil agotar los recursos del servidor, de hecho con el segundo escenario no se evita el potecial problema de DoS que per sé genera.
El argumento que da él es que en el primer si llega una retransmisión (que no es detectada como tal pues fue rechazado el request original stateless) entonces el servidor debe procesar de nuevo la autenticación, lo que conlleva tareas de IO (consulta SQL, LDAP...).
NOTA: Siempre estamos hablando del segundo request que envía el UA tras solicitársele autenticación, que será una transacción nueva (nuevo branch). Es cecir:
- UA envía INVITE (req1). - Proxy responde 407 stateless - UA envía INVITE con Authorization (req2). - Proxy procesa la autenticación. Dura tiempo porque hay LDAP... - Durante ese procesamento llega una retransmisión de req2. - Como el proxy no ha creado una transacción aún, considera este request como nuevo y procesa también la autenticación (LDAP...).
Esto último es negativo pues cuanto más se estrese al servidor de autenticación (LDAP o lo que sea) peor. Yo creo que en un escenario así (donde la autenticación toma tiempo) sí que puede ser bueno crear la transacción justo antes del proceso de autenticación (eso sí, sólo para requests que contengan la cabecera "(Proxy-)Authorization".
On Monday 13 October 2008 12:46:23 Iñaki Baz Castillo wrote:
Esto último es negativo pues cuanto más se estrese al servidor de autenticación (LDAP o lo que sea) peor. Yo creo que en un escenario así (donde la autenticación toma tiempo) sí que puede ser bueno crear la transacción justo antes del proceso de autenticación (eso sí, sólo para requests que contengan la cabecera "(Proxy-)Authorization".
Es que aún estoy intentando averiguar quien demonios puede tener un escenario en producción donde la respuesta del sistema de autentitación tarde tanto que provoque una retrasmisión del request por parte del UAC. Otra cosa distinta es que por temas de red, haya retrasmisión, pero entonces el proxy ya tendrá los datos de la autenticación y por lo lo tanto, dará igual.
Yo, personalmente, no lo veo util Iñaki, de hecho veo muchiiiiiiiiiisimo más probable meterse en berengenales del DoS con el escenario que Bogan comenta.
A parte de que ¿en que otras situaciones puede ser útil?, no veo muchos escenarios en los que pueda ser útil esa técnica anti-RFC
El día 13 de octubre de 2008 15:04, Raúl Alexis Betancor Santana rabs@dimension-virtual.com escribió:
On Monday 13 October 2008 12:46:23 Iñaki Baz Castillo wrote:
Esto último es negativo pues cuanto más se estrese al servidor de autenticación (LDAP o lo que sea) peor. Yo creo que en un escenario así (donde la autenticación toma tiempo) sí que puede ser bueno crear la transacción justo antes del proceso de autenticación (eso sí, sólo para requests que contengan la cabecera "(Proxy-)Authorization".
Es que aún estoy intentando averiguar quien demonios puede tener un escenario en producción donde la respuesta del sistema de autentitación tarde tanto que provoque una retrasmisión del request por parte del UAC.
Bueno, la primera retransmisión es a los T1 segundos (0,5 segundos), tampoco es tanto. A nada que el LDAP sea "muy" remoto o haya carga (en la conexión al LDAP me refiero)...
A parte de que ¿en que otras situaciones puede ser útil?, no veo muchos escenarios en los que pueda ser útil esa técnica anti-RFC
Bueno, no es anti-RFC. El 3261 simplemente aconseja no crear la transacción hasta haber autenticado el request, pero no es un MUST ni mucho menos.
Iñaki Baz Castillo wrote:
Bueno, la primera retransmisión es a los T1 segundos (0,5 segundos), tampoco es tanto. A nada que el LDAP sea "muy" remoto o haya carga (en la conexión al LDAP me refiero)...
En la última prueba de estress que le hice al kamailio 1.4.0 con autenticación en postgresql (en server a parte), sobre un PIV normalito a 3.0Ghz se comía más de 12.000 request por segundo ... creo que si llegas a tener semejante nivel de carga activa, ya tendrás montado un cluster que balancee ;-)
Saludos -- Raúl Alexis Betancor Santana Dimensión Virtual S.L.
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Raúl Alexis Betancor Santana