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
([email protected])
José António Gonçalves Nogueira
([email protected])
Orientador:
Prof. Dr. Francisco Fontes
Colaboradores:
Eng. Vítor Simões Ribeiro
Eng. Vítor Pinto
Eng. André Oliveira
Eng. Ricardo Azevedo
nº25381
LEET
nº26223
LEET
Serviços e Redes Residenciais
Interfaces e Infra-estrutura de Suporte para Operadores e ISP
ÍNDICE
1. Enquadramento
2. Objectivos
3. Introdução e Fundamentos Teóricos
3.1. Protocolos relacionados com o projecto
pág 3
pág 5
pág 7
pág 7
3.1.1. IP
3.1.2. PPP
pág 7
pág 11
3.1.3. DNS
3.1.4. NAT
3.1.5. AAA
3.1.6. RADIUS
3.1.7. HTTP
3.1.8. FTP
3.1.9. SIP
pág 13
pág 14
pág 15
pág 15
pág 16
pág 18
pág 18
3.1.2.1. PPPoA
3.1.2.2. PPPoE
pág 12
pág 12
3.1.9.1. Conceitos gerais
3.1.9.2. O problema da Firewall
3.1.9.3. O problema do NAT
3.1.9.4. Métodos para resolver o problema do NAT
3.1.9.4.1. Universal Plug and Play
3.1.9.4.2. Simple Traversal of UDP Through Network Address
Translation Devices (STUN)
3.1.9.4.3. Application Layer Gateway
3.1.9.4.4. Manual Configuration
3.1.9.4.5. Tunnel Techniques
3.1.9.4.6. Automatic Channel Mapping (ACM)
3.2. Tecnologias de Acesso
3.2.1. Dial-up
3.2.2. RDIS (ISDN)
3.2.3. BroadBand
pág 18
pág 20
pág 21
pág 22
pág 22
pág 23
pág 25
pág 26
pág 26
pág 27
pág 27
pág 27
pág 28
pág 29
3.2.3.1. DSL (ADSL)
3.2.3.2. Cable
3.2.3.3. Wireless
pág 29
pág 31
pág 34
3.2.3.3.1. Wi - Fi
3.2.3.3.2. WiMax
3.2.3.3.3. FWA
3.2.3.3.4. BWA
3.2.3.3.5. Tmax
3.2.3.3.6. xMax
pág 35
pág 36
pág 36
pág 37
pág 38
pág 38
3.3. Ofertas Serviços Residenciais
pág 38
4. Trabalho Desenvolvido
4.1. Apresentação do cenário a implementar
4.2. FreeRADIUS e base de dados mySQL
4.2.1. Instalação do freeRADIUS
4.2.2. Configuração do freeRADIUS para utilizar
base de dados mySQL
4.2.3. Colocação dos utilizadores em base de dados mySQL
4.2.4. Criação do túnel PPP
1/115
pág 43
pág 43
pág 45
pág 45
pág 45
pág 47
pág 50
Serviços e Redes Residenciais
Interfaces e Infra-estrutura de Suporte para Operadores e ISP
4.3. Dynamic DNS (DDNS)
pág 52
4.3.1. Instalação e configuração mhDNS
4.3.2. Instalação e configuração BIND
4.3.3. Análise do funcionamento do servidor DDNS
pág 52
pág 53
pág 59
4.4.1. Instalação do SER
4.4.2. Introdução do SIPALG
4.4.3. Permissões para segurança e restrição do acesso às câmaras
4.4.4. Análise dos pacotes trocados numa sessão SIP
pág 61
pág 63
pág 64
pág 69
4.4. SIP Express Router (SER)
4.4.4.1. Demonstração do funcionamento do SIP ALG
4.4.4.2. “REGISTER” cenários possíveis
4.4.4.3. “INVITE” cenários possíveis
4.4.4.4. Demonstração do funcionamento do módulo
permissions.so
4.5. Criação do “Centro de Serviços”
4.5.1. Captura das imagens e criação dos vídeos
4.5.2. Implementação dos servidores HTTP e FTP
4.5.3. Instalação e descrição do phpMyAdmin
4.5.4. Criação do portal web
4.5.5. Análise do funcionamento do Centro de Serviços
5. Principais Dificuldades
6. Possíveis Melhoramentos
7. Conclusões / Notas Finais
8. Bibliografia / Referências
9. Anexos
9.1. Ficheiros de configuração do freeRADIUS
pág 61
pág 69
pág 71
pág 73
pág 75
pág 76
pág 76
pág 76
pág 78
pág 78
pág 82
pág 85
pág 87
pág 89
pág 91
pág 93
pág 93
9.1.1. Radiusd.conf
9.1.2. Clients.conf
pág 93
pág 107
9.2.1. SER.cfg
pág 109
9.3.1. Index.php
9.3.2. Redirect.php
9.3.3. Redirect2.php
pág 114
pág 114
pág 115
9.2. Ficheiros de configuração do SIP Express Router (SER)
9.3. Porções de código relevantes associadas ao portal web
2/115
pág 109
pág 114
Serviços e Redes Residenciais
Interfaces e Infra-estrutura de Suporte para Operadores e ISP
1. ENQUADRAMENTO
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
Serviços e Redes Residenciais
Interfaces e Infra-estrutura de Suporte para Operadores e ISP
4/115
Serviços e Redes Residenciais
Interfaces e Infra-estrutura de Suporte para Operadores e ISP
2. OBJECTIVOS
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
Serviços e Redes Residenciais
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
Serviços e Redes Residenciais
Interfaces e Infra-estrutura de Suporte para Operadores e ISP
3. INTRODUÇÃO E FUNDAMENTOS TEÓRICOS
3.1. Protocolos relacionados com o projecto
3.1.1. 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
Serviços e Redes Residenciais
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 32bit 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
Serviços e Redes Residenciais
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
HighOrder
Bit(s)
Format
Purpose
Address Range
No. Bits
Network/Host
Max. Hosts
A
N.H.H.H1
Few large
organizations
0
1.0.0.0 to 126.0.0.0
7/24
167772142 (224 - 2)
B
N.N.H.H
Medium-size
organizations
1, 0
128.1.0.0 to
191.254.0.0
14/16
65534 (216 - 2)
C
N.N.N.H
Relatively small
organizations
1, 1, 0
192.0.1.0 to
223.255.254.0
21/8
254 (28 - 2)
D
N/A
Multicast groups
1, 1, 1, 0
224.0.0.0 to
239.255.255.255
N/A (not for
commercial use)
N/A
E
N/A
Experimental
1, 1, 1, 1
240.0.0.0 to
254.255.255.255
N/A
N/A
Figura 4 – Classes de endereços IP
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
Serviços e Redes Residenciais
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 192.168.0.0 então 192.168.1.0 e 192.168.2.0 são exemplos de
subredes pertencentes a 192.168.0.0.
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
Serviços e Redes Residenciais
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.
3.1.2. 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
Serviços e Redes Residenciais
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.
3.1.2.1. 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.
3.1.2.2. 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
Serviços e Redes Residenciais
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.
3.1.3. 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
Serviços e Redes Residenciais
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.
3.1.4. 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
Serviços e Redes Residenciais
Interfaces e Infra-estrutura de Suporte para Operadores e ISP
3.1.5. 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.
3.1.6. 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
Serviços e Redes Residenciais
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
3.1.7. 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
Serviços e Redes Residenciais
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
Serviços e Redes Residenciais
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.
3.1.8. 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.
3.1.9. SIP
3.1.9.1. 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
Serviços e Redes Residenciais
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 email (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
Serviços e Redes Residenciais
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”.
3.1.9.2. 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
Serviços e Redes Residenciais
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.
3.1.9.3. 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
Serviços e Redes Residenciais
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.
3.1.9.4. 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)
3.1.9.4.1. 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
Serviços e Redes Residenciais
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.
3.1.9.4.2. 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
Serviços e Redes Residenciais
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
Serviços e Redes Residenciais
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.
3.1.9.4.3. 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
Serviços e Redes Residenciais
Interfaces e Infra-estrutura de Suporte para Operadores e ISP
3.1.9.4.4. 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.
manual.
É muito provável que o UPnP, quando disponível, venha a substituir este método
3.1.9.4.5. 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
Serviços e Redes Residenciais
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.
3.1.9.4.6. 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.
3.2. Tecnologias de Acesso
3.2.1. 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
Serviços e Redes Residenciais
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.
3.2.2. 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
Serviços e Redes Residenciais
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 1.544
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.
3.2.3. 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.
3.2.3.1. 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
Serviços e Redes Residenciais
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 4312.5Hz,
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
Serviços e Redes Residenciais
Interfaces e Infra-estrutura de Suporte para Operadores e ISP
Exemplos de tecnologias DSL
•
•
•
•
•
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.
3.2.3.2. 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
Serviços e Redes Residenciais
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 256QAM apesar de mais rápida é mais sensível ao ruído.
32/115
Serviços e Redes Residenciais
Interfaces e Infra-estrutura de Suporte para Operadores e ISP
Figura 20 – Tecnologia Cabo
33/115
Serviços e Redes Residenciais
Interfaces e Infra-estrutura de Suporte para Operadores e ISP
3.2.3.3. 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
Tipos de WLAN
•
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.
Figura 22- Peer to Peer or Ad-Hoc LAN
Figura 23- Access Point Infrastructure
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.
3.2.3.3.1. 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 802.11. 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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.
3.2.3.3.2. WiMax
O WiMAX é definido como Worldwide Interoperability for Microwave Access.
É baseado no standard IEEE 802.16 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.
3.2.3.3.3. 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
•
•
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
3.2.3.3.4. BWA
É um conjunto de tecnologias que visa o acesso wireless a redes de dados com uma
elevada taxa de débito. Segundo o standard 802.16 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
3.2.3.3.5. 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" (HTTP://tek.sapo.pt/4O0/595829.html).
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.
3.2.3.3.6. 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.
3.3. 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 Emails 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 Email 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
•
•
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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
Triple play (Sonaecom)
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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
42/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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 2006.
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.
4.1. 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
4.2. FreeRADIUS e base de dados mySQL
Para fazer a autenticação dos utilizadores, resolvemos utilizar o servidor freeRADIUS
(HTTP://www.freeradius.org), 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
(HTTP://www.freeradius.org). É 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
(HTTP://www.freeradius.org/related/)
e
Apache
(HTTP://www.freeradius.org/related/). 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.
4.2.1. Instalação do freeRADIUS
Acedemos ao site do freeRADIUS (HTTP://www.freeradius.org) e descarregámos a
versão 1.1.0.
Após o donwload começamos por instalar o freeRADIUS, fazendo:
tar -xvzf freeradius-1.1.0.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;
4.2.2. 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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
4.2.3. 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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
| == | 192.168.0.1
----------------------------------------------------------------------------------Quando o utilizador JoeUser se tentar autenticar, os parâmetros “Password” e
“NASIPAddress” (definidos na tabela radcheck) serão verificados. Só é enviado um AccessAccept se a senha estiver certa e se a pergunta vier do NAS 192.168.0.1. 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
| == | 10.0.0.121
JoeUser | Framed-IP-Netmask
| == | 255.255.255.0
-----------------------------------------------------------------------------------
48/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
Com os registros acima, o utilizador JoeUser receberá uma mensagem de boas vindas e
o endereço IP 10.0.0.121/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
| == | 192.168.0.1
Dialup
| NASPortType
| == | Async
Directoria
| NAS-IP-Address
| == | 192.168.0.1
----------------------------------------------------------------------------------Acima, podemos ver que:
• quem é do grupo Admin e Directoria só se pode autenticar se a conexão for
interdadosda pelo NAS 192.168.0.1.
• 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
------------------------------------------------------------------------------------------------------Admin
| Reply-Message
| == | Bem vindo Chefe!
Dialup
| Reply-Message
| == | Um site de cada vez por favor.
Diretoria
| Reply-Message
| == | Acesso bloqueado as 19:00.
------------------------------------------------------------------------------------------------------•
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.
4.2.4. 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 10.10.1.93 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
pppoe enable
no cdp enable
Configuração da residential gateway
/etc/ppp/peers/7200
user "bela"
noauth
172.16.100.1:193.136.93.229
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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
4.3. Dynamic DNS (DDNS)
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
(HTTP://www.htoc.com/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) (HTTP://www.isc.org/index.pl?/sw/bind/) 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.
4.3.1. 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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-1.0.3-win32.zip.
4.3.2. Instalação e configuração BIND
Começamos por fazer o download do ficheiro bind-9.3.2.tar. De seguida, executamos as
linhas de comando:
cd /home/naotenho/Desktop
tar xzvf /root/bind-9.3.2.tar
cd bind-9.3.2
./make
53/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
./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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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 "0.0.127.in-addr.arpa" {
type master;
file "db.127.0.0";
notify no;
};
O arquivo de configuração faz referência a três ficheiros adicionais:
• db.rootcache
• db.localhost
• db.127.0.0
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:
dig @a.root-servers.net . ns > /chroot/named/conf/db.rootcache
Os ficheiros db.localhost e db.127.0.0 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
; db.localhost
;
$TTL 86400
@ IN SOA @ root (
42
; serial (d. adams)
3H
; refresh
15M
; retry
1W
; expiry
1D ) ; minimum
IN NS @
IN A 127.0.0.1
;
; db.127.0.0
;
$TTL 86400
@ IN SOA localhost. root.localhost. (
1 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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
Para automatizarmos o processo de inicialização do servidor NAMED, utilizamos o
script:
#
# 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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
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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
De seguida tornamos o ficheiro executável fazendo:
chmod a+x rc.named
4.3.3. 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
#define M_PASS
#define M_NOUSER
#define M_SUCCESS
#define M_UPDATE
#define M_IPADDR
#define M_OTHER
0
1
2
4
8
16
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 16”.
59/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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
172.16.100.1, 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
4.4. SIP Express Router (SER)
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
(HTTP://www.iptel.org). Como cliente SIP utilizamos numa primeira fase o kphone
(HTTP://sourceforge.net/projects/kphone) para testes entre plataformas com o sistema operativo
linux e mais tarde o Eyebeam (HTTP://www.counterpath.com/) da CounterPath para a
transmissão de vídeo, uma vez que o kphone não utiliza o SIP neste caso.
4.4.1. Instalação do SER
Acedemos ao site da Iptel (HTTP://www.iptel.org) 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
# 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
4.4.2. Introdução do SIPALG
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 2.6.11. No entanto, verificamos após algumas tentativas,
que versões superiores à 2.6.13 originam kernel panic, pelo que a versão que acabamos por
utilizar foi a 2.6.11.12.
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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
echo 1 > /proc/sys/net/ipv4/ip_forward
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.
4.4.3. 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
Tipo de
Mensagem?
REGISTER
INVITE
Outras
Processamento do
pedido.
Login e Password
Válidos?
Não
401 Unauthorized
Não
Login e Password
Válidos?
Sim
URI Válido?
Sim
Não
401 Forbidden
Não
URI Válido?
Sim
Sim
200 OK
401 NOT
ALLOWED!!!
Não
100 RINGING
Figura 31 – Fluxograma comportamento SER
68/115
Ligação entre o par
de URIs permitida?
Sim
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
4.4.4. 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
4.4.4.1. 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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
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
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
Através da captura retirada no terminal privado, verificamos que os pacotes SIP
provenientes deste terminal possuem o endereço IP privado (192.168.0.5).
Na captura obtida no servidor SIP isto já não é assim. Uma vez que a captura é feita na
rede pública, o terminal por detrás do NAT envia e recebe pacotes SIP, os quais saem e chegam
respectivamente à residential gateway com o endereço IP da interface pública da própria
residential gateway (172.16.100.1).
Fica assim demonstrado o correcto funcionamento do SIP ALG.
4.4.4.2. “REGISTER” cenários possíveis
Começamos por analisar a situação em que as credenciais introduzidas pelo utilizador
são válidas assim como o URI por ele utilizado (figuras 35 e 36).
Consideramos um URI válido, caso este coincida com o username utilizado pelo
utilizador para se registar. No caso do utilizador com username JoeUser, o URI válido será
JoeUser@domínio. É dada especial atenção à noção de URI válido devido à sua importância
para a segurança do cenário, tal como referido na secção anterior.
Figura 35 – Primeiro pacote (Credenciais válidas e URI válido)
71/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
Figura 36 - Terceiro pacote (Credenciais válidas e URI válido)
Analisando as capturas anteriores, podemos verificar que no primeiro pacote enviado
pelo terminal para se registar, apenas é feita referência ao username do utilizador que se
pretende registar. Em resposta, o servidor envia um “401 Unauthorized” indicando que para o
username enviado, é necessária password.
Desta forma, é enviado um novo pacote no qual se encontra a password codificada
(campo “Digest Authentication Response”). Após a recepção deste último pacote e consequente
validação dos dados, o registo é completado e é enviado um pacote “200 OK” por parte do
servidor.
Na figura 37 está representada a situação em que as credenciais introduzidas são
válidas mas o URI utilizado (JoeUser2@domínio) não é válido.
Figura 37 – Terceiro Pacote (Credenciais válidas e URI não válido)
72/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
Verificamos que o facto do URI não ser válido, origina o envio de uma mensagem de
erro por parte do servidor (“401 Forbidden”). Se consultarmos o ficheiro de configuração do SER
(ser.cfg), verificamos que essa mensagem corresponde, de facto, à situação verificada.
Por último, analisamos o caso em que as credenciais introduzidas não eram válidas
(figura 38).
Figura 38 – Pacotes capturados quando as credenciais não são válidas
Verificamos que após o envio da password (contida no 3ºpacote) o servidor responde
com um “401 Unauthorized” indicando que a autenticação não foi bem sucedida (esta mensagem
está implícita na secção do ficheiro ser.cfg correspondente à verificação dos dados para
autenticação).
4.4.4.3. “INVITE” cenários possíveis
A primeira situação analisada (figura 39) consiste em efectuar um INVITE com um
utilizador não registado no servidor que possui, no entanto, credenciais e URI válidos.
Figura 39 – Pacotes capturados quando as credenciais são válidas assim como o URI
Verificamos que à semelhança do que se passa com as mensagens REGISTER,
primeiro é enviado um pacote com o username, ao qual o servidor responde com um “401
Unauthorized”. Neste caso, o utilizador responde com um pacote de ACK ao pacote de erro
enviado pelo servidor. De seguida, o utilizador envia um novo pacote de INVITE no qual segue a
password (no campo “Digest Authentication Response”).
Uma vez que tanto as credenciais como o URI são válidos a sessão SIP é estabelecida
sem problemas (“200 OK”).
73/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
Na figura 40, temos a situação em que o utilizador, não registado no servidor (tal como
no caso anterior) tenta estabelecer uma sessão SIP utilizando credenciais válidas mas um URI
inválido.
Figura 40 – Pacotes capturados quando as credenciais são válidas mas o URI não
Verificamos que tal como acontece no caso equivalente do modo REGISTER, a
utilização dum URI inválido origina o envio de uma mensagem de erro “401 Forbidden” (ver
ser.cfg) por parte do servidor que impede o estabelecimento da sessão.
No caso das credenciais serem inválidas (figura 41), o servidor envia um pacote “401
Unauthorized” que impede o estabelecimento da sessão tal como acontece no modo
REGISTER.
Figura 41 – Pacotes capturados quando as credenciais não são válidas
74/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
4.4.4.4. Demonstração do funcionamento do módulo permissions.so
Resta-nos analisar o módulo permissions.so. Para tal efectuamos uma captura (figura
42) na qual está representada a tentativa de estabelecimento de uma chamada no sentido
Hemera → JoeUser o qual não tem uma entrada no ficheiro permissions.allow.
Figura 42 – Pacotes capturados quando a ligação é recusada devido ao módulo permissions.so
Verificamos que a tentativa de estabelecimento de uma sessão não autorizada em
termos do módulo permissions.so, conduz ao envio por parte do servidor de um pacote “401
NOT ALLOWED!!!” (definida no ficheiro ser.cfg) que faz com que a tentativa de estabelecimento
da sessão não tenha sucesso.
75/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
4.5. Criação do “Centro de Serviços”
Após termos concluído com sucesso a introdução e configuração do SER no nosso
sistema, pretendemos agora criar uma alternativa para acedermos aos conteúdos multimédia.
Optamos por introduzir o conceito de “centro de serviços” através da criação de um portal web, o
qual funcionará como um interface para o acesso aos vídeos por parte dos utilizadores.
Para a implementação deste centro de serviços, precisamos de considerar vários
elementos. Teremos de extrair vídeo a partir de um terminal e de o disponibilizar de uma forma
segura e ao mesmo tempo simples para que os utilizadores o possam visualizar.
4.5.1. Captura das imagens e criação dos vídeos
Para retirarmos as imagens utilizamos uma webcam da creative (QuickCam messenger).
Encontramos um programa bastante completo chamado Active WebCam
(HTTP://www.pysoft.com/ActiveWebCamMainpage.htm), o qual permite a captura de imagens,
geração de vídeos (a partir dessas imagens), restrição de acessos através de utilização de
credenciais (username e password), disponibilização desses conteúdos por HTTP, FTP, entre
outras funcionalidades.
Começamos por instalar e configurar devidamente o programa. De seguida, fizemos um
teste o qual consistia em capturar e disponibilizar algumas imagens por HTTP utilizando uma das
funcionalidades do programa que permite a criação duma página web. No entanto, verificamos
desde logo que esta opção não era a mais adequada uma vez que a página criada tinha como
endereço o endereço IP do PC onde o programa está instalado o que não é aconselhável uma
vez que o próprio conceito de centro de serviços implica que esta página esteja numa entidade
aparte e não no PC onde está a câmara.
Resolvemos por de parte esta solução e consideramos que a melhor alternativa seria
utilizar um servidor FTP para armazenarmos os conteúdos capturados e criar um portal web com
autenticação que permitisse o acesso a esses conteúdos dependendo do utilizador que se havia
autenticado.
4.5.2. Implementação dos servidores HTTP e FTP
Como servidor FTP e HTTP começamos por utilizar a versão para Windows XP do
Fastream Netfile. No entanto, tivemos que trocar este servidor por outro quando procedemos à
montagem da rede final porque a máquina que na montagem final vai conter o servidor terá o
sistema operativo linux instalado o qual não é suportado por este servidor.
Utilizamos o dreamweaver para criar uma página web (com autenticação no servidor
FTP) para efeitos de teste, bastante simples, que permite o acesso aos ficheiros multimédia
alojados no servidor FTP.
Configuramos novamente o Active WebCam para desta vez gerar ficheiros de vídeo
MPEG de aproximadamente 2 minutos a partir das imagens capturadas. Esses vídeos logo que
estejam completos serão idadostamente enviados para o servidor FTP. Optamos por vídeos de
curta duração para minimizar o atraso entre a captura do vídeo e a sua disponibilização ao
utilizador.
Após termos configurado devidamente os servidores FTP e HTTP, realizamos alguns
testes. Verificamos que tudo estava a funcionar correctamente, ou seja, as imagens estavam a
ser capturadas, os vídeos criados de acordo com a duração estabelecida e enviados logo de
seguida para o servidor FTP. Acedendo através do portal web, podemos após autenticação,
76/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
visualizar e descarregar os ficheiros de vídeo armazenados no servidor FTP respeitantes à
nossa câmara.
Como foi dito anteriormente, apesar do servidor FTP e HTTP estar a funcionar sem
problemas, tivemos de utilizar um outro servidor capaz de funcionar em linux tendo em vista a
interligação com os outros elementos do cenário.
Como servidor HTTP optamos por instalar o Apache.
Como servidor FTP instalarmos a aplicação pure FTPd. Em termos de configuração
tivemos de executar os seguintes passos:
1. Criar um ficheiro de configuração (/etc/pureFTPd-mysql.conf) com o seguinte texto:
#MYSQLServer localhost
#MYSQLPort
3306
MYSQLSocket mysql.sock*
MYSQLUser
root
MYSQLPassword rootpw**
MYSQLDatabase pure-FTPd
MYSQLCrypt cleartext
MYSQLGetPW SELECT Password FROM users WHERE User="\L"
MYSQLGetUID SELECT Uid FROM users WHERE User="\L"
MYSQLGetGID SELECT Gid FROM users WHERE User="\L"
MYSQLGetDir SELECT Dir FROM users WHERE User="\L"
*O caminho para este ficheiro pode ser encontrado no ficheiro /etc/my.cnf .
**Password de acesso ao mysql.
2. Criar uma base de dados no mysql com o nome pure-FTPd como especificado no
ficheiro de configuração anteriormente referido.
3. Dentro da base de dados pure-FTPd criar a tabela users com o seguinte comando:
CREATE TABLE users (
User VARCHAR(16) BINARY NOT NULL,
Password VARCHAR(64) BINARY NOT NULL,
Uid INT(11) NOT NULL default '80*',
Gid INT(11) NOT NULL default '422*',
Dir VARCHAR(128) BINARY NOT NULL,
PRIMARY KEY (User)
);
*Os valores que devem ser colocados neste campo devem estarde acordo com os
especificados no ficheiro /etc/passwd na entrada correspondente ao pure-FTPd.
criada.
4. Criar as contas para os utilizadores inserindo para tal os dados apropriados na tabela
5. Iniciar o servidor FTP com o seguinte comando:
“pure-FTPd -B -E –A –l mysql:/etc/pureFTPd-mysql.conf &”
Desta forma impedimos a entrada de utilizadores não registados (-E), efectuamos o
chroot a todos os utilizadores (-A) impossibilitando que estes acedam a directórios acima
77/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
daquele que foi definido como directório base para a sua conta. Definimos ainda, que para
efeitos de accounting (login) (-l) se utiliza a base de dados mysql com o ficheiro de configuração
criado no ponto 1. Optamos também por activar o modo de operação em background (-B).
4.5.3. Instalação e descrição do phpMyAdmin
Optamos por instalar o phpMyAdmin que é uma aplicação web utilizada para operar
sobre as tabelas da base de dados MySQL. A instalação desta ferramenta tem como objectivo
principal facilitar a gestão dos dados contidos nessas tabelas.
Para instalarmos o phpMyAdmin necessitamos do servidor HTTP Apache e da sua
extensão php.
Podemos aceder ao phpMyAdmin através do endereço:
HTTP://193.136.93.220/MyAdmin
No entanto, o acesso é restrito. Os dados de acesso são iguais aos utilizados para
aceder à base de dados MySQL no modo consola.
A página principal do phpMyAdmin está apresentada a seguir:
Figura 43 - phpMyAdmin
4.5.4. Criação do portal web
Para facilitarmos o acesso aos vídeos alojados no servidor FTP, criamos uma página
web utilizando o programa dreamweaver. A partir desta página é possível aceder a um servidor
FTP, desde que tenhamos as credenciais necessárias (username e password) para
autenticação.
78/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
Inicialmente tinhamos 2 páginas: index.php e redirect.php. Os dados eram introduzidos
na página index.php e recolhidos pela página redirect.php que os utilizava para aceder ao
directório pessoal do utilizador que se autenticou.
O portal web inicialmente criado está representado na figura 44:
Figura 44 - Portal Web (Página índex.php)
Optamos por introduzir uma nova funcionalidade no portal web. Alteramos a página
principal de modo a permitir ao utilizador visualizar os N primeiros vídeos em simultâneo. Deste
modo o utilizador ficará a saber mais rapidamente o que se passa, uma vez que não necessitará
de aceder ao servidor FTP para assistir a cada um dos vídeos individualmente.
O novo portal web e uma amostra da nova funcionalidade introduzida encontram-se nas
figuras 45 e 46 respectivamente.
79/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
Figura 45 - Portal Web Melhorado (Página índex.php)
80/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
Figura 46 – Visualização de 3 vídeos em simultâneo
(por razões relacionadas com a qualidade dos vídeos optamos por mostrar 3 vídeos não
consecutivos)
O código associado à introdução dos campos para a autenticação dos utilizadores,
acesso ao servidor FTP e disponibilização dos conteúdos vídeo, referentes às páginas
index.php, redirect.php e redirect2.php está presente no anexo 9.3.
81/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
4.5.5. Análise do funcionamento do Centro de Serviços
Na figura 47, encontra-se o conteúdo de um ficheiro gerado pelo Active Webcam que
regista a actividade do programa.
Figura 47 – Registo da actividade do Active WebCam
Os ficheiros de vídeo são criados em formato .mpeg com uma duração de
aproximadamente 1min cada. Podemos verificar que após a criação dum ficheiro, é feito o
respectivo upload, sendo o ficheiro imediatamente enviado para o servidor FTP.
Com vista a verificarmos o modo de acesso ao servidor FTP, utilizamos o ethereal para
realizar algumas capturas.
Na figura 48, estão apresentados os principais pacotes capturados quando um utilizador
válido no terminal (193.136.93.207) tenta aceder ao servidor FTP (193.136.93.220).
Podemos verificar que após a iniciação da ligação TCP por parte do utilizador, este envia
os seus dados para efeitos de autenticação (primeiro username e depois password) aos quais o
servidor responde com um ACK indicando que os dados enviados estão correctos e que portanto
está na presença de um utilizador válido. De seguida, é dada permissão ao utilizador para
aceder aos conteúdos presentes no seu directório pessoal.
82/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
Figura 48 - Principais pacotes capturados
Na figura 49 é feita referência ao conteúdo do pacote POST. Este pacote contém a
informação de autenticação: username (“JoeUser”) e password (“qwerty”) que foi introduzida na
página principal (índex.php) pelo utilizador para acesso ao servidor FTP. Verificamos que esta
informação não se encontra codificada, e portanto não confere a segurança desejada ao nosso
sistema. No entanto, este problema é facilmente resolvido através da utilização de um servidor
secure FTP ou através da introdução de um mecanismo de codificação de dados.
Figura 49 - Conteúdo do POST
Na figura 50 está representado o conteúdo do pacote associado à página redirect.php.
Podemos ver qual o tratamento dado pela página redirect.php aos dados que acabou de receber.
Verificamos que é feito um reencaminhamento para o link:
ftp://username:password@endereçodoservidor
ou seja
ftp://JoeUser:[email protected] (neste caso).
83/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
Figura 50 - Conteúdo do pacote associado à página redirect.php
Verificamos ainda qual o comportamento do servidor quando um utilizador se tenta
autenticar utilizando outros dados que não os correctos. A figura 51 retrata essa situação.
Verificamos que apesar de tanto o username como a password estarem errados, só após o envio
da password é que o servidor impede definitivamente a ligação através do envio de um “530
Login authentication failed”.
Figura 51 - Principais pacotes capturados quando as credenciais não são válidas
84/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
5. PRINCIPAIS DIFICULDADES
Foram algumas as dificuldades com que nos deparamos ao longo da realização de todo
este projecto.
Alguns problemas apareceram logo no decorrer do 1ºsemestre com a realização do
trabalho de pesquisa. Apesar de termos alguns conhecimentos teóricos a nível de protocolos de
rede, sentimos alguma dificuldade em seleccionar a informação que era, de facto, relevante e a
compreender os modos de funcionamento de algumas tecnologias e técnicas de autenticação.
Também constatamos alguma falta de informação na Internet sobre determinados assuntos,
como por exemplo, aspectos relacionados com a actual oferta de serviços residenciais.
Apesar de todo esse trabalho ser necessário para a aquisição de algumas bases para o
desenvolvimento do projecto, sentimos que a falta de experiência em termos práticos foi a
principal causa de todos os problemas que tivemos relacionados com a selecção de informação.
Com o início da realização do projecto propriamente dito deparamo-nos com outro tipo
de dificuldades de carácter sobretudo prático. Para essas dificuldades muito contribuiu a nossa
falta de experiência em Linux. Também o facto de nunca termos trabalhado directamente com
servidores e respectivos ficheiros de configuração não ajudou à transposição desses problemas.
No que diz respeito ao freeRADIUS, as poucas dificuldades que tivemos, estiveram
relacionadas com a compreensão do seu funcionamento, nomeadamente com a manipulação
dos seus ficheiros de configuração.
Relativamente ao servidor Dynamic DNS, a principal dificuldade esteve relacionada com
a procura de um servidor Dynamic DNS que cumprisse todos os requisitos por nós impostos.
Acabamos mesmo por ter que utilizar dois servidores a funcionar em conjunto para que o
comportamento obtido fosse o pretendido. Tivemos ainda algumas dificuldades com a instalação
do BIND que, no entanto, acabaram por ser superadas.
A fase relacionada com o SIP Express Router foi uma das que deu mais trabalho.
Apesar da instalação e configuração básica do SER ter decorrido sem grandes problemas, o
estabelecimento de sessões já não foi assim. O maior desses problemas esteve relacionado com
a configuração da placa de som de um dos PCs. Estivemos muito tempo de volta dessa questão
e acabamos mesmo por não a conseguir resolver. Foram muitas as soluções tentadas mas
infelizmente sem grandes resultados. Outra questão que levantou muitos problemas esteve
relacionada com o SIP ALG. A sua introdução no cenário originava um “Kernel Panic” na
residential gateway sempre que os clientes SIP (público e privado) tentavam comunicar entre si.
Após recompilarmos várias vezes o kernel e consultarmos fóruns e outras fontes de informações,
descobrimos que apenas um restrito conjunto de versões do kernel funcionavam correctamente
com o módulo SIP ALG. Só assim conseguimos resolver o problema. Ainda no âmbito do SER,
tivemos algumas dificuldades no estabelecimento da correspondência entre o username de
registo e o URI utilizado no estabelecimento de sessões. O módulo avpops.so acabou por se
revelar um pouco complicado de manusear e sem grande utilidade em termos práticos uma vez
que a noção de sala de conferência não servia para o que pretendíamos tal como foi explicado
na secção anterior. Também não chegamos a conseguir instalar a ferramenta serweb que
permite interagir graficamente com o ser o que seria útil pois facilitaria possíveis alterações em
termos de configuração.
As últimas dificuldades estiveram relacionadas com a criação de um centro de serviços e
de um portal web que funcionasse como alternativa ao cenário desenvolvido em torno do SER.
Mais concretamente, tentamos encontrar um cliente SIP baseado em web mas o único existente
que permitia a utilização do SER (SIP communicator construído em Java e ainda em fase de
desenvolvimento) acabou por não corresponder às nossas expectativas, revelando-se
complicado para o utilizador comum. Também a falta de tempo não nos permitiu criar um portal
85/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
com um maior número de funcionalidades à semelhança do que acontece com um centro de
serviços habitual.
86/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
6. POSSÍVEIS MELHORAMENTOS
Após a realização de todo o trabalho, considerámos útil analisar quais os pontos que
necessitam de ser melhorados, assim como a aplicabilidade do nosso projecto e possíveis
interacções com outros trabalhos.
Ao analisarmos todo o trabalho verificamos que apesar do “centro de serviços” funcionar
correctamente e fornecer a segurança necessária ao serviço disponibilizado, seria interessante
efectuar algumas modificações. Tudo o resto ficou a funcionar de acordo com as expectativas
iniciais o que não significa que não possa ainda vir a ser melhorado. No entanto, acreditamos
que o funcionamento desses elementos apresenta desde já um grau de complexidade adequado
ao tipo de projecto e seus objectivos.
No que diz respeito ao “centro de serviços”, acreditamos que nomeadamente o portal
web pode ser melhorado através da introdução de novas funcionalidades que o tornem mais
completo e “user friendly”.
Seria interessante efectuar um levantamento de possíveis interacções com outros
projectos já desenvolvidos. Por exemplo, poderia ser proveitoso efectuar uma análise em termos
da qualidade de serviço existente em função do número de utilizadores de forma a avaliar a
capacidade da plataforma.
Um outro aspecto que poderia ser explorado era o da encriptação de informação, uma
vez que num cenário de vídeo vigilância é essencial que os dados sejam transmitidos de uma
forma segura de forma a não poderem ser acedidos por terceiros. Um estudo relacionado com
as técnicas de segurança passíveis de serem aplicadas, assim como principais vantagens e
inconvenientes dessas mesmas técnicas poderia também ser útil.
Seria ainda interessante analisarmos em termos práticos outros métodos para a
resolução dos problemas causados pelo NAT para além do SIP ALG.
A implementação de soluções práticas que funcionassem como alternativa à solução por
nós adoptada facilitaria a obtenção de conclusões importantes em termos de requisitos mínimos,
robustez, flexibilidade e desempenho.
87/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
88/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
7. CONCLUSÕES / NOTAS FINAIS
Um dos maiores benefícios proveniente da realização de um projecto é sem dúvida a
aquisição de conhecimentos e as conclusões que dele se podem retirar. Deste modo, é
importante enumerar o que de mais importante podemos concluir com todo este trabalho.
Em primeiro lugar convém referir que de uma maneira geral, os objectivos associados à
realização deste projecto foram atingidos. Conseguimos desta forma projectar, desenvolver e
testar com sucesso um cenário de vídeo-vigilância sem ignorarmos alguns problemas habituais
para a maioria dos utilizadores, como a existência de redes privadas, a necessidade de
segurança, a facilidade de acesso ao serviço, entre outros.
Em termos de autenticação, verificamos que definitivamente, tal como pensávamos de
início, o freeRADIUS é uma boa solução. Este servidor freeware e open source possui tudo
aquilo que é necessário a um servidor de autenticação e ainda um conjunto de funcionalidades
extra que nem todos os servidores, mesmo comerciais, possuem. A utilização de uma base de
dados para armazenamento da informação associada aos utilizadores freeRADIUS é
definitivamente mais cómoda que a utilização dos ficheiros de configuração que o freeRADIUS
disponibiliza. Dentro das diversas bases de dados suportadas, verificamos que o mySQL acaba
por ser bastante acessível para quem tem pouca experiência, pelo menos no que diz respeito às
operações básicas de criação de tabelas, inserção e remoção de utilizadores, alteração de
atributos, entre outros.
Relativamente ao servidor Dynamic DNS, verificamos que este é sem dúvida uma mais
valia. A sua introdução no cenário criado permite-nos utilizar nomes em alternativa a endereços
IP mesmo quando estes não são estáticos. Desta forma, temos um sistema adaptado à
atribuição dinâmica de endereços IP e ao mesmo tempo cómodo para o utilizador que não
precisa de se preocupar com esses mesmos endereços. A solução adoptada (mhDNS e Bind a
funcionarem em parceria) foi, no nosso entender, a melhor de entre as soluções existentes. Com
a implementação desta solução para a resolução da questão do Dynamic DNS, o sistema
passou a ser capaz de responder com eficácia e rapidez às alterações dinâmicas dos endereços
IP. Para além disso asseguramos ainda a segurança necessária através da utilização de um
mecanismo baseado em passwords encriptadas.
No que diz respeito ao servidor SER, verificamos que este funciona à base de módulos
que são adicionados ao ficheiro de configuração, que disponibilizam funções as quais devemos
aplicar de acordo com a utilização que queremos fazer do servidor. Ficamos a saber que este
tem a capacidade de utilizar a base de dados MySQL para efeitos de gestão de logins,
passwords e URIs. Vimos que é possível reservar certos URIs para determinados utilizadores,
sendo mesmo possível fixar um URI a um utilizador. Para além disso é possível impedir que
utilizadores não autorizados no nosso servidor efectuem INVITEs para utilizadores nele
registados. No que diz respeito ao SIP ALG, podemos concluir que este se comporta como um
módulo que opera ao nível do kernel e que em cooperação com as iptables faz na residential
gateway a verificação e ajuste dos endereços IP dos pacotes SIP de acordo com os endereços
IP do cabeçalho IP. Verificamos que de facto, a utilização do SIP ALG permite resolver os
problemas relacionados com os endereços IP dos pacotes SIP utilizados na comunicação com
clientes que se encontram em redes privadas. Analisando as várias alternativas para a resolução
do problema do NAT, verificamos que a utilização do SIP ALG acabou por não ser uma má
escolha. Apesar deste método se encontrar ainda numa fase de desenvolvimento, não apresenta
grandes desvantagens em relação aos restantes métodos, antes pelo contrário. A principal
dificuldade relacionada com a introdução do SIP ALG está associada à instalação de novos
módulos do kernel, o que se pode revelar um pouco complicado para utilizadores que não se
sintam confortáveis em ambiente Linux.
89/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
Ainda acerca do SIP, concluímos que é complicado encontrar clientes SIP freeware que
suportem vídeo e que utilizem o servidor SER.
Relativamente à implementação do centro de serviços, verificamos que os clientes SIP
“web-based” não facilitam o estabelecimento de sessões por parte do utilizador comum,
acabando mesmo por ser mais complicados. A utilização dum servidor FTP para
armazenamento dos conteúdos pareceu-nos uma boa solução, apesar de em muitos casos a
segurança não ser a desejável (uma vez que as credenciais são enviadas sem qualquer tipo de
encriptação) a não ser que se utilize um servidor secure FTP ou algum tipo de encriptação
suplementar. Verificamos que o programa Active WebCam foi uma escolha acertada uma vez
que não nos impôs qualquer tipo de limitação, antes pelo contrário.
Comparando as duas hipóteses de acesso aos conteúdos multimédia (SIP SER e portal
web), verificamos que ambas acabam por ter um grau de complexidade em termos de utilização
semelhante. Enquanto que a solução baseada no SER permite a visualização em directo do
vídeo, o acesso via web apesar de não o suportar, fornece um outro tipo de funcionalidades, que
fazem com que seja possível assistir aos conteúdos em qualquer instante e em qualquer lugar
sem ser necessário um cliente SIP.
90/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
8. BIBLIOGRAFIA / REFERÊNCIAS
A principal fonte de informação utilizada no decorrer da realização do projecto foi a
Internet. Alguns sites considerados mais importantes podem ser encontrados a seguir:
Documentação da CISCO
HTTP://www.cisco.com/univercd/cc/td/doc/cisintwk/index.htm
Tecnologia FWA
HTTP://www.multitel.co.ao/wireless2.htm
www.fe.up.pt/~mleitao/ST2/Teoricas/ST2_FWA.pdf
Ofertas serviços residenciais
HTTP://www.artelecom.pt/residencial.php
HTTPs://www.ptcasasegura.pt/PortalDomotica/default.aspx?op=desc_servico&s=632883
167964531250
HTTP://www.optimus.pt/Site+Optimus/Empresas/Optimus/Press+Releases/Press200509
20.htm
HTTP://www.vodafone.pt/empresaseprofissionais/commoveis/MobileConnectedOffice/def
ault.htm
HTTP://tek.sapo.pt/4O0/571750.html
HTTP://www.necportugal.pt/index.php?object=2216&article=5048&section=467
Linux
HTTP://www.vivaolinux.com.br
HTTP://wwwnew.mandriva.com
FreeRADIUS
HTTP://www.freeradius.org
MySQL – The world’s most popular open source database
HTTP://www.mysql.com/
mhDNS
HTTP://www.htoc.com/mhdns
SIP Express Router
HTTP://www.iptel.org/ser
Módulo avpops.so
HTTP://www.voice-system.ro/docs/avpops/
Módulo permissions.so
HTTP://www.voip-info.org/wiki/view/SER+module+permissions
HTTP://openser.org/docs/modules/devel/permissions.html
Outros módulos relevantes
HTTP://openser.org/docs/modules/devel/uri_db.html
HTTP://openser.org/docs/modules/devel/auth_db.html
TCP/IP - NAT
HTTP://www.imasters.com.br/artigo/3202
91/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
SIP Firewall and NAT Traversal
HTTP://www.SIPCenter.com/SIP.nsf/html/SIP+Firewall+and+NAT+Traversal
Iptables
HTTP://www.siliconvalleyccie.com/linux-hn/iptables-intro.htm#_Toc92808862
Active WebCam Deluxe
HTTP://www.pysoft.com/
Fastream NETFile FTP/Web Server 8.2.7
HTTP://www.freedownloadmanager.org/downloads/secure_FTP_server_software/
Smart FTP client
HTTP://www.smartFTP.com
Pure FTPd
HTTP://www.pureFTPd.org/project/pure-FTPd
Web Based SIP phone
SIP Communicator - the Java VoIP and Instant Messaging client
HTTPs://SIP-communicator.dev.java.net/
Microappliances SIP Phone (ActiveX)
HTTP://www.microappliances.com/site/html/index.php?section=Products&page=
SIPphone.php
Web Integration of SIP Services (Click-to-Dial)
HTTP://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch06s02.html
92/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
9. ANEXOS
9.1. Ficheiros de configuração do freeRADIUS
9.1.1. Radiusd.conf
# inicio radiusd.conf
prefix = /usr/local/src
exec_prefix = ${prefix}
sysconfdir = ${prefix}/etc
localstatedir = ${prefix}/var
sbindir = ${exec_prefix}/sbin
logdir = ${localstatedir}/log/radius
raddbdir = ${sysconfdir}/raddb
radacctdir = ${logdir}/radacct
confdir = ${raddbdir}
run_dir = ${localstatedir}/run/radiusd
# variáveis definidas na instalação, essas opções
# foram disponibilizadas para que você não precise
# recompilar para mudar os arquivos de lugar
# você pode usar essas variáveis quando definir o
# valor de algum parâmetro ao longo desse arquivo.
log_file = ${logdir}/radius.log
# arquivo de log principal, nesse arquivo ficarão
# todas as mensagem de erro, tentativas de
# conexão, etc...
libdir = ${exec_prefix}/lib
# pasta de bibliotecas, se elas
# se encontrarem em varias pastas,
# separe as localizações
# por : , tipo: libdir = /usr/lib:/usr/local/lib
pidfile = ${run_dir}/radiusd.pid
# arquivo onde será armazenado o id
# do processo principal do freeradius
user = nobody
group = nobody
# definição do utilizador e grupo dos processos filhos do radiusd
# se você não especificar, o utilizador que deu partida
# será usado (root), se
# você usar o arquivo /etc/shadow para autenticação,
# defina o grupo como shadow, vale lembrar
# que o utilizador que executa o radiusd deve ter permissão
# de escrita no diretório de log
93/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
max_request_time = 30
# define o tempo que o processo filho segura o pedido,
# caso o tempo limite seja atingido, o servidor retorna
# acesso negado. Por exemplo: se você define 2 segundos
# e usa um banco de dados mysql sobrecarregado que demora
# 5 segundos para concluir uma pesquisa, seu servidor nunca
# vai dar acesso a ninguém!
delete_blocked_requests = no
# se no parâmetro max_request_time você
# definiu o valor 30 segundos, e o cliente
# perdeu a paciência e enviou outra solicitação sem
# ter concluído a primeira,
# o freeradius não ficara fazendo trabalho
# repetitivo simultaneamente. Se você definir
# esse parâmetro como yes, ao chegar a segunda
# requisição do mesmo cliente com a mesma
# "pergunta", ele desistirá da primeira para
# atender a nova solicitação.
cleanup_delay = 5
# esse valor funciona da seguinte maneira:
# se o NAS ou RAS enviou uma pergunta e
# a resposta foi perdida na rede, o NAS tornará
# fazer a pergunta, todo o processo de autenticação
# será realizado novamente. Para evitar isso o freeradius
# manter a resposta no cache pelo tempo definido aqui
# (em segundos), assim, se o pacote resposta for perdido
# e a pergunta for repetida, a resposta será idadosta,
# usando assim o mínimo de processamento.
max_requests = 1024
# define o número máximo de
# requisições que o freeradius pode atender
# simultaneamente, somando todas as requisições
# atendidas pelos processos filhos, assim,
# se você tem 4 processo filhos, cada um
# poderá atender 256 perguntas simultaneamente
# ATENÇÃO: as respostas cacheadas pela opção
# cleanup_delay são contabilizadas. Se você colocou
# cleanup_delay com um valor alto, seu radius
# ficará exposto a um DOS
bind_address = *
# isso fará o freeradius escutar em
# um endereço especifico, * inclui todos
# os endereços ip do host, você pode
# usar um FQDN, mas antes tenha certeza
# de que a resolução de dns estará disponível
94/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
# no momento em que o servidor radius inicia
port = 0
# porta de escuta. Equipamentos antigos tem a porta
# 1645 como padrão de autenticação e 1646 como
# contabilidade. A RFC 2138 mudou essa porta para
# 1812 autenticação e 1813 contabilidade. Equipamentos
# novos provavelmente terá essa porta como padrão.
# 0 (zero) fará com que a porta seja pesquisada
# em /etc/services, esse parâmetro pode ser
# sobreposto pela opção -p do comando radiusd
#listen {
# ipaddr = *
# endereço ip ou FQDN, mesmos critérios
# usados em bind_address
# port = 0
# porta de escuta, mesmos critérios
# usados em port
# Type of packets to listen for.
# Allowed values are:
# auth listen for authentication packets
# acct listen for accounting packets
#
# type = auth
# tipo de escuta:
# auth -> autenticação
# acct -> contabilidade
#}
# Se você quiser que o freeradius escute
# a porta de autenticação em um ip, e
# a porta de contabilidade em outro, ou
# em postas distantes no mesmo ip, o
# modelo acima de listagem será útil
# Esse recurso apareceu a partir da versão
# 1.0 e resolve o problema se você
# tem equipamentos novos e antigos
# servidos pelo mesmo radius
hostname_lookups = no
# define se o nome DNS dos clientes
# será pesquisado a partir do ip. Se definir como yes,
# toda vez que uma requisição chegar de
# um endereço ip, o freeradius irá consultar
# o dns para usar o nome no log de atividades.
# o valor no é a melhor opção, não sobrecarrega
# o servidor DNS
allow_core_dumps = no
95/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
# ative essa opção para depurar erros no
# servidor, caso contrario deixe como está
regular_expressions = yes
extended_expressions = yes
# ativa ou desativa expressões regulares
# nos parâmetros dos pacotes, desativar
# é uma boa idéia embora o padrão seja
# yes
log_stripped_names = no
# registra nos logs os dados completos do
# campo User-Name do pacote de autenticação,
# se definido como yes, do jeito que chegar,
# será usado.
log_auth = no
# deseja logar atividades de autenticação?
# se você tem milhares de clientes logando
# simultaneamente, significa
# que seu log vai crescer muito com essa
# opção ativa. Eu sempre coloco yes pois
# fica fácil e rápido descobrir por que
# certo cliente (leigo) não consegue autenticar
log_auth_badpass = no
# Logar senhas quando a autenticação falhar?
# embora seja útil para dar suporte - utilizador
# digitando senha incorretamente (branco, maiúsculas, etc...),
# a privacidade do utilizador fica reduzida e uma brecha de segurança,
# todas as senhas serão registradas no log
log_auth_goodpass = no
# idêntica a opção acima, porém se
# aplica para autenticações bem sucedidas.
usercollide = no
lower_user = no
lower_pass = no
# essas duas opções são muito importantes:
# se o utilizador deixar o CapsLock ligado,
# significa que não conseguirá se autenticar
# e isso significa uma insatisfação ou uma
# chamada desnecessária no suporte.
# Temos 3 opções: after, before e no
# suponhamos que eu informe meu login: PatrickBrandao
# "after" fará com que a autenticação
# seja primeiro testada com o valor
# informado, se falhar, aplica um lowercase
96/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
# nos valores e tenta novamente. Sendo a primeira
# tentativa com "PatrickBrandao" e a segunda com "patrickbrandao"
# "before" fará com que um lowercase seja
# aplicado antes de pesquisar a base de
# dados, que receberá "patrickbrandao"
# "no" desativa esse efeito passando para
# a base de dados o mesmo valor recebido: "PatrickBrandao"
nospace_user = no
nospace_pass = no
# as duas opções acima
# servem para retirar espaços de nome
# de utilizador e senha. Os seus clientes
# podem, sem perceber, colocar
# um espaço no final ou no começo
# das credenciais, o que gera uma
# chamada desnecessária no suporte técnico
# três valores poderão ser escolhidos:
# after, before e no
checkrad = ${sbindir}/checkrad
# comando ao usar para checar conexões simultâneas
# sessão de segurança ---------------------------security {
max_attributes = 200
# define o número máximo de atributos
# num pacote enviado para o servidor.
# um número muito baixo faria o servidor
# negar pacotes, número muito alto deixará
# o servidor vulnerável. O atacante pode emitir
# um pedido com um número exagerado
# de parâmetros e esgotar os recursos de memória
reject_delay = 1
# define o tempo de espera antes de enviar
# uma resposta de acesso negado.
# essa opção proteje seu servidor
# contra ataques de força bruta
# Escolha de 0 a 5, 0 (zero) fará com que
# a resposta seja enviada idadostamente
}
status_server = no
# permite ou nega o envio de pacotes
# de status do utilizador. Não é muito importante
# mas alguns NAS's com keep-alive podem
# precisar desse recurso para checar o
# status de uma sessão.
97/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
# sessão de proxy -----------------------------proxy_requests = yes
$INCLUDE ${confdir}/proxy.conf
# configuração de clientes NAS --------------$INCLUDE ${confdir}/clients.conf
# quando falo de clientes NAS não
# estou me referindo a seus clientes de
# conexão discada, mas sim aos dispositivos
# em contato com eles que se encarregam de
# procurar o radius para validar o utilizador,
# esses equipamentos podem ser RAS como
# cyclades, cisco, etc... ou mesmo serviços
# em qualquer servidor que se baseia numa
# autenticação com radius
# sessão de snmp ---------------------------snmp = no
$INCLUDE ${confdir}/snmp.conf
# ativa o suporte a monitoramento por snmp
# no freeradius
# configuração de processos filhos -----------------------thread pool {
start_servers = 5
# número de processos filhos a serem criados quando
# o serviço for iniciado
max_servers = 32
# número máximo de processos filhos
# atendendo solicitações
min_spare_servers = 3
max_spare_servers = 10
# regula o número de processos para manter
# um bom desempenho
}
max_requests_per_server = 0
# número máximo de solicitações feitas
# a um processo filho antes de ser destruído
# 0 (zero) para infinito, mas não recomendável
# pois um processo filho pode consumir recursos
# que nunca irá liberar, 250 é um bom valor.
98/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
# sessão de definição de módulos ----------------------modules {
# formato:
# name [ instance ] {
#
config_item = value
#
...
# }
# name -> se refere ao nome do
# modulo rlm_?????, muitos módulos
# são fornecidos com o freeradius, esse
# recurso permite que você crie seus próprios
# módulos.
pap {
encryption_scheme = crypt
}
# define o tipo de
# criptografia usada na autenticação PAP
# valores disponíveis:
# clear: sem criptografia, texto plano
# crypt: criptografia do unix
# md5: criptografia MD5
# sha1: criptografia SHA1
# padrão: crypt
chap {
authtype = CHAP
}
# adiciona suporte a autenticações
# usando CHAP
pam {
pam_auth = radiusd
}
# suporte PAM dos sistemas unix, configura
# o pamd em /etc/pam.d/ para usar esse tipo
# de autenticação
# autenticação baseada nas credenciais do sistema
# /etc/passwd e /etc/shadow
unix {
cache = no
# criar caches de dados de login?
# habilitar essa opção pode melhorar
99/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
# o desempenho se você tem muitos
# utilizadors de sistema
cache_reload = 600
# tempo em segundos para recarregar
# o cache de logins do sistema
# define a localização dos seus
# arquivos de autenticação de sistema
# encontra-se comentado, usando o
# valor padrão
#
# passwd = /etc/passwd
# shadow = /etc/shadow
# group = /etc/group
radwtmp = ${logdir}/radwtmp
}
# Extensible Authentication Protocol
$INCLUDE ${confdir}/eap.conf
# Micro$oft CHAP authentication
# esses módulos suportam MS-CHAP e MS-CHAPv2
mschap {
authtype = MS-CHAP
# protocolo M$ usado
#use_mppe = no
#require_encryption = yes
#require_strong = yes
#with_ntdomain_hack = no
#ntlm_auth = "/path/to/ntlm_auth --request-nt-key --username=%{Stripped-User-Name:%{User-Name:-None}} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NTResponse:-00}"
}
# Lightweight Directory Access Protocol (LDAP)
# permite usa autenticação LDAP (Auth-Type := LDAP)
ldap {
server = "ldap.your.domain"
# identity = "cn=admin,o=My Org,c=UA"
# password = senhadnaqui
basedn = "o=My Org,c=UA"
filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"
# base_filter = "(objectclass=radiusprofile)"
start_tls = no
# coloque yes se deseja usar tls para criptografar
# os dados nas conexões com o LDAP e
# configure e descomente os valores abaixo
100/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
# tls_cacertfile = /path/to/cacert.pem
# tls_cacertdir
= /path/to/ca/dir/
# tls_certfile
= /path/to/radius.crt
# tls_keyfile
= /path/to/radius.key
# tls_randfile
= /path/to/rnd
# tls_require_cert = "demand"
# default_profile = "cn=radprofile,ou=dialup,o=My Org,c=UA"
# profile_attribute = "radiusProfileDn"
access_attr = "dialupAccess"
dictionary_mapping = ${raddbdir}/ldap.attrmap
# define o arquivo de mapas de atributos
# do seu diretorio
ldap_connections_number = 5
# password_header = "{clear}"
# password_attribute = userPassword
# groupname_attribute = cn
# groupmembership_filter = "(|(&(objectClass=GroupOfNames) (member=%{Ldap-UserDn}))
(&(objectClass=GroupOfUniqueNames) (uniquemember=%{Ldap-UserDn})))"
# groupmembership_attribute = radiusGroupName
timeout = 4
timelimit = 3
net_timeout = 1
# compare_check_items = yes
# do_xlat = yes
# access_attr_used_for_allow = yes
}
# ---------------------------------------# modulo Realm, para proxy
# 'realm/username'
realm IPASS {
format = prefix
delimiter = "/"
ignore_default = no
ignore_null = no
}
# 'username@realm'
realm suffix {
format = suffix
delimiter = "@"
ignore_default = no
ignore_null = no
}
# 'username%realm'
realm realmpercent {
format = suffix
101/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
delimiter = "%"
ignore_default = no
ignore_null = no
}
# 'domain\user'
realm ntdomain {
format = prefix
delimiter = "\\"
ignore_default = no
ignore_null = no
}
checkval {
item-name = Calling-Station-Id
check-name = Calling-Station-Id
data-type = string
#notfound-reject = no
}
# reescrita de pacotes. Usado para autorização e contabilidade
#attr_rewrite sanecallerid {
# attribute = Called-Station-Id
# may be "packet", "reply", "proxy", "proxy_reply" or "config"
# searchin = packet
# searchfor = "[+ ]"
# replacewith = ""
# ignore_case = no
# new_attribute = no
# max_matches = 10
# ## If set to yes then the replace string will be appended to the original string
# append = no
#}
preprocess {
huntgroups = ${confdir}/huntgroups
hints = ${confdir}/hints
with_ascend_hack = no
ascend_channels_per_line = 23
with_ntdomain_hack = no
with_specialix_jetstream_hack = no
with_cisco_vsa_hack = no
}
files {
usersfile = ${confdir}/users
acctusersfile = ${confdir}/acct_users
compat = no
}
102/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
detail {
detailfile = ${radacctdir}/%{Client-IP-Address}/detail-%Y%m%d
detailperm = 0600
}
# detail auth_log {
# detailfile = ${radacctdir}/%{Client-IP-Address}/auth-detail-%Y%m%d
# detailperm = 0600
#}
# detail reply_log {
# detailfile = ${radacctdir}/%{Client-IP-Address}/reply-detail-%Y%m%d
# detailperm = 0600
#}
# detail pre_proxy_log {
# detailfile = ${radacctdir}/%{Client-IP-Address}/pre-proxy-detail-%Y%m%d
# detailperm = 0600
#}
# detail post_proxy_log {
# detailfile = ${radacctdir}/%{Client-IP-Address}/post-proxy-detail-%Y%m%d
# detailperm = 0600
#}
acct_unique {
key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port"
}
# Para Postgresql, use:
${confdir}/postgresql.conf
# Para MS-SQL, use:
${confdir}/mssql.conf
# For Oracle, use:
${confdir}/oraclesql.conf
#
$INCLUDE ${confdir}/sql.conf
# inclusão de arquivo de configuração contendo
# módulos de autenticação, sessão e contabilidade
# controlados em banco de dados SQL
# módulos responsáveis por controlar utilizadors ligados
# para evitar conexão simultânea quanto esta é
# usada
radutmp {
filename = ${logdir}/radutmp
username = %{User-Name}
case_sensitive = yes
check_with_nas = yes
perm = 0600
callerid = "yes"
}
radutmp sradutmp {
filename = ${logdir}/sradutmp
perm = 0644
callerid = "no"
}
103/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
attr_filter {
attrsfile = ${confdir}/attrs
}
counter daily {
filename = ${raddbdir}/db.daily
key = User-Name
count-attribute = Acct-Session-Time
reset = daily
counter-name = Daily-Session-Time
check-name = Max-Daily-Session
allowed-servicetype = Framed-User
cache-size = 5000
}
always fail {
rcode = fail
}
always reject {
rcode = reject
}
always ok {
rcode = ok
simulcount = 0
mpp = no
}
expr {
}
digest {
}
exec {
wait = yes
input_pairs = request
}
exec echo {
wait = yes
program = "/bin/echo %{User-Name}"
input_pairs = request
output_pairs = reply
#packet_type = Access-Accept
}
ippool main_pool {
range-start = 192.168.1.1
range-stop = 192.168.3.254
netmask = 255.255.255.0
cache-size = 800
session-db = ${raddbdir}/db.ippool
ip-index = ${raddbdir}/db.ipindex
override = no
maximum-timeout = 0
}
104/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
}
# controle de acesso, sessão e contabilidade ----------# sessão instantiate - inicia módulos, se não for usar, não inicie.
instantiate {
exec
expr
# daily
}
# sessão authorization - controla os módulos
# responsáveis por autorizar o acesso das
# requisições
authorize {
preprocess
# auth_log
# attr_filter
chap
mschap
# digest
# IPASS
# suffix
# ntdomain
# eap
# files
sql
# etc_smbpasswd
# ldap
# daily
# checkval
}
# Sessão authentication
# responsável por conferir o tipo de autenticação usado
authenticate {
Auth-Type PAP {
pap
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap
}
# digest
105/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
#
#
#
#
#
#
}
pam
unix
Auth-Type LDAP {
ldap
}
eap
# Sessão Pre-accounting. Decide qual tipo de contabilidade usar
preacct {
# preprocess
# acct_unique
# home server as authentication requests.
# IPASS
# suffix
# ntdomain
#
# Read the 'acct_users' file
# files
}
# Sessao Accounting. Registra dados de contabilidade
accounting {
# detail
# daily
# unix
# radutmp
# sradutmp
# main_pool
sql
# pgsql-voip
}
# Controle de sessão
# quando se faz o controle de sessão para
# evitar conexões simultâneas (impede o
# nome de utilizador de se ligar varias vezes de
# locais diferentes ao mesmo tempo com o mesmo login)
session {
# radutmp
# sql
}
post-auth {
# main_pool
# reply_log
106/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
# sql
# Post-Auth-Type REJECT {
#
insert-module-name-here
# }
}
pre-proxy {
# attr_rewrite
# pre_proxy_log
}
post-proxy {
# post_proxy_log
# attr_rewrite
# attr_filter
eap
}
# fim radiusd.conf
9.1.2. Clients.conf
# inicio clients.conf
client 127.0.0.1 {
secret = raioceleste
# segredo do servidor. Somente
# os NAS's que conhecem esse
# segredo poderão fazer pedidos
# de autenticação. OBRIGATÓRIO
shortname = localhost
# nome do cliente. Normalmente
# você pode colocar uma parte do FQDN
# esse nome é usado no arquivo de log
# e referencias de contabilidade
# OBRIGATÓRIO
}
nastype = other
# define o tipo de NAS ó cliente.
# Muito importante pois um
# NAS especifico pode ter campos
# definidos nos arquivos de dicionários
# de parâmetros. OPCIONAL. Padrão: other
# o exemplo acima trata um cliente
# em especifico, mas você pode
# abrir uma rede inteira no freeradius
107/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
client 192.168.10.0/24 {
secret = raioceleste10
shortname = intranet-10
}
# Importante: se seu NAS não estiver cadastrado
# aqui, possivelmente você vai ver no arquivo
# de log:
# Thu Aug 12 17:06:16 2004 : Error: Ignoring request from unknown client 192.168.10.24:41747
#
# sempre que adicionar um novo cliente, você terá que reiniciar o freeradius
# fim clients.conf
108/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
9.2. Ficheiros de configuração do SIP Express Router (SER)
9.2.1. SER.cfg
#
# $Id: ser.cfg,v 1.25.2.1 2005/02/18 14:30:44 andrei Exp $
#
# simple quick-start config script
#
# ----------- global configuration parameters -----------------------#debug=3
# debug level (cmd line: -dddddddddd)
#fork=yes
#log_stderror=no
# (cmd line: -E)
/* Uncomment these lines to enter debugging mode
fork=no
log_stderror=yes
*/
check_via=no # (cmd. line: -v)
dns=no
# (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
#children=4
fifo="/tmp/ser_fifo"
# ------------------ module loading ---------------------------------# Uncomment this if you want to use SQL database
loadmodule "/usr/lib/ser/modules/mysql.so"
loadmodule "/usr/lib/ser/modules/sl.so"
loadmodule "/usr/lib/ser/modules/tm.so"
loadmodule "/usr/lib/ser/modules/rr.so"
loadmodule "/usr/lib/ser/modules/maxfwd.so"
loadmodule "/usr/lib/ser/modules/usrloc.so"
loadmodule "/usr/lib/ser/modules/registrar.so"
loadmodule "/usr/lib/ser/modules/textops.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"
loadmodule "/usr/lib/ser/modules/permissions.so"
loadmodule "/usr/lib/ser/modules/uri_db.so"
109/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
# ----------------- setting module-specific parameters --------------# -- usrloc params -#modparam("usrloc", "db_mode", 0)
# 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")
# -- rr params -# add value to ;lr param to make some broken UAs happy
modparam("rr", "enable_full_lr", 1)
# Parametros do modulo de permissoes !!
modparam("permissions", "default_allow_file", "/etc/ser/permissions.allow")
modparam("permissions", "default_deny_file", "/etc/ser/permissions.deny")
# ------------------------- request routing logic ------------------# main routing logic
route{
# initial sanity checks -- messages with
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
break;
};
# we record-route all messages -- to make sure that
110/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
if (!method=="REGISTER") record_route();
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
break;
};
if (!(uri==myself)) {
# mark routing logic in request
append_hf("P-hint: outbound\r\n");
route(1);
break;
};
# if the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
if (uri==myself)
{
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")
111/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
{
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;
};
}
lookup("aliases");
if (!(uri==myself))
{
append_hf("P-hint: outbound alias\r\n");
route(1);
break;
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location"))
{
sl_send_reply("404", "Not Found");
break;
};
};
append_hf("P-hint: usrloc applied\r\n");
route(1);
}
112/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
route[1]
{
}
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay())
{
sl_reply_error();
};
113/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
9.3. Porções de código relevantes associadas ao portal web
9.3.1. Index.php
<form id="form2" name="form2" method="post" action="redirect2.php">
<blockquote>
<p><span class="style24">Login:</span>
<input type="text" name="login2" />
<span class="style24">Password:</span>
<input type="password" name="password2" />
<span class="style23">Número de vídeos:</span>
<input type="text" name="numero_videos" />
<input type="submit" name="Submit2" value="Submit" />
</p>
</blockquote>
</form>
<form id="form1" name="form1" method="post" action="redirect.php">
<blockquote>
<p>
<span class="style24">Login:</span>
<input type="text" name="login" />
<span class="style24">Password:</span>
<input type="password" name="password" />
<input type="submit" name="Submit" value="Submit" />
</p>
</blockquote>
</form>
9.3.2. Redirect.php
<head>
<?
$link= "FTP://" . $_POST['login'] . ":" . $_POST['password'] . "@193.136.93.220/";
?>
<meta HTTP-EQUIV="Refresh" CONTENT="0; url=<? echo $link; ?>"
114/115
Serviços e Redes Residenciais
Interfaces e infra-estrutura de Suporte para Operadores e ISP
9.3.3. Redirect2.php
<?
for ($i=1; $i<=( $_POST['numero_videos'] ); $i++)
{
$location = "ftp://" . $_POST['login2'] . ":" . $_POST['password2'] . "@193.136.93.245/Record No
00" . $i . ".mpeg";// TYPE=\"video/mpeg";
?>
<OBJECT DATA="<? echo $location; ?>" TYPE="video/mpeg" TITLE="Title" WIDTH=100
HEIGHT=75>
<PARAM NAME=pluginspage VALUE="http://quicktime.apple.com/">
<PARAM NAME=autoplay VALUE=true>
</OBJECT>
<?
}
?>
115/115