INSTITUTO POLITÉCNICO NACIONAL

Transcripción

1 INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA UNIDAD CULHUACAN SEMINARIO DE TITULACION SEGURIDAD DE LA INFORMACIÓN TESINA SEGURIDAD EN SIP QUE PRESENTA PARA OBTENER EL TÍTULO DE INGENIERO EN COMUNICACIONES Y ELECTRÓNICA DÍAZ PIÑERA MAHONRI Asesor: M. EN C. ELEAZAR AGUIRRE ANAYA VIGENCIA: DES/ESIME-CUL-2008/23/2/10 México, D.F., Octubre 2010

2

3 ÍNDICE GENERAL Págs. JUSTIFICACIÓN PLANTEAMIENTO Y DELIMITACIÓN DEL PROBLEMA OBJETIVOS I II III CAPÍTULO I. SESIÓN 1.1 Introducción Sesión Tipos de Sesión Capa de sesión Servicios que se dan a la capa de Transporte Servicios que proporciona Protocolos empleados en el proceso de la sesión Futuro de las sesiones Movilidad Sesión de Control Integrado de Servicios de IPTV 10 CAPÍTULO II. PROTOCOLO DE INICIO DE SESIÓN 2.1 Introducción SIP Descripción de la Funcionalidad de SIP Información General Estructura del Protocolo Mensajes SIP Comportamiento General del Agente Usuario 20 CAPÍTULO III. OPENSIPS 3.1 Introducción OpenSips Arquitectura de OpenSips 24

4 3.3.1 Escenarios de uso Características de OpenSips Archivos importantes de Opensips Archivos de Configuración Script de opensipsctl Módulos de OpenSips 33 CAPÍTULO IV. SEGURIDAD DE SIP Y OPENSIPS 4.1 Introducción Consideraciones de seguridad Autenticación en SIP Confidencialidad Integridad Seguridad en OpenSips Ataques y Amenazas 47 CONCLUSIONES 50 ACRONIMOS 51 GLOSARIO 54 REFERENCIAS 59 ANEXO I 61 ANEXO II 66

5 ÍNDICE DE FIGURAS Págs. CAPÍTULO I. SESIÓN 1.1 La capa de sesión del modelo OSI 3 CAPÍTULO II. PROTOCOLO DE INICIO DE SESIÓN 2.1 Ejemplo de la configuración de una sesión SIP con SIP Estructura de mensaje SIP Esquema del comportamiento del UA 22 CAPÍTULO III. OPENSIPS 3.1 Contenido de la arquitectura del núcleo de OpenSips OpenSips como balanceador de carga OpenSips como Proxy OpenSips con unidad de recorrido NAT Telefonía IP Relación SIP-WEB-DB Directorios OpenSips Script de configuración básica de OpenSips Módulos de OpenSips 33 CAPÍTULO IV. SEGURIDAD DE SIP Y OPENSIPS 4.1 Autenticación Digest Ejemplo de proceso de autenticación usando las respuestas 401 y/o Elementos esenciales de la seguridad Mensaje MIME firmado en un mensaje SIP 45

6 ANEXO I 1.1 Compilación del archivo Parámetros de configuración Manual de comandos de opensipsctl Inicialización del servidor Error en la creación de base de datos No se encontró variable de arranque Apoyo con la herramienta Wireshark 65 ANEXO II 1.8 Tipos de respuestas en SIP 66

7 JUSTIFICACIÓN La necesidad de comunicarse es indispensable para las empresas, se requiere una comunicación constante y efectiva. Hoy en día ya se cuenta con la infraestructura de red que permite cumplir con este propósito. La implementación de un nuevo servidor basado en SIP (Session Initiation Protocol) permite tener un mayor control de los usuarios y las sesiones que estos inician tales como: correo, video conferencias, voz. Hasta el día de hoy se han presentado diversas soluciones en cuanto a seguridad se refiere, como la implementación de dispositivos de red: Firewalls, IDS, Proxy, que protegen a diferentes protocolos. Sin embargo en el tema de sesión, son pocas las soluciones que se han presentado; una de las alternativas que se proponen es hacer uso de un servidor SIP para tener el control en el inicio, la modificación y la terminación de sesión. I

8 PLANTEAMIENTO Y DELIMITACIÓN DEL PROBLEMA La finalidad de este proyecto es mencionar el funcionamiento de un servidor SIP operando en una red. Los usuarios harán uso de diferentes servicios en el desempeño de sus labores, El problema se presenta cuando hacen uso de los recursos de manera simultánea, saturando el ancho de banda de la red, provocando un bajo rendimiento en los servicios. Con el uso de un servidor SIP, se administraran las sesiones, buscando con ello, dar prioridad a ciertas aplicaciones. II

9 OBJETIVO GENERAL Mencionar algunas aplicaciones de OpenSips utilizadas para la seguridad en una sesión y analizar las problemáticas de seguridad del protocolo SIP OBJETIVOS PARTICULARES Señalar el funcionamiento del protocolo SIP. Enunciar las características del servidor OpenSips Entablar una sesión de usuario SIP Usar la herramienta de Wireshark como apoyo en el análisis III

10 CAPÍTULO I SESIÓN

11 1.1 INTRODUCCIÓN Hoy en día, la mayoría de las personas trabajan, aprenden, se comunican, se divierten, etc. Usando las ventajas que Internet ofrece, pues se ha convertido en una herramienta esencial para poder enviar y recibir información a cualquier parte del mundo; existen diversas aplicaciones que permiten la comunicación entre las redes por medio de las capas que integran el Modelo OSI (Open System Interconection). Este modelo describe siete capas de interacción para que un sistema de información pueda comunicarse a través de un red, estas capas representan las principales áreas de función que son generalmente requeridas o útiles para la transmisión de datos en un en una red. En este documento se describe particularmente el uso de sesiones en internet, la capa de sesión del modelo OSI y algunos protocolos que interactúan entre sí para permitir que una sesión se lleve a cabo. 1.2 SESIÓN Una sesión comienza cuando un usuario desea conectarse a un servidor, la capa de sesión abre un canal temporalmente entre los dos puntos para que estos puedan comunicarse entre sí e intercambiar información. Es posible tener más de una sesión abierta al mismo tiempo, para lo cual se requerirá de cierta administración para que cada aplicación pueda ejecutarse sin que se generen errores. 1

12 Un usuario o cliente, puede ser tanto una persona como una computadora, ya que el concepto está vinculado al acceso a ciertos recursos o dispositivos. Un servidor es una computadora que forma parte de una red y que provee servicios a otras computadoras, que reciben el nombre de clientes. Entre los distintos tipos de servidores, pueden destacarse los servidores de archivos (almacenan los documentos y los distribuyen a los clientes de la red), los servidores de correo (que guardan, reciben y envían correos electrónicos) y los servidores web (almacenan los documentos que son accesibles a través de internet). 1.3 TIPOS DE SESIÓN Sesión ordinaria (dos usuarios establecen comunicación entre sí) Sesión múltiple (donde varios usuarios establecen comunicación y pueden intercambiar información) Sesión de multidifusión (Donde hay un usuario que transmite la información y los demás la reciben) [1]. 1.4 CAPA DE SESIÓN La capa de sesión permite a los usuarios de diferentes maquinas de una red establecer sesiones entre ellos con el fin de enviar y recibir información de una manera rápida y sencilla. 2

13 El propósito de la capa de sesión es proveer los medios necesarios para los usuarios presentes, en la organización y sincronización de sus diálogos y administrar el intercambio de datos. Para que esto se pueda realizar, la capa de sesión provee servicios para establecer una sesión de conexión entre dos usuarios presentes, manteniendo organizado el intercambio de datos y desconectando la sesión de manera ordenada, en la figura 1.1 muestra la capa de sesión dentro del modelo OSI Figura 1.1 La capa de sesión del modelo OSI SERVICIOS QUE SE DAN A LA CAPA DE TRANSPORTE En el modo de conexión, los servicios que la capa de sesión ofrece son los siguientes: a) Establecimiento de la sesión de conexión b) Terminación de la sesión de conexión c) Transferencia de datos de manera normal d) Transferencia de datos expedidos e) Administración de Tokens f) Sincronización de la sesión de conexión g) Reporte de excepciones 3

14 h) Administración de actividades i) Transferencia de datos escritos j) Re-sincronización El modo de conexión, se lleva a cabo cuando hay una solicitud de sesión ante un servicio de sesión en algún punto de acceso por un usuario presente, Dicha conexión se mantiene hasta que alguno de los dos puntos decide terminar la sesión de conexión. En el modo de no-conexión, los servicios que la capa de sesión ofrece son los siguientes: a) Transmisión en modo de no-conexión usando los servicios de transporte del modo de no-conexión b) Reporte de excepciones La función que tiene la capa de sesión para el modo de no-conexión es proporcionar un mappeo de las direcciones de transporte a las direcciones de sesión. En este modo, la segmentación y re-ensamble de datos no es proporcionada en la capa de sesión, por tal motivo, las entidades de datos de los servicios de sesión estará limitada por el tamaño por las unidades de datos del protocolo de sesión y la información del Protocolo de Control de Sesión (SCP) [2] SERVICIOS QUE PROPORCIONA a) Control del Diálogo: Éste puede ser simultáneo en los dos sentidos (fullduplex) o alternado en ambos sentidos (half-duplex). b) Agrupamiento: El flujo de datos se puede marcar para definir grupos de datos. 4

15 c) Recuperación: La capa de sesión puede proporcionar un procedimiento de puntos de comprobación, de forma que si ocurre algún tipo de fallo entre puntos de comprobación, la entidad de sesión puede retransmitir todos los datos desde el último punto de comprobación y no desde el principio [3]. 1.5 PROTOCOLOS EMPLEADOS EN EL PROCESO DE LA SESIÓN Se hace mención de algunos protocolos utilizados durante las sesiones: a) SIP- Session Initiation Protocol SIP, es un protocolo para la creación, modificación y finalización de sesiones con uno o más participantes. Estas sesiones incluyen llamadas telefónicas por Internet, distribución multimedia y conferencias multimedia [4]. b) SDP-Session Description Protocol SDP está destinado a describir sesiones multimedia como el anuncio de la sesión, invitación de sesión y otras formas de inicio de sesión multimedia. Al iniciar teleconferencias multimedia, las llamadas de voz sobre IP, streaming de vídeo, u otras sesiones, Hay un requisito para transmitir medios de información, direcciones de transporte, y otra descripción de sesión de metadatos a los participantes. SDP proporciona un estándar de representación para tal información, independientemente de la forma en que la información se transporta. 5

16 SDP es puramente un formato para la descripción de la sesión - no incorpora un protocolo de transporte y se pretende utilizar diferentes protocolos de transporte como la solución más adecuada, entré los cuales destacan: Session Announcement Protocol (SAP), SIP, Real Time Streaming Protocol (RTSP), correo electrónico usando extensiones MIME, y el Hypertext Transport Protocol (HTTP). El objetivo de SDP es transmitir información sobre flujos de medios en sesiones multimedia para permitir a los destinatarios de una descripción de la sesión, participar en la sesión. SDP está pensado principalmente para su uso en una interconexión de redes, aunque también puede describir conferencias en otros entornos de red. Hasta el momento, las sesiones de multidifusión basada en Internet han diferido de muchas otras formas de conferencias en la que cualquier persona que reciba el tráfico puede unirse a la sesión (a menos que el tráfico de la sesión este cifrado). En ese entorno, SDP tiene dos propósitos principales: Es un medio para comunicar la existencia de una sesión, y es un medio para transmitir información suficiente que permita unirse y participar en un período de sesiones. En un entorno de unidifusión, sólo este último propósito es el que pueda ser relevante [5]. c) SAP- Session Announcement Protocol SAP es un protocolo que ayuda en el anuncio de conferencias multimedia de multidifusión y otras sesiones de multidifusión, comunica información pertinente sobre la configuración de la sesión a los posibles participantes, para lograr este fin, un directorio de sesiones distribuidas puede ser utilizado. Un ejemplo de tal directorio de sesiones periódicamente envía paquetes por multidifusión que contienen una descripción de la sesión, y estos anuncios son 6

17 recibidos por otros directorios de sesión de tal manera que los posibles participantes a distancia puedan utilizar la descripción de la sesión para iniciar las herramientas necesarias para participar en la sesión. Un locutor de SAP periódicamente envía un paquete de voz por multidifusión a un puerto y dirección de multidifusión conocida. El anuncio es difundido con el mismo alcance con el que la sesión es anunciada, asegurándose de que los beneficiarios de la convocatoria se encuentran dentro del ámbito de aplicación de la sesión que el anuncio describe (ancho de banda y otros limitaciones permitidas). Esto también es importante para la escalabilidad del protocolo, ya que mantiene localmente anuncios de sesión local. Un oyente de SAP aprende de los ámbitos de multidifusión internos (por ejemplo, usando el MZAP (protocolo de anuncio de zona de ámbito de multidifusión, referido en el RFC 2776) y escucha en el puerto y dirección conocida de SAP los ámbitos de aplicación. De esta manera, con el tiempo aprenderá todas las sesiones que son anunciadas y permitiendo que dichas sesiones se unan. SAP y SDP se basaron originalmente en el protocolo utilizado por el directorio de sesiones de sd de Van Jacobson en LBNL. La versión 1 de SAP se diseñado por Mark Handley como parte de la Comisión Europea MICE (Esprit 7602) y MERCI (Telemática 1007) de proyectos. La versión 2 incluye funciones de autenticación desarrollado por Edmund Whelan, GoliMontasser-Kohsari y Peter Kirstein, como parte de la Unión Europea Comisión ICE-proyecto TEL (Telemática 1005), y soporte para IPv6desarrollado por Mary P. Maher y Colin Perkins [6]. d) SCP-Session Control Protocol El SCP proporciona un mecanismo simple para crear múltiples conexiones ligeras a través de una sola conexión TCP (Transfer Control Protocol). Varias 7

18 conexiones ligeras, pueden estar activas al mismo tiempo. SCP proporciona un servicio orientado a bytes, pero permite a los límites del mensaje ser marcados. Hay varios protocolos de uso generalizado en Internet para crear una única conexión TCP para cada transacción. Al hacerlo de esta manera, ofrece dos ventajas para el diseño del protocolo, el marcador final de archivo puede ser utilizado para marcar el final de una transacción, y varias transacciones pueden tener lugar simultáneamente. Desafortunadamente, debido a que estas transacciones son de tan corta duración, el costo de crear y derribar estas conexiones se vuelve significativa, tanto en términos de recursos utilizados y los retrasos relacionados con los mecanismos de control de congestión TCP. SCP es un protocolo simple que se ejecuta en la parte superior de TCP y que se puede utilizar para crear varias conexiones ligeras a través de una conexión de transporte único. Los datos de diversos canales pueden ser intercalados, y tanto los límites del mensaje y los marcadores de secuencia final pueden ser proporcionados. Debido a que SCP se ejecuta en la parte superior de un servicio de transporte confiable, puede evitar la mayoría de los trabajos adicionales que TCP debe pasar a fin de garantizar la fiabilidad. Por ejemplo, las sesiones de SCP no tienen que ser confirmadas, así que no hay necesidad de esperar a que apretón de manos para completar [7]. 1.6 FUTURO DE LAS SESIONES A continuación se describirán algunos de los escenarios que harán uso de las sesiones y sus aplicaciones: 8

19 1.6.1 Movilidad IP El rápido crecimiento de internet y aumento de la demanda para el acceso inalámbrico en todas partes son las fuerzas impulsoras detrás de una intensa actividad hacia el diseño de todas las redes IP de conexión inalámbrica en diferentes fórums técnicos y organismos de normalización. El principio de régimen de gestión de la movilidad en las conexiones inalámbricas de Internet proporciona los medios de la terminal, la sesión y servicio y movilidad personal. En la actualidad, la IP móvil y muchos de sus variantes como MIP con la optimización de la ruta proporciona una solución inter-dominio de la movilidad, por otro lado, hay otros enfoques en evolución, tales como IP celular, HAWAII, IDPM que proporcionan movilidad dentro de la fuente de dominio mediante enrutamiento fuente o agente dinámico de casa. Todos estos enfoques utilizan soluciones en la capa de red así como el apoyo continúo en los medios de comunicación cuando los nodos se mueven alrededor y proporcionar los medios de la movilidad de terminales, así como la asignación dinámica de direcciones usando el identificador de acceso a la red. Por otra parte, el protocolo de inicio de sesión SIP está ganando rápidamente la aceptación generalizada como el protocolo de señalización de la elección para servicios multimedia de Internet y de telefonía. Los cuales también pueden ser usados para conexión inalámbrica a Internet. SIP apoya la movilidad personal como parte de su mecanismo de señalización, su conjunto de características también puede ser ampliado para proporcionar medios adecuados de la terminal, y servicio de movilidad. 9

20 Ya ha sido admitida como un medio para la señalización de la administración de sesiones en muchos de los foros y organismos de normalización como MWIF, 3GPP que está diseñando la arquitectura de toda la red IP inalámbrica [8] Sesión de Control Integrado de Servicios de IPTV Peer-to peer Hoy en día un amplio despliegue de redes de acceso de banda ancha, el alto desarrollo de tecnologías de procesamiento multimedia personales, y los altos intereses de la UCC (contenidos creados por el usuario) están ampliando las redes P2P (peer to peer) en la era de la televisión por IP que se abrirá en un futuro próximo. La IPTV-P2P creará un nuevo paradigma para los servicios de Internet. El modelo de sesión de control propuesta permite que el componente de TPS (triple play), de la IPTV- P2P sea controlado de forma integrada. Y permite que los requisitos de QoS (calidad de servicio) de los servicios de IPTV-P2P puedan ser controlados adecuadamente dentro de un período de sesión para que el tráfico de IPTV pueda ser manejado de manera diferenciada del tráfico de acceso a Internet convencional, incluso en caso de congestión de la red. También incorpora los servicios de control de multidifusión a fin de apoyar la transmisión efectiva de cadenas de radiodifusión de vídeo. La propuesta del modelo control de sesión de IPTV-P2P está diseñado para ser basado en los protocolos del estándar SIP (protocolo de inicio de sesión), IGMP (Internet Group Management Protocol) y COPS (servicios comunes de la política abierta) [9]. 10

21 CAPÍTULO II PROTOCOLO DE INICIO DE SESIÓN

22 2.1 INTRODUCCION El crecimiento de las redes telefónicas de nueva generación como lo es VoIP (Voz sobre Protocolo de Internet) ha sido muy rápido en estos últimos años, y esto se debe al bajo costo de su implementación y mantenimiento si se compara con las redes de telefonía tradicional. SIP (Session Initiation Protocol) es considerado uno de los pilares para el desarrollo de las nuevas tecnologías en redes telefónicas. Debido a sus características y flexibilidad se ha convertido en el protocolo de control que mas se usa en los sistemas convergentes de tiempo real, dejando en segundo plano otros protocolos como H.323 y MGCP. Se ha visto que las sesiones multimedia pueden ser muy diversas tales como audio, videollamadas entre 2 o mas usuarios, sesiones de chat y sesiones de juego [10]. Se describirán las funciones y características principales de este protocolo; tomados del RFC (Request for Comments) SIP SIP significa Session Initiation Protocol, es un protocolo de señalización propuesto para iniciar, modificar y terminar una sesión de usuario interactiva que implica elementos multimedia, tal como video, voz, mensajería instantánea, juegos en línea y realidad virtual. SIP fue desarrollado por el IETF (Internet Engineering Task Force) y publicado como RFC 3261 en Junio del

23 Ahora bien, es conveniente revisar el RFC para poder saber un poco mas acerca de este protocolo, esto ayudara a tener una mejor perspectiva respecto al tema que se pretende cubrir en este proyecto. A continuación se presenta un pequeño resumen acerca del RFC 3261 [11]. El documento describe a SIP, como un protocolo de control de la capa de aplicación para crear, modificar y finalizar sesiones con uno o más participantes. Estas sesiones incluyen llamadas telefónicas por Internet, distribución multimedia y conferencias multimedia. Una invitación SIP es utilizada para crear una sesión y realizar una descripción de la sesión que permiten a los participantes llegar a un acuerdo sobre el conjunto de medios compatibles. SIP hace uso de elementos llamados servidores proxy para ayudar a enrutar las solicitudes a la ubicación actual del usuario, autenticar y autorizar los servicios a usuarios, proveedor de aplicaciones en las políticas de enrutamiento en llamadas, y proporcionar características a los usuarios. SIP también proporciona una función de registro que permite a los usuarios subir sus ubicaciones actuales para el uso de servidores proxy. SIP se ejecuta en la parte superior de varios protocolos de transporte. 2.3 DESCRIPCIÓN DE LA FUNCIONALIDAD DE SIP SIP es un protocolo de control de la capa de aplicación que puede establecer, modificar y finalizar sesiones multimedia (conferencias), como llamadas de telefonía por Internet. SIP también puede invitar a los participantes a sesiones ya existentes, tales como conferencias de multidifusión. Medios de comunicación 12

24 pueden ser añadidos (y retirados de) una sesión existente. SIP soporta de forma transparente la asignación de nombre y servicios de redirección, que apoya la movilidad personal (los usuarios pueden mantener un solo identificador visible externamente, independientemente de su ubicación de red). SIP utiliza cinco facetas en la creación y la terminación de sesiones en comunicaciones multimedia: Ubicación del usuario: determinación de la terminal para ser utilizado para la comunicación: Disponibilidad del usuario: determinación de la voluntad de la terminal para participar en las comunicaciones; Capacidades del usuario: determinación de los parámetros de los medios de comunicación para ser utilizado; Configuración de la sesión: "Ringing", el establecimiento de parámetros de la sesión en ambas partes, llamada y llamando; La administración de sesiones: incluida la transferencia y la terminación de sesiones, la modificación de parámetros de la sesión, e invocando los servicios. SIP funciona tanto con IPv4 como con IPv INFORMACIÓN GENERAL Esta sección introduce las operaciones básicas de SIP usando ejemplos simples. El primer ejemplo muestra las funciones básicas de SIP: ubicación de un punto final, el deseo de comunicar una señal, la negociación de la sesión con parámetros para establecer la sesión, y el desmontaje de la sesión una vez establecida, en la figura 2.1 se muestra un ejemplo típico de un intercambio de mensajes SIP entre dos usuarios, Alice y Bob. 13

25 En este ejemplo, Alice utiliza una aplicación SIP en su PC (en adelante, un softphone) para llamar a Bob en su teléfono SIP a través de Internet. También se muestran dos servidores proxy SIP que actúan en nombre de Alice y Bob para facilitar el período de establecimiento de sesiones. Esta disposición típica se refiere a menudo como el "SIP trapecio" como se muestra por la forma geométrica de las líneas de puntos en la Figura 2.1. Alice "llama" a Bob con su identidad SIP, un tipo de Identificador de Recursos Uniforme (URI) denominado SIP URI. Tiene una forma similar a una dirección de correo electrónico, que por lo general contiene un nombre de usuario y un nombre de host. En este caso, es sip: bob@biloxi.com, donde biloxi.com es el dominio del proveedor de servicios de SIP de Bob.Alice tiene una SIP URI, sip: alice@atlanta.com. Cada negociación consiste en una petición que invoca un método particular, en el servidor y la respuesta de al menos uno. En este ejemplo, la operación comienza con el envío de una solicitud del softphone de Alice, enviando una petición de INVITE dirigida a la SIP URI de Bob. INVITE es un ejemplo de un método SIP que especifica la acción que el solicitante (Alice) quiere mantener con el servidor (Bob). La petición INVITE contiene un número de campos de cabecera. En los campos de encabezado se nombran los atributos que proporcionan información adicional acerca de un mensaje. 14

26 Fig. 2.1 Ejemplo de la configuración de una sesión SIP con SIP trapecio La letra F y con su respectivo número consecutivo nos ayuda a identificar el proceso que sigue una invitación a una sesión y que a continuación se describe paso a paso: F1.- La información en una INVITE incluye un identificador único para la llamada, la dirección destino, la dirección de Alice, y la información sobre el tipo de sesión que Alice quiere establecer con Bob. El mensaje INVITE podría tener este aspecto: F2.- Es la petición del servidor proxy atlanta.com hacia el servidor proxy biloxi.com F3.- Es el mensaje que envía el servidor atlanta.com a Alice para avisar que ha encontrado el servidor de Bob F4.- Es la comunicación entre el servidor biloxi.com y el Teléfono SIP de Bob F5.- Es el aviso del servidor biloxi.com al servidor atlanta.com que ha localizado a Bob F6.- La respuesta que manda Bob a su servidor para confirmar que ha recibido el Invite de Alice F7.- El servidor biloxi.com avisa al servidor atlanta.com que Bob esta enterado de la petición 15

27 F8.- El servidor atlanta.com avisa a Alice que su petición fue entregada a Bob F9.- Bob decide tomar la llamada de Alice, avisando al servidor biloxi.com F10.- biloxi.com manda el mensaje al servidor atlanta.com F11.- El servidor atlanta.com avisa a Alice que Bob ha tomado la llamada F12.- Inicia la transacción entre ambos usuarios F13.- Bob decide terminar la sesión con Alice F14.- Alice acepta la petición de fin de sesión. 2.5 ESTRUCTURA DEL PROTOCOLO SIP es un protocolo estructurado en capas, lo cual significa que su comportamiento se describe como un conjunto de etapas de procesamiento bastante independiente con un acoplamiento flexible entre cada etapa. El comportamiento del protocolo se describe como capas con el propósito de presentación, lo que permite la descripción de las funciones comunes a través de elementos en una sola sección. No dicta una aplicación de ninguna manera. Cuando decimos que un elemento "contiene" capas, nos referimos a que es compatible con el conjunto de reglas definidas por esté. No todos los elementos especificados en el protocolo contienen todas las capas. Por otra parte, los elementos especificados en SIP son elementos lógicos, no físicos. La capa más baja de SIP es la sintaxis y su codificación. Su codificación es especificada mediante una gramática aumentada de Backus-Naur Form (BNF). La segunda capa es la capa de transporte. Define como un cliente envía peticiones y recibe respuestas y las formas en que un servidor recibe solicitudes y 16

28 envía las respuestas en la red. Todos los elementos de SIP contienen una capa de transporte. La capa de transporte es responsable de la transmisión real de solicitudes y respuestas sobre el transporte de red. Esto incluye la determinación de la conexión a utilizar para una solicitud o una respuesta en el caso de los transportes orientados a la conexión. La tercera capa es la capa de transacción. Las transacciones son un componente fundamental en SIP. Una transacción es una petición enviada por un cliente de transacción (usando la capa de transporte) a un servidor de transacción, junto con todas las respuestas a la solicitud enviada desde el servidor de transacción al cliente. La capa de transacción se encarga de las retransmisiones de la capa de aplicaciones, la adecuación de las respuestas a las peticiones, y los tiempos de espera de la capa de aplicación. En concreto, una transacción SIP consiste en una única solicitud y las respuestas a esa solicitud, que incluyen cero o más respuestas provisionales y una o más respuestas finales. En el caso de una operación en la que la solicitud fue un INVITE (conocida como una transacción INVITE), la transacción también incluye la confirmación sólo si la respuesta final no fue una respuesta del tipo 2xx. Si la respuesta era del tipo 2xx, la confirmación no se considera parte de la transacción. La capa sobre la capa de transacción se denomina transacción de usuario (TU). Cada una de las entidades SIP, con excepción del proxy sin estado, es una transacción de usuario. Cuando una TU desea enviar una solicitud, se crea una instancia de cliente de transacción y se pasa la solicitud junto con la dirección IP del destino, el puerto y el transporte al cual es enviada la petición. La TU que crea una transacción de 17

29 cliente también puede cancelar. Cuando un cliente cancela una transacción, solicita que el servidor deje de procesar y volver al estado en el que se encontraba hasta antes de la operación se inició, y generar una respuesta de error específica para esa transacción. Esto se hace con una petición CANCEL, que constituye su propia transacción. 2.6 MENSAJES SIP Un mensaje SIP puede ser una petición de un cliente a un servidor ó una respuesta del servidor hacia el cliente. Ambos tipos de mensajes consisten en una línea de salida, uno o más campos de cabecera, una línea que indica el final de los campos de cabecera y una opcional para el cuerpo del mensaje, mostrados en la figura 2.2 Fig. 2.2 Estructura del Mensaje SIP 18

30 Existen dos mensajes básicos en SIP, peticiones y respuestas. a) Petición (Request): La petición SIP se distingue por tener una solicitud en línea (Request- Line) para su línea inicial (Start- Line). Request- Line contiene un nombre de método, una solicitud URI y la versión del protocolo separado por un espacio. Generalmente son empleadas para iniciar alguna sesión o para información. INVITE sip:bob@biloxi.com SIP/ 2.0 Nombre de método se refiere a seis tipos de formas de iniciar una sesión: REGISTER para registrar la información del contacto, INVITE, ACK y CANCEL son utilizados para el establecimiento de periodos de sesiones y OPTIONS para consultar la capacidad de los servidores. b) Respuesta (Response): Las respuestas SIP se usan para confirmar que una petición fue recibida y procesada, contiene el estado de procesamiento. Las respuestas se distinguen de las peticiones por tener un estado de línea (Status-Line) como su línea inicial (Start-Line). Status-Line se compone de la versión del protocolo, seguido de un número de código de estado (Status-Code) y una frase textual asociada. Status- Code está integrado por 3 dígitos con los cuales se comprende y satisface una petición, seguido de la frase de razón (Reason-Phrase) que explica la respuesta en una forma más sencilla para los usuarios en general. Los códigos de respuesta son enteros entre 100 y 699, el primer dígito indica la clase. Existen 6 clases de respuestas: 19

31 1XX: (Provisional) La petición fue recibida pero se desconoce aún el resultado del procesamiento. El emisor detiene el envío después de recibir una respuesta de este tipo. Los más comunes son los códigos 180(Ringing) y 100(Trying). 2XX: (Éxito) Son respuestas finales positivas, la petición fue recibida y procesada exitosamente. Por ejemplo 200 (Ok) que significa que el extremo llamado aceptó la invitación de sesión. 3XX: (Redirección) Usados para re-direccionar, dan información acerca de la nueva localización de un usuario o sobre un proxy alterno que pueda resolver satisfactoriamente alguna petición. El emisor del mensaje debe reenviar su petición a otro lado para que su petición sea atendida. 4XX: (Error de cliente) Son respuestas finales negativas, la solicitud contiene una sintaxis errónea ó no puede cumplirse en este servidor. 5XX: (Error del servidor) El servidor no pudo cumplir con una petición aparentemente valida, el proxy es incapaz de procesarla. 6XX (Fallo global) La petición no puede ser atendida en ningún servidor. En el Anexo 1 se muestran las respuestas SIP más comunes. 2.7 COMPORTAMIENTO GENERAL DEL AGENTE USUARIO UA Un agente de usuario (UA) representa una terminal. Contiene un agente de usuario cliente (UAC), que genera peticiones, y un servidor de agente de usuario (UAS), que responde a ellos. La UAC es capaz de generar una petición sobre la base de un estímulo externo y el procesamiento de una respuesta. Un UAS es capaz de recibir una solicitud y generar una respuesta basada en el estímulo externo, el resultado de la ejecución de programas, o algún otro mecanismo. 20

32 Cuando un UAC envía una solicitud, la solicitud pasa a través de un cierto número de servidores proxy, que envía la solicitud a la UAS. Cuando el UAS genera una respuesta, la respuesta se envía a la UAC. Los procedimientos de UAC y UAS dependen de gran medida de dos factores. En primer lugar, a partir de si la solicitud o la respuesta están dentro o fuera de un cuadro de dialogo, y segundo, basado en el método de la petición. Autenticación, integridad y no repudio (mediante el uso de firma digital) y Privacidad y seguridad de los datos (mediante el uso de cifrado). a) Comportamiento del UAC Una petición SIP valida, formulada por un UAC debe contener como mínimo los siguientes campos de cabecera: To, From, CSeq, Call-ID, Max Forwards, y Vía ; todos estos campos de la cabecera son obligatorios en todas las peticiones SIP. Estos seis campos de cabecera son el componente fundamental en un bloque de un mensaje SIP, ya que en conjunto proporcionan la mayor parte de los servicios críticos para el enrutamiento de mensajes incluyendo el direccionamiento de mensajes, el enrutamiento de las respuestas, lo que limita la propagación de mensajes, el orden de los mensajes, y la identificación única de las transacciones. Estos campos de cabecera son adiciónales a la línea de solicitud obligatoria, que contiene el método de solicitud-uri, y la versión SIP. b) Comportamiento del UAS Cuando una solicitud fuera de un cuadro de diálogo es procesada por un UAS, independientemente del método, su principal función es recibir peticiones y generar respuestas a las mismas, en la figura 2.3 muestra el esquema en el que 21

33 trabaja un servidor basado en SIP. El UA trabaja como UAC y UAS, primero de una forma posteriormente de la otra, el UA realizara ambas funciones en una sesión Fig. 2.3 Esquema del comportamiento del UA 22

34 CAPÍTULO III OPENSIPS

35 3.1 INTRODUCCION Un proveedor de VoIP está integrado por varios componentes, uno de estos componentes es el servidor OpenSips (Open SIP Server). La mejor descripción de un servidor OpenSips es un router SIP. El cual es capa de manipular las cabeceras SIP se encarga del enrutamiento de paquetes a velocidades extremadamente altas. Los módulos de terceros dan a OpenSips gran flexibilidad para desempeñar funciones que anteriormente no se tenían en cuenta, como NAT (Network Address Translation), IMS (IP multimedia Subsystem), balanceo de carga, y otras funcionalidades. En este capítulo, se mostraran las arquitecturas de OpenSips más utilizadas y sus características principales. 3.2 OPENSIPS OpenSips es más que un proxy o router SIP, ya que incluye funcionalidades del nivel de aplicación. OpenSips, como un servidor, es el componente central de cualquier solución de VoIP basado en SIP. Con un flexible y personalizado enrutamiento; OpenSips unifica servicios de voz, video, mensajería instantánea y servicios de presencia en una forma eficiente, gracias a su diseño de escalabilidad modular. La visión de OpenSips consiste es una diversidad consolidada ; no solo es un proyecto de código abierto, sino también es una política dirigida a las contribuciones, la cooperación y para la comunidad. La diversidad consolidada se refiere a lo siguiente: 23

36 La diversidad proviene de la gran cantidad de personas involucradas en el desarrollo del proyecto y del gran enriquecimiento de sus características. Para alcanzar un alto nivel de fiabilidad y estabilidad, toda esta diversidad debe ser consolidada. 3.3 ARQUITECTURA DE OPENSIPS La arquitectura del servidor de OpenSips se basa en: Núcleo pequeño y funcionalidades provistas por módulos. Lenguaje de Scripting para la configuración Información de gestión: Datagramas. En la figura 3.1 podemos ver la arquitectura de Opensips Figura 3.1 Contenido de la arquitectura del núcleo de OpenSips. 24

37 OpenSips está construido en la parte superior de un núcleo que se encarga de la funcionalidad básica y la manipulación de los mensajes SIP. Los módulos son responsables de la mayoría de las funciones de OpenSips. Las funciones básicas son funciones que están disponibles sin ningún módulo cargado. Algunos son muy importantes para el comportamiento de la secuencia de comandos. Las funciones básicas no tienen restricciones sobre el número de parámetros que pueden aceptar ESCENARIOS DE USO OpenSips es principalmente usado con un SIP proxy, pero también se puede utilizar como: *SIP servidor de registro *Router SIP (enrutamiento dinámico) / p *SIP agente de presencia *SIP servidor de re direccionamiento *SIP balanceador de carga *SIP back to back (agente de usuario) *SIP servidor de mensajería instantánea *SIP NAT unidad de recorrido *SIP para puertas de enlace / Asterisk *Servidor de aplicaciones SIP Los siguientes diagramas son las aplicaciones más frecuentes para el OpenSips: En la figura 3.2 se muestra la topología de red de la configuración del servidor OpenSips para ser usado como balanceador de carga usado para compartir el trabajo a realizar entre varios procesos. 25

38 Figura 3.2 OpenSips como balanceador de carga La figura 3.3 muestra la topología del servidor usado como Proxy Figura 3.3 OpenSips como Proxy El servidor Proxy retransmite solicitudes y deciden a qué otro servidor debe remitir, alterando los campos de la solicitud en caso necesario. Es una entidad intermedia que actúa como cliente y servidor con el propósito de establecer llamadas (sesiones) entre los usuarios. Este servidor tiene una funcionalidad semejante a la de un Proxy HTTP que tiene una tarea de encaminar las peticiones que recibe de otras entidades más próximas al 26

39 destinatario. Existen dos tipos de Proxy Servers: Statefull Proxy y Stateless Proxy. 1. Statefull Proxy: mantienen el estado de las transacciones durante el procesamiento de las peticiones. Permite división de una petición en varias (forking), con la finalidad de la localización en paralelo de la llamada y obtener la mejor respuesta para enviarla al usuario que realizó la llamada. 2. Stateless Proxy: no mantienen el estado de las transacciones durante el procesamiento de las peticiones, únicamente reenvían mensajes. El servidor de Registro acepta peticiones de registro de los usuarios y guarda la información de estas peticiones para suministrar un servicio de localización y traducción de direcciones en el dominio que controla y el servidor de re-direccionamiento genera respuestas de re-dirección a las peticiones que recibe. Este servidor re-encamina las peticiones hacia el próximo servidor. La figura 3.4 se muestra la topología del servidor como travesía NAT 3.4 OpenSips con unidad de recorrido NAT 27

40 El funcionamiento de la Figura 3.4 se basa cuando se trata de acceder a un servicio a través de Internet y se ven afectados los usuarios por problemas de direccionamiento IP compartido NAT, esta configuración da solución a esta problemática con el SBC (Session Border Controller) que da las siguiente protecciones de borde SIP: *Bloqueo de direcciones IP que excedan limites permitidos. *Limite de procesamiento por tipo de petición SIP. *Manejo de las listas negras y listas blancas. En la figura 3.5 se muestra la Integración de un proveedor de telefonía IP: Figura 3.5 Telefonía IP Es una tecnología que permite la transmisión de voz a través de Internet en forma de paquetes de datos utilizando una PC, un teléfono convencional o una terminal SIP, mostrado en la figura

41 Figura 3.6 Relación SIP-WEB-DB. 3.4 CARACTERÍSTICAS DE OPENSIPS Algunas de las principales características de OpenSips lo hacen adecuado para ciertos ambientes. Cuando se necesita de velocidad, flexibilidad, escalabilidad, potabilidad y la capacidad para funcionar en entornos con poco procesamiento, OpenSips es la opción más adecuada. a) Velocidad OpenSips es capaz de manejar llamadas por segundo, incluso con hardware de bajo costo, esta velocidad permite a las redes ser configurada fuera de la plataforma y con poco mantenimiento. b) Flexibilidad 29

42 OpenSips es abierto y sus administradores pueden definir su comportamiento usando un lenguaje Script. Este lenguaje Script es flexible y de gran alcance para manejar incluso los más complicados escenarios. c) Escalabilidad OpenSips se puede ampliar mediante la vinculación de nuevos códigos desarrollados en C. El nuevo código puede ser desarrollado independiente del núcleo de OpenSips y vinculados al tiempo de ejecución. Este concepto es similar a los módulos en el servidor web de Apache. Recientemente, nuevas capas de programación fueron agregadas. Esto es posible para usar Call Processing Language (CPL) para simplificar el enrutamiento. WeSIP es una interfaz de la aplicación del programa que permite usar servlets Java y ampliar el servidor OpenSips creando un servidor de aplicación SIP. d) Portabilidad OpenSips fue escrito en el ANSI (American National Standards Institute ). Es altamente portátil y disponible para UNIX u otros sistemas como son: Linux, Solaris y BSD[11]. 3.5 ARCHIVOS IMPORTANTES DE OPENSIPS La estructura del directorio de OpenSips contiene varios archivos esenciales para tomar en cuenta, mostrado en la figura

43 Figura 3.7 Directorios de OpenSips ARCHIVOS DE CONFIGURACIÓN (ETC/OPENSIPS) Jonathan]# cd /usr/local/etc/opensips opensips]# ls opensips.cfg opensipsctlrc osipsconsolerc opensips.cfg.sample opensipsctlrc.sample osipsconsolerc.sample opensips]# vi opensips.cfg Al ejecutar el comando vi opensips.cfg podemos apreciar el resultado en la figura

44 Figura 3.8 Script de configuración básica de OpenSips SCRIPT DE OPENSIPSCTL Este código de comandos se utiliza para el gestionamiento de OpenSips que se encuentran en el directorio / usr / sbin. OpenSips desde la línea de comandos. Puede ser utilizado para: Iniciar, detener y reiniciar OpenSips. Mostrar, otorgar y revocar las ACL Añadir, eliminar y alias lista Añadir, eliminar y configurar un AVP Administrar LCR (rutas de bajo coste) 32

45 Administrar RPID Añadir, eliminar y suscriptores de la lista Añadir, eliminar y mostrar el resultado de la mesa usrloc "en-ram" Monitor de OpenSips MÓDULOS DE OPENSIPS (/ LIB / OPENSIPS / MODULE) OpenSips [12] contiene módulos externos al núcleo para aplicar funciones que se encuentre dentro de dichos módulos, como se puede apreciara en la figura 3.9 Figura 3.9 Módulos de OpenSips 33

46 CAPITULO IV SEGURIDAD DE SIP Y OPENSIP

47 4.1 INTRODUCCION Al hablar de servicios y aplicaciones que funcionan a través de internet, es de vital importancia que se hable de seguridad. Según el CERT-CC (Computer Emergency Response Team Coordination Center) el número de incidentes contra sistemas conectados a internet, se duplica cada año. Esto es creíble ya que el crecimiento tan rápido de internet en los últimos años ha sido sorprendente; esto implica por un lado, nuevas redes y servicios susceptibles a ser atacados y cada vez mas usuarios dispuestos a atacar dichos sistemas [13]. Se describirán cuestiones de seguridad en lo que respecta al protocolo SIP y el servidor OpenSips y de qué manera se puede evitar algunos de los ataques a los que son propensos. 4.2 CONSIDERACIONES DE SEGURIDAD SIP no es un protocolo fácil de asegurar debido al uso de sus intermediarios, las múltiples facetas en la relación de confianza y su uso entre elementos sin la confianza de todos. A fin de satisfacer diversas necesidades de distintos mecanismos aplicables a diferentes aspectos y usos que SIP requiere. La seguridad en la señalización SIP no tiene relación alguna con la seguridad utilizada en los protocolos utilizados en conjunto con SIP, como es el caso de RTP. 34

48 4.3 AUTENTICACIÓN EN SIP El protocolo SIP utiliza la autenticación Digest para la autenticación de los clientes. La autenticación Digest es un mecanismo simple de autenticación desarrollada originalmente para HTTP (se le llama con frecuencia HTTP Digest). Inicialmente se utilizaba un mecanismo de autenticación basado en HTTP Basic, pero actualmente está declarado obsoleto debido a su absoluta falta de seguridad, al enviarse el usuario y la contraseña en texto plano. El mecanismo de autenticación es muy simple, está basado en hashes criptográficos que evitan que se envíe la contraseña de los usuarios en texto claro. La autenticación Digest verifica que las dos partes que se comunican conocen un secreto compartido, que es la contraseña. Cuando un servidor quiere autenticar a un usuario, genera un desafío Digest y se lo manda al usuario. Una manera sencilla de establecer este proceso de autenticación es el siguiente: 1.-El cliente intenta establecer una llamada con el servidor. 2.-El servidor responde con un mensaje que incluye un valor aleatorio (nonce) junto al dominio contra el que se va a autenticar (realm). 3.-El cliente debe enviar una respuesta cifrada al servidor en un mensaje de tipo response, indicando el nonce, el realm junto con el nombre de usuario, el uri y la contraseña. 4.-El servidor compara el valor de la respuesta del cliente con el resultado de cifrar él por su cuenta los mismos datos, con la contraseña que tiene del cliente, mostrado en la figura

49 Figura 4.1 Autenticación Digest. Se definen algunos términos que son importantes durante el proceso de autenticación Digest: Desafío Digest: Digest realm="iptel.org", qop="auth,auth int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="", algorithm=md5 1. REALM: Es un parámetro obligatorio y debe estar presente en todos los desafíos. Su propósito es identificar las credenciales dentro de un mensaje SIP. Normalmente es el dominio del cual el servidor proxy SIP es responsable. 2. NONCE: Es un string (cadena) de datos generado únicamente cada vez que un servidor genera un desafío Digest. Se construye a partir del hash MD5 de algún dato. Dicho dato normalmente incluye un sello de tiempo y la frase secreta (contraseña) que tiene el servidor. De esta manera se asegura que cada nonce tenga un tiempo de vida limitado (que no puede volver a ser usado más tarde) y también es único (ningún otro servidor será capaz de generar el mismo nonce). 36

50 Los clientes generan la respuesta Digest a partir del nonce, así el servidor recibirá el contenido del nonce en una respuesta Digest. Normalmente verifica la validez del nonce antes de que compruebe el resto de la respuesta Digest. De manera que, el nonce es un tipo de identificador que se asegura de que las credenciales Digest recibidas han sido realmente generadas para un desafío Digest concreto, y además limita el tiempo de vida de la respuesta Digest, evitando que se vuelvan a lanzar ataques en el futuro. 3. OPAQUE: Es un string de datos que se envía al usuario en el desafío. El usuario pasará el string de datos de vuelta al servidor en la respuesta Digest. Esto permite a los servidores no mantener información sobre el estado. Si hay algún estado que ellos necesitan mantener entre el desafío y la respuesta, pueden pasárselo al cliente utilizando este parámetro y leerlo otra vez más tarde cuando la respuesta Digest venga. 4. ALGORITMO: El algoritmo utilizado para calcular los hashes. Sólo está soportado MD5 (Message-Digest Algorithm 5). 5. QOP: La protección de la calidad. Especifica qué esquemas de protección soporta el servidor. El cliente elegirá una opción de la lista. El valor auth indica solamente autenticación, el valor auth-int indica autenticación con protección de la integridad. Una vez recibido el desafio Digest, un agente de usuario pedirá al usuario el nombre de usuario y la contraseña (si no está preconfgurado), generará la respuesta Digest y la enviará al servidor. Respuesta Digest: Digest username="jan", realm="iptel.org", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:iptel.org", qop=auth, nc= , cnonce="0a4f113b", response="6629fae49393a c4ef1", opaque="" 37

51 En la respuesta, hay parámetros que son similares, pero se agregan algunos mas que se describen a continucion: 1. URI: Contiene el uri al que el cliente quiere acceder. 2. QOP: El nivel de protección elegido por el cliente. 3. NC: contador de nonce, el valor es el contador en hexadecimal del número de peticiones (incluyendo la petición actual) que el cliente ha enviado con el nonce en su petición. Por ejemplo, en la primera petición enviada en respuesta a un nonce dado, el cliente manda nc= La finalidad de esta directiva es permitir que el servidor detecte peticiones de replay manteniendo su propia copia de este contador. 4. CNONCE: El valor es un string proporcionado por el cliente y utilizado tanto por el cliente como por el servidor para evitar ataques de texto plano elegidos, para proporcionar autenticación mutua y protección de la integridad del mensaje. 5. RESPONSE: Es un string generado por el agente de usuario (cliente) que prueba que el usuario sabe la contraseña. Al ser recibida una respuesta Digest, el servidor se encarga de calcular nuevamente el valor de la respuesta y lo compara, esto es posible por medio de los parámetros que proporciono el cliente y el password que tiene almacenado el servidor. Si el resultado es similar a la respuesta que se recibió, el cliente esta autenticado y se le permite el acceso. Al analizar las cabeceras de autenticación SIP, se podrá ver la estructura de autenticación que se lleva a cabo durante el registro del cliente. El cliente solicita el registro: SIP/ Trying Via: SIP/2.0/UDP :2051;branch=z9hG4bK t88fqbra1bie; received= ;rport=2051from: 38