El ABC del SBC: definición, características y ventajas

wireless lan controllerEl firewall es el elemento por excelencia que proporciona seguridad a una red cuando se ha de interconectar con otras, permitiendo el tráfico de salida y bloqueando el de entrada no solicitado. El firewall es un elemento necesario, pero no suficiente para la seguridad, puesto que algunas amenazas pueden ocultarse en forma de tráfico legítimo firewall, lo que origina la necesidad de otros elementos de protección especializada.

El caso de la voz sobre IP es aún más especial. Por regla general los firewalls se basan en NAT, y por desgracia, las conexiones de voz sobre IP son incompatibles con NAT. Una posibilidad es abrir excepciones en el NAT del firewall para la voz sobre IP, pero no es una buena idea porque compromete la seguridad y no protege contra ataques de denegación de servicio e intrusión. El control de intrusión merece un capítulo a parte, no solo a nivel de red (lo cual podría realizar un firewall), sino principalmente a nivel de aplicación, con el fin de controlar que las llamadas sean legítimas, evitando ataques, intrusiones y fraudes.

Por si fuera poco, a todo esto se le suma que las sesiones de voz sobre IP se crean de forma aleatoria a medida que se establecen llamadas, lo cual complica aún más el control.

¿Qué es SBC?

Para hacer frente a estos riesgos se requiere un elemento nuevo, que tome parte activa en (y que monitorice) las sesiones de voz sobre IP que se establecen entre la red interna y la red externa, garantizando que son  legítimas, seguras y fiables. Ese elemento es el Session Border Controller (SBC).

El SBC es realmente un firewall para el tráfico de voz y su función es garantizar que las sesiones que se establecen son lícitas, detectando y bloqueando posibles ataques e intrusiones. Otra función de seguridad importante (de forma similar a lo que hace un firewall para los servicios de datos) es la ocultación de los servicios de voz de la red interna hacia el exterior. Para realizar todas estas funciones, el SBC se sitúa, al igual que el firewall, en la frontera entre la red interna y la red externa (de ahí su nombre, “Border Sessión Controller”), pero a un nivel más interno que el firewall, normalmente en una red intermedia entre el firewall y la red interna, o DMZ (“Zona Desmilitarizada” ).

El SBC no se limita a monitorizar y controlar las sesiones entre la red interna y la externa, sino que las reconstruye para tener un control total. Cuando se ha de establecer una sesión desde la red interna hacia la red externa, en realidad se establecen dos sesiones. Una, desde el elemento interno hacia el SBC; y otra, desde el SBC hacia el elemento externo. El SBC negocia los parámetros de la llamada de forma diferenciada hacia ambos extremos. Con ello se consigue no solo un total control de las sesiones (quién se puede conectar, a dónde, cuándo, cómo…) y la detección de ataques, sino también la ocultación de la red interna de cara al exterior. Esta es una de las funciones básico del SBC, y recibe el nombre de Back to Back User Agent (B2BUA).

Características y funciones

Aunque la seguridad suele ser la característica principal de un SBC, no es ni mucho menos la única. Entre otras funciones, el SBC también se suele encargar de:

  • La interoperabilidad: asegurar el establecimiento de sesiones, incluso en el caso de  elementos de la red interna y externa con señalizaciones distintas (por utilizar diferentes versiones de SIP, por requerir en uno de los lados una seguridad adicional, o por utilizar protocolos de señalización distintos).
  • La gestión del plan de numeración: permitiendo conexiones legítimas y evitando intrusiones y ataques.
  • La transcodificación: Adaptación de codecs en caso de que el códec usado por la sesión interna y por la sesión externa no coincidan.
  • El control de Admisión: limitar el número de sesiones establecidas para no sobrepasar el límite soportado por la línea WAN.
  • La conectividad de usuarios remotos: por ejemplo mediante VPN.
  • La gestión de la Calidad del Servicio.

De la necesidad surgieron los SBC, que sorprendieron a los organismos de estandarización con el paso cambiado, lo que dio lugar a cierta ambigüedad acerca de sus funciones y límites. Inicialmente los SBC eran máquinas dedicadas situadas en las fronteras entre redes de proveedores hacia clientes o hacia internet, que evolucionaron hacia una virtualización, en ocasiones integrada con firewall y routers. En la actualidad es común desplegar funciones de SBC incluso en sedes remotas para proteger la red interna de la sede, especialmente en aquellas con conexión directa a internet.

SBC en Teldat

Los routers Teldat implementan un SBC completo y avanzado mediante diversas funciones incluidas en el software, como la funcionalidad B2BUA, que permite un control absoluto de las sesiones de voz sobre IP que se establecen entre la red interna y la red externa, garantizando interoperabilidad y seguridad, junto a otras funcionalidades,  como: IPSec y securización de las sesiones de voz RTSP, TLS y SRTP, control total de la calidad de servicio IP, control de admisión de llamadas de voz sobre IP según diversos parámetros, tabla de enrutado/filtrado de llamadas o selección de codecs.

Marcel Gil: Ingeniero en Telecomunicaciones y Máster en Telemática por la Universidad Politécnica de Catalunya, es Responsable de la línea de negocio SD-WAN en Teldat

Redes Privadas Virtuales, tipos y características

¿Qué es una Red Privada Virtual? ¿Cuántos tipos de RPV existen, y para qué se utilizan? ¿Cómo elegir el tipo más adecuado para responder a necesidades específicas? Hoy respondemos a estas y otras preguntas

Una Red Privada Virtual (RPV), en esencia, consiste en usar una red (IP), normalmente pública, pero con un nivel de abstracción tal que se usa solo como mecanismo de transporte entre extremos, y que servirá para construir una red privada. Pero el hecho de usar una red pública conlleva la necesidad de extremar la seguridad en las comunicaciones. Así, ambos conceptos, RPV y seguridad, tienden a fundirse en uno solo, independientemente de que el núcleo de la red que proporciona conectividad sea público o privado. A tales efectos, las conexiones entre los puntos reciben el nombre de “túneles”, precisamente porque ocultan la información privada que viaja a través de la red pública.

Dado que la seguridad, como decíamos, es un factor clave en las comunicaciones, es necesario conocer los distintos tipos de RPV. Solo así se puede elegir, con conocimiento de causa, cuál es el que mejor se adapta a cada escenario en concreto. Pero no todo el mundo posee conocimientos avanzados en IT como para sopesar la información relevante. Uno de los problemas, es orientarse entre la maraña de acrónimos asociados a las RPV, tan crípticos que pueden suponer una barrera infranqueable para la comprensión (GRE, L2TP, IPSec, DMVPN, GDOI, SSLVPN, WebVPN, y un largo etcétera).

En Teldat nos hemos propuesto desmenuzar estos tecnicismos en la medida de lo posible, explicándolos para que todo el mundo, con independencia de sus conocimientos técnicos, pueda entender lo que está en juego, y sea capaz de orientar sus decisiones.

RPV a nivel de red

Consiste en la implementación de la Red Privada Virtual a nivel 3 de la capa OSI, esto significa que máquinas y aplicaciones a ambos lados del túnel se ven entre ellas exactamente igual que lo harían mediante una conexión directa. Este tipo de RPV es transparente a cualquier protocolo y aplicación.

  • GRE (Generic Router Encapsulation) y L2TP (Layer 2 Tunneling Protocol) son protocolos sencillos que permiten construir Redes Privadas Virtuales a nivel de red, si bien a pesar de ser protocolos perfectamente estandarizados y de probada compatibilidad, no se ha desarrollado sobre ellos un nivel de seguridad suficiente. Por esa razón, no son ampliamente usados, más que como un protocolo auxiliar para la interconexión de la RPV.
  • IPSec (Internet Protocol Security) es una alternativa estándar sobre la que sí se ha desarrollado un nivel de seguridad adecuado. De hecho, es el estándar en protocolo de seguridad en RPVs y, por tanto, es usado ampliamente en los routers de la periferia de red.
  • DMVPN (Dynamic Multipoint Virtual Private Networks) es una arquitectura de RPV basada en el uso simultáneo de GRE e IPSec. El primero (GRE), es usado para la conectividad, mientras que el segundo se emplea para la seguridad. Aquí, la principal ventaja de GRE es que permite enviar información de routing, de modo que los extremos del túnel se informan entre ellos de las redes privadas, lo cual reduce el esfuerzo de configuración para construir RPV. Y lo hace reduciendo el número de puntos: DMVPN se basa en uno, central (Hub) al que se conectan el resto de puntos remotos (Spokes), y que distribuye la información de routing entre todos ellos. DMVPN está basado en la RFC2332 NBMA Next Hop Resolution Protocol (NHRP).
  • GETVPN (Group Encrypted Transport Virtual Private Networks) or GDOI (Group Domain Of Interpretation) es un mecanismo adicional a IPSec, que facilita la gestión de claves. También basado en RFC e interoperable, se basa en un servidor central que genera y envía claves a todos los puntos. GETVPN no realiza túneles, razón por la cual, solo funciona si el direccionamiento de los hosts es público.

Los routers de las oficinas remotas establecen RPV a nivel de red, de forma transparente a las máquinas de la red local, aunque también es posible encontrar implementaciones (IPSec y L2TP, principalmente) en hosts, bien como parte del sistema operativo (Windows, Linux, Android, iOS), bien como servicios de red adicionales desarrollados por terceros.

RPV a nivel de aplicación

Se implementan estableciendo una Red Privada Virtual sin que los routers intermedios, ni la pila de red del host, intevengan en el proceso. Se basa en el protocolo SSL (Socket Security Layer) desde una sesión HTTP. En su versión más básica (clientless), el servidor SSL mantiene, a través de la red pública, una sesión segura con el navegador HTTP del cliente, y presenta recursos de la red interna (aplicaciones, servidores de ficheros, etc.) en formato web. Por esa razón, recibe el nombre de “HTTP Reserve Proxy”.

Una versión más avanzada (Full Network Access), descarga en el cliente un applet que crea interfaces virtuales para interceptar el tráfico privado a intercambiar entre el cliente y la red privada. De este modo, se consigue establecer, de forma efectiva, una RPV entre el host y la red privada conectada al servidor.

SSL es una implementación original de Netscape. La versión 3.0 ha sido estandarizada por IETF, adquiriendo el nombre de TLS 1.0 (Transport Layer Security). La parte estandarizada comprende el protocolo de seguridad, pero no las funcionalidades HTTP Reserve Proxy, ni los applets, que son propietarios.

Qué Red Privada Virtual es mejor

Depende de las necesidades a satisfacer. Las Redes Privadas Virtuales, a nivel de aplicación, son la solución para interconectar de forma individual una máquina, desde cualquier punto de la red pública, fuera de las oficinas. Por ejemplo usuarios móviles que se conectan con sus dispositivos portátiles desde internet (PCs, tablets, teléfonos, etc.) o incluso desde PCs públicos. Los servidores de RPV a nivel de aplicación suelen encontrarse en las oficinas centrales, y no en los routers de acceso.

Para establecer RPVs entre distintas sedes de una empresa la solución son las RPVs a nivel de red desde los routers de acceso de cada sede, donde IPSec es el estándar de facto.

Teldat es líder en interoperabilidad en tecnologías de RPV de red (L2TP, GRE, DMVPN, GETVPN e IPSEC). Le ofrecemos el asesoramiento que necesite sobre RPV de red. Contamos con amplias referencias por parte de grandes clientes. Porque la mejor forma de ganarnos su confianza, es ofrecerle un servicio de élite.

Marcel Gil: Ingeniero en Telecomunicaciones y Máster en Telemática por la Universidad Politécnica de Catalunya, es Responsable de la línea de negocio SD-WAN en Teldat

Routers y servidores para aplicaciones onsite

routers and servers for branch offices La evolución meteórica de las comunicaciones corporativas es un hecho. Hace unas décadas, los terminales “tontos”, se conectaban al mainframe mediante líneas punto a punto. Esto, que podría parecernos cosa del pleistoceno, era lo último en tecnología hace unas décadas. Las redes X25, Frame Relay o ISDN supusieron un importantísimo avance para las comunicaciones corporativas. Pero si esta tecnología supuso un salto evolutivo similar al descubrimiento del fuego, las redes IP podrían equipararse a la invención de la rueda.

Ahora, las conexiones de alta velocidad como DSL y fibra constituyen, ¡una auténtica “revolución industrial” de las comunicaciones! Y por último, evolucionamos sin olvidarnos de nuestros orígenes: si los antiguos pensaban que la sabiduría se encontraba en las divinidades que habitaban los cielos, nosotros tenemos la información alojada “en la nube”.

Las metáforas que hemos empleado no son casuales. Hablamos de evolución tecnológica. La virtualización es el próximo horizonte por conquistar.

El “Cloud Computing” y su implementación en las empresas

La expansión del Cloud Computing es la asignatura pendiente en las comunicaciones. Pero sin duda alguna, cobrará más fuerza cada vez. Prueba de ello es la forma en la que su uso se ha ido generalizando en las comunicaciones residenciales, con aplicaciones como Google Apps, Microsoft Office 365 o Dropbox. Y es que las comunicaciones residenciales suelen ir por delante de las corporativas, algo que podemos corroborar con ejemplos como la conectividad ADSL, FTTH o 4G.

Lo único que todavía genera dudas respecto a la propagación de la virtualización en el contexto corporativo, es si la nube en las empresas será pública, privada o híbrida, o el ritmo de migración que experimentaremos en los próximos años. Pero es un hecho que la virtualización está aquí, ¡y ha venido para quedarse.

Ventajas de la virtualización en empresas

La virtualización tiene ventajas obvias. Veamos algunas de ellas.

Reducción CAPEX y OPEX en la periferia de la red, debido a la centralización de recursos hardware y software en la nube.

  • Evidente mejora en el control.
  • Seguridad y fiabilidad en los datos y aplicaciones.
  • Incremento de la flexibilidad en la provisión de recursos.
  • Mayor control de licencias.

Pero no seríamos justos si no reconociéramos ciertas dificultades.

Problemas a los que se enfrenta la virtualización

La evolución en las aplicaciones en la nube no está exenta de complejidad. En primer lugar, los requisitos de conectividad para lograr una buena experiencia de usuario son más exigentes que en el caso del almacenamiento y procesamiento local. Como consecuencia de ello, hay que prestar especial atención a aspectos como la redundancia, la seguridad y la optimización del enlace de acceso a la red. En segundo lugar, determinadas aplicaciones con un trasiego de datos importante en modo local, como cartelería dinámica o gestión de contenidos, no escalan bien hacia la nube. Aquí el problema consiste en que ya no disponemos del servidor local para solventar la situación. Lo mismo ocurre cuando necesitamos conectar dispositivos no-IP, como impresoras, alarmas, control de accesos, cámaras web, etc.

¿Qué podemos hacer para sortear estos obstáculos?

El “router” como solución a diversos problemas en computación en la nube

Así es: el router, ¡importa! No se trata de algo banal en absoluto. La experiencia de usuario depende de su eficacia y estabilidad. Esto nos lleva a plantearnos una pregunta fundamental: ¿Qué rol ha de desempeñar el router en los nuevos escenarios surgidos del Cloud Computing?
Quizá se entienda mejor la cuestión si reformulamos la pregunta en otros términos: ¿Podría el router ampliar su radio de acción para adaptarse a las necesidades requeridas por el Cloud Computing?  Como habréis  observado, ahora la forma de plantear la pregunta nos da pistas sobre la dirección a seguir para ofrecer una respuesta.
El router conecta usuarios y aplicaciones, centralizando el tráfico y, por tanto, el proceso de datos. Su posición estratégica le permite aportar un plus de seguridad y optimización necesarios, y convertirse en la extensión de las aplicaciones en la nube que interactúan con los dispositivos locales.
La única cuestión que nos quedaría por resolver es: ¿tiene el router capacidad de almacenamiento y procesamiento, así como herramientas de gestión que permitan realizar procesos locales de forma fiable? En el pasado no nos planteábamos todo esto. Dichas prestaciones eran nulas o muy limitadas. En el mejor de los casos, se limitaban a soluciones artificiales que integraban una unidad de proceso (mini-PC) en el chasis.
En la actualidad existen soluciones convergentes basadas en procesadores multicore, que integran en un mismo soporte físico dos dispositivos virtuales (router + servidor), cada uno con su software y su sistema operativo independiente, orientado a una u otra tarea. También incluyen almacenamiento HDD o SSD, e interfaces USB para dispositivos locales.
Los routers de Teldat, Cloud Ready, se adecúan a las necesidades surgidas en la era de la computación en la nube, gracias a la integración de aplicaciones que ya no pueden correr en servidores locales. Los ejemplos más claros son los siguientes:

  • Seguridad: antivirus, sondas SIEM, antispam, filtrado de contenidos, etc.
  • Optimización: webcache, videoproxy, NAS replicado en la nube, repositorio para escritorios virtuales…
  • Auditoría local o cartelería dinámica: basada en DLNA

¿Estamos preparados para la era del Cloud Computing? La respuesta es, ¡sí!

Marcel Gil: Ingeniero en Telecomunicaciones y Máster en Telemática por la Universidad Politécnica de Catalunya, es Responsable de la línea de negocio SD-WAN en Teldat