Seção: Guia

Conforme estudo de caso realizado por Ramirez, constatou-se grande numero de vulnerabilidades em uma arquitetura IPTV. O número de informações contido em uma oferta específica de serviço de IPTV pode variar, pois o serviço de diferentes prestadores terão arquiteturas de rede diferentes como o tipo de acesso à rede, xDSL, cabo, fibra. Estas vulnerabilidades encontram-se nas camadas de aplicações, serviços, e infraestrutura, conforme é ilustrado na figura 4.

Figura 4: Pontos de ameaças em uma arquitetura IPTV

Fonte: (Adaptado de RAMIREZ, 2008)

Dentre as ameaças ao IPTV, podemos citar:

• Acesso não autorizado aos elementos do ambiente;
• Negação de serviço (DOS);
• Vulnerabilidades do sistema operacional e ataques de aplicação;
• Sistema operacional sem implementação de patches de segurança;
• Presença de aplicativos e serviços desnecessários;
• Existência de contas de usuário desnecessárias;
• Política de restrição de senha;
• Falta de arquivos de log;
• Auditoria desativada;
• Implementação de controles de acesso deficiente;
• Lista de aplicações autorizadas;
• Arquivo padrão e falta de controle de permissões de pastas.

Autenticação

O acesso a conteúdos e serviços deve ser fornecido somente para usuários autorizados. Prestadores de serviços de IPTV podem validar cada um dos set top box e verificar se esses elementos particulares representam assinantes autorizados ou não autorizados.

O DRM não é a única linha de defesa. Ambientes de IPTV tem na autenticação de rede e na autorização a primeira linha de defesa. Isto é feito no nível DSLAM, e a segunda linha é fornecida pelo middleware por meio da autenticação nesse servidor, contando com o DRM para fornecer o terceiro nível de proteção (RAMIREZ, 2008).

Detecção e Prevenção de Intrusão (IDS/IPS)

Todo sistema de segurança tem como princípio básico o monitoramento. Desse modo, todo o tráfego de dentro do ambiente de IPTV, deve ser monitorado para detectar possíveis ataques conhecidos e/ou tentativas de intrusões.

Embora firewalls e Access Control Lists (ACLs) sejam implantados em todo o ambiente de IPTV, a redução dos tipos de protocolos e das sessões permitidas é importante para manter as regras sobre o IDS/IPS, responsáveis pela detecção de sessões em portas e serviços que foram bloqueados pelo firewall.

A partir do IDS/IPS existem diferentes sistemas críticos que devem ser protegidos. São eles:

• O repositório de vídeo que contém os ativos mais valiosos e qualquer intrusão pode causar perdas significativas para os prestadores de serviços de IPTV;
• O Servidor DRM que é responsável por disponibilizar as chaves de criptografia para todos os conteúdos. Intrusos estarão interessados em roubar as chaves ou abrir conteúdo criptografado ou, até mesmo, para falsificar comunicações para set top boxes;
• O Servidor de middleware, identificado como o elemento central na operação da plataforma sendo um dos primeiros alvos dos atacantes, uma vez que permite a comunicação de todos os decodificadores;
• O servidor de streaming de vídeo e VOD que, também, aceitará comunicações de set top boxes, contudo, apenas em portas limitadas. Os atacantes podem planejar enviar negação de serviço.

Como alvos secundários, com menos exposição e com acesso mais difícil por intrusos, os seguintes sistemas também poderiam ter um Host-Based Intrusion Detection System (HIDS). Desse modo temos:

• O encapsulador MPEG;
• O transcoder;
• O servidor de gerenciamento de conteúdo;
• Os servidores de negócios.

Do ponto de vista da rede, os switches podem ser configurados para espelhar todo o tráfego na interface ligada ao IDS/IPS. Isto irá facilitar a detecção e contenção de ataques.

Firewalls de Rede

Devem ser utilizados para controlar o tráfego dentro do head-end.

O fluxo de tráfego entre os servidores dentro de uma VLAN é conhecido e, portanto, um firewall de rede ou um mecanismo equivalente, podem ser implantados para garantir que apenas os pedidos válidos serão transmitidos.

Prevenção de Fraudes

Qualquer serviço de IPTV deve ter recursos de prevenção de fraude, capazes de impedir o abuso do ambiente por assinantes ou fraudadores privilegiados.

Nesse sentido, existem elementos diferentes que podem participar na prevenção e detecção de fraudes. São, portanto:

• O middleware que pode relatar atividades de assinantes e detectar quando o mesmo assinante está solicitando conteúdo usando dois endereços IP separados;
• O servidor de middleware capaz de detectar quando um set top box está solicitando um número muito elevado de títulos de VOD;
• O servidor RADIUS que pode detectar quando o assinante está solicitando acesso a partir de dois diferentes endereços IP, sinalizando que esses tais IPs estão em DSLAMs separados. Este mecanismo pode sugerir a clonagem set top box.
• O DSLAM responsável por detectar quando o mesmo assinante solicita o acesso a partir de duas diferentes linhas físicas (somente se ambos estão na mesma DSLAM);
• Os servidores de negócios e o servidor RADIUS, que podem executar a validação de usuários, estabelecendo se existem assinantes no sistema RADIUS que não tenham sido criados nos servidores (de cobrança, provisionamento, etc.);
• Vale lembrar que, em geral, auditorias devem ser realizadas para confirmar se todos os elementos de IPTV têm o mesmo número de assinantes e se qualquer anomalia deve ser investigada. Uma fraude interna pode ser detectada para comparar registros e encontrar novas contas que foram criadas;
• Os servidores de negócios e o servidor de middleware capazes de executar validações de usuários, estabelecendo se existem quaisquer assinantes de comunicação com o servidor de middleware que não tenham sido criados no servidor de negócios;
• É mister salientar que, servidores DSLAM podem relatar para os servidores de negócios títulos unicast recebidos por assinantes. Esta informação pode ser combinada com os registros de faturamento para determinar se houve manipulação do sistema.

Encapsulador IP

Uma VLAN deve ser configurada com lista de controle de acesso, filtrando a origem e o destino, para permitir que o encapsulador IP receba dados a partir do MPEG e se comunique com o servidor de DRM, gestão de conteúdo e repositório de vídeo. Todo o acesso administrativo deve ser feito usando canais de comunicação seguros (como SSH, TLS, SSL e SNMPv3), além de possuir meio de inclusão de identificação, autenticação e autorização de usuários e sistemas que têm acesso para o encapsulador IP (RAMIREZ, 2008).

Em geral a maioria dos servidores dentro do head-end são protegidos por seis camadas de segurança, formadas principalmente por mecanismos independentes. É essa estrutura que aumentam os controles e reduzem as chances de fraude.

A primeira camada, mais externa, é formada pelos firewalls e IDS/IPS. Estes proporcionarão os controles de acesso entre as funções principais e de intercâmbio, bem como proteção contra ataques conhecidos, tais como vírus e worms.

A segunda camada compreende a VLAN estabelecida nos switches, que permitem somente hosts pré-aprovados para ingressar na rede. Desse modo, os servidores terão uma placa de rede destinada para a VLAN administrativa e placas de rede para várias outras VLANs de acordo com as necessidades essenciais de comunicação. Assim, o acesso à VLAN é controlado no endereço MAC da placa de rede ou no endereço IP da máquina.

A terceira camada é formada pela lista de controle de acesso no comutador. Na maioria dos casos, a comunicação será iniciada por um host e aceita pelo host de destino. Por exemplo: o servidor de encapsulamento IP, não será capaz de enviar pacotes para o Simple Mail Transfer Protocol (SMTP) da porta do servidor de gerenciamento de conteúdo. Nesta perspectiva, os consoles administrativos terão acesso mais flexível com os servidores, mas será validado pelo firewall.

A quarta camada é formada pela encapsulação fornecida dos protocolos seguros. Dito de outra forma é basicamente um túnel estabelecido entre hosts usando SSL, TLS, SSH, SNMPv3 ou canais de comunicação seguros que vão proteger a sessão de interceptação e modificação, bem como reduzir as chances de um ataque man-in-the-middle.

A quinta camada é constituída por os mecanismos de segurança específicos executados pelo software fornecedor que criou a aplicação em particular. Na maioria dos casos, as aplicações irão solicitar credenciais antes de permitir acesso como usuário ou administrador e atribuirão diferentes perfis de usuários.

A sexta camada é constituída pelo hardening da plataforma, o que inclui os patches e configurações do sistema operacional, seguindo as recomendações do fabricante.

Diante disso, por esta abordagem em camadas, torna-se muito difícil tomar o controle de elementos dentro do head-end.

Firewall de Aplicação Web

Os blocos de firewall de aplicação web de acesso a todas as páginas não autorizadas estão dentro do sítio do servidor do DRM e bloqueiam também as solicitações que não estejam em conformidade com os valores pré-aprovados ou estruturados. Nesse sentido, respostas serão também pré-validadas e qualquer resposta anormal será bloqueada.

Um exemplo: seriam intrusos enviando um ataque de injeção SQL contra o servidor. Esta seria uma solicitação usando personagens que não fazem parte da estrutura pré-aprovado. O firewall de aplicação web irá bloquear o pedido e nenhum pacote será encaminhado para o servidor DRM. Mesmo que um ataque passe a resposta de uma injeção SQL, não estaria em conformidade com a resposta do DRM padrão, e, portanto, seria bloqueada (RAMIREZ, 2008).

O DRM vai ter uma placa de rede dedicada para se comunicar com o firewall de aplicação web firewall, permitindo que as seis camadas de proteção sejam aplicadas.

Servidor Streaming de Vídeo

O servidor de streaming de vídeo recebe o conteúdo criptografado a partir de qualquer repositório ou o vídeo diretamente do DRM de forma criptografada. Uma VLAN dedicada pode ser configurada para estes elementos se comunicarem. Com esta abordagem, a VLAN irá proporcionar um ambiente seguro onde apenas os sistemas esperados estarão trocando informações.

É importante, pois, seguir as seguintes recomendações:

• Desativar login anônimo de FTP;
• SFTP (ou seja, FTP seguro) deve ser usado em vez de FTP;
• Configurar ACLs nas interfaces do firewall para bloquear pacotes SFTP provenientes de interfaces ou com endereços IP desconhecidos.

IGMPv2/v3

O tráfego multicast proveniente do head-end encapsulados no interior de VLANs deve ser protegido contra modificação não autorizada. Uma alternativa, é o uso de um cabeçalho de autenticação IPsec. Após sua implantação a IPSec fornecerá autenticação e proteção de integridade.

O IPSec Authentication Header (AH) é usado para fornecer integridade sem conexão e autenticação de origem dos pacotes, reduzindo a exposição a ataques de repetição. Ainda, o IPsec AH podem ser usados em conjunto com IP Encapsulating Security Payload (ESP) fornecendo proteção do payload.

Os firewalls podem ser configurados para bloquear qualquer tráfego que não é IGMPv2/v3 proveniente de endereços de transmissão autorizados. Para evitar ataques DOS, recomenda-se que IGMPv3 seja utilizado. Todos os gateways residenciais e set top boxes que recebem pacotes IGMP devem ser verificados e descartados, se o endereço MAC Ethernet não é um endereço multicast válido (DUQUE,2008).

Protocolo RTP

Para reduzir a exposição aos pacotes falsos ou modificados do Real Time Protocol (RTP),o Secure Real-Time Transport Protocol (SRTP), deve ser usado no lugar do protocolo RTP, uma vez que fornece proteção de integridade e autenticação na forma de um HMAC-SHA-1, para os pacotes RTP e RTCP (GILBERT, 2007).

A especificação do Secure Real-Time Transport Protocol (SRTP) fornece confidencialidade através de criptografia de autenticação de mensagens e proteção replay para RTP e RTCP.

Recomenda-se, portanto, que ACLs sejam configuradas em interfaces de firewall para bloquear pacotes RTP/SRTP originários de interfaces impróprios ou com endereços IP impróprias fonte. Além disso, para evitar a possibilidade de captura de pacotes RTP em trânsito, o SRTP deve ser usado, uma vez que fornece a criptografia na forma de AES para pacotes RTP e RTCP.

Pacotes RTSP

Para evitar ataques por meio de pacotes não autorizados de RTSP, adota-se a autenticação RTSP (Shared Secret) ou autenticação Digest (MD5) habilitada em servidores VOD e interfaces STB. Além disso, é importante proteger os pacotes RTSP com Ismacryp (i.e. ISMA 1.1).

O Ismacryp usa SRTP para fornecer tráfego com autenticação, integridade e criptografia. Para uma proteção adicional contra o acesso não autorizado DOS é importante configurar ACLs nas interfaces de firewall para bloquear mensagens RTSP transportando pacotes RTSP originários de interfaces desconhecidas ou com endereços IP de origem duvidosa.