El objetivo del ataque era encontrar gateways o equipos con interconexión a PSTN que no estuviesen protegidos y aceptasen llamadas desde cualquier origen para enviarles tráfico a destinos bastante caros. Un efecto colateral de este incidente ha sido uno de los mayores ataques de SPIT que han habido ya que muchos teléfonos IP o ATA conectados directamente a Internet (por ejemplo, los Fritzbox de AVM de lo que hay millones en Alemania) empezaron a sonar a cualquier hora del día o de la noche… y seguro que molesta mucho más que el Spam

En el artículo se hacen algunas recomendaciones básicas para asegurar los equipos de VoIP, pero no dejan de ser cosas básicas de sentido común que todo aquel que trastee con estos equipos debería tener en cuenta desde el primer momento.

Este ataque ha sido uno de los incidentes de seguridad relacionados con la VoIP que más repercusión ha tenido en medios, listas y foros, lo que no es de extrañar visto el ámbito de actuación.

El 62% de los UA probados enviaban RTCP y tenían en cuenta el RTCP recibido. Esta es la primera vez que tantos UA tienen en cuenta este parámetro.

Parece que ya no podré meterme tanto con Víctor ya que se ha conseguido que tres implentaciones de ICE sean (casi) interoperables

Los roles representados en este evento se han dividido de la siguiente manera (una implementación puede ejercer más de un rol):

• 29 endpoints
• 13 proxy/registrars
• 8 event servers
• 7 gateways
• 2 autonom UAs (voicemail, conference, appserver, etc)
• 14 b2bua/sbc
• 3 UA with signaling, but without media
• 5 test/monitoring tool

Implementaciones usando los diferentes transportes para los mensajes SIP:

• UDP 100%
• TCP 93%
• TLS 48%
• SCP 11%
• DTLS none

Es curioso como el soporte de TCP está creciendo muy rapidamente… creo que el futuro de SIP pasa por migrar de UDP a TCP y los fabricantes se han concienciado de ello.

El 30% de las implementaciones soportaban SIP sobre IPv6 (¿dónde se puede encontrar de una vez algún UA con soporte IPv6?) y el 19% soportaba SIP sobre IPSec.

Otra cosa que me ha parecido muy curiosa es el lío que hay para saber qué parámetro usa cada implementación para mostrar el número llamante:

• P-Asserted-Identity if present, then From
• From display name part of the From uri
• P-Asserted-Identity only
• Contact uri
• Remote ip address
• P-Asserted-Identity, then Remote-Party-ID, then From
• From, then Remote-Party-ID, then P-Asserted-Identity
• Remote-Party-ID, then From
• From, then P-Asserted-Identity
• P-Asserted-Identity, then Reply-To, then From
• Entire From uri

Como se puede ver, es un completo galimatías y cuando te mueves en un entorno multifabricante de UAs gestionar todo esto es realmente complicado :-/ … tendrían que ponerse de acuerdo para decidir qué valores usar… no debería ser tan difícil, ¿no?.

Parece que también se hicieron bastantes pruebas referentes a presencia, XCAP, etc, y que son partes que van ganando participantes.

Uno de los equipos participantes en este SIPIt me había invitado a ir y hacer las pruebas con ellos pero no me fue posible acudir … la verdad es que los SIPIt es de los eventos que más me llaman y espero poder participar en el próximo… y contar la experiencia, claro

En lo referente al proyecto, se han terminado de definir los módulos que se desarrollarán, los próximos entregables (este proyecto tiene un total de 13 entregables en dos años, lo que es bastante trabajo) y se ha empezado a definir la maqueta que hará falta para probar los módulos desarrollados.

Próxima reunión en septiembre en Atenas.