PBX IP - Publicación de Servicios SIP (NAT)

Porfavor, LEA DETENIDAMENTE esta guía para no dejar pasar ningún aspecto importante.

Introducción:

Publicar los servicios SIP (VoIP) de una PBX IP hoy en día suele ser una práctica muy común para brindar mayor flexibilidad a las empresas en cuanto a contectividad con su proveedor de telefonía y sus comunicaciones internas. Sin embargo, hoy en día también es una práctica común el "hacking" de PBX IP por personas desconocidas lo cual genera a fin de mes una sorpresa en la factura del servicio de telefonía. Aquí detalaremos las recomendaciones para la adecuada publicación de servicios VoIP.

Diagrama ~~conceptual:~~conceptual de publicación de servicios:

PBX2: Es la sede o ubicación ejemplo donde se publican servicios VoIP mediante un NAT de todos los puertos de una IP pública.

Vulnerabilidades:

Si configuramos una IP pública drectamente en la PBX (sin uso de NAT o firewall) estamos exponiendo todos los puertos de la PBX, los cuales pueden tener vulnerabilidades que hasta puedan estar documentadas en CVE's oficiales.(https://cve.mitre.org/)

Es por ello que se han desarrollado equipos destinados a dar la cara por las PBX IP y ser ellos los que reciben ataques y previenen a la PBX de recibirlos directamente. No son firewalls tradicionales, ni routers, se llaman: Session Border Controllers los cuales aparte de contar con características de seguridad y prevención tienen capacidad de manejar codificación del audio para ajustes en el ancho de banda y evitar transcoding dependiendo de la complejidad del entorno VoIP.

Sin embargo, estos equipos por costo suelen ser poco aceptados y los clientes prefieren realizar una publicación de servicios SIP mediante firewalls tradicionales, es por ello que hemos creado una sección en esta guía con ~~sus~~las recomendaciones y advertencias.

~~Recomendaciones:~~Alternativas:

Existen alternativas si no se puede adquirir un SBC para la publicación de servicios, una de ellas es realizar un NAT de los servicios VoIP utilizando un firewall que pueda tener cierto control y monitoreo de ataques básicos (no VoIP). Si esta es la elección, recomendamos realizar los siguientes cumplimientos:

Cambiar contraseñas de las extensiones con longitud de 12 dígitos mínimo (de preferencia 16 dígitos), incluyendo al menos cuatro mayúsculas intercaladas entre cinco números y varias minúsculas. NO utilizar: palabras diccionario o relacionadas al país o negocio, tampoco relacionadas a la extensión o que lleven correlativos alfanuméricos.
NO publicar servicios administrativos HTTP para la PBX, solo VoIP.
Mantener activas las políticas de Fail2Ban para que los intentos fallidos sean bloqueados y rechazados. Configurar el bloqueo al menos por 1 hora para intentos fallidos, si es factible aumentar el tiempo a un día mucho que mejor.
Mantener las claves administrativas de los teléfonos IP (equipos) de manera robusta (admin) pues es otra puerta para indagar contraseñas SIP.
SI es viable, implementar llamadas mediante el uso de TLS para tráfico RTP.
Habilitar la administración de la PBX (Web, ssh, etc) sólo para un rango de IP's de la red interna, para evitar vulnerabilidades mediante el uso de robots anidados en la red interna de la PBX (PC's, teléfonos, etc).

Pueden configurarse contraseñas con símbolos, esto es muy recomendado, pero ciertos equipos de telefonía no lo soportan, por lo que se deja como una opción deseada y la que se recomienda probar.

Configuraciones Técnicas: Mediante NAT o Port Forwarding se redireccionan los siguientes puertos:

Puerto: UDP 5060 hacia la IP interna de la PBX IP para permitir tráfico SIP en dicho puerto.
Puertos desde: UDP 10,000 hasta: 20,000 para permitir tráfico RTP en dichos puertos.

En Firewalls Fortinet: Deshabilitar el servicio de SIP ALG, consulte con el fabricante o su Ingeniero de Soporte sobre como deshabilitar dicho servicio.

Seguridad avanzada en Firewalls: En algunos firewalls como Watchguard o Fortinet, se permite el uso de funcionalidades de bloqueos mediante funciones pagadas o incluídas en la suscripción de los servicios estándar. Se recomienda implementar las funcionalidades siguientes:

Programar las políticas de Firewall donde se hace el NAT o Port Forwarding con horarios específicos de operación. Un ejemplo puede ser: Deshabilitar tráfico SIP a partir de las 20:00 horas de Lunes a Viernes y en ningún horario para fines de semana.
Bloquear tráfico de las políticas de Firewall donde se hace NAT o Port Forwarding para las IP's origen de otros territorios, paises o continentes. En Watchguard se denomina "Geolocation Block" y permite seleccionar los países de donde se puede recibir tráfico para dicha política. En Fortinet se denomina "Geo IP Black list" y permite seleccionar los países también. Más información con el fabricante o su Ingeniero de Soporte.

NOTA: NO publicar servicios web u otros puertos hacia la PBX IP, únicamente los servicios antes descritos. Si se publican más servicios o se hace un redireccionamiento completo se pueden vulnerar: Servicios Web, Servicios de Base de Datos, Servicios de Asterisk AMI, Servicios SSH y otros, dependiendo la plataforma de la PBX IP.

Advertencias:

Los servicios PBX IP publicados mediante IP pública son los destinos más buscados por los hackers, pues estos representan una “mina de oro” para ellos poder negociar con tráfico de llamadas internacional sin costo alguno.
Existen robots que operan 24x7 los cuales escanean IP’s constantemente para indagar que IPs atienden servicios SIP/VoIP y luego de detectar generan listas para que otros robots lancen ataques SIP para vulnerar cuentas y así poder aterrizar llamadas internacionales en una IP hackeada.
Es responsabilidad del cliente propietario de la PBX el cumplir con los lineamientos mínimos recomendados en seguridad de la IP PBX.
Es responsabilidad del cliente cualquier vulnerabilidad que haya sido explotada mediante hackings a su plataforma IP PBX, ya que la publicación de servicios es una práctica que debe ser protegida por Session Border Controllers (Firewalls SIP) y no por firewalls tradicionales, sin embargo se proveen aquí las alternativas para publicar los servicios y proveer la seguridad de la mejor manera posible mediante “mejores prácticas”.

Vox Datacomm, S.A.: NO se hace responsable por servicios vulnerados por terceras personas, tampoco se hace responsable del pago de facturas o servicios de telefonía del cliente final que ha sido vulnerado. La información aquí expuesta y compartida NO supone un compromiso o garantía de que la PBX IP será segura. El cliente o el lector de este documento es el único responsable por la gestión y administración de la PBX y de garantizar su seguridad.