Universidade de Aveiro Departamento de Electrónica, Telecomunicações e Informática Instituto de Telecomunicações

Transcrição

1 Universidade de Aveiro Departamento de Electrónica, Telecomunicações e Informática Instituto de Telecomunicações Ano Lectivo 2005/06 Projecto de 5ºano Serviços e Redes Residenciais Interfaces e Infra-estrutura de Suporte para Operadores e ISP Data limite de entrega: Sexta-Feira, 14 de Julho de 2006 Autores: Pedro Manuel Paupério Duarte Oliveira nº25381 LEET (a25381@alunos.det.ua.pt) José António Gonçalves Nogueira nº26223 LEET (a26223@alunos.det.ua.pt) Orientador: Prof. Dr. Francisco Fontes Colaboradores: Eng. Vítor Simões Ribeiro Eng. Vítor Pinto Eng. André Oliveira Eng. Ricardo Azevedo

2 Interfaces e Infra-estrutura de Suporte para Operadores e ISP ÍNDICE 1. Enquadramento pág 3 2. Objectivos pág 5 3. Introdução e Fundamentos Teóricos pág Protocolos relacionados com o projecto pág IP pág PPP pág PPPoA pág PPPoE pág DNS pág NAT pág AAA pág RADIUS pág HTTP pág FTP pág SIP pág Conceitos gerais pág O problema da Firewall pág O problema do NAT pág Métodos para resolver o problema do NAT pág Universal Plug and Play pág Simple Traversal of UDP Through Network Address Translation Devices (STUN) pág Application Layer Gateway pág Manual Configuration pág Tunnel Techniques pág Automatic Channel Mapping (ACM) pág Tecnologias de Acesso pág Dial-up pág RDIS (ISDN) pág BroadBand pág DSL (ADSL) pág Cable pág Wireless pág Wi - Fi pág WiMax pág FWA pág BWA pág Tmax pág xmax pág Ofertas Serviços Residenciais pág Trabalho Desenvolvido pág Apresentação do cenário a implementar pág FreeRADIUS e base de dados mysql pág Instalação do freeradius pág Configuração do freeradius para utilizar base de dados mysql pág Colocação dos utilizadores em base de dados mysql pág Criação do túnel PPP pág 50 1/115

3 Interfaces e Infra-estrutura de Suporte para Operadores e ISP 4.3. Dynamic DNS (DDNS) pág Instalação e configuração mhdns pág Instalação e configuração BIND pág Análise do funcionamento do servidor DDNS pág SIP Express Router (SER) pág Instalação do SER pág Introdução do SIPALG pág Permissões para segurança e restrição do acesso às câmaras pág Análise dos pacotes trocados numa sessão SIP pág Demonstração do funcionamento do SIP ALG pág REGISTER cenários possíveis pág INVITE cenários possíveis pág Demonstração do funcionamento do módulo permissions.so pág Criação do Centro de Serviços pág Captura das imagens e criação dos vídeos pág Implementação dos servidores HTTP e FTP pág Instalação e descrição do phpmyadmin pág Criação do portal web pág Análise do funcionamento do Centro de Serviços pág Principais Dificuldades pág Possíveis Melhoramentos pág Conclusões / Notas Finais pág Bibliografia / Referências pág Anexos pág Ficheiros de configuração do freeradius pág Radiusd.conf pág Clients.conf pág Ficheiros de configuração do SIP Express Router (SER) pág SER.cfg pág Porções de código relevantes associadas ao portal web pág Index.php pág Redirect.php pág Redirect2.php pág 115 2/115

4 1. ENQUADRAMENTO Serviços e Redes Residenciais Interfaces e Infra-estrutura de Suporte para Operadores e ISP Uma das áreas que tem vindo progressivamente a adquirir cada vez mais importância é, sem dúvida, a das telecomunicações. Cada vez mais se verifica um aumento das ofertas de serviços por parte dos operadores que procuram dessa forma abranger todo o tipo de clientes, sejam eles residenciais ou outros. A disponibilização de novos serviços cria nos consumidores apetência a novas necessidades. Daí o esforço demonstrado por parte dos operadores de telecomunicações e ISP no desenvolvimento de soluções atractivas que possam satisfazer essas mesmas necessidades. Muito se tem falado sobre a convergência das redes de comunicações mas só recentemente começamos a ver na prática a utilização deste modelo. Esta nova estrutura de rede baseada na tecnologia IP, capaz de suportar para além dos serviços tradicionais de tráfego de dados, o transporte de áudio (ex: Voz, rádio, ) e imagem (ex: TV, vídeo conferência, vídeo vigilância, ) sobre o mesmo suporte está associada ao conceito de triple play muito em voga nos dias de hoje. No caso residencial, áreas como a domótica e a vídeo-vigilância começam a adquirir uma importância crescente. Aliados a este tipo de serviços temos vários aspectos para além da simples conectividade IP, tais como segurança, qualidade de serviço, interligação entre redes heterogéneas, entre outros, os quais não deverão ser descurados. Outros aspectos, como a pluralidade de tecnologias de rede de acesso existentes actualmente e a sua incidência no mercado alvo, devem também ser tomados em consideração aquando do lançamento de novas ofertas. Alguns temas como padrões de compressão, formas de codificação, entre outros ainda necessitam de ser analisados com vista a permitir interoperabilidade entre equipamentos de fabricantes ou tecnologias diferentes. No entanto, tudo não passará duma questão de tempo atendendo à própria pressão do mercado consumidor. 3/115

5 Interfaces e Infra-estrutura de Suporte para Operadores e ISP 4/115

6 2. OBJECTIVOS Serviços e Redes Residenciais Interfaces e Infra-estrutura de Suporte para Operadores e ISP Este projecto tem como objectivo o estudo, caracterização e posterior desenvolvimento de um cenário de teste relacionado com o aprovisionamento de serviços para clientes do tipo residêncial. Mais concretamente, pretendemos implementar um cenário simples de televigilância, não esquecendo de fazer um levantamento dos principais requisitos, dando especial importância à questão da segurança. Este projecto foi dividido em 2 partes, uma de pesquisa e outra de desenvolvimento, sendo que a segunda parte foi estruturada em 5 fases com vista a facilitar e melhorar a progressão do trabalho. Deste modo temos: 1ªPARTE Esta 1ª parte teve como objectivo a realização de uma pesquisa com vista à recolha de documentação relacionada com vários aspectos importantes para a realização do projecto. As principais áreas de trabalho foram: Estudo dos principais protocolos a utilizar; Identificação das várias tecnologias de rede de acesso existentes, quais as suas principais características e métodos de autenticação utilizados em cada uma delas; Determinação do grau de implementação do conceito de triple play no mercado actual e identificação das principais empresas que o fornecem; Análise das ofertas de serviços residenciais disponibilizadas actualmente e identificação dos operadores que as fornecem. Apresentação de sugestões relacionadas com o cenário a desenvolver (quais as entidades de rede e da plataforma de serviços que deverão estar presentes e como se deverão relacionar entre si). 2ªPARTE 1ªfase Esta fase inicial de desenvolvimento teve como objectivo a introdução do registo de utilizadores freeradius numa base de dados mysql, com vista a facilitar a introdução de novos utilizadores e consulta/actualização dos dados lá existentes sempre que tal seja necessário. 2ªfase Nesta fase foi implementado um servidor de dynamic DNS com vista a manter actualizada a correspondência entre nomes e máquinas resolvendo possíveis problemas relacionados com a renovação dos endereços IP e a atribuição dinâmica dos mesmos. 3ªfase Esta fase teve como primeiro objectivo a instalação, configuração e teste do servidor SIP designado por SER (SIP Express Router) da iptel. Posteriormente tratamos de resolver os problemas relacionados com o NAT. Para tal instalamos o SIPALG (Application Layer Gateway). Nesta fase estabelecemos ainda um cenário simples de teste para a comunicação entre 2 terminais (um na rede privada e outro na rede pública). 5/115

7 Interfaces e Infra-estrutura de Suporte para Operadores e ISP Numa fase mais avançada introduzimos instruções suplementares no ficheiro de configuração do SER com vista a restringir o acesso ao servidor e às diferentes câmaras por parte dos utilizadores e deste modo garantir a segurança deste serviço. 4ªfase Esta fase teve como objectivo a criação de um portal web seguro que funcionasse como alternativa à utilização do protocolo SIP. Associado a este portal web está o conceito de centro de serviços o qual os utilizadores poderão utilizar para acederem às suas câmaras. 5ªfase Esta última fase teve como objectivo a interligação dos vários blocos desenvolvidos anteriormente nas fases 1, 2, 3, e 4 e a demonstração do cenário criado. Implementamos um bloco BBRAS utilizando o servidor de autenticação freeradius o qual utiliza a informação presente nas tabelas da base de dados mysql que permitiu a criação dum túnel PPP para o acesso á rede por parte dos utilizadores. 6/115

8 Interfaces e Infra-estrutura de Suporte para Operadores e ISP 3. INTRODUÇÃO E FUNDAMENTOS TEÓRICOS 3.1. Protocolos relacionados com o projecto IP O IP (Internet Protocol) é um protocolo pertencente à camada 3 do modelo OSI (ver figura 1) que contém informação de endereçamento e alguma informação de controlo que permite o encaminhamento de pacotes. O IP tem duas responsabilidades primárias: fornecer conectividade (política de entrega de datagramas do tipo best effort através da rede) e permitir a fragmentação e reconstrução de datagramas para suportar ligações de dados com diferentes MTUs (maximum transmission units). Figura 1 Modelo OSI 7/115

9 Interfaces e Infra-estrutura de Suporte para Operadores e ISP Um pacote IP contém diversos tipos de informação. O conteúdo dum pacote IP encontrase representado na figura 2. Figura 2 Conteúdo dum pacote IP Version - Indica a versão do IP que está a ser usada. IP Header Length (IHL) Indica que o cabeçalho do datagrama tem um comprimento de 32- bit words. Type-of-Service Especifica como um protocolo de camada superior quer que o datagrama seja utilizado e atribui aos datagramas diferentes níveis de importância. Total Length Especifica o comprimento em bytes de todo o pacote IP (cabeçalho e dados). Identification Contém um inteiro que identifica o datagrama. Este campo é usado para facilitar a juntar fragmentos dum mesmo datagrama. Flags Consiste num campo composto por 3 bits dos quais os 2 menos significativos controlam a fragmentação. O bit de mais baixa ordem especifica se o pacote pode ou não ser fragmentado. O bit do meio especifica se o pacote é o último fragmento duma série de pacotes fragmentados.o bit de maior ordem não é utilizado. Fragment Offset Indica a posição dos dados fragmentados relativamente ao início dos dados no datagrama original. Isto permite a correcta reconstrução do datagrama original. Time-to-Live Mantém um contador que vaí sendo decrementado até zero, ponto no qual o datagrama é descartado. Protocol Indica qual o protocolo de camada superior que recebe os pacotes após o processamento IP estar completo. Header Checksum Ajuda a garantir a integridade do cabeçalho IP. Source Address Especifica o endereço origem. Destination Address Especifica o endereço destino. Options Permite ao IP suportar opções de diversos tipos. Data Contém informação de camada superior. 8/115

10 Interfaces e Infra-estrutura de Suporte para Operadores e ISP O endereçamento IP está relacionado com o routing dos datagramas IP através da rede. Cada endereço IP possui componentes específicos e segue um formato base. Os endereços IP podem ser ainda sub-divididos e usados para criar subredes. Cada terminal numa rede TCP/IP possui um endereço único de 32 bits (figura 3) que está dividido em 2 partes: uma associada à rede e outra associada ao terminal. A primeira, identifica a rede e tem de ser atribuída pelo InterNIC (Internet Network information Center) se se pretender que a rede faça parte da Internet. Um ISP pode obter blocos de endereços de rede a partir do InterNIC e atribuir espaço de endereçamento caso seja necessário. A segunda parte do endereço IP identifica o terminal numa determinada rede e é atribuída pelo o administrador de rede local. Figura 3 Formato dos endereços IP Existem 5 classes de endereços IP: A, B, C, D, e E. No entanto, apenas as classes A, B e C estão disponíveis para uso comercial. Na figura seguinte, encontram-se caracterizadas cada uma das 5 classes. IP Address Class Format Purpose A N.H.H.H 1 Few large organizations B N.N.H.H Medium-size organizations C N.N.N.H Relatively small organizations High- Order Bit(s) Address Range No. Bits Network/Host Max. Hosts to / (2 24-2) 1, to , 1, to / (2 16-2) 21/8 254 (2 8-2) D N/A Multicast groups 1, 1, 1, to E N/A Experimental 1, 1, 1, to Figura 4 Classes de endereços IP N/A (not for commercial use) N/A N/A N/A Inicialmente os endereços IP tinham fronteiras fixas, sendo a fronteira definida a partir dos primeiros bits do campo de endereço; é o caso dos endereços de classe A, B e C. Depois passaram a ter fronteiras flexíveis, sendo estas definidas a partir de uma máscara. A máscara é utilizada para separar a parte de rede da parte de host dos endereços. 9/115

11 Interfaces e Infra-estrutura de Suporte para Operadores e ISP Figura 5 Endereços IP e máscaras Como foi referido anteriormente, as redes IP podem ser divididas em redes mais pequenas denominadas subredes. A utilização de máscaras, permite que uma rede seja dividida em subredes estendendo a parte de rede à parte de host do endereço IP. Esta técnica aumenta o número de redes mas reduz o número de hosts. Se considerarmos a rede então e são exemplos de subredes pertencentes a A divisão em subredes fornece alguns benefícios ao administrador da rede como por exemplo, flexibilidade extra, maior eficiência no uso dos endereços da rede e capacidade de conter o tráfego broadcast. As subredes estão sob uma administração local. Deste modo, quem vê a rede pelo lado de fora nada sabe acerca da organização interna da mesma. Outro aspecto importante é o default gateway. O default gateway é configurado pelo utilizador. Corresponde ao endereço IP da interface de um dos routers que pertence à rede do terminal em que o utilizador se encontra e faz com que seja possível enviar um pacote IP para uma rede IP que não a sua. Os pacotes para essas redes serão assim enviados para o default gateway. Convém ainda fazer uma breve referência aos protocolos ARP e ICMP. O ARP (Address Resolution Protocol) é utilizado para determinar qual o endereço MAC de um terminal. Para tal é feito um broadcast dum pacote do tipo ARP request. O terminal com o endereço IP igual ao especificado no pacote ARP request irá responder enviando um pacote ARP response com o seu endereço MAC. O ICMP (Internet Control Message Protocol) permite a troca de mensagens de controlo e diagnóstico. Os pacotes ICMP são encapsulados nos pacotes IP. Os diferentes tipos de mensagens associadas ao ICMP estão representadas na figura seguinte. 10/115

12 Interfaces e Infra-estrutura de Suporte para Operadores e ISP Figura 6 Tipos de mensagens ICMP Apesar da versão actual do protocolo IP ser a v4, cada vez mais se tem falado do IPv6. O IPv6 é a futura versão do protocolo IP que se encontra actualmente em fase de desenvolvimento. É também conhecido por Ipng (Internet Protocol next generation). O IPv6 está a ser projectado como um upgrade do IPv4 e irá de facto coexistir com a antiga versão durante algum tempo. O IPv6 está a ser construído para permitir um crescimento firme da Internet, quer em termos do número de estações ligadas quer em termos de quantidade de tráfego de dados transmitido. Alguns dos principais benefícios do IPv6 são: maior espaço de endereçamento, existência de QoS interna, melhor performance e serviços de encaminhamento PPP O protocolo PPP (Point-to-Point Protocol), surgiu inicialmente como um protocolo de encapsulamento para transportar tráfego IP sobre ligações ponto a ponto. O PPP estabeleceu também um standard para atribuição e controlo de endereços IP, encapsulamento assíncrono e síncrono orientado ao bit, multiplexing do protocolo de rede, configuração da ligação, teste da qualidade da ligação, detecção de erros e negociação de opções para o acréscimo de capacidades de rede. Em computação, o protocolo PPP, é utilizado para estabelecer uma ligação directa entre dois nós. A sua primeira utilização foi ligar computadores usando a linha telefónica, embora seja também ocasionalmente usado sobre ligações broadband (como PPPoE ou PPPoA). Muitos ISPs utilizam o PPP para fornecerem dial-up access aos clientes. O PPP é habitualmente usado para funcionar como um protocolo de 2ªcamada (camada Data Link do modelo OSI) para ligações sobre circuitos síncronos e assíncronos. O PPP foi concebido para funcionar com vários protocolos da camada de rede como IP, IPX e AppleTalk, e como um substituto para o protocolo de 2ªcamada não-standard SLIP. O PPP fornece um método para transmitir datagramas sobre ligações ponto a ponto em série, o qual inclui os seguintes três componentes: um método para encapsular datagramas sobre ligações em série; um LCP (Link Control Protocol) extensível para estabelecer, configurar e testar a ligação; uma família de NCPs (Network Control Protocol) para estabelecer e configurar diferentes protocolos da camada de rede. 11/115

13 Interfaces e Infra-estrutura de Suporte para Operadores e ISP O PPP LCP fornece um método para estabelecer, configurar, manter e terminar a ligação ponto a ponto. O LCP pode ser dividido em quatro fases: Estabelecimento da ligação e negociação da configuração. Antes da troca de quaisquer datagramas, o LCP necessita de iniciar uma ligação e negociar os parâmetros de configuração. Esta fase será dada por completa quando uma frame configuration-acknowledgment tiver sido enviada e recebida. Determinação da qualidade da ligação (opcional). Nesta fase, a ligação é testada para determinar se a sua qualidade é suficiente para permitir protocolos da camada de rede. Negociação da configuração dos protocolos da camada de rede. Os protocolos da camada de rede são configurados separadamente pelo NCP. Se o LCP fechar a ligação, então ele informa os protocolos da camada de rede para que estes tomem a acção adequada. Terminação da ligação. O LCP pode terminar a ligação em qualquer instante. Esta acção ocorre geralmente em seguimento de um pedido por parte de um utilizador. No entanto, pode ocorrer em consequência de um evento físico como por exemplo a perda da portadora. Existem três classes de frames LCP: frames de estabelecimento da ligação - usadas para estabelecer e configurar uma ligação; frames de terminação da ligação usadas para terminar a ligação; frames de manutenção da ligação usadas para gerir a ligação. O PPP foi criado muito mais tarde que as especificações HDLC originais. Como resultado, os criadores do PPP incluíram muitas outras especificações que até aquela altura não tinham sido vistas em outros protocolos WAN Data Link PPPoA O protocolo PPPoA (Point-to-Point sobre ATM) é um protocolo para encapsulamento de frames PPP em ATM AAL5. É normalmente usado com um modem para cabo, e em serviços DSL e ADSL. Oferece funcionalidades PPP standard como autenticação, encriptação e compressão. Se for usado como método de encapsulamento da ligação em redes baseadas em ATM, pode reduzir ligeiramente o overhead (+/- 0.58%) em comparação com o PPPoE. Suporta ( tal como o PPPoE) os tipos de encapsulamento baseados em VC-MUX e LLC PPPoE O protocolo PPPoE (Point-to-Point sobre Ethernet) é um protocolo de rede para encapsular frames PPP em frames de Ethernet. É usado geralmente com um modem de cabo e serviços DSL. Oferece funcionalidades PPP standard como autenticação, encriptação e compressão. Permite usar software tradicional baseado em PPP para segurar uma ligação que não utiliza uma linha série mas sim uma rede orientada ao pacote, como a Ethernet, para fornecer uma ligação clássica com login e password para uma conta de ligação à Internet. 12/115

14 Interfaces e Infra-estrutura de Suporte para Operadores e ISP Também o endereço IP no outro lado da ligação é apenas atribuído quando a ligação PPPoE está aberta, o que permite a reutilização dinâmica do endereço IP DNS O DNS (Domain Name System or Server) é um serviço de Internet que faz a tradução de nomes de domínios (alfabéticos e mais fácil de lembrar) em endereços IP. A Internet é, no entanto, baseada em endereços IP o que significa que sempre que utilizamos um nome dum domínio, o serviço DNS vai traduzir o nome para o correspondente endereço IP. O sistema DNS é de facto uma rede própria. Se um servidor DNS não souber como traduzir um determinado nome de domínio, ele pergunta a outro e assim sucessivamente, até o respectivo endereço IP ser devolvido. Utiliza uma base de dados distribuída que proporciona um serviço de tradução de nomes de estações (hostnames) em endereços IP. Permite também traduzir endereços IP em nomes de estações. Os nomes são organizados em domínios de acordo com uma estrutura hierárquica. Cada sistema DNS define uma ou mais zonas sobre as quais tem a autoridade de resolução. Podemos ter 2 tipos de resoluções: resolução recursiva e resolução iterativa. Resolução recursiva: Mais eficiente: minimiza o tempo entre o pedido DNS e a resposta ao pedido. Penaliza o desempenho dos servidores DNS: cada servidor tem em média mais pedidos simultâneos em processamento. Figura 7 DNS Resolução recursiva Resolução iterativa: Menos eficiente: aumenta o tempo médio entre o pedido DNS e a resposta ao pedido. Optimiza o desempenho dos servidores DNS: cada servidor responde de imediato a cada pedido. Figura 8 DNS Resolução iterativa O DNS dinâmico é um sistema que permite que a informação relacionada com o nome de um domínio seja actualizada em tempo real. É geralmente utilizado para permitir a atribuição dum nome de domínio a um PC com endereço IP variável. Isto faz com que outros terminais 13/115

15 Interfaces e Infra-estrutura de Suporte para Operadores e ISP consigam estabelecer ligações com esse PC sem necessitarem de, eles próprios, determinar qual o endereço IP da máquina em questão. O serviço de DNS dinâmico é fornecido em larga escala por vários DNS hosting services, os quais retêm o endereço corrente numa base de dados e fornecem um programa cliente que enviará um update sempre que se verificar uma alteração do endereço IP. Muitos routers e outros componentes de rede contêm uma funcionalidade destas no seu firmware. Para implementer o DNS dinâmico é necessário definir o tempo máximo de cache do domínio com um período curto. Isto impede que outros nós da Internet retenham endereços desactualizados na cache DNS, fazendo com que eles contactem o name server do domínio para cada nova ligação NAT O NAT (Network Address Translation) surgiu como uma alternativa real para o problema da falta de endereços IPv4 na Internet. Cada computador que pretende acesser à Internet deve ter o protocolo TCP/IP configurado. Para isso, cada computador da rede interna, precisa de um endereço IP válido na Internet. Não existem endereços IPv4 suficientes. A criação do NAT veio de certo modo solucionar esta questão (ou pelo menos fornecer uma alternativa até que o IPv6 esteja em uso na maioria dos sistemas da Internet). Com o uso do NAT, os computadores da rede Interna, utilizam os chamados endereços privados. Os endereços privados não são válidos na Internet, isto é, pacotes que tenham como origem ou como destino, um endereço privado, não serão encaminhados. O protocolo NAT é portanto um standard da Internet que permite que uma rede local (LAN) utilize um conjunto de endereços IP para tráfego interno e outro conjunto de endereços IP para tráfego externo. Uma NAT box localizada no ponto onde a LAN está em contacto com a Internet efectua todas as traduções necessárias. O protocolo NAT serve três propósitos principais: fornecer uma espécie de firewall através da ocultação dos endereços de IP externos; permitir a uma corporação utilizar mais endereços IP internos (desde que eles sejam utilizados apenas a nível interno, não existe possibilidade de conflito com outros endereços IP utilizados por outras companhias e organizações) e permitir a uma companhia combinar múltiplas ligações ISDN numa única ligação à Internet. Quando um cliente interno tenta aceder à Internet, o NAT substitui o endereço interno do cliente (endereço de origem), por um endereço válido na Internet. Para além das mudanças em termos de endereços é também associado um porto de comunicação ao terminal. O NAT mantém uma tabela interna onde fica registrado que, a comunicação através do porto x está relacionada com o cliente x. Todos os endereços da rede interna são traduzidos para o mesmo endereço externo, porém com um número de porto diferente para cada cliente da rede interna. Quando a resposta retorna, o NAT consulta a sua tabela interna e, pela identificação do porto, ele sabe para qual computador da rede interna deve ser enviada a referida resposta, uma vez que cada porto está associado a um e só um endereço IP da rede interna. 14/115

16 Interfaces e Infra-estrutura de Suporte para Operadores e ISP AAA O protocolo AAA (Authentication Authorization and Accounting) é um protocolo de segurança que engloba autenticação, autorização e contabilidade. A autenticação está relacionada com a confirmação de que o utilizador que está a requerr um determinado serviço é um utilizador válido do serviço de rede que está a ser requisitado. A autenticação é realizada pela apresentação de uma identidade e credenciais (por exemplo password). A autorização refere-se aos tipos de serviço específicos que são concedidos a um utilizador tendo em consideração a sua autenticação, os serviços que foram requisitados e o estado do sistema actual. A contabilidade refere-se ao seguimento do consumo dos recursos da rede por parte dos utilizadores. Esta informação pode ser utilizada para controlo, planeamento, facturamento e outros propósitos RADIUS O RADIUS (Remote Authentication Dial-In User Service) é normalmente usado para fornecer autenticação centralizada, autorização e contabilidade para dial-in, virtual private network, e mais recentemente acesso a redes wireless. Um cliente RADIUS (tipicamente um servidor de acesso) envia as credenciais do utilizador e informação acerca de parâmetros da ligação na forma de uma mensagem RADIUS para um servidor RADIUS. O servidor RADIUS autentica e autoriza o pedido feito pelo cliente RADIUS e envia uma mensagem RADIUS de resposta. Os clientes RADIUS também enviam mensagens RADIUS de contabilidade para servidores RADIUS. Adicionalmente, o standard RADIUS suporta o uso de proxies RADIUS. Um proxy RADIUS é um PC que encaminha as mensagens RADIUS entre clientes RADIUS, servidores RADIUS e outros proxy RADIUS. As mensagens RADIUS nunca são enviadas entre o cliente de acesso e o servidor de acesso. As mensagens RADIUS são enviadas como mensagens UDP. O porto UDP 1812 é usado para as mensagens RADIUS de autenticação e o porto UDP 1813 é usado para mensagens RADIUS de contabilidade. Alguns servidores de acesso poderão usar o porto UDP 1645 para mensagens RADIUS de autenticação e o porto UDP 1646 para mensagens RADIUS de contabilidade. Apenas uma mensagem RADIUS é incluída na carga paga UDP de um pacote RADIUS. Como exemplo de tipos de mensagens RADIUS temos: - Access-Request: Enviada por um cliente RADIUS para pedir autenticação e autorização para uma tentativa de ligação à rede de acesso. - Access-Accept: Enviada por um servidor RADIUS em resposta a uma mensagem de Access-Request. Esta mensagem informa o cliente RADIUS que a tentativa de ligação é autenticada e autorizada. - Access-Reject: Enviada por um servidor RADIUS em resposta a uma mensagem de Access-Request. Esta mensagem informa o cliente RADIUS que a tentativa de ligação é rejeitada. Um servidor RADIUS envia esta mensagem caso as credenciais não estejam correctas ou caso a tentativa de ligação não seja autorizada. - Access-Challenge: Enviada por um servidor RADIUS em resposta a uma mensagem Access-Request. Esta mensagem é um desafio para o cliente RADIUS que requer uma resposta. 15/115

17 Interfaces e Infra-estrutura de Suporte para Operadores e ISP - Accounting-Request: Enviada por um cliente RADIUS para especificar informação de contabilidade para uma ligação que foi aceite. - Accounting-Response: Enviada por um servidor RADIUS em resposta a uma mensagem de Accounting-Request. Uma mensagem RADIUS engloba um cabeçalho e vários atributos. Cada atributo RADIUS especifica um pedaço de informação acerca da tentativa de ligação. Para vários protocolos de autenticação, os resultados da negociação da autenticação entre o servidor de acesso e o cliente são encaminhados para o servidor RADIUS para verificação. Para fornecer segurança às mensagens RADIUS, tanto o cliente RADIUS como o servidor RADIUS são configurados com um segredo comum. Na figura seguinte encontra-se uma representação das mensagens trocadas entre um terminal e o AAA Server utilizando o protocolo RADIUS. Figura 9 Mensagens trocadas com o protocolo RADIUS HTTP O protocolo HTTP (HyperText Tranfer Protocol) define as interacções entre Web browsers e Web servers assim como os formatos das mensagens necessárias. Cada interacção engloba duas acções: O envio de uma mensagem request por parte do cliente identificando o ficheiro que pretende receber. 16/115

18 Interfaces e Infra-estrutura de Suporte para Operadores e ISP O envio de uma mensagem response por parte do servidor com uma resposta negativa ou positiva (neste caso, com o conteúdo do ficheiro pedido). De assinalar que é efectuado um pedido por cada ficheiro, mesmo em páginas Web com múltiplos ficheiros. O HTTP é um protocolo stateless de transferência de informação hypermedia baseado na linguagem Hiper-Text Mackup Language (HTML). Corre sobre TCP e o servidor responde a pedidos no porto 80 (por defeito, ou outro se configurado explicitamente). Figura 10 Esquema HTTP As mensagens HTTP request são compostas em formato ASCII. Começam por uma linha de pedido (GET, POST, HEAD ). Incluem um número variável de linhas de cabeçalho. Os principais campos são: Host: identifica o endereço do servidor. Connection: indica se o servidor deve terminar a ligação (close) ou não (keep-alive). User-agent: especifica o tipo de browser. As mensagens HTTP response começam por uma linha de resposta. Incluem um número variável de linhas de cabeçalho e termina com o conteúdo do ficheiro pedido. Os tipos de respostas são: 200 OK Pedido aceite e o conteúdo do ficheiro é incluído na resposta 301 Moved Permanently O ficheiro pedido foi transferido permanentemente A resposta inclui uma linha de cabeçalho do tipo Location com a nova localização do ficheiro 400 Bad Request O pedido não foi compreendido pelo servidor 404 Not Found O ficheiro não existe no servidor 505 HTTP Version Not Supported A versão HTTP do pedido não é suportada pelo servidor 17/115

19 Interfaces e Infra-estrutura de Suporte para Operadores e ISP O HTTP inclui um processo de autenticação que permite limitar o acesso a ficheiros com base num username e password. Uma mensagem request enviada por um browser para um ficheiro protegido tem como resposta 401 Authorization Required. Esta resposta inclui uma linha de cabeçalho do tipo WWW-Autenticate indicando o método de autenticação a usar. O novo pedido inclui uma linha de cabeçalho do tipo Authorization com a informação do username e password gerada pelo método pedido pelo servidor. Tipicamente, o browser guarda a informação de username e password em memória para ser usada em futuras mensagens de request FTP O protocolo FTP (File Transfer Protocol) é um serviço de transferência de ficheiros que corre sobre TCP. O servidor usa dois números de porto: Porto 21: para ligação de controlo Porto 20: para ligação de dados É mais sofisticado que o TFTP (Trivial File Transfer Protocol) em termos de segurança, uma vez que utiliza credenciais para autenticação: username e password Numa sessão FTP, o utilizador estabelece uma ligação de controlo com o servidor por onde são trocados os comandos FTP. Essa ligação de controlo mantém-se activa até terminar a sessão FTP. Sempre que seja necessário a transferência de dados, o servidor estabelece uma ligação de dados do seu número de porto 20 para um número de porto previamente anunciado pelo cliente pelo comando PORT. No fim da transferência de dados, o servidor termina a respectiva ligação SIP Conceitos Gerais O SIP (Session Initiation Protocol) é um protocolo textual de controlo ao nível da aplicação baseado nos protocolos Hyper Text Transfer Protocol (HTTP) e Simple Mail Transfer Protocol (SMTP). O facto do SIP ser um protocolo textual dá-lhe a vantagem de ser facilmente implementável, extensível e legível. Este protocolo de sinalização para comunicação multimédia permite a criação, gestão e terminação de sessões e funciona em conjunto com outros 2 protocolos: RTP e SDP. O protocolo RTP (Real Time Protocol) é usado para transportar dados multimédia em tempo-real; este protocolo define um standard para o formato dos pacotes e torna possível a codificação e divisão dos dados em pacotes, de forma a possibilitar o seu transporte através da Internet. O SDP (Session Description Protocol) é usado para descrever e codificar as capacidades dos participantes na sessão. Esta descrição é depois usada para negociar as características da sessão (por exemplo, a negociação dos codecs), de forma a que todos os potenciais intervenientes possam participar. 18/115

20 Interfaces e Infra-estrutura de Suporte para Operadores e ISP O SIP usa um modelo de comunicação do tipo cliente-servidor. Os pedidos são gerados por um cliente e enviados para um servidor que os recebe e aos quais responde. O SIP pode usar TCP ou UDP nas suas comunicações. Há dois tipos de mensagens SIP: pedidos de um cliente para um servidor ou respostas de um servidor para um cliente (mensagens de estado). Existem seis tipos diferentes de mensagens de pedidos: REGISTER: usado pelo utilizador para registar o seu endereço SIP num servidor SIP. Um utilizador pode registar-se em vários servidores SIP e pode também ter vários registos activos ao mesmo tempo no mesmo servidor, o que acontece quando está ligado em vários terminais. INVITE: usado para iniciar uma sessão; BYE: usado para terminar a sessão; pode ser enviado por qualquer um dos participantes na sessão. OPTIONS: usado para inquirir o servidor sobre as suas capacidades. CANCEL: termina um pedido pendente, isto é, um pedido à espera de uma resposta final. As mensagens de resposta são iniciadas por uma linha de estado a qual contém um código de três dígitos (códigos de estado) que indica o resultado do pedido e uma frase para uma descrição textual. Os códigos de resposta estão divididos em 6 classes. Cada classe refere-se a um grupo de códigos de estado relacionados. As classes são: Classe 1XX: respostas provisórias que fornecem informação acerca do progresso do pedido. Classe 2XX: respostas que indicam o sucesso do pedido (pedido entendido e realizado pelo servidor). Classe 3XX: respostas que indicam redirecção, resultantes da não acessibilidade da parte chamada. Fornecem um endereço alternativo. Classe 4XX: respostas que indicam insucesso do pedido, resultante dum erro no lado do cliente. Classe 5XX: respostas que indicam insucesso do pedido, resultante dum erro no lado do servidor. Classe 6XX: respostas que indicam insucesso global, o que significa que houveram problemas durante a execução do protocolo. Tal como acontece com um qualquer protocolo se sinalização, os pedidos e respostas são enviados para endereços particulares. No SIP, esses endereços (SIP:user_identifier@domain), cuja forma é idêntica aos endereços (mas com um URL SIP e não mailto), são conhecidos por SIP URIs (Uniform Resource Identifiers). Numa rede SIP existem cinco tipos de entidades lógicas principais. Cada entidade tem funções específicas e participa numa comunicação SIP como cliente (inicia pedidos), como servidor (responde a pedidos) ou como ambos. Uma entidade física SIP pode conter as funcionalidades de mais do que uma entidade lógica. 19/115

21 Interfaces e Infra-estrutura de Suporte para Operadores e ISP As várias identidades são: User Agent: parte integrante de qualquer terminal SIP. São constituídos por um cliente - User Agent Client (UAC) - e um servidor - User Agent Server (UAS). O UAC é responsável pelo envio dos pedidos e pela recepção das respostas. O UAS é responsável pela recepção de pedidos e pelo envio de respostas a esses pedidos. Servidor proxy: entidade intermediária que funciona simultâneamente como cliente e servidor com o propósito de efectuar pedidos em nome de outros clientes. Esta entidade reencaminha pedidos SIP para UASs e respostas SIP para UACs. Servidor registrar: entidade que recebe registos de utilizadores, extrai informação acerca da localização actual do utilizador (endereço IP, porta e nome de utilizador) e guarda esta informação numa base de dados de localização. Tipicamente este servidor existe em conjunto com os servidores proxy e redirect. Servidor redirect: entidade que responde a um pedido com um endereço alternativo para o qual o pedido deve ser direccionado, à excepção de pedidos não suportados, aos quais responde com mensagens de resposta do tipo 4XX, 5XX ou 6XX, e também para pedidos de CANCEL aos quais responde com uma mensagem de resposta 200. Gateway SIP: entidade que serve de interface entre uma rede que implementa SIP e outra rede que utiliza outro protocolo de sinalização. O SIP é um protocolo transaccional uma vez que as suas mensagens são organizadas em transacções. Uma transacção é uma sequência de mensagens trocadas entre elementos SIP; consiste num pedido e todas as respostas a esse pedido, o que inclui as possíveis respostas provisórias e uma ou mais respostas finais. Os diálogos estabelecem as relações entre as várias transacções que relacionam. Os diálogos SIP representam uma relação ponto-a-ponto entre User Agents. Os diálogos facilitam a sequenciação e encaminhamento de mensagens SIP entre os terminais SIP e são identificados usando os cabeçalhos Call-ID, From e TO O problema da Firewall O papel da firewall é proteger a rede contra acessos por parte de fontes não autorizadas. Ela bloqueia tráfego baseada em três parâmetros: a origem, o destino e o tipo de tráfego. As firewalls também tomam decisões baseadas na direcção do fluxo de tráfego. Tipicamente, tráfego que entra (proveniente do domínio público não confiável) apenas é permitido se a sessão tiver sido iniciada por um dispositivo no domínio confiável, ou seja, no domínio privado. 20/115

22 Interfaces e Infra-estrutura de Suporte para Operadores e ISP Figura 11 O problema da firewall As comunicações baseadas em SIP, assim como a telefonia tradicional, são baseadas na chegada de chamadas não autorizadas, provenientes de uma vasta gama de fontes desconhecidas e portanto não confiáveis. Isto entra em desacordo com as politicas de filtragem de pacotes da firewall descritas anteriormente. A maior parte dos gestores de comunicações estão relutantes em mudar essas políticas de modo a permitir uma comunicação sem restrições em ambos os sentidos devido aos sérios riscos em termos de segurança que daí derivam. Qualquer abordagem para resolver este problema tem de permitir uma comunicação segura em ambos os sentidos sem alterar significativamente as regras de filtragem da firewall. Por outras palavras, o actual nível de segurança fornecido pela firewall não deverá ser reduzido O problema do NAT Como foi visto anteriormente, o NAT efectua a tradução de endereços IP e números de porto privados em endereços públicos quando o tráfego flui da rede privada para a rede pública. Isto faz com que um número limitado de endereços IP públicos sirvam as necessidades de uma grande corporação resolvendo assim o problema da falta de endereços IPv4. Figura 12 O problema do NAT Cada terminal na rede privada tem o seu próprio endereço IP privado. O tráfego enviado para um terminal na rede pública será dinamicamente associado a um número de porto específico na rede pública pelo NAT. O NAT mantém uma tabela com a correspondência entre endereços IP e números de porto privados e endereços IP e números de porto públicos. É importante salientar que estas associações apenas podem ser iniciadas pelo tráfego externo. O NAT funciona de maneira idêntica a um PABX. A iniciação de uma chamada no sentido privado público é fácil. Os utilizadores dum PABX podem efectuar uma chamada 21/115

23 Interfaces e Infra-estrutura de Suporte para Operadores e ISP para fora utilizando uma das poucas linhas telefónicas (equivalentes aos endereços IP públicos) que estão disponíveis. A linha que está a ser usada (o número do porto) é seleccionada automaticamente e é invisível para o utilizador. A recepção de chamadas no sentido oposto é, no entanto, mais complicada uma vez que não é possível, a partir da rede pública, definir uma rota tendo em conta os números referentes às extensões da rede interna. Utilizadores que ligam para dentro têm de ser encaminhados para um assistente de modo a serem ligados à extensão correcta. No caso do NAT, não existe um equivalente a esse assistente. Deste modo, chamadas não solicitadas que cheguem não poderão ser suportadas. Figura 13 NAT impede o fluxo de dados Para complicar ainda mais, as mensagens SIP end-to-end entre clientes, contêm detalhes relacionados com os endereços IP e portos privados que os clientes (User Agents) querem usar para os fluxos de dados. Quando os clientes tentam utilizar esses endereços privados para enviar/receber dados, a ligação falha porque eles não são válidos. Este problema não é apenas característico do SIP. Outros protocolos de sinalização como o H.323 e o MGCP apresentam o mesmo problema. Qualquer abordagem para resolver este problema tem de permitir uma comunicação segura em ambos os sentidos incluindo a chegada de chamadas não solicitadas e minimizar a dependência relativamente aos upgrades das NATs ou até à utilização de qualquer dispositivo NAT especifico de um determinado vendedor Métodos para resolver o problema do NAT As propostas correntes para a resolução do problema do NAT são: Universal Plug and Play (UPnP) Simple Traversal of UDP Through Network Address Translation Devices (STUN) Application Layer Gateway Manual Configuration Tunnel Techniques Automatic Channel Mapping (ACM) Universal Plug and Play UPnP é uma tecnologia que está predominantemente direccionada para utilizadores home-office, instalações residenciais, etc Uma das grandes forças impulsionadoras do UPnP é a Microsoft Corporation. A arquitectura UPnP está projectada tendo em conta um conjunto de problemas gerais não apenas VoIP e de forma a permitir a configuração de pequenas redes por parte de 22/115

24 Interfaces e Infra-estrutura de Suporte para Operadores e ISP utilizadores comuns. UpnP permite que aplicações cliente descubram e configurem componentes de rede incluindo NATs e Firewalls, as quais estão equipadas com software UPnP. A principal necessidade em aplicações VoIP é descobrir e usar o endereço IP e porto externos que o NAT selecciona para os fluxos de sinalização e dados. Uma vez conhecida esta informação, o cliente VoIP pode colocar esta informação na sinalização VoIP para estabelecer a chamada. Isto assegura que a chamada é estabelecida usando endereços e portos públicos (e portanto válidos) o que garante conectividade end-to-end. Para alcançar isto, tanto o NAT como os clientes VoIP têm que suportar UPnP. Existem actualmente poucos clientes VoIP UPnP disponíveis. No entanto, será apenas uma questão de tempo até estes dispositivos estarem disponíveis e muitas pequenas companhias (e subscritores residenciais) os considerarem úteis. A principal desvantagem desta aproximação está relacionada com a segurança. Ela não resolve satisfatoriamente o problema relacionado com a firewall. Existe actualmente apenas um pequeno número de vendedores NAT e Firewall que suportam UPnP. Resumindo, este método está provavelmente limitado a pequenas instalações Simple Traversal of UDP Through Network Address Translation Devices (STUN) O protocolo STUN permite que um cliente SIP descubra se está ou não atrás dum NAT e, no caso de estar, qual o tipo de NAT existente. O STUN recebeu muita atenção por parte do IETF, mas esta técnica apenas funciona com alguns tipos de NAT. De facto, o STUN não funciona com o tipo de NAT mais comum entre as redes de corporações a NAT simétrica. O IETF Midcom Working Group efectuou uma investigação de dispositivos residenciais de NAT e concluiu que algumas NATs não funcionam com o STUN. O STUN não implica que os dispositivos SIP sejam baseados em TCP. Á medida que algumas entidades SIP se tornam mais complexas, a utilização do TCP vai aumentando. O protocolo STUN define um servidor especial (STUN server) no espaço dos endereços públicos para informar o cliente SIP (com STUN activado) no espaço de endereços privados do endereço IP e porto públicos usados para essa sessão em particular. A necessidade de utlização de clientes com o STUN activado e de efectuar o upgrade de clientes antigos para que estes suportem o STUN, torna este método impopular. De facto, muito poucos vendedores disponibilizam suporte em termos de STUN para os seus clientes. Figura 14 - STUN 23/115

25 Interfaces e Infra-estrutura de Suporte para Operadores e ISP O STUN identifica os detalhes do lado público da NAT, inspecionando mensagens STUN de exploração que chegam ao servidor STUN. Os clientes com STUN activado enviam uma mensagem de exploração para o servidor STUN externo para determinar quais os portos de recepção a usar. O servidor STUN examina a mensagem que chega e informa o cliente acerca de qual o endereço IP e portos públicos que são usados pelo NAT. Estes são depois usados nas mensagens de estabelecimento de chamadas. De realçar, que o servidor STUN não afecta os fluxos de dados ou de sinalização. Como mencionado anteriormente, existe um problema com esta técnica. A maior parte das NAT utilizadas são do tipo simétrico. Isto significa que elas criam um mapeamento baseado no endereço IP e porto origem e no endereço IP e porto destino. O endereço do cliente VoIP destino é diferente do endereço do servidor STUN. Isto significa que o NAT irá criar um novo mapeamento usando um porto diferente para o tráfego de saída que por sua vez significa que a informação contida nas mensagens de estabelecimento da chamada está incorrecta e que a tentativa de chamada pode falhar. O mesmo problema ocorre com o tráfego de entrada. Consequentemente, o STUN confia no facto de que, uma vez que o porto de saída é mapeado pelo tráfego do servidor STUN, qualquer tráfego que chegue de qualquer parte da rede com qualquer endereço IP de origem, poderá utilizar o mapeamento na direcção inversa e deste modo alcançar o porto de recepção no cliente. As NATs que funcionam desta maneira são susceptíveis a ataques que têm os portos como alvo, o que levanta preocupações em termos de segurança. Este método não resolve o problema relacionado com as firewalls uma vez que introduz riscos adicionais em termos de segurança que são incorportáveis para os gestores de comunicações. O IETF propôs um mecanismo adicional TURN que tem como objectivo resolver o problema relacionado com a passagem de dados no caso de termos NAT simérica. Figura 15 - TURN O TURN depende dum servidor que é inserido no percurso dos dados e da sinalização. Este servidor TURN está localizado no DMZ do cliente ou na rede do provedor de serviços. O cliente SIP com TURN activado envia um pacote de exploração para o servidor TURN, o qual responde com o endereço IP e porto públicos usados pelo NAT os quais deverão ser usados nesta sessão. Esta informação é usada nas mensagens SIP de estabelecimento de chamada e nos subsequentes streams de dados. 24/115

26 Interfaces e Infra-estrutura de Suporte para Operadores e ISP A vantagem desta alternativa é que não existe alteração do endereço IP destino visto pelo NAT e deste modo a NAT simétrica pode ser utilizada. O TURN foi recentemente extendido de forma a tentar resolver alguns problemas sérios de segurança. Muitos provedores de serviço esperam ser capazes de manipular informação relacionada com QoS e fornecer segurança suplementar no ponto de entrada para a rede. O TURN não suporta estes requisitos porque os detalhes da sessão SIP não são revelados ao servidor TURN através do protocolo TURN. Sendo assim a aceitação pela comunidade de provedores de serviços não é certa nesta fase. Ambos os métodos acrescentam uma complexidade significativa à instalação CPE. O TURN assim como o STUN, requer o upgrade dos clientes SIP. Existe uma relutância considerável por parte dos vendedores clientes em levar a cabo este trabalho, tornando o STUN e o TURN em soluções não ideais Application Layer Gateway Esta técnica consiste na instalação de uma nova e melhorada Firewall/NAT com o nome de Application Layer Gateway que entende as mensagens de sinalização e a sua relação com os fluxos de dados resultantes. Figura 16 Application Layer Gateway O ALG processa os streams de sinalização e dados modificando a sinalização de modo a revelar os endereços IP e portos públicos que estão a ser usados pelo tráfego de dados e de sinalização. Como sugerido, esta técnica requer a substituição da NAT/Firewall existente por um ALG. Alternativamente, alguns vendedores fornecem upgrades de software para as suas NAT/Firewall para permitir que estas suportem a funcionalidade ALG. As ALGs requerem idênticos, se não mais avançados, conhecimentos quer em termos de configuração, quer em termos de gestão de NAT e Firewall. Isto significa que upgrades ou novas instalações não são fáceis de realizar. Estes problemas significam que o desenvolvimento do ALG será provavelmente lento e restricto a grandes redes de corporações detentoras dum significativo staff de suporte. 25/115

27 Interfaces e Infra-estrutura de Suporte para Operadores e ISP Manual Configuration Neste método, o cliente é configurado manualmente e é feita referência aos endereços IP e portos públicos que a NAT irá usar para sinalização e dados. Também a NAT é configurada manualmente com mapeamento estático para cada cliente. Este método requer que o cliente tenha um endereço IP e portos fixos para receber dados e sinalização. Figura 17 Manual Configuration Devido ao processo de configuração ser manual, baseado em certos conhecimentos prévios e devido ao facto de termos uma configuração que é fixa, este método apenas é apropriado para redes muito pequenas e quando existe uma boa dose de experiência em termos de configuração e gestão de NAT/Firewall. É muito provável que o UPnP, quando disponível, venha a substituir este método manual Tunnel Techniques Este método permite obter resolver o problema relacionado com Firewall/NAT com a criação de túneis para dados e sinalização através das instalações Firewall/NAT existentes para um servidor no espaço dos endereços públicos. Este método requer um novo servidor dentro da rede privada e outro na rede pública. Estes dispositivos criam um túnel entre eles através do qual será transportado todo o tráfego SIP através de uma firewall reconfigurada. O servidor externo modifica a sinalização para revelar o seu porto de saída permitindo assim ao sistema fazer e receber chamadas. Geralmente o túnel criado através da infra-estrutura existente não é encriptado. 26/115

28 Interfaces e Infra-estrutura de Suporte para Operadores e ISP Figura 18 - Tunneling Apesar das mudanças em termos de politicas de segurança devido a este método serem reduzidas, ele acaba por criar riscos adicionais. O próprio servidor externo é um ponto de vulnerabilidade. No caso de ruptura deste servidor, o invasor poderá fácilmente aceder à rede privada. Este método pode ainda criar um atraso adicional no percurso de dados o qual poderá reduzir a qualidade de voz Automatic Channel Mapping (ACM) O Newport Networks 1460 session border controller equipado com o ACM Application Pack, é especialmente projectado para solucionar os problemas relacionados com o NAT e Firewall sem necessitar de quaisquer mudanças, quer em termos de regras de segurança quer em termos de clientes Tecnologias de Acesso Dial-up Neste tipo de acesso á Internet o cliente usa um modem ligado a um PC e a linha telefónica para se ligar a um nó de um ISP para estabelecer uma ligação com um outro modem o qual se encontra ligado a Internet. Apesar deste tipo de acesso ter sido usado durante muito tempo, está a ser progressivamente substituído pelo acesso de banda-larga à Internet que provisiona um acesso mais rápido que excede em muito a velocidade deste acesso ( 56Kbps vs <1Mbps). Este tipo de acesso não requer nenhuma infra-estrutura adicional na rede telefónica. Como por todo o mundo estão disponíveis pontos de acesso telefónico o acesso Dial-up é especialmente útil para viajantes. Nas zonas mais rurais, é o único acesso disponível devido á baixa população e procura, o que torna desta forma inviável a implementação de um acesso de banda-larga. Estamos perante um acesso lento em que são necessários tempos para estabelecer a ligação e todas as politicas necessárias antes que uma transferência de dados possa ocorrer. De igual forma, a velocidade de transmissão é reduzida, teoricamente de 56Kbps (usando o 27/115

29 Interfaces e Infra-estrutura de Suporte para Operadores e ISP protocolo V.92), embora na maioria dos casos apenas seja possível no máximo 53Kbps devido ao overhead e a regulamentação FCC. Estas velocidades são actualmente consideradas as máximas possíveis. Na maior parte dos casos são inferiores (33 a 43 Kbps). Factores como o ruído na linha telefónica assim como a qualidade do próprio modem determinam em grande parte a velocidades de ligação. As ligações deste tipo têm habitualmente uma latência que pode chegar aos 200ms ou até mais, o que torna as torna incapazes de suportar aplicações real-time (vídeo-conferência). Algumas das aplicações on-line não são de todo compatíveis com este acesso. O modo conhecido como accelerated dial-up não é mais que uma táctica para optimizar o acesso a Internet através do uso do novo protocolo de ligação V.92 que usa um processo de log-on mais curto. Depois de estabelecida a ligação o provedor do serviço de Internet irá selectivamente comprimir, filtrar e fazer cache dos dados enviados para os utilizadores aumentando desta forma a velocidade de acesso aos conteúdos mais requisitados RDIS (ISDN) A RDIS (Rede Digital com Integração de Serviços), em inglês ISDN (Integrated Service Digital Network), refere-se a um tipo de rede telefónica de comutação de circuitos desenhada para permitir a transmissão digital de voz e dados sobre as linhas telefónicas de cobre comuns. Isto permite obter uma melhor qualidade e maior velocidade do que era conseguido com as linhas analógicas. Na frase Rede Digital com Integração de Serviços : Rede refere-se ao facto do RDIS não ser apenas uma simples solução ponto a ponto como uma linha alugada. A rede RDIS vai desde a central telefónica até ao utilizador remoto incluindo todo o equipamento de telecomunicações e de comutação intermédio. Digital refere-se á transmissão digital pura em oposição a transmissão analógica do serviço telefónico usual. Se usarmos um modem para aceder à Internet o modem do ISP tem de converter o conteúdo digital para sinais analógicos antes de os enviar. No nosso modem esses sinais são convertidos novamente para conteúdos digitais. No RDIS não existe essa conversão resultando numa transmissão com uma qualidade quase transparente. Não existe por isso nenhuma estática ou ruído resultantes da transmissão analógica que diminuem a taxa de transmissão. Integração de serviços refere-se á capacidade do RDIS oferecer duas conexões simultâneas de uma qualquer combinação de dados, voz e fax sobre a mesma linha. Múltiplos dispositivos podem estar ligados à mesma linha e serem usados como necessário. Isto significa que uma linha RDIS é capaz de satisfazer todas as necessidades de comunicações dos utilizadores sem que para tal seja necessário adquirir múltiplas linhas analógicas e possuir ainda uma maior largura de banda. No sistema RDIS existem dois tipos de canais, B( Bearer ) e D( Delta ). Os canais do tipo B são usados para a transmissão de dados (o que inclui voz), os canais do tipo D são usados para sinalização e controlo(mas também podem ser usados para a transmissão de dados em casos especiais). Existem dois tipos de acesso RDIS: Basic rate interface (BRI) ou Basic rate access (BRA): Consiste em dois canais do tipo B, cada um com uma largura de banda de 64Kbps e um canal do tipo D com uma 28/115

30 Interfaces e Infra-estrutura de Suporte para Operadores e ISP largura de banda de 16Kbps. Juntos, estes canais são designados como 2B+D permitido uma largura de banda máxima de 144Kbps. Primary rate interface (PRI) ou Primary rate access (PRA): Consiste num número maior de canais do tipo B e um canal do tipo D agora com uma largura de banda de 64Kbps. O número de canais do tipo B varia de acordo com a localização. Na América e no Japão são 23B+1D tendo como tal agregada uma largura de banda total de Mbps (T1). Na Europa e na Austrália são 30B+1D com uma largura de banda total agregada de 2.048Mbps (E1). Uma linha RDIS pode ser usada numa configuração em que os canais do tipo B são agregados para permitir uma largura de banda de 128Kbps. No entanto, isto impede que a linha seja usada para chamadas de voz enquanto a ligação à Internet se encontrar activa BroadBand O acesso à Internet de banda larga mais vulgarmente denominado de Internet de bandalarga é uma ligação a Internet com uma elevada taxa de transmissão. DSL e cabo são dois tipos de acesso largamente difundidos no mercado que permitem uma largura de banda igual ou superior a 256 kbps, isto é igual ou superior a 4 vezes a velocidade permitida por um modem ligado a uma linha telefónica digital. Este tipo de acesso varias vezes superior aos acessos RDIS e Dial-up é mais económico que o acesso RDIS e muitas vezes tem um custo semelhante ao acesso Dial-up, embora tanto os custos como a performance variem de acordo com o pais. A definição do FCC de banda-larga é de pelo menos 200Kbps numa direcção e bandalarga avançada de pelo menos 200Kbps em ambas as direcções. O OECD definiu a banda-larga com 256Kbps pelo menos numa direcção. Esta taxa de transferência é a mais comum taxa base no mercado da banda-larga a nível mundial. Na prática a largura de banda anunciada nem sempre está disponível, os ISPs frequentemente agregam mais utilizadores do que aqueles teoricamente suportados pela sua ligação backbone tendo como pressuposto de que frequentemente a maior parte dos utilizadores não estará a usar a totalidade da largura de banda da sua ligação. Esta estratégia de agregamento de fluxos funciona quase sempre. Os acessos de banda-larga mais comuns são a DSL e cabo DSL (ADSL) Digital Subscriber Line ou DSL é uma família de tecnologias que permite a transmissão de dados digitais através da ligação de cobre da rede telefónica local. Tipicamente a velocidade de download desta ligação vai desde 128Kbps ate 24000Kbps dependendo da tecnologia e do nível de serviço implementado. A origem da tecnologia remonta a 1988 quando os engenheiros da então bellcore criaram uma maneira de transmitir sinais digitais sobre o espectro de frequência livre no par de linhas de cobre entre a central telefónica e os clientes. Esta implementação permitiria que uma linha telefónica comum disponibilizasse comunicações digitais sem que tal interferisse com os serviços de voz. No entanto, as companhias telefónicas não estavam assim tão entusiastas em relação à DSL uma vez que não era rentável a instalação de uma segunda linha telefónica para os clientes que quisessem uma ligação à Internet e serviços de voz em simultâneo. Ao mesmo tempo, ao introduzir o acesso de banda-larga tal iria reduzir em muito o mercado RDIS existente. 29/115

31 Interfaces e Infra-estrutura de Suporte para Operadores e ISP Este ponto de vista foi alterado quando as companhias de televisão por cabo introduziram também o acesso de banda-larga a Internet. A implementação da tecnologia DSL que até então tinha sido atrasada, foi apressada pelas companhias telefónicas na tentativa de conquistarem parte do mercado do acesso de banda-larga à Internet oferecido pelos operadores de televisão por cabo. DSL é o principal concorrente do cabo no que respeita ao acesso de banda-larga a Internet dos consumidores domésticos na Europa e norte da América. O standard ADSL permite a velocidade de 8 Mbps num raio de 2km usando o comum par de linhas de cobre. O último standard ADSL2+ permite até 24Mbps dependendo da distância do DSLAM. No entanto, alguns clientes estão para além do raio de 2km o que reduz significativamente a largura de banda disponível. A central local telefónica foi inicialmente concebida para transportar os canais de voz e respectiva sinalização uma vez que o conceito de comunicações de dados como hoje o conhecemos não existia na altura. Por razões económicas o sinal de voz ocupa as frequências entre 300 e 3400Hz que é considerado o intervalo de frequências requerido para que a voz humana seja claramente inteligível. Na central telefónica local, a voz é digitalizada num stream de 64kbps na forma de um sinal de 8 bits por amostra com uma frequência de amostragem de 8000Hz. As ligações ás centrais locais da maioria dos utilizadores são capazes de suportar frequências muito superiores a 3400Hz. Dependendo da distância a da qualidade da ligação, o limite superior anda na ordem das dezenas de megahertz. O DSL tira partido desta largura de banda disponível da ligação, criando canais com uma largura de banda de Hz, começando entre as frequências de 10 e 100kHz, dependendo da forma como o sistema se encontra configurado. A alocação dos canais continua até altas-frequências até que os novos canais deixem de ser utilizáveis. Cada um dos canais é testado para verificar se é fiável, da mesma forma que um modem analógico testava a sua ligação. Quantos mais canais utilizáveis existirem, maior será a largura de banda disponível, razão pela qual a distância e qualidade da ligação são um factor importante. O grupo de canais utilizáveis é dividido em dois grupos para downstream e upstream baseado numa relação pré configurada. Uma vez que estes grupos estejam formados os canais são juntos num par de circuitos virtuais um em cada direcção. Tal como os modems analógicos, os tansreceptores DSL monitorizam constantemente a qualidade de cada canal e irão adicionar ou remover canais do serviço dependendo se são utilizáveis ou não. Figura 19 Tecnologia DSL 30/115

32 Exemplos de tecnologias DSL Serviços e Redes Residenciais Interfaces e Infra-estrutura de Suporte para Operadores e ISP SDSL Velocidade de upstream igual a velocidade de downstream. Velocidades desde 72 até 2320Kbps com um alcance máximo de 3km. ADSL Velocidade de upstream inferior a velocidade de downstream. Velocidade máxima de downstream de 8Mbps e upstream de 1024Kbps ADSL2+ - Versão melhorada da ADSL com uma velocidade de downstream de 12Mbps num raio de 2.5km e de 24Mbps num raio de 1.5km. VDSL Versão que permite os limites teóricos de 54Mbps para downstream e 12Mbps para upstream. PDSL Versão que permite o acesso a Internet através das linhas de alta voltagem Cabo Um cable modem é um tipo único de modem desenhado para modular sinais de dados sobre a infra-estrutura da televisão digital. Estes modems são primariamente usados para permitir o acesso à Internet usando para tal a largura de banda livre na rede da televisão digital. A largura de banda para downstream vai tipicamente dos 3Mbps até aos 15Mbps ou mais. Para o upstream vai desde os 384Kbps até aos 2Mbps ou mais. Em comparação com o serviço DSL este serviço é mais independente da distância a que nos encontramos da central local. Existem no entanto, duas desvantagens tradicionais deste serviço: O cabo é um meio partilhado ao contrario do DSL em que o par de fios de cobre que liga o utilizador a central local é apenas usado por um utilizador (embora na central local os pacotes dos utilizadores ligados a essa central sejam introduzidos em células ATM, sendo esse um meio partilhado). Neste acesso, o cabo coaxial é partilhado normalmente por todos os utilizadores que se encontrem na vizinhança. Como tal a qualidade de serviço e velocidade de ligação podem variar dependendo do número que pessoas que estejam a usar o serviço ao mesmo tempo, embora na maioria das áreas isto seja eliminado devido a redundância e a redes de fibras ópticas. Como o cabo tende a cobrir uma área superior á da DSL, têm que ser aumentados os cuidados com a qualidade de serviço fornecida de forma a assegurar uma boa performance da rede. Um outro ponto é que muitos fornecedores deste serviço de Internet normalmente fazem-no agregado ao serviço de televisão por cabo aumentado por isso os custos. Para a modulação e transmissão de dados pelo cabo coaxial o modem usa a norma DOCSIS (Data Over Cable Service Interface Specification). O CMTS (cable modem termination system) é um equipamento do lado do provedor do serviço de Internet por cabo que está na outra extremidade do cabo e que é responsável por fazer o interface com a rede de dados. Para transmitir dados (upload) são usadas as frequências desde 5MHz até 65MHz com uma largura de banda de 2MHz. A modulação do sinal pode ser QPSK ou 16-QAM, dando uma taxa de transmissão no primeiro caso de 3Mbps. A modulação 16-QAM, apesar de fornecer uma taxa de transferência de dados superior é também mais frágil e mais sensível ao ruído. A transferência de dados é feita em bursts de dados em timeslots (TDM) definidos pelo CMTS. Para receber dados e os canais de TV são usadas as frequências desde 65MHz a 850MHz, divididas em canais de 8MHz. Estes canais são usados para transmitir o sinal de TV, sendo que os canais não usados para TV são os que vão ser usados como canais de 31/115

33 Interfaces e Infra-estrutura de Suporte para Operadores e ISP downstream. A modulação do sinal é 64-QAM ou 256-QAM, tendo uma taxa de recepção de dados de 41.4 Mbps no primeiro caso ou de 55.2 Mbps no segundo caso. A modulação 256- QAM apesar de mais rápida é mais sensível ao ruído. 32/115

34 Interfaces e Infra-estrutura de Suporte para Operadores e ISP Figura 20 Tecnologia Cabo 33/115

35 Interfaces e Infra-estrutura de Suporte para Operadores e ISP Wireless O wireless é um método de comunicação que usa radiofrequências de baixa potência para transmitir dados entre sistemas. Este termo refere-se a comunicação sem cabos ou fios, usando para tal radiofrequências ou infravermelhos. Algumas das aplicações típicas deste tipo de comunicação incluem as comunicações definidas pela IrDA e as redes sem fios de computadores. Desta forma é dado aos utilizadores mobilidade dentro do raio de cobertura permitido pela rede. Uma WLAN ou rede de acesso local sem fios é composta por vários elementos: Figura 21- Arquitectura WLAN Estações: Todos os equipamentos capazes de se ligar a rede sem fios. Estas podem ser clientes wireless ou pontos de acesso. Clientes Wireless: Estes podem ser dispositivos móveis como computadores portáteis, PDA s, telefones IP ou então dispositivos fixos como os tradicionais PC s ou Workstations equipados com uma interface wireless. Pontos de Acesso (AP s): São as estações base de uma rede wireless. Eles transmitem e recebem ondas de radiofrequência para comunicarem com os clientes wireless permitidos. Basic Service Set (BSS): É o conjunto de todas as estações que podem comunicar entre si. Existem dois tipos de BSS: independent BSS e infrastructure BSS. Independent BSS: São redes ad-hoc que não contêm pontos de acesso. Uma vez que não usam pontos de acesso este tipo de redes não se pode ligar com outras redes BSS. Infrastructure BSS: Este tipo permite que as estações possam comunicar com estações que não estejam no mesmo BSS, através dos pontos de acesso. Extended Service Set (ESS): É um conjunto de BSS ligadas entre si. Um ponto de acesso é um ESS e estão ligados por um sistema de distribuição. Cada ESS tem um ID chamado de SSID que é um conjunto de caracteres com um tamanho máximo de 32bytes. Sistema de distribuição: Um sistema de distribuição liga os pontos de acesso num ESS. Usualmente é uma rede wired LAN mas pode ser também uma rede Wireless LAN. 34/115

36 Tipos de WLAN Figura 22- Peer to Peer or Ad-Hoc LAN Figura 23- Access Point Infrastructure Ponto a ponto ou ad-hoc Este tipo de redes permite que os dispositivos wireless comuniquem directamente entre si. Dispositivos wireless que se encontrem dentro do raio de cobertura um do outro podem-se detectar e comunicar entre si sem ser necessário recorrer a pontos de acesso centrais. Este é um método tipicamente usado por dois PCs para que se possam ligar e formar uma rede. Ponto de acesso ou Infrastructure Wireless LAN O tipo mais comum de WLAN quando um cliente wireless se liga a um ponto de acesso para se ligar a uma rede. O ponto de acesso é muitas vezes um hub ou um router que possui uma antena para transmitir e receber as ondas de radiofrequência e transmitir os dados para uma rede ethernet comum. Nesta configuração, as estações só podem comunicar com o ponto de acesso e caso pretendam comunicar entre si têm de o usar como intermediário da sua comunicação. Sendo uma rede sem fios e possuindo um raio de cobertura ainda considerável são colocadas varias questões relacionadas com segurança e privacidade das comunicações. Estes problemas são contornados através do uso de algoritmos de encriptação como é o caso do WEP, WPA e WPA2. Nos dois últimos casos, temos ainda um protocolo adicional EAP que possui varias técnicas de autenticação. De forma a impedir o acesso de elementos não autorizados, é ainda aconselhado o uso de um SSID diferente dos que vêm por defeito e a filtragem dos endereços MAC aos quais é permitido o acesso á rede Wi - Fi Wi-Fi era uma marca originalmente licenciada pela Wi-Fi Alliance que descrevia uma tecnologia de WLAN baseada nas especificações do standard IEEE Este termo tornouse tão genérico que a marca já não se encontra protegida. Inicialmente era destinado ao uso de dispositivos móveis de computação, como os PCs portáteis, em redes locais de acesso (LANs), sendo usado actualmente para mais aplicações como acesso a Internet, jogos, e para conectividade básica de aparelhos domésticos como televisões e leitores de DVD. Uma pessoa com um dispositivo Wi-Fi como um PC, um telefone ou um PDA pode ligar-se a Internet se estiver na proximidade de um ponto de acesso. A região 35/115

37 coberta por um ou mais pontos de acesso é denominada de hotspot. Os hotspots podem ir desde uma divisão até vários metros quadrados de hotspots consecutivos. O Wi-Fi também permite conectividade no modo ad-hoc sendo este método muito útil para jogos e aparelhos domésticos WiMax O WiMAX é definido como Worldwide Interoperability for Microwave Access. É baseado no standard IEEE e é definido como uma tecnologia que permite o fornecimento de serviços de Internet de banda-larga a utilizadores que se encontrem em locais remotos ou que pela sua localização não seja possível, viável ou rentável a instalação de acessos wired, sendo visto este serviço como uma alternativa ao xdsl e cabo. Esta tecnologia tem um MAC diferente do Wi-Fi. No Wi-FI os terminais competem entre si pela atenção do ponto de acesso, isto faz com que os terminais mais distantes sejam constantemente interrompidos por terminais mais próximos ou menos sensíveis reduzindo desta forma a taxa de transferência destes. Já no WiMAX so têm de competir uma vez para o acesso a rede, depois o MAC atribuilhes slots temporais para este usar. Tem teoricamente, um raio de cobertura de cerca de 50km. No entanto, no mundo real fica-se pelos 5 a 8 km. Em termos de taxa de transferência, o valor máximo é cerca de 70Mbps. Mais uma vez, testes no mundo real demonstram uma taxa máxima entre os 500kbps e 2Mbps dependendo das condições do local FWA É um acesso fixo via rádio a uma rede de telecomunicações que permite chegar aos clientes sem ter de instalar infra-estrutura de rede fixa. Foi desenvolvida para permitir/facilitar o acesso a utilizadores que dificilmente podem ser alcançados pelo tradicional par de cobre. Os principais objectivo da tecnologia FWA são: acesso sem fios na rede local; suporte de serviços de diversos débitos, desde a telefonia à distribuição de TV; funcionalidades idênticas ao acesso por par simétrico ou cabo; novas instalações mais simples e baratas do que as baseadas em cobre; possibilidade de oferta imediata de serviços por parte de novos operadores. Os sistemas actuais e planeados são: P-MP: Point to Multipoint : diversas faixas de frequência, sujeitas a licenciamento DECT: Digital Enhanced Cordless Telecommunication perfil para acesso na rede local numa faixa de frequência sem licenciamento prevista extensão para faixas de frequência de P-MP, sujeitas a licenciamento UMTS: Universal Mobile Telecommunication System definido perfil para acesso na rede local Existem três diferentes cenários de aplicação (figura 24) desta tecnologia: FWA-1: ligação directa do assinante ao nó de rede local 36/115

38 FWA-2: ligação do assinante até ao ponto de distribuição de área / edifício FWA-3: ligação do ponto de distribuição de área / edifício até ao nó de rede local Figura 24 Cenários de aplicação O modelo de referência desta tecnologia pode ser encontrado na figura seguinte. Figura 25 Modelo de referência BWA É um conjunto de tecnologias que visa o acesso wireless a redes de dados com uma elevada taxa de débito. Segundo o standard banda-larga significa ter uma largura de banda instantânea de pelo menos 1MHz e uma taxa de transferência de pelo menos 1.5Mbps. Do ponto de vista da conectividade uma rede de banda-larga wireless é equivalente ao xdsl ou cabo. É uma tecnologia de acesso com um uso crescente e tem um raio de cobertura estimado de 50km. Tecnologias como LMDS e MMDS são as mais difundidas mundialmente. 37/115

39 Tmax A tecnologia Tmax é uma tecnologia wireless, totalmente digital, constituindo a primeira plataforma de rádio BFWA a nível mundial com capacidade para oferecer serviços de TV Digital, Telefone e Dados. "O Tmax oferece voz sobre IP, banda larga simétrica e de baixa latência e vídeoconferência em televisão" ( A implementação da tecnologia Tmax exige a construção de uma nova rede de telecomunicações edifício-a-edifício que a AR Telecom está a desenvolver e que irá crescer de forma faseada xmax Trata-se de uma tecnologia ainda em desenvolvimento que teoricamente permite uma taxa de débito elevada (pelo menos 10Mbps) com uma potência reduzida (50W) num raio de 20km Ofertas Serviços Residenciais PT Casa Segura PT CasaSegura é um serviço que permite aceder a eventos ocorridos no seu sistema de alarme, a partir de qualquer computador com acesso à Internet. Serviço de Segurança Algumas das funcinalidades principais deste serviço são: Receber SMS e/ou s caso ocorra um evento específico (como uma falha de energia ou desactivação do sistema); Visualizar relatórios de eventos; Configurar outras funções do sistema de alarme. Através do portal, é possível configurar a lista de pessoas a quem se pretende que seja enviado um SMS e/ou em caso de necessidade. Os principais requisitos deste sistema são: uma linha telefónica analógica da PT Comunicações e um Kit Telesegurança PowerMax. Este Kit Telesegurança PowerMax é uma consola de segurança com sirene incorporada e dois detectores sem fios (detector de movimento e detector de fumos) que fornece ao cliente um conjunto de funcionalidades. Serviço de Vigilância Este serviço permite: Visualizar, através de um acesso seguro, imagens em tempo real obtidas a partir da casa do cliente. 38/115

40 Gravar pequenos vídeos. Em cooperação com o serviço de Segurança existe a possibilidade de configurar o sistema de forma a que a gravação seja iniciada quando ocorre um alarme. Definir utilizadores com permissões de acesso a diferentes câmaras. Através do portal, é possivel configurar a lista de pessoas a quem se pretende dar acesso a cada uma das câmaras configuradas no sistema. Os principais requisitos deste sistema são: uma linha telefónica analógica da PT Comunicações, um Kit de TeleVigilância PTComunicações e uma ligação permanente à Internet via ADSL. Nortel NetWorks Os serviços residenciais fornecidos resultam de combinação de caracteristicas da voz tradicional fornecida sobre IP com um conjunto de serviços multimédia. Serviços Fornecidos: Personal call management services Simultaneous/sequential ringing of multiple devices Call Screening based on Time of Day and Caller ID Incoming Call Options including answer, ignore, and redirect One-click calling from network-based address books Voice mail graphical interface Picture caller ID Multidados communications services Instant desktop video calling Integrated instant messaging Incoming/outgoing call log Web-push and co-browse File sharing/conferencing Top traditional voice services, including Call Forward (answer, no answer, busy) Caller ID Name and Number Call Waiting ID Name and Number Conference Calling Call Transfer Ar Telecom Responsável pelo desenvolvimento da primeira tecnologia mundial de redes fixas digitais sem fios Tmax. Oferece serviços de telefone, TV e Internet completamente baseados em IP. Pacote TEV.NET.TEL : Solução integrada de Televisão, Internet e Telefone assente na rede digital Tmax da AR Telecom. 39/115

41 Triple play (Sonaecom) Serviços e Redes Residenciais A Sonaecom pretende disponibilizar triple play a 45% da população até ao fim do presente ano. No arranque a plataforma vai disponibilizar quatro serviços. Além da TV, Internet e telefonia fixa estará disponível o Clube de Vídeo, o qual permitirá alugar filmes por períodos de tempo variáveis, comodamente a partir de casa. Numa fase posterior, estão previstos serviços como o Live Tv Recording (possibilidade do utilizador escolher a que horas quer ver determinado programa), Time Shift (permite fazer uma pausa na emissão televisiva), Real Time Video Calls (basta ter uma web cam associada) ou Gamming on Demand. Triple play (NEC) A NEC Portugal acaba de lançar no mercado nacional a solução Triple Play que se caracteriza pela facilidade de implementação e utilização, assim como pela sua capacidade de evolução futura com a integração de outras tecnologias na mesma plataforma. Esta solução vem permitir aos Operadores alargar a sua oferta de serviços de banda larga, rentabilizando a infra-estrutura instalada através da exploração de novos modelos de negócios e da criação de novas fontes de receita. Transmissão digital de TV, near-video-on-demand (NoVD), vídeo-on-demand (VoD), serviços Internet e Intranet, transmissão de dados empresariais, virtual LAN, VPN, comunicação de voz sobre linha digital (VoDSL) e comunicação de voz sobre linha analógica, são alguns dos serviços que os Operadores de rede fixa vão poder oferecer aos seus clientes através da solução NEC Triple Play, diferenciando-se da oferta actualmente disponível nas redes móveis e permitindo assim uma maior fidelização dos seus clientes. Kanguru (Optimus) O Kanguru é um serviço inovador de Banda Larga Portátil. As principais características deste novo serviço que o diferenciam das ofertas até então existentes são o acesso simples em qualquer lugar, o custo competitivo e controlado e a substituição da ligação fixa à Internet por uma ligação banda larga sem fios. O Kanguru destina-se a todos os utilizadores de computadores portáteis e permite o acesso em Banda Larga à Internet em todas as zonas de cobertura da rede 3G da Optimus. O Kanguru constitui uma alternativa ao acesso sem fios através de Wi-Fi público, o qual apenas está disponível num conjunto limitado de locais e obriga o utilizador a realizar configurações específicas no seu PC. O novo serviço Kanguru Xpress é cerca de 5x mais rápido, oferecendo velocidades de download até 1.8 Mbps. Para tal apenas é necessário estar numa zona de cobertura da rede 3G ou 3.5G da Optimus. Vodafone Mobile Connect Card O Vodafone Mobile Connect Card utiliza a rede móvel da 3ª Geração, o que permite velocidades de banda larga (até 384 Kbps). 40/115

42 Agora com a nova placa 3G Banda Larga é possível aceder à Internet navegando em banda larga com velocidades até 1,8Mbps, que excedem em cerca de 4/5 vezes a velocidade actualmente disponibilizada com a versão 3G/GPRS. Acesso Giga (TMN) Á semelhança das ofertas anteriores, a banda larga TMN permite navegar na Internet, usufruindo de total mobilidade, através de um pc portátil e de uma placa de dados, com velocidades até 1.8Mbps. 41/115

43 42/115

44 4. TRABALHO DESENVOLVIDO Com todo o trabalho de pesquisa realizado ao longo do 1ºsemestre, adquirimos uma base de conhecimentos importante para a realização das actividades necessárias no âmbito deste projecto. A primeira tarefa foi configurar o nosso PC de trabalho. Após várias tentativas, optamos por instalar o sistema operativo Linux Mandriva Em termos do projecto propriamente dito, foi-nos proposto um cenário de vídeo vigilância no qual a questão relacionada com a segurança seria o aspecto mais importante a ter em conta. Quando falamos de segurança, referimo-nos ao facto de que apenas os utilizadores autorizados podem aceder ao serviço. Para além disso, cada um desses utilizadores terá apenas acesso aos conteúdos a ele destinados Apresentação do cenário a implementar Após uma análise mais aprofundada, definiu-se o cenário da figura seguinte, onde se podem encontrar os seguintes componentes com as seguintes funcionalidades: Figura 26 - Topologia de rede do cenário Pretendemos implementar um cenário semelhante ao existente numa rede tradicional ADSL ( PPPoE, autenticação da RGw e não do utilizador, Radius para as funções de AAA, ). Numa primeira fase, é feita a verificação do utilizador que pretende aceder ao serviço. Desta forma, é enviado um pedido ao servidor freeradius que concederá ou não acesso à rede dependendo das credenciais introduzidas pela residential gateway. A verificação desses dados é feita consultando a base de dados mysql. Caso seja concedido o acesso, é criado um túnel PPP. Num cenário deste tipo, as renovações dos endereços IP comuns nas redes de acesso dos ISP, poderão trazer algumas complicações no acesso a terminais com endereço dinâmico (endereço sujeito a alterações). Para resolver este problema, será necessário implementar um servidor Dynamic DNS. Este servidor dinâmico de DNS, que funcionará como um serviço público 43/115

45 algures na Internet (o qual já existe actualmente), será capaz de manter a correspondência entre o nome do terminal e o próprio terminal mesmo quando o endereço IP do terminal em questão é alterado. Para isso é necessário a presença de uma aplicação cliente nesse mesmo terminal. As imagens são obtidas através da utilização de uma webcam. O utilizador poderá visualizar os seus vídeos (gerados a partir das imagens retiradas com a webcam) estabelecendo uma transmissão em directo ou utilizando o modo de gravação pré programada. O modo de transmissão em directo baseia-se no estabelecimento de uma sessão SIP. Para tal, será necessário configurar um servidor SIP de modo a definir quais os utilizadores que nele se podem registar e quais as câmaras que cada um deles tem permissão para aceder. O modo de gravação pré programada consiste na gravação de vídeo dum modo contínuo e na sua disponibilização aos utilizadores através de um portal web. Deste modo, serão periodicamente criados ficheiros de vídeo que estarão idadostamente disponíveis para serem visualizados e descarregados pelo utilizador através do portal web. Também neste caso será necessário algum mecanismo de autenticação para controlar o acesso aos vídeos por parte dos utilizadores de modo a que um determinado utilizador só tenha acesso aos seus próprios vídeos. 44/115

46 4.2. FreeRADIUS e base de dados mysql Para fazer a autenticação dos utilizadores, resolvemos utilizar o servidor freeradius ( o qual, como o próprio nome deixa transparecer, é um servidor RADIUS open source que possui uma vasta gama de funcionalidades. Este servidor encontra-se entre os 5 servidores RADIUS mais usados actualmente para funções AAA ( É rápido, flexível, configurável e suporta mais protocolos de autenticação que muitos servidores comerciais. O servidor FreeRADIUS não é apenas um simples servidor RADIUS. Possui módulos de autenticação PAM ( e Apache ( Suporta também várias bases de dados, como por exemplo MySQL, PostgreSQL e Oracle, entre outras. O servidor contém ainda uma ferramenta de administração de utilizadores via web baseada em php chamada dialupamin Instalação do freeradius Acedemos ao site do freeradius ( e descarregámos a versão Após o donwload começamos por instalar o freeradius, fazendo: tar -xvzf freeradius tar.gz cd freeradius-1.1.0/./configure make make install Desta forma, os arquivos foram instalados nos seguintes directórios: /urs/local/etc -> arquivos de configuração; /usr/local/sbin -> comandos do administrador; /usr/local/share -> arquivos de dicionário de radius e outros arquivos compartilhados; /usr/local/var -> arquivos de pid e logs; Configuração do freeradius para utilizar a base de dados mysql Para configurarmos o freeradius tivemos que utilizar dois ficheiros de configuração: radiusd.conf (arquivo de configuração principal responsável pelo daemon do RADIUS e onde é feita a inclusão dos demais ficheiros de configuração); clients.conf (responsável pela lista de clientes NAS que desfrutam do serviço RADIUS). O conteúdo destes ficheiros encontra-se no Anexo 9.1. Começámos por verificar se o ficheiro radius.conf possuía a linha: $INCLUDE ${confdir}/sql.conf 45/115

47 linhas: De seguida, editámos o arquivo /usr/local/etc/raddb/sql.conf e alterámos as seguintes Sql{ driver = "rlm_sql_mysql" # informa ao freeradius qual modulo de banco # de dados usar, neste caso, mysql server = "localhost" # diz ao freeradius em qual # host está o servidor mysql login = "root" # define o nome de utilizador registrado no mysql password = "senhadologinaqui" # senha do utilizador definido no parâmetro "login" radius_db = "radius" # nome do banco de dados que contem # as tabelas } # abaixo deste texto (arquivo truncado aqui) se encontram definições de SQL para # pesquisa de dados, não altere, ao menos # que tenha um propósito #... #... Criamos o banco de dados e as tabelas acedendo ao directório: /usr/local/src/freeradius-1.1.0/src/modules/rlm_sql/drivers/rlm_sql_mysql. Dentro deste directório existe um ficheiro chamado db_mysql.sql que contém todos os comandos para criar as tabelas. Criamos a base de dados radius no mysql: # mysqladmin -psenharoot create radius E as tabelas: # mysql -psenharoot radius < db_mysql.sql De seguida, editamos o radiusd.conf, para autenticar os dados no mysql. Procuramos no final do ficheiro a secção authorise e adicionamos sql : authorise { sql } 46/115

48 Isto fará com que os utilizadores sejam procurados na tabela radcheck, base de dados mysql do RADIUS. De seguida registamos a contabilidade dos acessos. Fomos até à secção accounting e adicionamos sql : accounting { sql } Isto faz com que os dados das ligações sejam armazenados na tabela radacct. Introduzimos ainda o controlo de conexão simultânea. Isso impede que as mesmas credenciais (login e password) sejam usadas mais que uma vez. Na secção session colocamos sql : session { sql } Para finalizarmos o controlo de sessão, editamos o ficheiro sql.conf e descomentamos as linhas que definem as variáveis: simul_count_query simul_verify_query Colocação dos utilizadores em base de dados mysql Começamos por nos ligar à base de dados mysql: mysql -psenharoot radius Para criarmos um utilizador chamado JoeUser tivemos que fazer: mysql> INSERT INTO radcheck (username, attribute, op, value) mysql> VALUES ('JoeUser', 'Password', '==', 'senhasecreta'); Para criarmos um grupo com direito a uma única conexão chamado sessaounica : mysql> INSERT INTO radgroupcheck (groupname, attribute, op, value) mysql> VALUES ('sessaounica', 'Simultaneous-Use', ':=', 1); Neste caso, o número de utilizadores em simultâneo é 1 ( 'Simultaneous-Use', ': =', 1 ). No entanto, este parâmetro pode ser modificado, utilizando o campo value. Para inserirmos o utilizador JoeUser nesse grupo fizemos: mysql> INSERT INTO usergroup (username, groupname) VALUES ('JoeUser', mysql> 'sessaounica'); 47/115

49 Poderá, por vezes, dar-se o caso do utilizador ser desligado do RAS ou NAS, sem o RADIUS dar baixa na sessão. O motivo para que tal aconteça pode ser a perda de pacotes no caminho até ao RADIUS. Da próxima vez que o utilizador se tentar ligar, o acesso será negado, uma vez que o servidor RADIUS pensa que se trata de uma sessão simultânea (não permitida neste caso uma vez que definimos anteriormente que o número máximo de sessões simultâneas seria 1). Para resolver este problema, sempre que um utilizador for desligado sem ser dada a baixa da sessão teremos que fazer a actualização manualmente. Uma forma de o fazer é: mysql> DELETE FROM radacct WHERE username = 'JoeUser' AND mysql> acctsessiontime = 0 ORDER BY radacctid DESC LIMIT 1; Quando criamos a base de dados mysql do RADIUS a partir da DDL fornecida, as tabelas seguintes são criadas: radacct - contém informações de contabilidade dos utilizadores; radcheck - contém a lista de atributos que serão usados para autenticar um utilizador específico. O atributo mais necessário para que o utilizador tenha acesso seguro é a "Password. mysql> SELECT UserName, Attribute, op, Value FROM radcheck WHERE UserName = mysql> 'JoeUser'; UserName Attribute op Value JoeUser Password == senhasecreta JoeUser NASIPAddress == Quando o utilizador JoeUser se tentar autenticar, os parâmetros Password e NASIPAddress (definidos na tabela radcheck) serão verificados. Só é enviado um Access- Accept se a senha estiver certa e se a pergunta vier do NAS A definição do atributo NASIPAddress deve ser feita caso se pretenda limitar a fonte de acesso. Muitos outros parâmetros podem ser adicionados. radreply - contém uma lista de atributos devolvidos ao utilizador. Estes atributos só serão enviados caso a resposta seja diferente de Access-Reject. mysql> SELECT UserName, Attribute, op, Value FROM radreply WHERE UserName = mysql> 'JoeUser'; UserName Attribute op Value JoeUser Reply-Message == Bem Vindo! JoeUser Framed-IP-Address == JoeUser Framed-IP-Netmask == /115

50 Com os registros acima, o utilizador JoeUser receberá uma mensagem de boas vindas e o endereço IP /24. Caso não se pretenda atribuir um endereço IP específico, os campos Framed-IP-Address e Framed-IP-Netmask deverão ser omitidos. Nesse caso a atribuição do endereço IP será feita pelo DHCP. Seria muito complicado administrar centenas de utilizadors inserindo os atributos individualmente. Existe a possibilidade de criar grupos e de inserir utilizadors nesses grupos. usergroup serve para inserir utilizadors em grupos. É possível adicionar grupos de verificação e de retorno nas tabelas radgroupcheck e radgroupreply respectivamente. Ao criar um relacionamento entre o grupo e a utilizador nessa tabela, os parâmetros do grupo são usados nas operações com o utilizador. mysql> SELECT UserName, GroupName FROM usergroup; UserName GroupName JoeUser Directoria User1 Admin User2 Dialup User3 Dialup radgroupcheck - contém informações dos grupos referenciados em usergroup para verificação de parâmetros. mysql> SELECT GroupName, Attribute, op, Value FROM radgroupcheck ORDER BY mysql> GroupName; GroupName Attribute op Value Admin NAS-IP-Address == Dialup NASPortType == Async Directoria NAS-IP-Address == Acima, podemos ver que: quem é do grupo Admin e Directoria só se pode autenticar se a conexão for interdadosda pelo NAS quem é do grupo Dialup só se pode autenticar se o tipo de porta (NASPortType) for assíncrono. radgroupreply - contém informações dos grupos referenciados em usergroup para retorno de parâmetros. mysql> SELECT GroupName, Attribute, op, Value FROM radgroupreply ORDER BY mysql> GroupName; GroupName Attribute op Value 49/115

51 Admin Reply-Message == Bem vindo Chefe! Dialup Reply-Message == Um site de cada vez por favor. Diretoria Reply-Message == Acesso bloqueado as 19: radpostauth - salva informações de respostas enviadas para os utilizadors. Utilizado para obter, por exemplo, um relatório das tentativas de acesso. mysql> SELECT user, pass, reply, date FROM radpostauth WHERE user = 'JoeUser'; user pas reply date JoeUser senhasecreta Access-Accept xxxxxxxxxxxxxx JoeUser senhasecreta Access-Accept xxxxxxxxxxxxxx Consultando a tabela anterior podemos verificar que o utilizador JoeUser se autenticou com sucesso nas duas tentativas. O campo date é timestamp: ano, mês, dia, hora, minuto e segundo Criação do túnel PPP A residential gateway e o router CISCO 7200 estão ligados através dum túnel PPP. Configuração servidor PPP (CISCO 7200) aaa authentication ppp default group radius radius-server host auth-port 1812 acct-port 1813 radius-server key cisco #radius-server authorization permit missing Service-Type #radius-server attribute 8 include-in-access-req interface Virtual-Template1 mtu 1492 ip unnumbered Port-channel1.2 peer default ip address dhcp ppp authentication chap callin vpdn-group 1 accept-dialin protocol pppoe virtual-template 1 interface Port-channel1.10 description Troco ethernet para establecmento do tunel PPPoE encapsulation dot1q 10 50/115

52 pppoe enable no cdp enable Configuração da residential gateway /etc/ppp/peers/7200 user "bela" noauth : noipdefault defaultroute #nodefaultroute usepeerdns lcp-echo-interval 20 lcp-echo-failure 3 persist mtu 1492 lock show-password #+chap plugin rp-pppoe.so eth0 /etc/ppp/chap-secrets "teste" * "cisco" * "bela" * "cisco" * 51/115

53 4.3. Dynamic DNS (DDNS) Serviços e Redes Residenciais Completada a questão relacionada com o freeradius, começámos então a pensar em como implementar um servidor DDNS. Este servidor será capaz de superar o problema causado pela atribuição dinâmica de endereços IP, mantendo constante a correspondência biunívoca entre o nome atribuído a um terminal e o próprio terminal através do seu endereço IP. Começamos por efectuar uma pesquisa na Internet, com o propósito de ficarmos a conhecer os servidores DDNS existentes que cumprem os nossos requisitos (freeware, funcionamento em linux, segurança). Tivemos problemas para encontrar um programa que servisse para realizar o que pretendíamos. A maior parte funcionava apenas como cliente DDNS e apenas permitia certos servidores pré definidos. Acabamos por encontrar um programa chamado mhdns ( com versões para linux e windows, o qual cumpria todos os requisitos por nós impostos. Contudo, este servidor DDNS apresenta um problema. Na realidade, o servidor mhdns não funciona como um servidor DDNS habitual. Apenas mantém uma correspondência entre domínios e endereços IP em bases de dados (uma por cada domínio ou utilizador). Com vista a resolvermos este problema resolvemos instalar o Bind (servidor DNS open source) ( o qual, trabalhando em parceria com o mhdns, seria capaz de contornar o problema anterior. Verificamos que tínhamos 2 hipóteses em termos de implementação: utilizar o Bind na sua versão dynamic dns ou colocar o Bind a funcionar em parceria com o mhdns acedendo às bases de dados por ele criadas. Optamos por utilizar a 2ªsolução, uma vez que o mhdns apresenta maiores facilidades em termos de instalação e funcionamento; além do mais apresenta alguma segurança (password encriptada). Verificamos que as alterações nas tabelas do mhdns só eram detectadas pelo Bind caso este fosse reiniciado. Para solucionarmos esse problema tivemos que alterar o código do mhdns, adicionando uma linha que faz o refresh do Bind sempre que o endereço IP da base de dados do mhdns é alterado. Desta forma é possível actualizar o Bind sem ser necessário reinicia-lo Instalação e configuração mhdns Para instalarmos o servidor mhdns, apenas precisamos de descompactar o ficheiro mhdns-1.5.tar.gz: tar -xzvf mhdns-1.5.tar.gz Uma vez instalado, tivemos de configurar devidamente o servidor. Para tal necessitamos de actuar sobre os ficheiros: mhdns.conf : # U:<path/file to user file> localização users file # L:<path/file to log file> localização log file # P:<port to bind to> porto a utilizar # <N{1-3}>:<nameservers (atleast 2 are required!)> 52/115

54 nameservers mhnsclient.conf : # U:<username>:<uncrypted password> usarname : password desencriptada # P:<mhdns server>:<port> servidor : porto mhdns.users : # <name>[tab]<crypt'd password>[tab]<domain>[tab]<db file> registo dos utilizadores (username, password encriptada, domínio, database) Para encriptarmos a password utilizamos um executável que vem com o servidor mhdns:./mkpasswd Após termos configurado todo o sistema, passamos à fase de teste do servidor mhdns. Antes de mais, tivemos de definir o nosso PC como servidor mhdns. Para tal, alteramos o ficheiro /etc/resolv.conf: search av.it.pt nameserver endereço_ip_nosso_pc nameserver... nameserver... nameserver... Para iniciarmos o servidor fizemos:./mhdns. Como cliente DDNS em linux temos duas hipóteses. Podemos, utilizar: mhnsclient: aplicação cliente mhdns básica; (./mhnsclient -c localização_ficheiro_mhnsclient.conf) ou mhnsclientd: aplicação daemon cliente mhdns que escuta permanentemente uma interface e regista as suas mudanças de IP. (./mhnsclient -c localização_ficheiro_mhnsclient.conf -d interface_a_monitorar) Para o caso do utilizador não utilizar linux mas sim windows, teremos de utilizar a aplicação cliente mhdns: MHDns win32.zip Instalação e configuração BIND Começamos por fazer o download do ficheiro bind tar. De seguida, executamos as linhas de comando: cd /home/naotenho/desktop tar xzvf /root/bind tar cd bind /make 53/115

55 ./make install Devido ao facto do Bind ser muito utilizado, este está inevitavelmente sujeito a falhas. Por isso mesmo, foi criada uma forma de se limitar o acesso a um determinado serviço dentro do servidor que tem o nome de chroot. Este sistema tem o objectivo de criar um mini ambiente contendo apenas o necessário para que seja possível a execução do ficheiro executável, com o propósito de minimizar o risco de acesso não autorizado. Este conceito tem o nome de "JAIL". Para implementarmos este conceito fizemos o seguinte: Criação do utilizador e do grupo groupadd named useradd -g named -d /chroot/named -s /bin/true named passwd -l named Remoção de configuração bind pré existente rm -rf /chroot/named Criação da "JAIL" mkdir -p /chroot/named cd /chroot/named Criação dos sub directórios mkdir dev mkdir etc mkdir logs mkdir -p var/run mkdir - p conf/secondaries Criação dos devices mknod dev/null c 1 3 mknod dev/zero c 1 5 mknod dev/random c 1 8 Copia do arquivo localtime cp /etc/localtime etc Após esta implementação, tivemos de construir os ficheiros de configuração. O ficheiro named.conf é o principal ficheiro de configuração do Bind. O ficheiro named.conf deve estar dentro do directório etc, que por sua vez deverá estar na directoria chroot. Deste modo, criamos o ficheiro no directório /chroot/named/etc/. 54/115

56 Editamos o ficheiro named.conf e escrevemos as seguintes linhas: options { directory "/conf"; pid-file "/var/run/named.pid"; statistics-file "/var/run/named.stats"; dump-file "/var/run/named.db"; # hide our "real" version number version "[secured]"; }; # The root nameservers zone "." { type hint; file "db.rootcache"; }; # localhost - forward zone zone "localhost" { type master; file "db.localhost"; notify no; }; # localhost - inverse zone zone " in-addr.arpa" { type master; file "db "; notify no; }; O arquivo de configuração faz referência a três ficheiros adicionais: db.rootcache db.localhost db Todos eles necessitam de ser criados em /chroot/named/conf. O ficheiro db.rootcache, refere-se à lista de servidores DNS que compõem a rede "root server", ou seja, que conseguem chegar a qualquer endereço IP. Para o criarmos basta que o PC esteja associado a algum servidor DNS válido na Internet (para tal consultar o ficheiro /etc/resolv.conf). Caso isso se verifique, o arquivo é criado facilmente com o comando: ns > /chroot/named/conf/db.rootcache Os ficheiros db.localhost e db terão de ser criados manualmente. Para tal temos de escrever em cada um deles os respectivos códigos que se encontram a seguir: ; 55/115

57 ; db.localhost ; $TTL IN root ( 42 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum IN IN A ; ; db ; $TTL IN SOA localhost. root.localhost. ( 1 ; Serial ; Refresh ; Retry ; Expire ) ; Minimum IN NS localhost. 1 IN PTR localhost. Estes arquivos só precisam de ser criados uma única vez. Precisamos agora de garantir que as permissões de acesso e que o registo com os donos dos ficheiros estão correctos. O procedimento habitual e mais cómodo, consiste em criar um ficheiro que contém as regras de permissões. Desta forma, evitamos erros e facilitamos a alteração dos dados relativos às permissões. Esse ficheiro tem o nome de named.perms, e pode ser encontrado na directoria /chroot. Os comandos que necessitamos de colocar nesse ficheiro foram: # # named.perms # # Configura os donos e as devidas permissões dentro do diretório named # cd /chroot/named # Por padrão, root é o dono de tudo e apenas ele pode gravar, mas os diretórios # tem execução para todos. Note que algumas plataformas usam como # marcador/separador um ponto entre utilizador/grupo nos parâmetros do chown} 56/115

58 chown -R root.named. find. -type f -print xargs chmod u=rw,og=r # regular files find. -type d -print xargs chmod u=rwx,og=rx # directories # os arquivos named.conf e rndc.conf precisam ter suas chaves protegidas chmod o= etc/*.conf # o diretório secondaries cria arquivos dinamicamente a partir dos # servidores de DNS Master e o daemon named precisa de poderes para gravar ali # afim de criar os arquivos das zonas. touch conf/secondaries/.empty # placeholder find conf/secondaries/ -type f -print xargs chown named.named find conf/secondaries/ -type f -print xargs chmod ug=r,o= chown root.named conf/secondaries/ chmod ug=rwx,o= conf/secondaries/ # Garante que a criação do arquivo de PID em var/run seja efetivado chown root.root var/ chmod u=rwx,og=x var/ chown root.named var/run/ chmod ug=rwx,o=rx var/run/ # Permite que o daemon named crie sossegado seus arquivos de log. chown root.named logs/ chmod ug=rwx,o=rx logs/ Após gravarmos o ficheiro, tivemos que o executar utilizando a linha de comando: sh -x /chroot/named.perms script: Para automatizarmos o processo de inicialização do servidor NAMED, utilizamos o # # named.start # # ATENÇÃO - O Path possui o parâmetro -c relacionado # com a raiz da gaiola e não com a raiz do sistema. # # Adicione "-n2" se você tiver múltiplos processadores # # uso: named [-c conffile] [-d debuglevel] [-f -g] [-n number_of_cpus] # [-p port] [-s] [-t chrootdir] [-u username] cd /chroot/named 57/115

59 touch named.run chown named.named named.run chmod ug=rw,o=r named.run PATH=/usr/local/sbin:$PATH named \ -t /chroot/named \ -u named \ -c /etc/named.conf Serviços e Redes Residenciais Para transformarmos este arquivo em executável fizemos: chmod a+x /chroot/named.start Para iniciarmos o servidor fizemos: sh /chroot/named.start Desta forma configuramos o servidor BIND. Utilizando o comando ps -fcnamed podemos verificar o funcionamento do servidor. Outro comando útil para o teste de funcionamento é o comando dig. Convém não esquecer que é necessário alterar o ficheiro /etc/resolv.conf para utilizar o nosso servidor. Para o NAMED ser iniciado automaticamente após o arranque do PC criamos um ficheiro rc.named cujo código é: #!/bin/sh # # rc.named # export PATH=/usr/local/sbin:$PATH # needed for rndc case "$1" in start) # Start daemons. echo -n "Starting named: " sh /chroot/named.start echo ;; stop) # Stop daemons. echo -n "Shutting down named: " rndc stop echo "done" ;; esac exit 0 58/115

60 De seguida tornamos o ficheiro executável fazendo: chmod a+x rc.named Análise do funcionamento do servidor DDNS Antes de começarmos a estudar o funcionamento do servidor DDNS, é importante mostrar o conteúdo do ficheiro status.h o qual nos permitirá compreender os códigos numéricos que aparecem nas várias capturas. O conteúdo do ficheiro necessário para a compreensão dos valores numéricos é: #define M_NONE 0 #define M_PASS 1 #define M_NOUSER 2 #define M_SUCCESS 4 #define M_UPDATE 8 #define M_IPADDR 16 #define M_OTHER 32 Os vários números acima indicam qual a situação que ocorreu. São muito úteis principalmente para a interpretação das capturas obtidas. Para analisarmos o funcionamento do servidor DDNS, estudamos 3 situações distintas. Começamos por efectuar o registo do terminal que funciona como residential gateway no servidor DDNS. De seguida, efectuamos a partir do PC que se encontra por detrás da residential gateway, um pedido de resolução do nome hemera.home.mydomain.com o qual corresponde à residential gateway. Esta situação encontra-se retratada nas figuras 27 e 28. Figura 27 - Registo no servidor DDNS Verificamos que o registo foi feito com sucesso, uma vez que obtivemos o código 10 (assinalado na captura pelo quadrado verde) que corresponde a 16 em notação decimal #define M_IPADDR /115

61 Figura 28 Resposta ao pedido de resolução do nome do terminal registado Quanto ao pedido de resolução do nome feito pelo PC por detrás do NAT, verificamos que o nome hemera.home.mydomain.com corresponde de facto ao terminal com endereço , ou seja ao terminal que funciona como residential gateway tal como era esperado. A situação seguinte (figura 29) corresponde a uma falha de registo no servidor DDNS. A falha resultou do facto da password enviada no registo não ser válida. Figura 29 Falha de registo no servidor DDNS devido erro na password Verificamos que o código obtido (assinalado na captura com um quadrado verde) foi agora 01. De acordo com o ficheiro status.h, isto significa que houve algum problema relacionado com a password (#define M_PASS 1). A última situação retrata a actualização do registo quando ocorre uma mudança do endereço IP do terminal registado no servidor. A figura 30 ilustra essa situação. Figura 30 Actualização do registo devido à alteração do endereço IP Na captura obtida voltamos a verificar uma mudança do código numérico. Desta vez, o valor é 04 (#define M_SUCCESS 4) o que significa que a actualização do registo devido à alteração do endereço IP foi feita com sucesso. 60/115

62 4.4. SIP Express Router (SER) Serviços e Redes Residenciais Uma vez resolvida a questão do Dynamic DNS, entramos na fase relacionada com a transmissão multimédia entre terminais. Optamos por utilizar o protocolo SIP para essa comunicação. Como servidor decidimos utilizar o SIP Express Router (SER) da iptel ( Como cliente SIP utilizamos numa primeira fase o kphone ( para testes entre plataformas com o sistema operativo linux e mais tarde o Eyebeam ( da CounterPath para a transmissão de vídeo, uma vez que o kphone não utiliza o SIP neste caso Instalação do SER Acedemos ao site da Iptel ( e de entre as várias versões, descarregamos o ficheiro: ser-0.9.6_linux_i386.tar.gz. Consultamos os ficheiros de ajuda à instalação que vinham com o SER e verificamos que seria necessário instalar dois programas: bison e flex. Após a instalação destes ficheiros instalamos o SER utilizando os comandos seguintes: make prefix=/usr/local make prefix=/usr/local modules make prefix=/usr/local install export SIP_DOMAIN="myserver.mydomain.com" # necessário para utilizarmos a ferramenta de monitorização O ficheiro de configuração do SER, ser.cfg (que está em anexo), encontra-se na directoria /etc/ser. Neste ficheiro são carregados todos os módulos que consideramos necessários e é definido o comportamento do servidor para as diversas situações (REGISTER, INVITE,...). No que diz respeito à informação relacionada com os utilizadores, tentamos inicialmente colocar o SER em associação com o freeradius, mas acabamos por pôr de parte essa solução uma vez que o freeradius apenas funcionaria como um intermediário para o acesso à base de dados mysql. Dessa forma, estaríamos a complicar todo o procedimento desnecessariamente, uma vez que estaríamos a misturar a informação de acesso do freeradius com a do SER. Isto poderia ainda conduzir a que um utilizador se registasse no SER utilizando as credenciais para autenticação no freeradius. Resolvemos então, colocar toda a informação dos utilizadores numa base de dados mysql separada do freeradius. Tivemos também que fazer o load dos módulos auth.so e auth_db.so: # Uncomment this if you want digest authentication # mysql.so must be loaded! loadmodule "/usr/lib/ser/modules/auth.so" loadmodule "/usr/lib/ser/modules/auth_db.so"... 61/115

63 # Uncomment this if you want to use SQL database # for persistent storage and comment the previous line modparam("usrloc", "db_mode", 2) # -- auth params -- # Uncomment if you are using auth module # modparam("auth_db", "calculate_ha1", yes) # # If you set "calculate_ha1" parameter to yes (which true in this config), # uncomment also the following parameyserver.mydomter) # modparam("auth_db", "password_column", "password") Para permitirmos o registo apenas aos utilizadores presentes na base de dados mysql, introduzimos no ficheiro de configuração do SER, as seguintes linhas: if (method=="register") { # Uncomment this if you want to use digest authentication if (!www_authorize("mydomain.com", "subscriber")) { www_challenge("mydomain.com", "0"); break; }; if (!check_to()) { sl_send_reply("401", "Forbidden"); break; }; }; save("location"); break; Para iniciarmos o SER utilizamos o comando: ser Para monitorarmos o sistema, utilizamos o comando: serctl monitor Para verificarmos quais os utilizadores que estão registados utilizamos o comando: serctl alias show Utilizamos o kphone para o teste do registo dos utilizadores no SER e verificamos que tudo estava a funcionar correctamente. 62/115

64 Introdução do SIPALG Serviços e Redes Residenciais Um dos problemas relacionados com a comunicação SIP está associado com o NAT. O protocolo NAT apenas altera os cabeçalhos IP dos pacotes, não actualizando a informação contida nos pacotes SIP. Deste modo, no caso de termos redes privadas, os endereços privados contidos nos pacotes SIP, ao contrário dos endereços contidos no cabeçalho IP, não são alterados para endereços públicos com a passagem pela gateway e vice-versa. Isto faz com que nestes casos as entidades não sejam capazes de comunicar entre si. Com vista a resolver este problema resolvemos implementar o SIP Application Layer Gateway (SIP ALG). Este módulo é instalado no kernel e actua em cooperação com as iptables. Para instalarmos este módulo, necessitamos em primeiro lugar, de actualizar o kernel existente na residential gateway. A versão mínima requerida é a No entanto, verificamos após algumas tentativas, que versões superiores à originam kernel panic, pelo que a versão que acabamos por utilizar foi a Para além da questão relacionada com o kernel, necessitamos ainda de instalar nessa mesma máquina as seguintes aplicações: Iptables patch-o-matic Para configurarmos as iptables na residential gateway fizemos o seguinte: #load the modules modprobe ip_conntrack_sip modprobe ip_nat_sip lsmod grep ip_nat_sip #Set iptables rules to allow UDP packets on port 5060: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p udp -j ACCEPT # POSTROUTING statements for Many:1 NAT # (Connections originating from the entire home network) iptables -t nat -A POSTROUTING -s "rede_privada" -j SNAT -o "interface_para_rede_publica" --to-source "endereço_publico_gateway" ou iptables -t nat -A POSTROUTING -s "rede_privada" -o ppp0 -j MASQUERADE # Prior to masquerading, the packets are routed via the filter table's FORWARD chain. # Allowed outbound: New, established and related connections # Allowed inbound : Established and related connections iptables -A FORWARD -t filter -o "interface_para_rede_publica" -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -t filter -i "interface_para_rede_publica" -m state --state ESTABLISHED,RELATED -j ACCEPT 63/115

65 echo 1 > /proc/sys/net/ipv4/ip_forward Serviços e Redes Residenciais Após instalarmos com sucesso o SIP ALG, passamos à fase de testes. Começamos por tentar estabelecer uma sessão áudio entre 2 terminais, um na rede pública e outro na rede privada, usando o kphone. No entanto, os problemas relacionados com a configuração da placa de som de um dos PCs, acabaram por condicionar a realização desses testes. Tentamos então encontrar um cliente SIP freeware que suportasse vídeo, funcionasse com o SER e que de preferência tivesse uma versão para linux. Tentamos vários clientes como por exemplo: Ekiga, Yate, Wengophone, SIP Communicator (SIP User Agent em Java), Genico, Damaka, entre outros. O Eyebeam foi a melhor hipótese encontrada apesar de só possuir versão para windows. Optamos então, por instalar o windows XP nos dois terminais para podermos utilizar o cliente SIP Eyebeam. Instalamos uma câmara e todos os drivers necessários e após configurarmos os clientes SIP conseguimos finalmente estabelecer uma sessão multimédia entre dois PCs e verificar com o Ethereal a troca de endereços dos pacotes SIP com a passagem pelo residential gateway Permissões para segurança e restrição do acesso às câmaras Para concluirmos a questão relacionada com o estabelecimento de sessões SIP restanos assegurar a segurança do sistema. De momento, nada garante que um utilizador se registe no SER com o seu username e depois de registado utilize um username de outro utilizador, por outras palavras, não existe uma ligação pré estabelecida entre o username de registo no servidor e o username pelo qual o utilizador é conhecido. Outro problema é a ausência de restrições, o que faz com que qualquer utilizador consiga estabelecer uma sessão com qualquer um dos outros utilizadores registados. Se pensarmos em termos de vídeo vigilância isto é incomportável. Para solucionarmos este problema começamos por utilizar o módulo avpops.so do SER, com vista a estabelecermos salas de conferência com entradas restritas a certos utilizadores. No entanto, acabamos por colocar esta solução de parte, uma vez que nada garantia que um utilizador acedesse a uma câmara directamente sem passar pela sala de conferência. Além disso a utilização deste módulo apresentava algumas dificuldades em termos de implementação derivadas sobretudo da falta de documentação. Resolvemos então utilizar um outro módulo chamado permissions.so. A utilização deste módulo tem por base dois ficheiros: permissions.allow; permissions.deny. A sessão será permitida quando um par (FROM, Request URI) corresponder a uma entrada do ficheiro permissions.allow. Caso isso não se verifique, o estabelecimento da sessão será negado quando um par (FROM, Request URI) corresponder a uma entrada do ficheiro permissions.deny. Neste caso, será enviada a mensagem "401 NOT ALLOWED!!!" indicando que a ligação não foi estabelecida 64/115

66 pelo facto de não ser permitida. Caso isso também não se verifique, o estabelecimento da sessão será permitido. A sintaxe de ambos os ficheiros é idêntica e encontra-se a seguir: # SIP Express Router permissions module config file # # Syntax: # from_list [EXCEPT from_list] : req_uri_list [EXCEPT # req_uri_list] # # from_list and req_uri_list are comma separated expressions # Expressions are treated as case insensitive POSIX Extended # Regular Expressions. # Keyword ALL matches any expression. # # Examples: # ALL : "^SIP:361[0-9]*@abc\.com$" EXCEPT "^SIP:361[0- # 9]*3@abc\.com$", "^SIP:361[0-9]*4@abc\.com$" # É importante referir que a não existência de um ficheiro de controlo das permissões será tratada como se o ficheiro existisse e estivesse vazio. Deste modo, o controlo de permissões pode ser desactivado, desprovendo o servidor dos ficheiros de controlo de permissões. As alterações que foram necessárias fazer no ficheiro ser.cfg para este utilizar o módulo permissions.so foram: loadmodule "/usr/lib/ser/modules/permissions.so" # Parametros do modulo de permissoes!! modparam("permissions", "default_allow_file", "/etc/ser/permissions.allow") modparam("permissions", "default_deny_file", "/etc/ser/permissions.deny") A imposição destas restrições no estabelecimento das sessões só faz sentido se conseguirmos de alguma forma estabelecer uma correspondência entre o username de registo no SER e o URI escolhido pelo utilizador para se identificar perante os outros utilizadores. Após alguma pesquisa conseguimos estabelecer essa correspondência, garantindo que um utilizador só se conseguirá registar caso o URI por ele escolhido para se identificar coincida com o username utilizado na autenticação no servidor SIP. Caso os dois usernames não correspondam, o servidor responde ao pedido do utilizador com um "401 Forbidden" negandolhe o registo. A solução encontrada assenta na tabela da base de dados mysql chamada uri, a qual contém toda a informação necessária à verificação do username e URI utilizados pelo utilizador. Relativamente ao ficheiro ser.cfg a única alteração a registar foi a introdução de uma instrução para fazer o load do módulo respectivo: 65/115

67 loadmodule "/usr/lib/ser/modules/uri_db.so" if (method=="register") { # Uncomment this if you want to use digest authentication if (!www_authorize("mydomain.com", "subscriber")) { www_challenge("mydomain.com", "0"); break; }; if (!check_to()) { sl_send_reply("401", "Forbidden"); break; }; }; save("location"); break; if (method=="invite") { if (!proxy_authorize("mydomain.com", "subscriber")) { proxy_challenge("mydomain.com", "0"); break; }; if (!check_from()) { sl_send_reply("401", "Forbidden"); break; }; if (!allow_routing()) { sl_send_reply("401", "NOT ALLOWED!!!"); break; }; } Para finalizar esta fase do trabalho e para resolver definitivamente todos os problemas de segurança, introduzimos no ficheiro de configuração ser.cfg as seguintes linhas de código: if (method=="invite") { if (!proxy_authorize("mydomain.com", "subscriber")) { proxy_challenge("mydomain.com", "0"); 66/115

68 } break; }; if (!check_from()) { sl_send_reply("401", "Forbidden "); break; }; if (!allow_routing()) {b sl_send_reply("401", "NOT ALLOWED!!!"); break; }; Estas linhas suplementares, fazem com que um utilizador não autorizado no nosso servidor seja incapaz de enviar INVITEs para os utilizadores registados que estejam activos no servidor. Desta forma asseguramos a segurança mínima necessária a este cenário de comunicação SIP. Na figura seguinte encontra-se um fluxograma no qual está resumido o comportamento do servidor SER em termos de controlo de acesso para cada um dos tipos de mensagens SIP. 67/115

69 REGISTER Tipo de Mensagem? INVITE Outras Processamento do pedido. Login e Password Válidos? Não 401 Unauthorized Não Login e Password Válidos? Sim Sim URI Válido? Não 401 Forbidden Não URI Válido? Sim Sim 200 OK 401 NOT ALLOWED!!! Não Ligação entre o par de URIs permitida? 100 RINGING Sim Figura 31 Fluxograma comportamento SER 68/115

70 Análise dos pacotes trocados numa sessão SIP Para analisarmos as sessões SIP efectuamos algumas capturas de forma a verificar qual o comportamento do cenário para diferentes situações. Os casos estudados foram os seguintes: Demonstração do funcionamento do SIP ALG REGISTER cenários possíveis 1. Credenciais válidas a. URI certo b. URI errado 2. Credenciais inválidas INVITE cenários possíveis 1. Utilizador que inicia a sessão não está registado no servidor a. Credenciais válidas i. URI certo ii. URI errado b. Credenciais inválidas Demonstração do funcionamento do módulo permissions.so Demonstração do funcionamento do SIP ALG Para demonstrarmos o funcionamento do SIP ALG, estabelecemos uma sessão SIP entre dois terminais (um na rede privada e outro na rede pública). Capturamos os pacotes trocados em três pontos: no terminal privado (figura 32), no servidor SIP (figura 33) e no terminal público (figura 34). Nas capturas efectuadas nos terminais, fizemos referência não só aos pacotes SIP como também aos pacotes de dados trocados entre eles. No servidor SIP, optamos por capturar apenas os pacotes SIP trocados. De realçar, a mudança verificada no endereço IP dos pacotes SIP do terminal privado com a passagem pela residential gateway. 69/115

71 Figura 32 Demonstração do funcionamento do SIP ALG (terminal privado) Figura 33 Demonstração do funcionamento do SIP ALG (servidor SIP) Figura 34 Demonstração do funcionamento do SIP ALG (terminal público) 70/115